Secuobs.com : 2009-07-10 06:39:25 - skeptikal.org - I've been watching the Twitter traffic pertaining to TweetMyPC So far,I've amassed a decent collection of users' screenshots, all of whichreveal private dataFirst off, I have already confirmed my previous statement:Your Twitter feed is public Even if you make it private, recentincidents with Twitter should be enough to make you consider itpublicWhen TweetMyPC posts a screenshot, it uses Twitpic to do so Thoughthe TweetMyPC documentation encourages users to make the "command"Twitter accounts private, it makes no mention of TwitPic, which is acompletely different service, and does not reflect Twitter's privacysettings This being the case, locating command Twitter accounts eventhe private ones is a simple matter of searching through Twitpic'sarchives for the string "TweetMyPC - Screenshot"While Twitpic doesn't have a search feature they've been promisingone for some time, they do have a public feed, and there are thirdparty fourth party, I suppose sites that allow you to do just thatThe next thing I learned is also a TwitPic issue a bug, perhaps Youwon't see this one on the Month of Twitter Bugs, but it turns out thatdeleted photos on TwitPic aren't actually deleted An example: TwitPicclaims that the image with the ID 9s4gx no longer exists However, ifyou go directly to the full-sized image, you'll see that you candownload the image- a screenshot of a TweetMyPC user's window'sregistryIt's worth noting that this user has indeed protected his updates onTwitter not that it did a lot of goodNow let's get to the screenshots themselvesEven the tiniest bit of information can be extremely useful to anattacker It all depends on his motivation, his expertise, and howmuch free time he has As none of this is predictable, I recommendthat you use extreme caution in posting screenshots onlineThis screenshot displays the contents of the user's Gmail account, hisGmail address, and the IP address that he is logged into Gmail fromFrom his bookmarks toolbar, we can guess what websites he visitsregularly, and from the browser's status bar, we know that he is usingGreasemonkey From the Windows XP taskbar, we can see what software heis currently running, including antivirus and instant messaging Weknow that he's not using NoScript, and that he appears to be arelatively savvy computer userI think we've got enough info to own this computer Let's move onThis guy is clearly logged into his investment management portalCombining the info in this screenshot with some of the otherinformation revealed in that user's Twitter account, and noting thatthere's an XSS hole on the investment site, I'm betting I could XSShim out of his stock portfolioWant more You just have to lookDesktop shortcuts, NoScript settings, browser history, Yahoo mailboxes,network and firewall settings, not to mention everyday activity, frompiracy to IM conversations to grocery lists, are all freely availableIMAGEhttp://www.secuobs.com/revue/news/118714.shtmlhttp://www.secuobs.com/revue/news/118714.shtml Secuobs.com : 2009-07-08 19:35:46 - skeptikal.org - Sadly, Milw0rmcom is going offline- permanently, from the sound of itStr0ke posted the following message on the site before it went dark:Well, this is my goodbye header for milw0rm I wish I had the timeI did in the past to post exploits, I just don't : For the past3 months I have actually done a pretty crappy job of gettingpeoples work out fast enough to be proud of, 0 to 72 hours takingoff weekends isn't fair to the authors on this site I appreciateand thank everyone for their support in the past Be safe, /str0keWhile it gets a bad rap for its large script kiddie user base, I'velearned a lot from the exploits on that site, and it will be missedThanks Str0keIf anybody has info about where I can get a copy of the milw0rmarchives, I'd be happy to mirror it hereIMAGEhttp://www.secuobs.com/revue/news/118100.shtmlhttp://www.secuobs.com/revue/news/118100.shtml Secuobs.com : 2009-07-06 22:13:30 - skeptikal.org - Some people just don't thinkTweetMyPC is an application you can install on your PC It will readyour Twitter feed and execute commands based on your tweets How didsomebody get all the way through writing this app without consideringwhat a supremely poor idea it is A few problems:Your Twitter feed is public Even if you make it private, recentincidents with Twitter should be enough to make you consider itpublicDo you really want the whole world to be able to view all yourscreenshotsThe entire security model of this app if it could be considered suchrelies on the idea that only you can post things to your Twitteraccount Aviv Raff and his month of Twitter bugs are proving thisevery dayWhat is wrong with people I know I'm a security guy, but seriously,think before you install remote access software for your PC From thelooks of the chatter, a lot of people are using this app alreadyRemote desktop works fine, and there's no reason to use Twitter asyour carrier Twitter is not a network protocol It's not even a greatsocial networking appEdit: I'm collecting screenshots of personal information or othersensitive data here I'll probably write a bot to do this for me soonenoughIMAGEhttp://www.secuobs.com/revue/news/117350.shtmlhttp://www.secuobs.com/revue/news/117350.shtml Secuobs.com : 2009-06-24 21:59:28 - skeptikal.org - Fun fact: When your browser parses a document, it locates and tags before evaluating the javascript within While thisappears to make sense, it creates an interesting quirk- injected tags, even within quoted javascript strings, will force itto end a block of javascript code and throw a parse error It willalso allow you to start a new block of unquoted and therefore,executed codeI put together a basic demonstration of this quirk a while ago andbounced it off a few people As it turns out, this is known behavior,and was even used in one of the first examples on RSnake's XSS CheatSheetArguably, this is not really even a bug It stems from the order inwhich the document is parsed- structure tags is handled beforeparsing javascript content I looked into the various standards thatapply and didn't see anything dictating how this behavior should behandled, but I confess I didn't look that hardAt any rate, the reason I'm writing about it today is because I foundan XSS hole in the popular URL shortener, bitly This can be used tocompromise browsing history, tamper with a user's bitly settings, andeven abuse Twitter accounts they have a Twitter APIDue to the nature of the exploit the link only works once, so I can'tsend you directly there However, if you take the following URL andmake "CHANGEME" a unique string, it should workhttp://bitly/url=http%3A%2F%2Fskeptikalorgetkeyword=%22%3C/script%3E%3Cscript%3Ealert1337%3C/script%3ECHANGEMEWhile it's generally known that putting user-supplied input intoexecutable code is a bad idea, many developers still do it, especiallywith javascript Don't assume that just because the input is wrappedin quotes, it will not be XSS-ableIMAGEhttp://www.secuobs.com/revue/news/113309.shtmlhttp://www.secuobs.com/revue/news/113309.shtml Secuobs.com : 2009-06-16 00:11:22 - skeptikal.org - As part of our recent research on CSRF attacks, Russ McRee found avulnerability in the Linksys WRT160N router Sadly, this wasn't a hugeshock to us, but what was surprising was the response from Linksys:We can’t reasonably prevent CSRF's without bogging down our codeThe compromise we had made here is to have a timeout on the webinterface, so users are logged out after 10 mins of inactivity Wehave also advised users to not click on suspicious links whilelogged in to the web interface, or close the web interface as soonas they are finished configuring the routerAs ridiculous as the entire response is, I'd like to focus on the"Don't click suspicious links" bit Most users will click on any linkyou throw at them, particularly from link-heavy social sites such asTwitter In fact, if you clicked through to this page from my Twitterpost, the page you're currently on should be at "http://skeptikalorg/a_very_suspicious_link"Why did you click itBecause you trust me And you trust Twitter And you trust my hostingcompany And your DNS servers And my DNS servers And TinyURLI could rant on this topic for a while, but I know I'd be preaching tothe choir Don't trust any links, anywhere Especially don't trust theones from TinyURL, bitly, or any other URL shortening service Youhave no way of knowing whether a site is malicious or not until youload it into your browser Even then, it's doubtful that you'd evernotice You're probably not a normal user, but most people wouldn'tever recognize real malware for what it is, especially if it'sproperly obfuscatedIn theory, a goal of never clicking a malicious link is impossible toachieve In practice though, many malicious links are fairly easy torecognize if you just look at the URL This is why sites like TinyURLallow you to preview links before being redirected to them Earliertoday, @OWASP_podcast sent out the following tweet:http://tinyurlcom/previewphpenable=1 will force all TinyURLs toappear in preview mode on your machineIt's a good idea, but this is clearly a URL that modifies userpreferences based on GET variables, and I couldn't help noticing thatthe same preference could be disabled with a bit of CSRF:I'd call this a failure on TinyURL's part, but even if you did previewthe URL, there's no guarantee the seemingly innocent link won't havemalicious content, redirects, cross-site scripting, HTML injectionholes, poorly configured DNS, poorly coded flash files, contentownership problems, compromised FTP accounts or other issuesJust keep that in mind- previewing a link is a convenience, not asecurity featureIMAGEhttp://www.secuobs.com/revue/news/110016.shtmlhttp://www.secuobs.com/revue/news/110016.shtml Secuobs.com : 2009-06-11 21:19:09 - skeptikal.org - I ran across a press release from GuestCentric Systems dated April 20, inwhich they announced their partnership with McAfee to put the McAfeeSecure logo on all their client's pagesGuestCentric offers a booking management service to independenthotels, and from the looks of things, it's actually a pretty cool appThey appear to be awfully proud of that system, and the fact that itwas certified as secure Now we all know that the McAfee Securecertificaton has serious deficiencies, but that horse doesn't appearto be dead yet, so I'll keep floggingThe video on GuestCentric's press release essentially mimics the hypefrom McAfee- put the logo on your website, watch your sales jump 14%It says nothing about the actual state of security in the app, and ispurely marketing fluff This always irritates me, but it doesn'tsurprise me Of course, it also should come as no surprise thatGuestCentric has XSS holes on their website, or that the bookingapplication itself contains XSS holes as well It also has CSRF holesand moreWhat is interesting to me in this instance is that the GuestCentricapp is almost completely AJAX While McAfee secure is terrible atfinding XSS and CSRF holes in the first place, it certainly does notparse AJAX and does not intelligently fuzz for these vulnerabilitiesShort of detecting out of date software on the server, scanning thisapplication with McAfee Secure is particularly uselessThe really amazing thing to me is that McAfee values their brand solittle Their name and logo are put on so many websites that they haveso little to do with, nobody actually trusts or in most cases, evensees their certificationMcAfee keeps citing their 14% number While I have doubts about thevalidity of that study and real data has never been released, I haveto wonder whether those numbers would be the same today Somethingtells me that the answer is a resounding "no"IMAGEhttp://www.secuobs.com/revue/news/108673.shtmlhttp://www.secuobs.com/revue/news/108673.shtml Secuobs.com : 2009-06-10 22:33:44 - skeptikal.org - The idea isn't entirely new- CSRF has been used in the past to abuseranking systems and push pageviews through the roof These attackshave a lot of applications in spamming, black hat SEO, andmanipulating site statisticsI came up with an interesting variant on this recently Instead oftrying to get as many hits as possible to a page in an ecommerce app,for example, we can force users to view a product of our choosingone we sell, of course This, in turn, will make that product pop upin his "recently viewed items" page, or, in many cases, the front pageof the site It's easy to see how this attack could be directlymonetized- putting your product on the front page of, say Amazoncom,will go a long way towards increasing its visibility and ultimately,its salesThis attack can even be targeted towards specific audiences veryeasily by sticking these history-poisoning links in domain-specificwebsites- weight loss products on weight loss forums, tech products ontech sites, etcThe important distinction is that instead of attacking the serverdirectly, we're abusing the user's session Taking it a step further,some sites allow the attacker to actually stick products in the user'sshopping cart via CSRF If you don't notice that they're there, youmay end up buying things you didn't intend If you do notice them, youstill will likely click through and view the product- effectiveadvertising, no doubtAs a proof of concept, this page will poison your browser's Amazoncomrecommendations, eBay product views, your Walmartcom shopping cart,and your Overstockcom cartCould spammers use CSRF to push their products to the front page ofyour favorite ecommerce portals You bet Would that be valuableGiven the massive amount of money people throw at the SEO andadvertising industries, I have to assume soIMAGEhttp://www.secuobs.com/revue/news/108188.shtmlhttp://www.secuobs.com/revue/news/108188.shtml Secuobs.com : 2009-06-10 05:09:52 - skeptikal.org - I've known about this for a few weeks, but it just went up on Defcon'swebsite today Russ McRee and I will be presenting at Defcon 17 in LasVegas next month The title of the presentation is "CSRF: Yeah, itstill works" If you're going to be there, I'd love to see youIMAGEhttp://www.secuobs.com/revue/news/107826.shtmlhttp://www.secuobs.com/revue/news/107826.shtml Secuobs.com : 2009-06-10 02:45:54 - skeptikal.org - StrongWebMail announced yesterday that we officially won their $10kcontest Surprisingly, they don't appear to have learned from thislast round of bad publicity and intend to launch another contest- oncethey've patched some holes and tightened the rulesAssuming that the new rules aren't ridiculously restrictive, I'llprobably participate in the next round- I've still got a few tricks upmy sleeve However, I must say I feel a bit dirty for feeding thispublicity machine These hacking contests, frankly, are a joke Ifnobody gets in, marketing will hail their product as unbreakable Ifsomebody does get in, they call foul for breaking the rules Whilesome structure is necessary for any organized contest, the whole pointof hacking is finding ways to bend rules and manipulate the systemStrongWebMail's press release said "It is important to note that thefrontend protection offered by StrongWebmailcom was not compromisedIn fact, Lance and his team were forced to find a way around the phoneauthentication" That's not entirely true- we simply took the easiestroute With the webmail app riddled with holes, we saw no point inbothering with the front end Considering it took us less than aminute from registration to find the hole we used to compromise theapp, can you blame usI understand that StrongWebMail was created to demonstrate Telesign's2-factor authentication system, but this is a perfect demonstrationthat security needs to be addressed holistically When you claim tohave "The Most Secure Email Accounts on the Planet", nobody cares thatit's the third party app that is vulnerable- they care about the factthat the email accounts are indeed vulnerableThe exploit that we used to break in involved an XSS hole in the emailpreview feature We sent a message to the CEO's email account, andwhen viewed, his web browser made several AJAX requests to the server,slurping the contents of his inbox and then depositing it on a loggingscript under our control Lance did an interview in which he discussedthe details of the exploit further, and I recommend you read that formore detailsFinally, I want to give another big thanks to Lance James and AvivRaff for working on this with me Not only was it very fun, but itmade some very good points that will likely be forgotten soon aboutweb application security: Escape outputs, be careful with whatthird-party software you use, and don't taunt the hackersIMAGEhttp://www.secuobs.com/revue/news/107757.shtmlhttp://www.secuobs.com/revue/news/107757.shtml Secuobs.com : 2009-06-05 22:58:40 - skeptikal.org - In case you've been living under a rock, Lance James, Aviv Raff, and Itook up StrongWebMail's challenge to break into their CEO's webmailand claim a $10,000 prize The terms of the contest preclude us fromdisclosing the details of the exploit, and while they've partiallypatched the holes that caused it, I'm not sure we're ever going to beallowed to tell the whole storyRest assured, we will openly disclose as much as we can, as soon as wecan In fact, I already have a blog post written and ready to go liveIt will be published early next week at the latest, so stay tunedThe current status: StrongWebMail's CEO confirmed that we exploitedthe application They still have not confirmed that we won the prize,and are checking to make sure we complied with the contest rules I'mconfident we did They gave themselves 3 business days fromyesterday, when we submitted the golden ticket to confirm the winA few news reports about the incident implied that we may not qualifybecause social engineering is off limits I can't make commentsregarding the extent to which we used social engineering, but therules say nothing about it- only that "working with an employee ofStrongWebmailcom or one of its affiliates or partners to complete thehack" is not allowedIMAGEhttp://www.secuobs.com/revue/news/106397.shtmlhttp://www.secuobs.com/revue/news/106397.shtml Secuobs.com : 2009-05-21 00:36:31 - skeptikal.org - Luca Carettoni and Stefan di Paola presented at OWASP Appsec Poland,speaking about HTTP Parameter Pollution The short version is this- bymangling the inputs for a HTTP request, you can cause all kinds ofstrange behaviors On a high level, this isn't too different fromSQLi, XSS, and plenty of other attacks What sets HPP apart is thatthe quirks you can generate aren't all data sanitization issues- theyare often logic bugs, which are much harder to test for, easier tointroduce into an application, and more fun to exploitThe presentation involved a few very different attacks, which makes ita bit difficult to summarize, but essentially, it involves overwritingHTTP parameters A few examples:PHP applications and others primarily get their user inputs fromCOOKIE, GET, and POST If the application reads input from the genericREQUEST parameter, the data could conceivably come from any of these,and developers don't always have a clear understanding of how thatdecision is made By abusing the order in which inputs are handled, anattacker can generate unexpected behavior in the application-expecting data to come from POST but instead reading it from GET, forexampleThis really isn't new- the register_globals mess in PHP stems from avery similar issue While register_globals is dying a well-deserveddeath, similar attacks can still be made against the $_REQUESTparameter, which many developers usually the same ones that usedregister_globals rely on Java, perl, and ASP have all seen the sameissues, and are at varying levels of fixed-nessThe more interesting and sneaky attack: If you pass a query stringwith multiple copies of the same parameter egindexphpfoo=baretfoo=baz, the application may handle it inunexpected ways PHP will use the last occurence of that parameter,JSP will use the first occurence, mod_perl converts it to an array,and ASP concatenates the parameters into a comma-separated stringCustom-buit parsers on embedded hardware can be even more surprisingNow, if the developer is doing his job right- being paranoid aboutwhere his inputs come from, validating, and escaping, this should notbe a major problem However, no developer is perfect, and this being afairly unknown behavior, it is quite likely to pop up Quirks are edgecases, and edge cases are where you find security holesI recommend you go over the slides, and the whitepaper when it comesout which should soon Some very interesting, very cool real-worldattacks are outlined there I especially like the ASP SQLreconstruction, but I won't go into them here In summary, you canleverage these parameter processing quirks against both the server andthe client, in a lot of interesting ways:* Bypassing input validation* Bypassing WAFs* Manipulating application flow* Manipulating mod_rewrites* Forcing/spoofing cookies* Manipulating client-side applications* Manipulating and polluting page contentAs a pentester, I absolutely love these kinds of attacks- they exploitseemingly-benign quirks in the application They rely on the attackerknowing more about how the application works than the person who wroteit Besides that, they're wicked fun to play with I see HPP asyet-another useful tool in my arsenal Like CSRF and XSS, it is andwill continue to be extremely common in poorly built applicationsWell-designed apps will have minimal attack surface, defense in depthwill further limit their exposure, and what holes do exist will bequickly remediatedHTTP Parameter Pollution isn't an entirely new attack, but it is amuch more in-depth revisiting of older flow-control and input parsingissues, specifically at the border between the application and itsback-end engine I expect to see a surge of HPP-related vulnerabilityreports in the future From the defender's perspective, though, it isthe same story: Know your inputs, know where data flows through theapp, validate before you use it, and escape it on the way outIMAGEhttp://www.secuobs.com/revue/news/99719.shtmlhttp://www.secuobs.com/revue/news/99719.shtml Secuobs.com : 2009-05-12 22:11:18 - skeptikal.org - When the latest version of Ubuntu was released, it came with a newversion of the Transmission bit torrent client One of the newfeatures of Transmission was a web interface, which would allow usersto manage torrents from their web browsers The service isip-restricted to localhostWhy the service should be enabled by default, or why the local userthe only one able to access it by default would ever want it, I'llnever know, but it should be no surprise to anybody that I immediatelypoked around for CSRF holesAs it turns out, the holes were there, and though a bit tricky toexploit- it required mangling the form inputs and using the text/plainencoding, Transmission was quite vulnerable Here's a proof-of-conceptBasically, it allows me to first change the download destination toone of my choosing, then download a torrent of my choosing This isbad- I could force a user to download a new bashrc file or overwritetheir entire home directory I actually did this by accident whiletesting the exploit Backups are greatOther problems do make it harder to exploit First, when you start thetorrent, it pops up a box asking the administrator what he wants to dowith it Many people, including myself, have it configured to skipthis step, as it's extremely annoyingWhen you make the CSRF requests, the result is returned in JSONformat, and browsers without handlers for it will pop up a box askingif you'd like to save the file When this box pops up, it is alreadytoo late, as the request has already been processed by the server, butit does at least keep the attack from being silentThis isn't really a new exploit- Nate McFeters talked about doing thesame thing through an XSS hole in the Azureus web interface in histalk, "the Internet is Broken", at Black Hat 2008The hole is fixed in today's release, so go ahead and upgrade, thendisable that web serverPlease, let's start taking CSRF seriouslyIMAGEhttp://www.secuobs.com/revue/news/95091.shtmlhttp://www.secuobs.com/revue/news/95091.shtml Secuobs.com : 2009-05-08 20:56:22 - skeptikal.org - I've been publishing a lot of holes in security companies' websites, andmore are coming next week While I'll continue to point out theseflaws, I'm hoping that we can turn these disclosures into industrywidechangesI know I've pissed some people off I'm pretty sure McAfee isn't goingto be giving me much love in the future I personally think that toomuch attention has been paid to them in particular Though theirofficial response was pretty lame and not entirely true, theydefinitely aren't the worst offenders I must admit, however, if ithadn't been for that issue making big headlines, I don't think as manypeople would be listening to me nowAt this point, I want to issue an industry-wide challenge- any ASVwants me to evaluate their PCI scanning service need only contact meI will perform rigorous tests, find whatever issues I can, and publishthem in brutally honest fashion I will provide recommendations to thevendors on how to improve the services, and if I'm impressed withthem, I will certainly make that known publicly as well I will givecredit where it is due, but I will happily call you out if you've donesomething stupid I have no love or hate for any PCI companies outsidemy own experiences, and I have no agenda beyond improving theindustryDo I expect any vendors to take me up on this challenge No I amskeptical by nature, but I would love to have somebody take the leadand prove me wrongI'm out for the weekend, but I'll leave you with one last batch ofscreenshots These are error messages from a handful more PCI ASVs,none of which are critical security issues, but all of which discloseinformation about the internal workings, directory structure, orconfiguration of their respective applications As before, all ofthese would be found with a simple website auditAn SQL error in ControlScan's trustmark validation scriptSQL error in ControlScan's Trustmark Validation ScriptCounterpane CGI Error with file path disclosureThanks to Russ McRee for this oneCounterpane CGI Error Path Disclosureonestoppciscancom Error Pageonestoppciscancom Error Pagesecureconnectcom ASP errors with stack tracesecureconnectcom Stack TraceSymantec included file manipulation and file path disclosureThis script actually throws about half a dozen different errors,depending on how you manipulate itSymantec Filepath Manipulation and Path DisclosureIMAGEhttp://www.secuobs.com/revue/news/93781.shtmlhttp://www.secuobs.com/revue/news/93781.shtml Secuobs.com : 2009-05-07 22:06:04 - skeptikal.org - McAfee has been hit very hard this week, and the vulnerabilities in theother ASVs that I published are starting to make waves as well Whileit's fun and it really is to point a finger and say "LOL McAfeeFail", this really isn't helpful It's time we take this as anopportunity to look at things that are seriously wrong with PCI andthe way that it is implementedI don't claim to be an expert on the PCI standards I am just one ofmany people who is trying to improve the security of his company andthe internet as a whole In my view, achieving compliance should be anafterthought While any business executive worth his paycheck shouldunderstand and value security from a risk-management perspective, thefact is that most respond better to industry requirements Regulationis a dirty hack, but it at least gets the attention it needsSince the service providers already understand that they need tocomply with these regulations, we may as well fix them so that theyare effective In my view, here are the major changes that need to bemade:Better EducationFor many small service providers, the PCI testing process is the firsttime they look seriously at their own security Having them sign a fewforms and running a scan on their servers does not educate them, andit does not prepare them to deal with security properly This sets apoor precedent for a growing company, and in my experience, itinvariably causes problems down the road Having an expert consultanteducate the service provider about how to design a security programwould do more to protect cardholder, customer and company data thanany set of prescriptive security regulations This phase of theprocess is usually skimmed over by a company trying to get thenot-so-elusive compliance certificate In my opinion, it may be themost important partBetter documentationWithout clear definitions of the standards and recommendations forcompliance, we'll never get far Most service providers do not evenhave a clear understanding of which standards they are expected tocomply with, much less how to do so Instead, they speak with thesales department at the cheapest ASV they can find, perform a scan,and send the vulnerability reports to their system administratorsTo be fair, there is documentation out there, but there's a lot ofmisinformation too The official PCI FAQ which is itself vulnerableto XSS doesn't provide much useful information beyond the standardsthemselves and a few supporting documents Several unofficial forumshave sprung up, but the information contained within isn't alwaysreliableMore ResponsibilityTo my knowledge, this week's McAfee issues, as well as the issues withother ASVs, have not affected their status as a PCI scanning vendor atall Given that some of the ASVs' XSS holes have still not been fixed,I find this extremely shocking PCI companies need to treat customerdata responsibly, and need to be held responsible when they do notRevoking their ability to perform PCI scans would be disastrous totheir business, but the stated goal of the PCI standards isn't to keeppoorly managed companies in business If the true goal of thesestandards is to "help organizations proactively protect customeraccount data", then the ASVs need to be held responsible when they donotPCI ASVs should be held to much more rigorous standards than theService Providers they certify I was shocked to find out that regularthird-party penetration tests are not a requirement for ASVs Fromwhat I understand and I may be misinformed, they essentially fillout paperwork and assure the PCI board that they are themselvescompliant Does this strike anybody else as insaneMore TransparencyWhile the PCI Council provides documentation of proper scanningprocedures, they do not go into much depth In particular, they barelytouch on web application scans, while in my biased opinion, this isone of the most vulnerable and therefore critical parts of mostService Providers' systemsNo data is available to the public regarding the relative efficacy ofthe scans I'm not aware of anybody with a truly effective web appscan, but I've run several on the same servers in a ratherunscientific fashion, and come up with vastly different results Thefree PCI scan offered by nCircle took less than an hour, and only dida cursory inspection of my web application By contrast, McAfee's scantook close to 3 hours, most of which was spent testing the webapplication Neither found the rather basic XSS and SQLi holes that Ideliberately put inWhile neither app was up to par, the McAfee scan was clearly superior-at least at finding web application holes At the time, I was moreinterested in finding problems with the scanning services, rather thandoing a direct comparison of the two However, it would not bedifficult to design a system for measuring the effectiveness of ASVscans The PCI council should do so They should make the results ofthese tests public, and should make scanners' status as an ASVdependent upon themBetter EnforcementAn end user has a right to know whether the company he is doingbusiness with is PCI compliant or not A verification process, even assimple as a list of compliant companies on the PCI website, isessential to an effective certification program Of course, whenproblems are found, the Service Provider in question should have theircertification revokedI have come across many companies with poor security practices, andmany simply do not care The financial institution that I bank withused to have its access logs publicly accessible I first alerted themto the issue over a year ago, and no action was taken In the courseof my PCI research, I coincidentally found out who their auditor was,and after alerting them to the issue, the logs were removed almostimmediatelyIdeally, I should not be able to find out who performs the auditing ona company lest I perform attacks through the ASV However, only byreporting this issue to the auditor was I able to get it fixed If Iwere able to report it directly to the PCI board, and a system were inplace for getting that report to the right people, this would not havebeen a problemBetter TestingFinally, we arrive at the elephant in the room: the testing performedby the ASVs sucksScanning has a place in security- it can find unpatched software, poorconfiguration, and other issues that often go unnoticed However,until we have strong AI in the scanners, it will never have theability to detect logic flaws or reliably fuzz for applicationvulnerabilitiesJames Lester Senior Security Analyst for McAfee, of all placestouched on this last month, and I think he's right- scanning is noteffective in and of itself, and should not be relied on as the solemethod of testing for PCI compliance A full-scale audit will findissues that no scanner can, and more importantly, it will giveauditors a reliable "feel" for the security of a Service Provider Anyprovider that builds their own applications for payment and customerdata management should be required to perform a QSA audit, regardlessof the scale of the applicationThose Service Providers that cannot afford a full audit should not beallowed to build their own applications Instead, they should use oneof the already approved applications, on a sandboxed or privatesystem Scanning should still be required, but this way we can limitthe scope of this scan to finding out-of-date software, unpatchedholes, and configuration issues- things that the scanners are alreadyvery good atIMAGEhttp://www.secuobs.com/revue/news/93283.shtmlhttp://www.secuobs.com/revue/news/93283.shtml Secuobs.com : 2009-05-06 19:27:43 - skeptikal.org - My company has a client with a small but successful ecommerce site Thissite is a prime example of what I'd like all ecommerce sites to looklike- thoroughly tested code, FTP disabled and no other unnecessaryservices running The client is careful to make sure that patches stayup to date, and system logs are regularly reviewedIt's one of the few companies that I would trust to handle securitythemselves Unfortunately, this client needs to have his websitetested for PCI compliance He signed up with an ASV, and they startedrunning scans When the results came back, it showed every port on theserver as being closed A bit of research determined that the IDS hadkicked in during the initial portscan and blocked the scanner fromaccessing his website at all- exactly as it should have I received anemail from the client:They told me that their server needs to be 'whitelisted' - TheirIP address needs to be listed as 'friendly'Essentially, we had to whitelist their IP on both IDS and firewall inorder to get the PCI compliance certificate This is pretty commonthroughout the industry, and I've heard this request from clientsusing a variety of ASVsAny security person should notice the problem though- the scanningsystem could not get past the IDS, so we opened the door and invitedit to come in and break thingsI don't think many people have looked into the implications of thisSecurity administrators routinely poke holes in their own systems forthe purpose of achieving PCI compliance If that scanner were to becompromised in any way, it would leave my client's system andthousands of others vulnerableOn Monday, I published details about a critical McAfee CSRF holeYesterday, I disclosed vulnerabilities in a handful of PCI ASVs' websites and customer portals Compromising the security administrator'saccount with web exploits is just one way to abuse the scanningservice Here are a few more-* Client credentials can be compromised through offline attacks Ina recent weekend trip, I was driving by an ASV's office On thetop of their dumpster was a stack of customer signup forms withusernames, passwords and contact info- faxed in, entered into thesystem and discarded without even a trip to the paper shredder* The auditors themselves can be compromised in the same way- nextto that customer information were printed pages from theadministrator side of the ASV's website Sales scripts, emails,and everything necessary to perform a social engineering attackwere there too* Once the client or auditor accounts are compromised, the attackergets lists of servers-including "secret" database, backup,infrastructure, development servers and others that shouldn't bepublicly known Along with the servers, they get nicely-formattedreports of all the vulnerabilities found* In general, A few servers will perform the scans on all an ASV'sclients If compromising accounts isn't to your taste, you couldjust sign up and pay for the service In most cases, all that'skeeping you from scanning systems other than your own is a serviceagreement As one employee at an ASV noted: "I amwaiting for arogue account to use an ASV to scan sites that they don't haveprivileges to scanto assist them with identifying vulns" Wouldthey know if it had happened With IDS disabled and scans alreadyperformed at random intervals, who would notice It may not havehappened yet, but it's bound to happen eventually* Knowing the source IP of the scanner and knowing that it has fullaccess to the target system, packets may be spoofed and amalicious payload delivered* Many ASVs use Nessus to perform these scans It would betheoretically possible to piggyback a targeted, malicious payloadwith a normal plugin update This probably wouldn't be worth theeffort, but the idea of subverting the entire security communityto execute a single attack appeals to me in a sick wayI understand the good intentions and even the necessity of performingwebsite scans I should be clear: I am all for the testing ofapplications and systems, and I think that by and large, most systemsare better off because they perform these PCI scans The problem isthat when we are trying to get that compliance certification, weapproach it with an engineer's mindset "How can I make it work"rather than an auditor's mindset "How can I make it fail" Even inthe process of securing our systems, we need to stop at every step andconsider the implications of our actionsAssuming that the PCI ASVs treat clients and data with due care, theseattacks are mostly not practical Considering how irresponsible thesesecurity companies often are, inviting them to attack your server islikely a Bad IdeaIMAGEhttp://www.secuobs.com/revue/news/92751.shtmlhttp://www.secuobs.com/revue/news/92751.shtml Secuobs.com : 2009-05-06 19:27:43 - skeptikal.org - In yesterday's post on ASV vulnerabilities, I said that nCircle did notrespond to my report and belonged in the doghouse In fact, they wereone of the best, and had the vulnerability fixed within mere minutesof my report I had lists of good and bad ASVs and they accidentallyended up in the wrong oneApologies to nCircle, and thanks to Andrew Storms for pointing it outI've corrected yesterday's postIMAGEhttp://www.secuobs.com/revue/news/92750.shtmlhttp://www.secuobs.com/revue/news/92750.shtml Secuobs.com : 2009-05-06 07:30:55 - skeptikal.org - I just finished an interview with Patrick at Riskybiz for a podcastabout my McAfee CSRF and the other PCI ASV vulnerabilities If you'reinto this kind of thing and the traffic spikes I've seen this weekindicate you probably are, go give it a listenhttp://riskybiz/netcasts/rb2/rb2-mcafee-bug-finder-mike-bailey-speaks-riskybizIMAGEhttp://www.secuobs.com/revue/news/92586.shtmlhttp://www.secuobs.com/revue/news/92586.shtml Secuobs.com : 2009-05-05 19:34:33 - skeptikal.org - The McAfee XSS got slashdotted I think that all this attention is a goodthing, putting a spotlight on XSS issues, but I have to say, I'msurprised by it It's not like XSS attacks are news anymore, and it'snot as if this is the first McAfee XSS to be published Last night, Ifound an XSS hole in the verification script for their SiteAdvisorservice for extra ironyMcAfee SiteAdvisor XSSBut really, focusing on these XSS holes is missing the point I neverthought I'd say this, but in my experience, McAfee is one of thebetter ASVs out there This isn't a compliment to them, it's an insultto the entire industry Here are a few examples of other ASVsUntil last week, atseccom was vulnerable to XSSUntil last week, secureconnectcom was vulnerable to XSSsungardcom is still vulnerable to XSSncirclecom is still vulnerable to XSScontrolcasecom is still vulnerable to XSSsupportfoundstonecom McAfee's premium brand is still vulnerable toCross-site FramingUp until a few weeks ago, there were also open redirects on thewebsites of Qualys, SecurityMetrics, and others Is it any wonder I'mnot at all shocked at a few XSS holes in McAfee's web siteSome of these companies should be commended for handling thevulnerabilities correctly- Atsec, SecureConnect, Qualys, and evenMcAfee responded admirably- sometimes the issue was fixed withinminutes of my vulnerability report Others- Foundstone, ControlCase,nCircle and Sungard, belong in the doghouse- none of them evenrespondedHowever, the glaring fact is that the entire PCI scanning industry is,frankly, bad at scanning for vulnerabilities Most of these websitesuse their own scanning service on their own websites While I stillhold that in-depth audits for these sites should have taken place longago, the scanners should have caught the problems as well Some ofthese domains contain the portals for customers to manage their PCIcompliance scansPeople, let's take the focus off of McAfee, and put it where itbelongs The PCI scanning industry as a whole is a joke, and acrossthe board, these Web Security companies are themselves bad atsecurityIMAGEhttp://www.secuobs.com/revue/news/92310.shtmlhttp://www.secuobs.com/revue/news/92310.shtml Secuobs.com : 2009-05-04 21:41:55 - skeptikal.org - If anybody actually pays attention to what I have to say, there's a goodchance that this post is going to make a lot of people awfully mad Itneeds to be saidMost web sites built by my company are mass-hosted on cPanel serversWe're not the only company around that does this- there are many moreOn the internet, there are hundreds of thousands of mass hostingservers, with hundreds of users on each server On our systems, about1/3 of those accounts have some kind of ecommerce software I don'tknow whether that fits with industry averages, but it paints a prettyinteresting pictureThe internet has a massive number of ecommerce web sites, allprocessing credit card transactions, hosted on servers with at least afew hundred other users Let's presume one thing for the sake of thispost: breach of one account can lead to compromising another accountthrough local attacks world-readable configuration files, local fileinclusion, and a whole host of others that I haven't publiclydisclosed yet as well as web-based attacks see my previous post onserver and client attacks via mod_userdir I'll be posting a lot moreways to attack shared hosting in the future, but humor me and take itfor granted if you mustI've seen some debate as to whether PCI standards apply to ecommerceapps that outsource the payment processing to a third party likePayPal or Authorizenet, but I honestly don't think it should matterFirst off, any site that handles CC data, even if they are not storedon the system, can be abused If I can break into your Zen Cartinstallation and 'customize' your payment module to email thosenumbers to me, it doesn't matter who does the payment processing Ifyou have a payment form, the PCI standards should apply to youBut here's the thing: every one of my company's servers gets scannedfor PCI compliance Every one of them passes, and I've got thecertificate to prove it When you hit a cPanel server directly via IPaddress, only one website will come up, and it is usually a defaultcPanel page, which is pretty minimal Each of these servers hashundreds more accounts that don't even get touched by McAfee's web appscannerFinding XSS holes on at least one of those accounts is practicallyguaranteed In fact, when I first started in my current position, Iwas able to gain shell access on any given server in less than 5minutes I've since been able to make incredible progress with masspatchings and my own vulnerability research, but there are enoughunknown issues and custom code that I'll never be able to fix themallSo why are these servers being certified as PCI compliantNow, my company don't actually advertise that our shared servers arePCI compliant, but we do test them as part of our own merchantagreements In addition, we've greatly improved our processes andsales practices to make sure that new code is reviewed and apps withsensitive data go on VPSes, but that does nothing for all the oldclients, and even less for the millions of other sites out thereThe main point here, of course, is that these servers are consistentlytested as PCI compliant This isn't really a attack on McAfee Many ofour clients use other ASVs for their own sites, and none have aproblem with the fact that these sites are mass-hosted, nor the factthat other sites on the same server are not PCI compliant though ifthey tried to scan the other sites on the server, I'd put a stop to itpretty quickly, for obvious reasonsCan somebody with more background in PCI weigh in on this Is thisjust a massive oversight on the part of every ASV out there When mycompany gets big enough that they need a PCI QSA audit rather than theineffective ASV scans, are we going to be have to rebuild all of ourcustomers' websites Are we going to be completely screwedcompliance-wiseIMAGEhttp://www.secuobs.com/revue/news/91848.shtmlhttp://www.secuobs.com/revue/news/91848.shtml Secuobs.com : 2009-05-04 21:41:55 - skeptikal.org - Just as a quick follow up to my earlier post, here is a prime example ofa "PCI Compliant" company who is probably notI attempted responsible disclosure several weeks ago and received noresponse from this company, a New York based web hosting anddevelopment company I'm not trying to get them in trouble, so Iredacted the screenshots and won't refer to them by name, but I haveno doubt that anybody who cared could find them quickly enoughAs part of my research, I made a phone call to this company Iinquired about the PCI compliance of their servers, and the salesassociate assured me that their servers are scanned regularly and arecompliant He did not tell me who their ASV is, and while I have mytheories, I won't speculate publiclyClient Login PortalRegardless, this company has a login portal on their main web site Iknow one of their customers, so I can tell you that the credentialsused to log into this portal are used for customer cPanel accounts,billing system, and webmail Those credentials are probably prettyvaluable, rightCustomer Database SQL DumpHow did this site ever pass any kind of PCI testing It's only atheory, but I suspect this is because it's on a mass-hosted serverWhen you hit the server directly by IP, it brings up the defaultcPanel pageDefault cPanel PageBut this company was, by their claim, 100% PCI compliant They told methat some customers also get their sites tested and are in turn PCIcompliantIMAGEhttp://www.secuobs.com/revue/news/91847.shtmlhttp://www.secuobs.com/revue/news/91847.shtml Secuobs.com : 2009-05-04 21:41:55 - skeptikal.org - When you outsource all your PCI scanning to another company, you'd expectthat company to be careful with your data First off, there's the factthat security is what they do- if that data were to get leaked, you'dexpect the damage to reputation alone to be cripplingSecond, and probably the least important, really, the PCI ASVvalidation requirements section 451, if you're interested make itpretty clear that client data should be kept very confidentialFinally, the data contained on those servers- lists of vulnerabilitieson all their clients' systems, along with security administrators'passwords and more, is pretty high on the list of Things You Don'tWant Getting OutYou know what's comingWe've found problems with McAfee time and time again I was savingthis for a post later this week, but given recent events, I think thetime is rightUntil last week, McAfee Secure was vulnerable to critical CSRF holesNot little ones, or ones that were difficult to exploit- basic,zero-kowledge, classic GET-based total-account-compromise holes Ithink the pictures tell the story:Logged in, 3 Accountsiframed CSRF AttackMalicious User AddedAccount Confirmation EmailI sent a vulnerability report to a contact at McAfee and theyresponded quickly, communicated with me, and fixed the issue Theyalso began reviewing their entire codebase for similar holes Icommend them for that, but I cannot overlook the fact that thisvulnerability never should have existed in the first placeIt's not going to be a surprise to anybody, but this is solid proofthat McAfee Secure is mis-named Their failure here is on an epicscale:* They did not comply with PCI requirements for ASVs* They did not use a secure software development lifecycle inbuilding this application* An in-depth penetration test should catch an issue like this, so Ipresume that no such audit has taken place* Until I reported it, they had never performed a full code reviewfor web vulnerabilities* As you can see in the 1st and 3rd screenshots, the application wasitself certified as McAfee Secure when I performed thisdemonstration* At no point in five weeks from me finding the vulnerability and itbeing fixed was that McAfee Secure logo removed from their ownwebsiteThe ultimate and obvious irony, however, is that McAfee Secure is inthe business of testing others' web applications I'll be the first tosay that they are not equipped to do soI have a lot more information coming on this and related issues Trythe veal, tip your waitress, I'll be here all weekIMAGEhttp://www.secuobs.com/revue/news/91846.shtmlhttp://www.secuobs.com/revue/news/91846.shtml Secuobs.com : 2009-04-28 21:16:45 - skeptikal.org - As part of my research, I have been reporting a lot of web-basedvulnerabilities lately I've been using the following procedure toreport those vulnerabilities, and I think that I should make thisprocedure knownWhen I publish a vulnerability, I will make what I feel is areasonable effort to inform a website or application's maintainerabout it before making it public I enjoy breaking websites, but Ihave no intention of causing any particular company or website harmHaving reported hundreds of issues over the past few years, I've foundthat often, they are only fixed when there is a threat of them beingmade public My goal is to promote quick patching of holes, to fixwhat I see as widespread poor security practices, and to educatesystem maintainers about the risks that they faceBefore submitting a report, I will check several vulnerabilitytracking services If unfixed issues that are over 1 month old exist,I will assume that the site's maintainers do not take these securityissues seriously, and I will publish the vulnerability at mydiscretion I may or may not attempt to contact the affected site'sownerIf no old vulnerabilities exist, I will check the website for acontact email address I will not submit vulnerability reports throughweb-based contact forms, customer portals, or by speaking with asalesperson If an email address is not available on the website, Iwill do a whois search for this information Barring that, I willattempt to email the report to abuse@, info@, root@, security@, andwebmaster@yourdomaincomOnce a vulnerability report has been submitted, I will wait one weekfor a response before publishing at my discretion If the website'smaintainers are responsive, acknowledge the issue and keep me informedwith regards to the patching process, I will attempt to coordinate mydisclosure so that it is published after the issue has been fixed, andmay postpone the publishing to do soI will note that I only provide notice as a courtesy, to give websitemaintainers an opportunity to address the issues before they gopublic While no website is perfect, I expect website owners,particularly those with business-oriented websites, to act responsiblyin handling these issues efficientlySome researchers are more generous with timeframes and will evenattempt multiple contacts over several weeks In my experience, a siteowner that is unresponsive for the first week will rarely improve inthe next My own time is valuable and I have no intention of wastingit in contacting an unresponsive partyWhen I do make a vulnerability public, I may choose to do so through apublic vulnerability tracking service, on my own website, or in theform of other writing, speaking, or consulting engagements If theresponse and interaction I recieve from the site owner is positive, Iwill generally attempt to make that known at the time of publishingThe corrollary is also true- if my report is met with disinterest,threats, or negative feedback, I will make every effort to ensure thatit is publicly known Frankly, you don't want to go there- controversytends to make headlinesAs noted previously, I am here to help, but I'm not necessarily hereto help youIMAGEhttp://www.secuobs.com/revue/news/89369.shtmlhttp://www.secuobs.com/revue/news/89369.shtml Secuobs.com : 2009-04-16 22:46:05 - skeptikal.org - I found a minor hole in phpnet the other day It's a small reflected XSShole that uses URI parameters At first, I thought it wasn't a hugedeal, and wrote up a vuln reportThen it occurred to me to look deeper, and I found that there arehundreds of mirrors of the phpnet site, spread across the internet inwhat turned out to be some awfully interesting locations Many of thedomains it is mirrored on are web hosting companies, and most of thosehave some type of customer portal on the same domain In addition tothese, there are some gov and edu sites of interest, and the reallyinteresting one- Facebookphpmirrorfacebookcom XSSWhile Facebook's session cookies are set as HttpOnly and notaccessible to javascript, this is still a serious issue First off,not all browsers support HttpOnly cookies Second, HttpOnlyimplementations aren't perfect Finally, even the non-HttpOnly cookiescontain valuable data which can be leaked through the subdomain Iwrote up a proof of concept that will allow me to de-anonymize usersby reading their facebook UID off of phpmirrorfacebookcomIn fact, I sent a vulnerability report to Facebook as well, and sentthem the wrong link- normally I'd just pop an alert box as aproof-of-concept, but I accidentally sent the link with the weaponizedcookie-stealer in it Much to my surprise, I checked my logs thismorning and found that one of Facebook's product managers had clickedthe link I suppose there' a lesson in there about not trusting thelink that some random hacker sends you, even if they seem helpfulFacebook Product Manager's Stolen CookieThe phpnet people responded quickly and fixed this vulnerability, andthe fix is slowly propagating to the mirrors, but I have no doubt thatmore exist This got me thinking about the possibility of writing across-domain XSS worm It turns out, it's completely possible, thoughin this case the scope is a bit limitedLessons learned: Be careful with where you get your content, and whatyou put on your subdomains- mirrorvictimcom can nearly as useful toan attacker as wwwvictimcomIMAGEhttp://www.secuobs.com/revue/news/84406.shtmlhttp://www.secuobs.com/revue/news/84406.shtml Secuobs.com : 2009-04-13 18:46:58 - skeptikal.org - I've been playing a lot with CSRF lately As I find ways to manipulatemore and more services with what is probably the most basic type ofattack possible, I keep getting surprised by the insanely cool thingsthat one can do with itPhotobucket allows users to make albums either "Public" or "Private",the latter of which will enable access only with a guest passwordWhile chatting with a friend online recently, I tried to view one ofher private albums Knowing what I do for a living, she gave mepermission to do so, but said I'd have to find my way in without herhelp So I didThe form for setting a private album's password, as well as the onefor making an album public, both are vulnerable to CSRF In fact, bothuse GET parameters to do their magic, so it's actually pretty trivialto pull off a successful attack I wrote a proof of concept, but it'sreally not that complicatedNot only can users' albums be made public, but variations on thisexploit can be used to change passwords on albums, delete photos, andcompromise account passwords This really is a serious issue- whilePhotobucket's TOS may protect them from liability and may or may nothold up in court, there are a lot of extremely private photos storedthereI emailed a vulnerability report to Photobucket on 4-10-2009, but havenot received a responseIMAGEhttp://www.secuobs.com/revue/news/82714.shtmlhttp://www.secuobs.com/revue/news/82714.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - I've had a few people contact me about this cPanel exploit- mostly peopleI'd rather not give further information to sorry guys, but you're noteven very good at being bad guys Unfortunately, I also don't thinkanything will get fixed unless it gets made publicI did some more work on the WHM interface, and it turns out that XSSisn't even necessary to change the root password It can all be donewith CSRF:http://victimcom:2086/scripts/passwduser=rootetpassword=ownedetpassword2=ownedetsubmit-domain2=Change+PasswordIn case you're not familiar with CSRF, it is a vulnerability that isextremely underrated- forcing authenticated users to perform actionsfor you via well placed links, resource tags, or open redirectsLet me repeat that: If you are logged into cPanel, and you hit awebsite that I can embed an image link in which is nearly every website out there, these days, I can root your server I What's more, Iwon't leave any traces at all, because you actually root the serverfor meThis is a big dealBut it's worse than that There are plenty of other CSRF holes in theWHM interface Here, I can force you to download and install arbitrarycode from cPanel's servers, downgrading or upgrading your software toa vulnerable version at will:http://victimcom:2086/scripts2/saveuthemesthemetype=moduleset${moduleName}=${versionNumber}One final point, in case you think needing local access for mypermanent XSS hole is too much work, here's a reflected XSS exploit:http://victimcom:2086/scripts2/confdkillproc%3Cscript%3Ealert1337%3C/script%3E=1ettrusted=Seriously, folks Web-based management interfaces are a bad ideaIMAGEhttp://www.secuobs.com/revue/news/82443.shtmlhttp://www.secuobs.com/revue/news/82443.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - In my day-to-day activities, I often find security vulnerabilities inwebsites, software, and servicesWhen I find these issues, I make an effort to contact the affectedparties to disclose the vulnerabilities responsibly Unfortunately,many vendors and website owners do not supply contact information ontheir site, or make it needlessly difficult to contactBack when I built my first website in the mid-90s, it was commonpractice to supply a webmaster's email address at the bottom of everypage, or on a 'contact' page I don't know why this practice seems tohave died out, but it needs to come backWebsite Owners: Please put an email address or at least a contact formon your website for users to contact you regarding technical issues,problems with your website, or other concerns It is in your bestinterest to communicate with your audienceVendors: Because your service is more complicated than a simpleexchange of information with your clients, you have a higherresponsibility believe it or not to acknowledge and address foundissues Provide a communication channel for users and non-users alikeAllow them to contact you anonymously if they wish Do not requirethat they register, have an account, or log in to your website inorder to contact you And please, when you are alerted to an issue,thank the party in question, publicly acknowledge the issue, and fixit Do not shoot the messenger; fix the problemOnce a good-faith attempt has been made to disclose the issue, many ofus will then make it public This is bad for you Don't get caughtwith your pants down If you communicate with those who are trying tohelp, most will wait until you have fixed the issue to make it publicWe are here to help, but we aren't necessarily here to help youIMAGEhttp://www.secuobs.com/revue/news/82442.shtmlhttp://www.secuobs.com/revue/news/82442.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - So here's the rundown, for those that didn't make it:My 1-hour flight was delayed 3 hours, so I missed the Toxic BBQ Don'tfly Jet BlueTime-based SQL injection is cool I started playing with it as a wayto get around the blindness of blind SQL injection about 6 monthsback, but these guys are way better than me at itCaptchas are on the way out Their usefulness is decaying by the day-most of the big-name ones have been cracked already, and the smallones just aren't worth the effort yetRSnake doesn't like Google Google doesn't like RSnake The talk wasreally good, but mostly not news if you've been following his blog forthe past yearIndustrial espionage is cooliPhones in UPS boxes can be used to penetrate wireless networks fromthe mailroom This is coolDan Kaminsky can drink a lot of beer very quickly, but can alsodisappear quickly He may be a ninja25 years later, WarGames is still coolI can still sleep through an entire economics lecture, even if it'sabout hacker economicsDNS is broken More importantly, we rely way too heavily on it Thisis badThe state of Massachusetts can suppress a talk on breaking the Bostonsubway system, but they can't suppress one on breaking the Dutchsubway system which uses the same technology Also, they can'trecall the slides from the original talkIMAGEhttp://www.secuobs.com/revue/news/82441.shtmlhttp://www.secuobs.com/revue/news/82441.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - Privacy is a pretty touchy subject for me In short, I don't really trustanybody who isn't meThe government has illustrated time and again that they can't keepprivate data private Corporate America isn't far behind As astereotypical counterculturist, I frankly I don't trust them to usethe data in my best interests in the first placeAnyways, I came across this comic today that nicely illustrates theneed for people to be careful with data that they don't think issensitiveIMAGEhttp://www.secuobs.com/revue/news/82440.shtmlhttp://www.secuobs.com/revue/news/82440.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - From time to time, I'm asked to evaluate a particular application for useon my company our our customers' servers This is often depressing, asmost of the ready-built web apps out there are poorly written at bestThis is pretty much the status quo, it would seemI evaluated V3 Chat, a web-based instant messenger service, about ayear ago for a client Based on the high number of XSS and other holesin the software, I strongly recommended against it The client foundanother solution, and life went onToday I was asked to look at it again, as another client wanted to useit and a new version has since been released Within seconds, I foundthe first of many holes in their demoNormally, this wouldn't irritate me so much- recommend that they notuse it, move on with life, etc But the vendor's web site states thefollowing as a bullet point:"New - Improved User Security Greater safety and security forprivate chat conversations Increased protection against XSS and MySQLattacks"The really irritating part to me here is the fact that they are usingimproved user security as a sales point, when not just the original,but the "improved" version of the software would not pass basic PCIcompliance testing They haven't even fixed the XSS hole that Iemailed to the vendor several weeks before sending it to XSSedcomabout a month ago this was partially the inspiration for my OpenLetter to the Internet at about the same time While this softwareis, in my professional opinion, lousy, this is nothing new to the webUnfortunately, there is a lot of broken software out there, and veryfew vendors, much less their customers, realize thisWhat would it take to fix the web A lot, I'm afraid Bruce Schneierkeeps telling people that it starts with legal accountability on thevendor's part, which I'm inclined to agree with In the meantime, youcan secure your own web services with a healthy dose of skepticismhence, the title of my blog It's common enough that it's not evennews anymore, but I've seen far too many instances of encrypted,unbreakable, or "improved" software turning out to be insecureWhenever my company is looking to use some commercial software, theyrun it by me first I talk to the sales representative and am alwaystold that the product is perfectly secure, will solve all my problemsand whiten my teeth while I sleep Invariably, I get a demo copy andfind holes in the softwareThis in itself isn't always enough to get a negative recommendation; Isend the vendor my findings, and watch how quickly the issues areresolved After evaluating the vendor's response to the problems, Ican finally make a recommendation Usually, we end up buildingwhatever we needed in-house The times that we don't, we usually wishwe hadOften, the vendor is the most surprised to find out that their magicalsoftware is full of holes At least, they act surprised Don't trustthe marketing, don't trust the reviews in ad-supported-magazineweekly If it's going to be used somewhere important, it's worth yourtime to look for yourself If the vendor won't let you demo a copy,move on If you haven't the time or the knowledge to evaluate it, Ihave both, but less money than I would preferThat's my rant for the dayIMAGEhttp://www.secuobs.com/revue/news/82439.shtmlhttp://www.secuobs.com/revue/news/82439.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - I work for a web development and hosting firm, where have an ongoingcompetition Our webapp developers submit their newly-built sites fora voluntary cracking attempt If I cannot in some way compromise,abuse, DOS, or gain escalated privileges, the developer in questiongets a monetary prizeSo far, I have not failed, and the prize keeps getting biggerOf course, it isn't really a code audit or even a penetration testPrimarily, it's a way for me to hone my own skills while informing ourdevelopers about web security issues The contest has a somewhatlimited scope- I must get in by abusing a hole in the code orconfiguration, so social engineering, server configuration, and otherattacks are out at least as the primary attack vector, though I mayuse them as leverage against another hole It also is limited tosingle-developer applications, so they tend to be small in scaleI'm writing about this here for two reasons First, I think it's avery good idea We have had an extremely positive response from thedevelopers They code better than ever They are actively engaged inmaintaining the security of the applications, rather than building andthen forgetting about them The contest has sparked many insightfuldiscussions about various security concepts, including CAPTCHA, PHPsession management, and XSS filtering If anybody out there manages ateam of developers, I highly recommend holding a similar competitionThe second reason is because I've received permission from thehigher-ups to publish some of the post-exploitation writeups on thisblog I hardly consider myself to be the best web application hackerout there, and I don't think I'm a definitive authority on thesubject, but I've found and I'm not alone that very few non-securitypeople, particularly the developers in charge of building theapplications, know how an attacker worksI'm hoping that by showing the thought process and techniques that Iuse, I can enlighten a few developers, project managers, and maybeeven a few other security-folkIMAGEhttp://www.secuobs.com/revue/news/82438.shtmlhttp://www.secuobs.com/revue/news/82438.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - Here's the first of many writeups for my "Hacker Challenge" Keep inmind, this isn't a penetration test- it's just a train-of-thoughtwriteup of how I cracked an application The idea is to demonstrateinstances of various attacks in use, rather than the theoreticalproof-of-concepts that appear in most security web sitesThe site is a file repository- basically customers can pay a monthlyfee to have access to a virtual filing cabinet-type-thing I don'tthink that's a fabulous business model, but that's not the point ofthis blog After familiarizing myself with the site, my first attemptswere file upload attacks naturally, given the purpose of the siteFortunately, the site used several layers of protection for uploadedfiles- first, it only allowed a whitelist of filetypes, preventingmalicious files from being uploaded Next, it stored those files in anon-web-accessible directory Even if I could get a malicious fileuploaded, I could not access it directly Finally, the filenames wererandomly generated- if I found a way to circumvent the access control,I still would not know the name of my malicious fileBasically, this type of attack didn't work; I moved onThroughout the site, inputs were validated thoroughly excessively insome cases No matter where I looked and how much I mangled theinputs, I could not find an SQL injection hole I did find a reflectedXSS hole in an obscure stock script, so I decided to work with thatMy goal was tosteal an admin session using Javascript, and after setting up my evillittle javascript-session-stealing kit I'm quite proud of it, foundout that this also wouldn't work so easily The developer had addedthe following directive to phpini:sessioncookie_httponly = 1This directive made it so that session IDs were inaccessible toclient-side Javascript I could have still used the XSS hole for otherthings, such as forcing the administrator to perform actions on mybehalf, but this would require work and inside knowledge to code, andwould have a relatively low chance of successI'm rather lazy, so I moved onI went to myipneighborscom and found a list of sites on the serverIt didn't take me long to find one with some known vulnerabilities,and next thing I knew, I had filesystem access Faithful readersalready know where I'm going with this, but mass-hosted servers are aBad Idea Even so, it is possible to configure file permissions andcode a site so that an attacker can't simply walk in and read yourconfiguration filesI whipped up a quick script and ran it on the compromised account Theserver runs FreeBSD and cPanel This script monitored the output of`ps -aux` while fetching a page from the target account Because ofsuexec, I immediately knew the username of the targeted websiteWith this information, I tried to read files from the public_htmldirectory, but the permissions were set up mostly correctly andprevented access While I couldn't list the files in the directory, Icould guess at their filenames, and eventually landed on one file thatwas readable- phpiniReviewing the site's phpini file, I could tell the server wasrelatively locked down, but one line in particular caught myattention:sessionsave_path = /home/theSiteUsername/tmp/I tried to list the files in that directory and was able to view alist of open sessions' IDs This was the hole I needed to compromisethe account:$ ls -la /home/theSiteUsername/tmp/ | grep sess-rw------- 1 theSiteUsername theSiteUsername 5068 Sep 18 09:20 sess_1a1aexxxxxxx5e282e1a5747694ec8e2-rw------- 1 theSiteUsername theSiteUsername 5023 Sep 18 09:19 sess_462fexxxxxxx13dafa331bc15e962e22-rw------- 1 theSiteUsername theSiteUsername 5109 Sep 18 10:51 sess_717edxxxxxxx653df341f91d096e0484-rw------- 1 theSiteUsername theSiteUsername 5079 Sep 18 09:14 sess_91850xxxxxxxef480524c23412b23dc1-rw------- 1 theSiteUsername theSiteUsername 5011 Sep 18 10:38 sess_9246dxxxxxxxe6e710a9e623af23ca95-rw------- 1 theSiteUsername theSiteUsername 5079 Sep 18 09:25 sess_a4cdcxxxxxxx065ede6ecb062d443f86I then manually set the SESSID cookie in my browser to those found inthe session filenames, and confirmed that I could hijack otheraccounts' sessions Unfortunately, none of those sessions wereadministrators I wrote a shell script to watch the directory inquestion and send a text message to my cell phone when a new sessionis created, but no admins logged in over the 50-somethinghours that I waitedWhile this tactic would eventually work, I wanted to speed things upI sent the following email to the programmer:Log into the admin section and check the 'edit_usersphp' page;The developer and I have done a fair amount of trash-talking aboutthis account in the past, so worried that I had successfully hackedthe site, he logged in to check the admin section As soon as his newsession was created, I hijacked it, accessed the admin page, andsnagged a screenshot as proofSo what could have been done to prevent this attack A few littlethingsFirst, making the ~/tmp directory globally unreadable would haveprevented me finding session IDs This isn't failproof, as there areother ways I could have found them, but every little bit helpsSecond, adding further session validation would have made hijackingthe session very difficult This can be as simple as storing thesource IP address in the $_SESSION array on login, then comparing iton each pageload to make sure the user isn't suddenly coming from theother side of the world Admittedly, there are legitimate uses thatwould have issues web proxies and Tor, specifically, but it wouldhave closed the hole If the site's user base are likely to be behindproxies, there is other information that can be used to identify thebrowser uniquely- client's user agent, supported protocols, OS,connection latency, etcThe biggest lesson here, though, is to follow the 'defense in depth'mantraIMAGEhttp://www.secuobs.com/revue/news/82437.shtmlhttp://www.secuobs.com/revue/news/82437.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - RSnake is starting to release details about his much-hyped clickjackingexploits, and I have to say, I'm a bit disappointedBasically, the attack boils down to using Javascript, Flash, or CSS tosurreptitiously place links or other controls under the user's cursorright before he clicks A clever attack, but I was expecting somethingnew I've been doing this for years, and Rsnake mentioned somethinglike it back in 2006 He even noted that some of these attacks havebeen around since 2002 It still hasn't been fixed, but this isn'texactly newsThe "news" part which sparked some drama is that Flash is particularlyvulnerable, and can be used to access client-side devices likemicrophones and cameras Considering Flash's past record, even earninga Pwnie nomination, it's not all that shocking Due to RSnake'sholding off on releasing the vulnerability, this bug has already beenresolved by the vendorI suppose due to Flash's huge market penetration, this is somewhatnoteworthy, but none of the users seem to careCall me cynical, I guessThat's why I just use LynxIMAGEhttp://www.secuobs.com/revue/news/82436.shtmlhttp://www.secuobs.com/revue/news/82436.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - The McAfee Secure certification is uselessOver at holisticinfosecorg, Russ McRee has been covering this indepth, but I've had the fortune to know the inside storyRuss has been making snake oil vendors' deficiencies public for sometime A few weeks before Black Hat, he and I were talking about this,and he showed me a handful of "McAfee Secure" sites All of them hadXSS holes, and many had much worse- SQL injection and other seriousissues Over the next few weeks, we traded more vulnerabilities as wefound them, and he amassed a pretty impressive list of weak, butcertified secure sites To top all of this off, we found XSS holes onMcAfee's own domainWe also got our hands on a PCAP dump of one of their scans, whichrevealed quite a bit of insight into the scanning process We wereable to prove that they do not revoke PCI compliance or McAfee Securecertifications for XSS, though the engine does indeed fuzz for andoccasionally even find themWhile they were being awarded their Pwnie, Russ put together a paperdetailing these findings He sent the paper to McAfee beforepublishing, in order to give them a chance to address the issuesbefore they were made public They surprised us both by respondingpositively Some of McAfee's top people spoke with Russ in person afew weeks later, resulting in him publishing this blog postThat was some time ago, but we still haven't seen any progress Apublished standard for what exactly "McAfee Secure" means was promisedafter 2-3 weeks, and we're now pushing five The information that wehave isn't encouraging- it appears that McAfee Secure will have adifferent set of standards for enterprise websites and the smaller "Maand Pa" shops The latter will not be required to fix XSS issues andthe former will not have to do so until an arbitrary time period hasexpired What this means is that, to a user looking for evidence thata site can be trusted, the "McAfee Secure" badge on a website willmean exactly what it does now: Absolutely nothingI suppose that anybody can offer their own meaningless certificationsand some people have, but as Rafal noted yesterday, calling thesesites "McAfee Secure", "Hacker Safe" or anything of the sort is inpoor taste at best- fraudulent on the other end of the spectrumThis brings us to todayIt appears that McAfee intendes to leverage their brand recognitionand captalize on the trust of the ill-informed They have a newservice advertised on parts of their website Found atsecureshoppingmcafeecom, it is basically a meta-search engine whichwill allow one to "shop with confidence at McAfee SECURE certifiedmerchants", according to the text on the site This actually doesn'tstrike me as a bad idea, provided the certification is worthsomething Considering the certification isn't, the whole thing israther laughableI first stumbled across this site just before Black Hat The app wasprobably not intended to be public then, but I immediatelyaccidentally, actually discovered an XSS hole in it this was one ofthe holes on McAfee's domain mentioned above While that hole hassince been fixed, the situation really isn't any better nowTo begin with, the application doesn't use transport-layer encryption,and is therefore vulnerable to sniffing, tampering, and all theman-in-the-middle attacks that we already know and love But whobothers with SSL these daysThe shopping application itself seems to be based on the same code asthat of becomecom Actually, they appear to have partnered for thisservice, because when you click a link from McAfee's site to aparticular product, you are given a 302 redirect topartnerbecomecom, then to statdealtimecom whoever that is Fromthere you are 302-ed anywhere from one to three more times beforelanding on the requested product page, provided by a McAfee SecuremerchantIn theory, at leastFor the sake of breaking things, let's build a link that will take usthrough the McAfee Secure gateway to an uncertified website We'll goto wwwbecomecom, find a product, then deconstruct the link and passits unique identifier to McAfee shopping center which, being based onthe same code, uses the same format for its links Lo and behold, thefollowing link will take you directly to the product on Amazoncom-which according to McAfee Secure, is not McAfee SecureNext, let's take a look at the app's session ID generationAdmittedly, sessions don't appear to be used for anything in the siteexcept maybe tracking user activity, but I have to assume thatsession functionality was added for some reason, and it nicelydemonstrates their own lack of understanding of web applicationsecurity Can you find the pattern1223516988361-0-9IDB1223516989602-0-gnpY1223516990254-0-SZPR1223516990913-0-F9jCThat's right folks, they're using timestamps as session IDs Now, I'veseen this practice used by banks, mortgage companies, and ecommercesites, but I never expected to see such poor practices on the websiteof the "world's largest dedicated security technology company" theirboast, not mineFinally let's look at the partners, who we have to assume will helpprovides us "a secure online shopping experience with thousands ofMcAfee SECURE sites" The sites at becomecom and dealtimecom arethemselves riddled with XSS and open redirect holes not to mentionstoring the answer to a CAPTCHA within the form to be submittedWith such poor decisions being made, can we really expect McAfeeSecure to live up to its nameIMAGEhttp://www.secuobs.com/revue/news/82435.shtmlhttp://www.secuobs.com/revue/news/82435.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - I found this a few months ago and have been racking my brain for a way touse it in a pentest Maybe somebody else can find a practical exploitfor this; so far, I have nothing I do think it's kind of funnythoughWith display_errors on, PHP will send errors to the browser, alongwith the location of the buggy code This is often useful fordebugging, and helpful to malicious users Interestingly, it doesn'tfilter the filename for HTML charactersIf you were able to, say, create a folder named"alert1337php", which in turn threw an error, you'd get something likethisIMAGEhttp://www.secuobs.com/revue/news/82434.shtmlhttp://www.secuobs.com/revue/news/82434.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - I don't think this is news to the other security people, but as adeveloper, I had never heard of this issue As far as I know, none ofthe developers I regularly work with had heard of it either thoughusing the code as recommended by the phpnet manual will prevent itIn many PHP applications, there is an admin side and a public side Itis common for developers to have an "admin check" in the code headerof the admin side, which essentially evaluates whether a user isauthorised to view a resource and either redirects them to the loginpage, the public page, or lets them through to the resourceWhat many developers don't realize is that a browser doesn't have toterminate a connection as soon as it receives a 302 redirect If youare relying on the following call to keep the riffraff out of youradmin pages, you may be vulnerable:header'Location: loginphp';I can't tell you how many times I've been able to access reports fullof user logins, order information, or even account modificationfunctionality, simply by asking my browser to continue loading a pageafter receiving a redirect If you need a testing tool to see if youare vulnerable, I whipped up this perl script one day to allow me tosimply snag admin pages or post content to them during a penetrationtestIn case it isn't obvious, you can prevent this hole simply by haltingthe flow of the application If you aren't using more advancedtemplating and flow control which I'd recommend anyways, this willwork:header'Location: loginphp';die'Kindly piss off';While obvious, this issue is incredibly widespread, and I have towonder how many developers are unaware of itIMAGEhttp://www.secuobs.com/revue/news/82433.shtmlhttp://www.secuobs.com/revue/news/82433.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - I just upgraded a few servers to the latest version of cPanel, which issupposedly fully PCI compliantYou may be wondering why, with its massively widespread use, cPanelwasn't already PCI compliant Basically it dealt with a variety of SSLissues- the administration interface supported weak SSL ciphers andthere was no way to change that through cPanel You had to hack ittogether, disabling cPanel's internal SSL libraries and using othertools to implement it properlyWhile I'm happy that they got around to fixing that issue after onlyabout 4 months, they still haven't fixed the XSS or CSRF issues thatI sent to them in June and posted here back in AugustBut I'm getting awfully jaded, and I'm not expecting them to everfix itIMAGEhttp://www.secuobs.com/revue/news/82432.shtmlhttp://www.secuobs.com/revue/news/82432.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - With Russ's latest blog post came links to a few articles dealing withthe recently exposed American Express XSS holes In short, AmEx dealtwith it badly- ignoring Russ's three attempts to contact them and onlyfixing the issue when it got posted publicly after their PR watchdogsbrought the post to their attentionOne of the more interesting articles was at BetaNews Please read itI don't think that AmEx's web developers read my blog at least Ihaven't seen many related IPs pop up in my logs, but maybe theyshould Their primary excuse for not fixing the flaw is that it didn'tget to the right peopleNow, exactly whose fault is thatI wrote a few months ago, in my "Open Letter to The Internet" thatwebsite owners need to make it painless to report security issues Ifthey don't provide a simple process for doing so, I have a hard timefeeling sorry for them Russ's goal was to get the bug fixed, andcontacting the company didn't do it Once he posted it publicly,people actually started caring Unfortunately, the fix only lasted aday before getting broken by two more researchers, which makes methink that AmEx's programmers are inept to begin withRuss made a good-faith attempt to contact the company not one, butthree times He sent messages to two different entities and gave themtwo weeks to respond If it had been me reporting the bugs, Icertainly wouldn't have given them that much effort unless I was ontheir payrollAs I wrote back in August, "We are here to help, but we aren'tnecessarily here to help you"IMAGEhttp://www.secuobs.com/revue/news/82431.shtmlhttp://www.secuobs.com/revue/news/82431.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - Here's a fun story about XSS and why we should take it seriouslyDue to the location of my residence and the ineptness of my HOA, thebuildings around me get fiber optic, but I can't So I use Qwest DSLfor my home internet access While I'm not a huge fan of the company,they generally tend to get things done and not cause me too muchgrief There's a lot I don't like, but not enough to quit using theirserviceAbout a year ago, I was paying my bills and visited the "My Profile"page Out of curiosity, I stuck a few quotes and HTML tags into a fewfields and much to my surprise not really, found some permanent XSSholes While I don't like seeing it, this alone isn't really news asevidenced by the recent string of holes we've been finding on bank andcredit company websites I left one field set to pop up an alert boxevery time I log in and mostly forgot about itA few months later there was an internet outage The Tech Support callwas a whole 'nother adventure what "scheduled router maintenance"results in a 30+ hour outage There's something they weren't tellingme, but the interesting part was when the rep brought up my accountinformation She sounded confused on the phone, said something like"what's this This is weird" and after a few loud clicks, seemed toget back on track and finish the call It wasn't until after I hung upthat I realized what had happened- my XSS has executed in the contextof a Tech Support rep, who presumably has access to other accounts,network information, and other goodiesI never did anything with it, but did mention it to a few of Qwest'sIT people I met a few months later They didn't seem too concerned Ithen looked through the Qwest website a bit more and found a few moreXSS holes- these ones in the public side I reported them, posted themon XSSed, and forgot about them They never did get fixedWhile finding security holes in the financial sector seems to be allthe rage these days, I'm going to focus for the next while on somepublic utilities Frankly, they scare me more- they're oftengovernment owned and operated, so have less market-driven controls inplace Most of them know your Social Security number, your credit cardnumber, your checking account information, and they directly affectyour everyday lifeWouldn't it be scary if your power company used outdated perl scriptsto handle billing and account management Mine doesIMAGEhttp://www.secuobs.com/revue/news/82430.shtmlhttp://www.secuobs.com/revue/news/82430.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - Despite my vocal criticism, I really had a lot of hope for the McAfeeSecure Standard I certainly think there's a need for well-defined andcomprehensive web security guidelines The PCI-DSS is a good start,but very few website owners know when it applies to them, much lesshow to comply Enforcement of PCI compliance is, let's face it, ajoke Considering that Visa, American Express, and the PCI-DSS's ownFAQ have been having XSS holes lately, that's not really a surpriseOf course, I didn't expect McAfee Secure to have any consequences fornoncompliance besides not being able to display that shiny logo onyour site What it can provide, though, is a set of guidelines forthe web developer and administrator to realistically get a feel forhis own security You know, all that stuff that you can already getover at owasporg Those guidelines, combined with a reliablekeyword: reliable certification system could actually be prettyhelpful to the web security world I'm of the opinion that is aproject for the nonprofit sector, but I was willing to give McAfee achanceBut, they've proven again with their newly published standard, thatthey either don't understand or don't care about web security It's ashame, reallyTo begin with, the published standard reads more like a sales brochurethan a standard I'm convinced that's really all it is There's notreally much on there that we haven't already seen on their websiteThe only real new thing is a list of security risks that areidentified in the scans and, we assume, risks that would prevent onefrom being certifiedInterestingly, they compare their own standard with the PCI-DSS aswell as somehow, with a SSL certificate Seeing as an SSLcertificate is not a standard, this doesn't make a lot of sense I'mreally trying to wrap my head around this comparison, but I'm notgetting it According to the "Standard", either implementing SSLencryption is required to aquire a certificate It's not, or McAfeeSecure somehow provides SSL encryption it doesn't I guess there's athird option- they're comparing apples to oranges and hoping we don'tknow the differenceIn that same chart, they compare themselves directly to the PCI-DSSThey make a point of the fact that they have many things PCI doesn't,like checking for "Misuse of Personal Information" Apparently, thePCI-DSS doesn't have anything to say about that oh, wait That'sthe whole point of PCI Here's the first full sentence of the PCI-DSS:"The Payment Card Industry PCI Data Security Standard DSS wasdeveloped to encourage and enhance cardholder data security andfacilitate the broad adoption of consistent data security measuresglobally"Here's a thought- McAfee is a PCI Qualified Security AssessorShouldn't they, of all people, understand the PCI-DSS Are theyimplying that their standard is superior Under McAfee's "Required forCertification" section, the following items must be handled for PCICompliance, but are only "Optional" for McAfee Secure:* Error Handling* Session Exipration* Directory Indexing* Client Side Vulnerabilities* Server Misconfigurations a broad category if I've ever seen one* SSL Encryption Seriously, that's not a requirementMaybe more information from McAfee is required, but they aren'tproviding it This is obviously only an outline of a standard at bestNo details are given about what exactly "Sever Misconfigurations" are,and I hope that a standard including actual descriptions of what isrequired for certification is forthcoming The standard that theypublished is a jokeI was awfully disappointedIMAGEhttp://www.secuobs.com/revue/news/82429.shtmlhttp://www.secuobs.com/revue/news/82429.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - I know I've made my views on shared hosting clear in the past, but I keepcoming up with more reasons to not use itTo begin with, let me start by saying that yes, I know thatmod_userdir isn't recommended by its creators, cPanel, or Apache forsecure applications I may be grabbing at low-hanging fruit here, butthat doesn't change the fact that its use is hugely popular formass-hosted webservers It is a convenient way to get a lot of sitesonto a server, to get valid SSL certificates for each, and foraccessing/managing content on all of themWith that out of the wayFor those that aren't in the know, mod_userdir is an Apache modulethat allows you to create a separate website for each user on aserver These sites can all be accessed by going tohttp://servernamecom/~username The module is installed on mostApache setups by default, but isn't necessarily always enabled Mostmass-hosted cPanel servers make extensive use of it for a variety ofreasonsI should note that in the following examples, 'victim' is the usernameand 'victimcom' the domain of the targeted web site 'attacker' and'attackercom', respectively, are used to compromise victim, but donot have to be run by the attacker- they can simply be accounts withpoor log management, PHP or XSS holes, depending on the exploit Withhundreds of sites on a server, finding such a site is usually trivialcPanel's default Apache configuration has a handful of flaws in itthat make mod_userdir suprisingly useful to the wily attacker Tobegin with, the attacker can attack one site, but have the logsdeposited in another's log directory To do this, hit the serverthrough the domain of the site that you want to logs to show up on,but use the username of the target site:http://attackercom/~victim/adminphpWith this url format, we can scan, probe, and bruteforce loginswithout the target site hearing a peep from his apache logs Even ifhe does suspect foul play, he will have a hard time getting the logs,as theoretically, at least both the server's administrator and theattacker's site will be rather resistant to turning over their ownsite's logs without a court orderIf you can't find a decent user account on the server, you can alwaysuse the server's IP address instead of a domain and run the scripts asapache rather than attacker This way, only root will be able toaccess the logs, and surprisingly few administrators ever review theglobal apache logsThe one caveat here is that cPanel does allow you to set up a"default" account which may end up catching the logs, but if you godirectly to the server's address and see something like this, you havea winnerDue to poor default Apache configuration, directory listings on/cgi-bin are enabled when you access it in similar fashion:http://victimcom/~victim/cgi-binThis alone has been enough for me to crack accounts in pastpenetration tests While it has been fixed recently, past versions ofcPanel would also print out cgi scripts' contents rather thanexecuting them Still, included files without a cgi, pl, plx, pplor perl extension can be easily located and downloaded with thismethodBy going to http://attackercom/~victim, we can execute PHP scriptsfrom the user "victim", with the server thinking that we're"attacker" This can be handy for a few things First off, printingout $_SERVER'DOCUMENT_ROOT' tells me that I'm running in/usr/home/attacker/ By contrast, the server knows that$_SCRIPT'FILENAME' is /usr/home/victim/public_html/scriptphp Thescript is executed with victim's privileges, so you can't read orwrite anything that the user doesn't normally have access to, but ifvictim is including files or locating resources based on the$_SERVER'DOCUMENT_ROOT' variable, we can manipulate it, forcing theapplication to load your own PHP codeLet's say you don't even want to bother with PHP If you can find asingle XSS hole on any user's site on the server and you can, Ipromise, you just have to get people to hithttp://victimcom/~attacker/XSSedPagephpLet me repeat that- You can XSS every domain on an entire server Manyof these servers contain hundreds of users In cases where an entireserver is owned by one web development company, that server's phpapplications are usually homogenous The implications of this arehuge While many are certified as such, no site on a cPanel servershould be considered PCI compliant Many people downplay theimportance of XSS exploits, because they have to be individually foundand have custom exploit code written With mod_userdir and a bit offancy coding, an attacker can compromise hundreds of accounts, allperforming hundreds of ecommerce transactions per dayThat's just good economicsIMAGEhttp://www.secuobs.com/revue/news/82428.shtmlhttp://www.secuobs.com/revue/news/82428.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - It was kind of a trend for a while to post Myspace XSS holes, but thatkind of died out I had a bit of time this morning and decided to findone Given that these days, MySpace has a huge amount of partnershipswith other companies, all creating their own apps, it didn't takelongThe XSS URL is:http://ksolomyspacecom/actions/showSongProfiledorid=1135511a"style="font-size:25em" onmouseover="alert1337IMAGEhttp://www.secuobs.com/revue/news/82427.shtmlhttp://www.secuobs.com/revue/news/82427.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - Just as I joined Twitter and felt dirty for doing it, it paid offApparently, there will be a congressional hearing on the PCI-DSStomorrow and whether it actually does any goodMore info from pcianswerscom I'll be watching the webcast with greatinterestIMAGEhttp://www.secuobs.com/revue/news/82426.shtmlhttp://www.secuobs.com/revue/news/82426.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - Maybe I expected too much from the congressional hearing on PCI-DSSWhile the stated intent was to discuss whether it does any good, itpretty much boiled down to the merchants, the PCI council, and the DoJsaying "It's not our fault, it's your fault" to each otherYou can still view the video online Despite the overall uselessnessof the hearing, a few interesting points were made:Companies need to understand that PCI compliance is a bare minimum forsecurity It takes an ongoing security program, with periodic auditsand evaluations, to actually improve an organization's securitySimply passing the scanner test does not make you compliantRep Bennie Thomspon noted that the PCI system isn't working, and putforth the idea that the government should take over from privateindustry I hope it doesn't come to thisEverybody seems to agree that the standards aren't really where we arelacking, but everybody disagrees on where the problem is The PCIpeople said it is because they are not followed by the vendors, andthat there has never been a breach on a PCI compliant organization Ifthat was the goal, we should just reduce the standards down to "Don'thave any holes" The goal is to reduce data breaches, not reduce thenumber of compliant companiesThe merchants, in turn, said that it is too hard to be compliant- theynoted that the auditing and the techology to maintain compliance isexpensive, and that the payment card industry is far behind in thetechnology While true, the fact remains that most companies havedismal security practices, and that fixing this is their problemMichael Jones, the CIO from Michaels Stores, Inc was probably theonly one making coherent statements He testified that the standardsare too complex and arcane, designed to protect the Payment CardIndustry rather than the merchants or consumers, and impossible toimplement fully in any caseThis may be proving his point about the difficulty of stayingcompliant, but Mr Jones testified that he was "proud to report thatMichaels has never had evidence of a breach of consumer data" If thisis true and this is a big if, it's only because nobody has tried AnXSS hole in michaelscom was reported to XSSedcom almost 2 years ago,and still hasn't been patched In all that time, they have not beenPCI compliant I am betting they would disagree with this pointI went to michaelscom and noted that their "Find A Store" feature,which is outsourced to a third party, contains XSS holesFinally, the money shot, it took me less than 60 seconds of searchingto find the following hole in forumsmichaelscom, which is a2-for-one: XSS, and SQL injection with error reporting and scriptpath disclosure thrown in for free:I have to wonder who has been doing their PCI auditingExploit URLS:http://directwhere2getitcom/cwc/apps/w2giphptemplate=search%22%3E%3Cscript%3Ealert1337%3C/script%3Eetclient=michaelshttp://wwwmichaelscom/art/online/searchsearch=yesettype=0etsearchWords=%3C/script%3E%3Cscript%3Ealert/xss/%3C/script%3Ehttp://forumsmichaelscom/community/searchphpCat=asdf%22%3E%3Cscript%3Ealert1337%3C/script%3EIMAGEhttp://www.secuobs.com/revue/news/82425.shtmlhttp://www.secuobs.com/revue/news/82425.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - You've probably noticed that I haven't updated much since the beginningof the year I've been studying up for a new certification, and as ofthis morning, I am a certified Application Security Specialist I'mhoping that being an ASS will give me new respect from my peers in thesecurity industryIMAGECertified Application Security SpecialistIMAGEhttp://www.secuobs.com/revue/news/82424.shtmlhttp://www.secuobs.com/revue/news/82424.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - I was just sent this code by a hacker who asked me to call him "bWNrd-A"Apparently he found his way onto the Scanless PCI network and managedto get a copy of the application they use for their auditsI've been tearing into PCI compliance testing pretty hard lately, buthaving reviewed the code, I can't see a lot wrong with itIMAGEhttp://www.secuobs.com/revue/news/82423.shtmlhttp://www.secuobs.com/revue/news/82423.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - This is the first in a series of posts on "cool things I broke with webexploits"A few weeks ago, I demoed an access control system from ADT Being thebad person that I am, I was less interested in the system's featuresthan I was in the ways that it could be broken, and as soon as I heardit had a web-based administration interface, I knew I was going tohave funLike any good hacker, I paid careful attention through thedemonstration, probing for more information about the system "Howmany customers use this system Banks too, huh Which banks Do theyall use the same admin interface", slyly jotting down the usernameand password from the post it note on the demo kit, and making carefulnote of the admin login's URL After the presentation, I did a bitmore online research, and came up with the following-The system in question Brivo ACS is widely installed by ADT, but wasdesigned by a company named Brivo Systems, LLC Brivo runs the serversand maintains the application ADT, as well as a wide range of othercompanies, function as dealers, resellers, and installers Roughly25,000 doors are controlled by one server, with users ranging fromfinancial institutions to IT datacenters The system runs the logicbehind HID and other token-based authentication mechanisms- You scanyour card, the server decides whether you are allowed in, logs therequest, and opens the doorSo I set out to find an exploit It being a web app, I was in mycomfort zone Probing for input validation holes, I was prettyimpressed with the thoroughness of the filtering until I found anerror pageI love error pages, they tell you all kinds of useful information,including account data, a stack trace, and internal applicationvariables For bonus points, they print it all out without anyescaping Once I found the error page, I was just one request awayfrom a working XSS exploit:The consequences of this are huge- while it may not be a simpleexploit to pull off, this gives an attacker the ability to stealsessions and manipulate a building administrator's browser Anattacker can easily add his own keycard to the list and walk aroundsecured areas uninhibited That's a pretty Big DealSo, for all those people that think XSS is a minor issue, I presentthis as Exhibit AOn the plus side, Brivo's response to my emailed vulnerability reportwas exemplary Almost immediately, I had a call to let me know theywere looking into it The next day, a developer spoke with me aboutit, and by the end of the week, a patch was being tested I have togive them credit- they responded quickly and professionally They'recurrently doing a full review of their systems for other configurationissues like the error page and input validation holes They eveninvited me to poke around some more once the review process iscompleteLessons learned- Web-based administration is tricky stuff to do right,XSS does very cool things, and I like companies that listenIMAGEhttp://www.secuobs.com/revue/news/82422.shtmlhttp://www.secuobs.com/revue/news/82422.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - Readers who have been with me from the beginning as well as the guy thatread my entire site yesterday will recall that last fall, I postedseveral XSS and CSRF vulnerabilities with the cPanel WHM interfaceEssentially, these vulnerabilities would allow me, as an attacker, toroot a cPanel server simply by having an authenticated administratorbrowse my website At the time, the vendor did not respond to myvulnerability reports, and the problems went unfixed until Iresubmitted them to Secunia in FebruarycPanel finally took action, fixing the XSS hole that I had foundHowever, the CSRF issues which were much more critical in this casewere ignored Their response to these issues was that CSRF can beprevented using the "XSRF Protection" feature in the WHMadministration interface I double checked and sure enough, there wassuch a feature It was obscure, disabled by default, nowhere to befound on the cPanel documentation pages and FAQ which ironically hasits own XSS holes, and had verbage next to it that would discouragemost administrators from enabling the feature Essentially, cPaneltreats these critical CSRF holes as a feature:cPanel XSRF Protection SettingI didn't have all that much time to look into it until today, when Idecided to actually test this feature Digging into the code, thefirst thing I noticed was that all the "XSRF Protection" does is checkthe referrer that your browser sent- if it doesn't match one of theknown domains for the server, the requested action is not allowed totake placeThe first way around this was obvious If your browser does not sendany referrer, the XSRF protection does not kick in Referrers can besuppressed several ways, but the first one that comes to mind for meis SSL Many browsers will not send referrers when coming from an SSLpage This morning, I wrote a proof of concept that bounces the useroff an SSL-encrypted open redirect there's plenty of them out thereA few tests with the latest version of cPanel confirmed that Firefox 3does not send a referrer, and the XSRF Protection feature had noeffectAssuming that the browser did send referrers, there are still plentyof ways to bypass it The next thing that comes to mind is simplyusing a domain on the whitelist to execute the attack With a fewhundred users on most cPanel servers, finding an open redirect, fileupload, XSS, or cross-site framing hole is usually trivial If youcombine that with the mod_userdir attacks I posted last week, you canincrease the effectiveness of this attack even furtherThe next idea I had was to add my domain to the list of alloweddomains It requires access to a local account on the serverlegitimately or not, but any user can add extra domains andsubdomains to his site- subdomains which are considered "allowed" bycPanel This provides yet another effective way to avoid the XSRFprotection featureThe back end code for the cPanel interface is an absolute mess- it'samazing that it works as well as it does Not just the WHM interface,but the entire package is vulnerable to CSRF and XSS attacks at nearlyevery level This software manages hundreds of thousands of websitesThis is badBut preventing CSRF would break your third party billing software, sowe should probably allow it by default That's a great ideaEdit: cPanel did, in fact, mention the XSRF Protection feature ontheir blog about a year ago This post calls the CSRF issues "securityissues, which range in severity from trivial to medium-critical"IMAGEhttp://www.secuobs.com/revue/news/82421.shtmlhttp://www.secuobs.com/revue/news/82421.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - This came up in a discussion with a developer quite a while ago, and I'vebeen meaning to write a proof-of-concept So far, I haven't had achance to, but I think the idea is interesting enough to talk aboutaloneThe idea of using semantic CAPTCHAs has been discussed quite a fewtimes over, and even implemented in a few cases So far, theseimplementations have worked reasonably well, but that is only becausethey aren't worth the trouble yetOne example of a semantic captcha is found on phpnet, the onlinebible for PHP developers Each PHP function's manual page has a"comments" section where people can leave helpful tips for using thefunction in question This comments form is a particularly poorimplementation of a semantic CAPTCHA it's vulnerable to replayattacks, has a very limited number of possible solutions, among otherthings and also contains an open redirect hole Let's focus onsolving the captcha without using those flawsPHPnet semantic captchaThis captcha asks the user to solve a math problem, but substituteswords for mathematical symbols In this example, the question is "twominus one" Anybody who has ever used the Google calculator can solvethat one with a single request tohttp://wwwgooglecom/searchq=two+minus+one:Google Calculator breaking Semantic CaptchaIt's a simple matter of plugging the data into google and parsing theoutput It could be argued that this isn't really a semantic CAPTCHA,just a mathematical one with a semantic output format Otherdevelopers suggested asking pop culture or trivia questions Theexample that was given to me was "Is Paris Hilton A Slut" Theobvious flaw with this question is that it has a boolean solution, and50% isn't a very good success rate for a CAPTCHA However, if wewanted to improve our chances, we could turn to Google again:Google Results: Is Paris Hilton a SlutJust by parsing the titles of the returned results pages, we get twotitles with negative operators If we parsed the result descriptions,we'd get a few more, but statistically, it's pretty clear that Googlethinks Paris Hilton is a slut The AI to do this type of languageprocessing has been around since 1966IMAGEhttp://www.secuobs.com/revue/news/82420.shtmlhttp://www.secuobs.com/revue/news/82420.shtml Secuobs.com : 2009-04-12 13:24:29 - skeptikal.org - cgiecho is a test cgi script, usually packaged with a formmailer calledcgiemail It's found in the cgi-bin directory of a lot of sites, dueto it being a default script in many cPanel installations The scriptwas written by somebody at MIT some time ago, and so is common onhigh-profile sites such as mitedu andxmissioncomThe script contains XSS and path disclosure holes, one example ofwhich can found on mitedu, but that's not really the emphasis of thisreportBasically, cgiemail allows a user to specify a template file fromanywhere within the web root When data is posted to it, substitutionsare made based on the parameters posted and the content of thetemplate fileFor example, if a template file "/templates/mailtxt" contains thefollowing:Hello firstname lastnameWhen the parameters firstname=dretlastname=evil are submitted tohttp://victimcom/cgi-bin/cgiecho/templates/mailtxt, the returnedpage will make those substitutionsMany web scripting languages dereference array values using the characters, so the cgiecho script can be forced to return the contentsof sensitive files if the index of any one array is knownIf a configuration file is located at /includes/configphp andcontains the following:define'HOME', $_SERVER'DOCUMENT_ROOT';define'USERNAME', 'victim';define'PASSWORD', 'secret';An attacker can post "%27DOCUMENT_ROOT%27=bork" tohttp://victimcom/cgi-bin/cgiecho/includes/configphp and read thecontents of that filedefine'HOME', $_SERVERbork;define'USERNAME', 'victim';define'PASSWORD', 'secret';For testing purposes, a form to generate correct attack parameters islocated hereIMAGEhttp://www.secuobs.com/revue/news/82419.shtmlhttp://www.secuobs.com/revue/news/82419.shtml