Paid Advertising
web application security lab

Archive for the 'Webappsec' Category

Allbots.info Imagetotext.com

Friday, June 13th, 2008

If the title of this post sounds awfully spammy, that’s because it is. Someone sent me a link to allbots.info and imagetotext.com today. Both of which are tied together into one system that allows someone to purchase a robot and the human CAPTCHA breaking necessary to create accounts in some of the largest social networking sites out there.

These include MySpace, Hi5, Facebook, Youtube, Gmail, and on and on… This reminds me a lot of XRumer which is also designed for the same purpose, but more for message boards and the like. Making hundreds of accounts, for spamming is getting more commonplace and accessible. Just plunk down your stolen PayPal or Google Checkout IDs and you’re off to the races! CAPTCHAs aren’t working folks - we’re just creating another micro-industry.

Key Point SMiShing

Sunday, June 1st, 2008

Yesterday, my gfnd got a SMiShing text to her phone against Key Point Credit Union. The obvious tip off that this was an attack was that she doesn’t have an account with Key Point, not to mention the other clues. This is the first instance of it in the US I’ve heard of, although I’d be surprised if this was the first example of it. The number it was from was 905-392-8040. Unlike normal phishing though, it’s much harder to report the issue. Most people wouldn’t have the first clue how to log, forward or respond to the SMiShing attack.

Dear Key Point Credit Union Customer, we regret to inform you that we had to lock your bank account access. Call 800-482-0452 to restore your bank account.

Just another thing to be worried about. I have no idea what the lift on SMiShing attacks are compared to their online variants, but it’s an interesting phenomena. Since email addresses of SMSs are fairly easy to predict, it’s fairly simple to re-purpose spam gateways that are designed exactly for this purpose. The only trick is gathering enough mobile phone numbers.

TJX Whistle Blower

Thursday, May 22nd, 2008

I had some very disturbing news today from one of the forum users - he had just been fired by TJX for whistle blowing on their security issues. CrYpTiC_MauleR, who’s posts on TJX can be found here was fired today by TJX for talking about the company’s security flaws. This is the same company who recently lost millions of credit card numbers, for those of you who don’t recall. They tracked him down by IP (we’re still not completely sure how they did this, but we think it may have to do with a DynDNS account he uses), contacted his ISP to find out who he was, brought him into the office, questioned him about what he found, asked for him to write down his thoughts on how to fix the issues and then promptly fired him.

I completely understand why a company would want to reduce their risk, but this doesn’t bode well for future would-be whistle blowers, or for the future state of security for TJX. CrYpTiC_MauleR has been a long time poster on sla.ckers.org and has made a lot of contributions. I, for one, feel terrible about what happened, and I implore the community to reach out to him on sla.ckers.org, especially if you are looking for someone to help out in any open positions you might have. I think the best possible outcome of this would be that he gets a better job for caring about consumer security at large. Only time will tell.

But as a side note, I must caution everyone who prefers full disclosure as a rule, to be particularly cautious when posting that information, especially when it’s under your own name or a name you use elsewhere that may be tied back to you. Many of the largest companies on earth post to or read this site regularly, and no doubt someone will take personal offense at your actions, so I encourage everyone by way of example to please protect yourself - especially from those who would claim to care about security. Only actions matter in this world.

Google Health

Wednesday, May 21st, 2008

It must be a Wednesday because it’s feeling a lot like “pick on Google” day! Let’s see here, what’s in the news today? Oh! Google Health - from the same company that brought you countless vulnerabilities both fixed and unfixed, with a policy of not alerting people to security issues comes a new service that asks you to input all your most sensitive personal health records! “But it’s medical records,” I can hear people saying, “surely they’ll be as secure as any HIPAA compliant entity.” Except, legally not so much… (from their terms of service):

Google is not a “covered entity” under the Health Insurance Portability and Accountability Act of 1996 and the regulations promulgated thereunder (”HIPAA”). As a result, HIPAA does not apply to the transmission of health information by Google to any third party.

I think it’s a shame Google found a legal get out of jail free card to absolve themselves from securing consumer medical records in the same way everyone else who handles this kind of data does. At least Google gives you advice on how to protect your personal data. By uhm… protecting it!

You are responsible for the security of your passwords and for any use of your account. You must immediately notify Google of any unauthorized use of your password or account by following the instructions at this link: http://www.google.com/support/accounts/bin/answer.py?answer=48601

Incidentally my favorite line from their form is:

Google Accounts: I think someone else is using my Google Account. Tip: In most cases, this problem can be resolved by resetting your password. Please do so before completing our form.

