First there was the QVC and OpenSocial incidents that I blogged about, but there are others, many others. And a lot of the references can via WASC's Web Hacking Incidents Database (WHID). While the industry won't have it own form of blaster or slammer to wake people up to the problem, maybe like the old saying goes, we'll make up for it in numbers.
1) A pair of college students hacked into the PeopleSoft database of the California State University at Fresno's to change their grades. Looks like they used a tab bit of insider access to get the job done. For their trouble they face potentially 20 years in the pokey and 250K in fines. If convicted or plead out, the charges will likely be reduced way down, but still. Wow! I wonder how this crime compares with that of a DUI.
2) Funny enough, Oracle is suing SAP for hacking their customer portal. According to the story, “Oracle accuses SAP of attaining the log-in information of recent or current Oracle customers and using it to download software and support materials from the Web site for the PeopleSoft and J.D. Edwards product lines. The materials allow SAP to tell Oracle customers that it can support their PeopleSoft and J.D. Edwards products while they transition to SAP products, Oracle said.”
3) Scarborough & Tweed recently disclosed that the personal data (name, address, telephone #, CC#, acct #) of 570 of their U.S. customers may have been compromised through the use of SQL Injection.
4) A couple of hackers that RSnake knew, Sirdarckcat and Kuza55, attempted to compromise him and his site in a prank gone wrong. They were not successful, but RSnake was right to be angry with them for trying. RSnake being the chill and understanding guy that he is and the hackers taking full responsibility for their actions and expressing remorse were able to resolve matter peacfully. All has been forgiven. Its really good to see how these guys were able to work things out without unnecessary escalation.
5) MustLive’s is actively running his Month of Bugs in CAPTCHA's. About one week in and Google, Blogger, reCAPTCHA, and CraigsList are a the notables on his list. CLARIFICATION: With respect to reCAPTCHA, "The issue that was found was actually a drupal specific issue -- it applies equally to any Drupal CAPTCHA implementation. In fact, a patch for this issue has been available for months."
6) Art.com and Vertical Web Media disclosed that someone broken into their websites and nabbed customer names and credit card #'s. Neither said how it occurred.
7) A couple of other defacements took place (Chilean Presidency, Aberdeen City Council), again didn't say the method used, but worthy of a mention.
8) Internet bank Cahoot had an issue where a customer found that by guessing usernames and manipulating URLs they could get access to other accounts.
9) Ryan Barnett spotted some Blind SQL Injection in the wild through WASC's Distributed Open Proxy Honeypot Project. An interesting find! This particular project is going to teach us a lot about webappsec and what is really going on out there. Plus its data set posed unsolved challenges for people to dive into.
10) And while not recent, a really good video demonstration of how to take advantage of XSS on Facebook.
7 comments:
Jeremiah asked me to post this email which I wrote to him clarifying some of the CAPTCHA issues in this post
--------
Hi Jeremiah,
I'm one of the developers of reCAPTCHA. On your blog, you stated:
5) MustLives is actively running his Month of Bugs in CAPTCHA's. About one week in and Google, Blogger, reCAPTCHA, and CraigsList are a the notables on his victim
list.
reCAPTCHA was not a "victim" in any sense. The issue that was found was actually a drupal specific issue -- it applies equally to any Drupal CAPTCHA implementation.
In fact, a patch for this issue has been available for months:
http://drupal.org/node/114364
I'd really appreciate if you could clarify this -- I've done so on the source blog entry, however since you don't link to that, it's hard to find the clarification.
For what it's worth, some of these other "CAPTCHA issues" really aren't bypasses. For example, the blogger one is simply a XSRF which you happen to need to have a
CAPTCHA solution to make use of. In fact, the only role CAPTCHA plays in the blogger issue is to make it harder to exploit the XSRF in question (because you need to
solve one CAPTCHA per XSRF).
I hope you'll put the reports of the MoBiC blog in context for your readers. Some of the issues reported are real issues (like the craigslist one), but others seem to
be reaches just to increase the number of bugs found.
Thanks!
-Ben
Ryan Barnett doesn't allow comments, so I'll post this here.
What he is seeing is much more likely a broken PHP script, rather than an attempt at Blind SQL injection, especially considering that the code he highlights is not valid SQL, but is valid PHP code.
It reminds me of those spam emails with a subject of $subject, personally.
The Cahoot bank story is 3 years old :)
And I agree with kuza55 that what Ryan Barnett is seeing is not an attempt at blind SQL injection as the code is definitely PHP and not any form of SQL.
I guess this is what I get for not properly checking my references. Sorry. Ryan Barnett has been notified of the issue and is making updates, he removed the post for the blog index, but the file still is there for now.
Kuza55 - thanks for the feedback. As it turns out, we were simultaneously reviewing this specific transaction also. You are right, it appears to be a False Positive. It is not that the rule triggered on something that it shouldn't have (which can happen if the rule is too generic), but rather that this was not an actual Blind SQL Injection attack.
The string that was matched was indeed a PHP code snippet that was present in the page. It seems that the SPAMMER's script automatically included all of the hidden arguments in their request. I guess that instead of taking the time to code in the proper intelligence as to what fields are required for their request, it is just easier to "throw the kitchen sink" at it and included everything. Most web apps will not error out with extra parameters, however they will if you are missing require elements.
This does raise an important issue - we need help with data analysis! If you are interested in participating in the WASC honeypot project (even if you don't want to deploy an actual honeypot) then please let me know and we will get you signed up for the project mail-list. This way, we can get more eyes on these alerts for validation.
Hi Jeremiah,
I have been looking at your steal history code, I looked at other code which were developed using your code, but I do not understand the logic that is used to steal the history. The code works fine, I didn't get the trick here, I'd really appreciate if can explain this trick.
kalyani, the trick is easy. Basically you print out a bunch of links on the screen that you want to test if the the user has been to. Then you use some JS to check the CSS computed color of the link. If its a visited link color, like purple, you know they've been there... if not... then they haven.t
Post a Comment