Resetting your password will recover your stolen personal data and make you and your family whole again, I guess. As a side note, a year has come and gone and silently the Google security blog has had its first birthday. Has anyone noticed? I recall a year ago I said to a number of people I’d be surprised if anything interesting came out of it, and here we are a year later, with about 13 posts (one a month) and pretty much nothing of note about any actual issues/flaws has been discussed. There were two brief non-technical posts about “Lemon”, a year ago, to be fair. Maybe someone learned something from it, but it sure wasn’t me or any researchers I’ve talked to. Happy belated birthday, Google Security! Another year has come and gone, and the redirects still aren’t closed - how about a post about that?

As another noted security expert pointed out to me two days ago - Google represents the single greatest travesty of our generation. You gather the largest collection of the most brilliant minds you can possibly find, for the sole purpose of displaying ads next to search results. Remember, this is the same company who just a few short months ago was ranked the single worst in privacy of all the top Internet sites. Great - just who I want to be the keeper of my apparently non-HIPAA regulated medical data.

Okay, enough picking on poor Google for today.

HTTP Proxies Bypass Firewalls

Tuesday, May 20th, 2008

This may seem painfully obvious to some people, but I looked around and couldn’t find a reference to it, so I apologize ahead of time for anyone who already knew this. When we normally think of how attackers use proxies they are almost always just trying to hide their IP addresses. id and I have written papers on bypassing content restricting firewalls using proxies, etc… Those are all fine topics, but that’s not what this post is about. I was pouring through my logs a few weeks ago and came across a number of people attempting to see if I was running an open proxy. Obviously I’m not, and the reason someone would likely check is that it is a robot looking at large swaths of the web for open proxies.

I ran into an open proxy after that and started poking around with it. The obvious way to look for it was to type in “GET http://www.yahoo.com/ HTTP/1.0″ and see if it shows you Yahoo’s homepage. But then it occurred to me that this could be used for Intranet hacking as well. The open proxy doesn’t have to point out to the web. It can, in fact, be pointed inward, to internal addresses. Here’s a diagram of what I’m talking about:


Click to enlarge

The first scenario is what most bad guys use proxies for. They connect back out to the Internet, to hide their real IP addresses. The second scenario, however, would allow them to use that same proxy server to hack other machines on the same network, including the firewall itself. The funny part is that there are tons of machines out on the Internet who have already been compromised, and the bad guys have intentionally placed proxies on these machines for other nefarious purposes. But it can also be used for internal reconnaissance, or worse. And yes, I have found this in the wild. By quickly enumerating the most likely places within RFC1918, it’s fairly easy to spot where the majority of devices are in most networks (note that this kind of internal scanning will become more difficult with IPv6).

If there are internal machines with critical vulnerabilities on them, the proxy can be used to connect back into that network, to exploit those vulnerabilities which may give a bigger foothold or uncover other sensitive information. If you haven’t scanned your own network for open proxies, you probably should. This is yet another reason to limit what your web servers have access to within your own networks.

Phishing Site in Email

Thursday, May 15th, 2008

I was looking at a phishing email last night for OANDA FXTrade. At first glance I could see something a little different about it. Instead of linking directly to the phishing site in the email, it contained an attachment (an html file) that you are supposed to double click on. The page is a flat HTML page, with nothing of substance on it, other than a form that tries to get you to submit your data to http://0x47f865c1/webview/images/fxtrade.php (which automatically redirects you to the correct website, if you go there directly).

That’s a fairly clever implementation of a phishing email, because the phishing page is actually on your local computer, not on the web. So it’s harder for anti-phishing researchers to find anything of interest on the remote computer, or even verify that it is a phishing site. But I think I must be getting a little jaded because as soon as I saw the html file I was actually disappointed. While clever since the HTML file contains the phishing site, why on earth wouldn’t they put malicious code in it? Think about it, if someone is dumb enough to open a HTML file on their local computer, why wouldn’t you use it to install malware or something equally bad? To me it just seemed like a no-brainer. I suspect these malicious techniques will eventually converge, but for now, I don’t think the phishers understood exactly what power they had.

Spammers Hurt The Blind

Sunday, May 4th, 2008

There’s an interesting link talking about the lawsuit that Rite Aid just settled regarding their accessibility issues. In part it was in regards to their in-store issues, but it was also about their online accessibility, specifically around CAPTCHAs. So I spent a little time doing some more research into other issues around CAPTCHAs and the blind and in fact there are even concerns around the audio CAPTCHAs for the deaf-blind users.

One thing that was interesting is that many of the sites that have been targeted for law suits and angst have been either online retailers or websites that are heavy text based websites (Typepad, Livejournal, etc…). I guess that makes perfect sense, I just hadn’t thought about it before. I would expect there to be a lot more of this in the future, so if you use CAPTCHAs I’d consider at least getting an audio version, as I’ve discussed countless times. An interesting thought though: spammers have made it harder on the blind. Yet another reason to hate spammers, I guess.

Older Browsers Blocked By PayPal

Thursday, May 1st, 2008

This news is coming in a little late but I thought it was worth talking about. PayPal apparently is going to start blocking older browsers that it deems as a security risk to it’s own users. Pretty funny in a way - consumers can’t protect themselves so PayPal is having to tell them to upgrade to something that doesn’t come from the Paleozoic era.

There’s an upside to doing this and a few downsides. The obvious upside is that people will be using more current and theoretically more secure browsers that support EV certs and anti-phishing technology. The downsides are that some people seriously cannot afford to buy new equipment, or have chosen older browsers that are less likely to be exploited because no one is writing exploits for them any more. And the worst downside to the browser eco-sphere is an even more homogeneous browser base. I’m not sure if I’m completely in the “this is a good thing for security camp” but it’ll be interesting to see how it plays out over time.

eFashion Security Overview

Thursday, May 1st, 2008

I was pointed to an interview with Ed Foy of eFashion. It’s a pretty interesting interview about how companies are reeling in a post TJX world. The good news is obviously people like Mr. Foy are paying attention to the problem and trying to do their best to fix it. The issue is everything mentioned into the article has nothing to do with the problems TJX faced. He mentions network access control and Hacker Safe. Hrmm… my personal feelings about the validity of Hacker Safe being anything other than a marketing gimmick aside, security this does not make.

TJX was compromised through WEP, poor network access controls and poor infrastructure, not web compromises. Not that you should ignore the web, definitely not, but throwing a Hacker Safe logo on your site doesn’t do anything for your security other than make you a bit of a joke. Sure, explaining to your customers that you care is important, network security is important, and sure, even a logo on your site explaining that is okay. But it’s no substitute for real security, as TJX found out. I have absolutely nothing against eFashion but just as TJX themselves found out just because you embrace security doesn’t mean you’re good at it.

What Was Your Epiphany?

Friday, April 25th, 2008

A few weeks ago at RSACon I sat down with Amit Klein and asked him one question that I’ve wanted to ask for a long time. I wanted to know if there was one defining moment in his past that suddenly opened his eyes. More specifically, some event that made him realize that he had stumbled upon knowledge that would lead him down a path that only a very select few would ever travel. I wanted to know that one cathartic event that made him realize the web was extremely vulnerable. I wanted to know this because I wanted to know if there was a common thread between him and some of the other experts in the field.

Amit took his sweet time thinking of a good answer, of course telling me all the while that there was no single defining moment and that the question was harder than it sounds. Yes, yes, Amit, but out with it! He finally began to tell me the first time he messed with a binary. He went in with an editor and changed one word. Expecting it not to work, he ran it, and sure enough it did. To him that was totally amazing that it would work, and suddenly, he realized that there were probably a lot of exploitable things out there similar to that. He also told another story about how he had read the HTTP spec and realized you could put a newline in front of the first line of the HTTP request, which in the future would eventually lead to exploitation.

So then I asked the same question of Dinis Cruz:

I can probably point to three key moments:

- the first was when I was a CTO of an university and one of campus’ IT guys showed me how he was able to access (over the internet) another campus internal network (via a remote shell delivered via one of the earlier IIS exploits)
- the 2nd was when I read back to back the first Hacking Exposed book and really got an understanding of network and application exploitation
- the 3rd was when I realized that my programming background (ZX Spectrum generation, Assembly programming on Amiga/x86, etc..) really allowed me to ‘understand’ Application security (vs network security) AND to write exploits

Jeremiah Grossman also gave his story:

For myself it started almost immediately when I began developing web applications many years ago. I read all the books, walk through the examples, and built websites. Being the natural prankster that I am I immediately saw how others could potentially screw around with the way my application worked, post offense stuff, and just generally cause a poor user experience. At the time I didn’t know to even to call it "security", it was just something that could be done to a webapp. The AHA moment came when I got the feeling that my code was no better or worse than anyone elses. :)

As I just passed my 800 blog post mark, I realized I had never talked about my moment either, and what better way to talk about it than to talk about other people’s moments as well. Mine was a very vivid point in time in my memory. I had read the HTTP spec and knew the basic principles of how it worked, but one day I followed some guide and telnetted to port 80 for the first time and started typing in commands. The first time I saw a flood of headers fly by my screen was like getting hit in the face with a brick. I just couldn’t deny how powerful that knowledge was and how broken everything must be if it was that simple. I know most people look at HTTP and kinda shrug their shoulders, but for me it was an awakening that made me realize that there is almost no end to the potential and danger that it allows.

I don’t know that I can point to any one particular thread between these experts, but I do know that the net effect was the same. The realization that everything is vulnerable is a pretty profound concept. So? What’s your story?