I guess I get to add another book to my X-mas list for myself. Jaime Sirovich wrote me about a book he has been authoring for quite a while now. I knew he was writing it but apparently they have been moving ahead a good clip and are already ready for pre-orders.

The book is Professional Search Engine Optimization with PHP and is designed to teach the fundamentals of SEO. Jamie thought I would be interested in the chapter on Blackhat SEO, since that applies to some basic web application security concepts, including HTML injection (as opposed to JavaScript injection which traditionally isn’t read by search engine spiders since no one searches on JavaScript). Pretty interesting with some good code snippets. If you’re interested in SEO, I’d add it to your list of upcoming book purchases.

Well the forums are alive again, this time ControlScan sites are being found to have issues, as well as the ControlScan website itself. ControlScan has a similar model to ScanAlert where a graphic is hosted to alert customers that the site has been verified as a safe site. Unfortunately the guys on the forums have been finding many issues.

The president of ControlScan, Aaron Biddar, wrote and thanked the researchers on the forum for helping to drive home the point that an image does not make you safe. According to him his clients are more interested in the graphic than they are in the security and he actually has to use the images themselves to up-sell his actual security services as the clients claim that they are already safe.

Now there’s a twist. Normally it’s the other way around, someone selling snake oil and leaving town before the poor client realizes they have been fooled. In this case it’s really the other way around. People feel secure or aren’t willing to admit that they know they are insecure and will do anything to drop the ownership of the issue onto another company. It’s the equivalent of extremely cheap hacker security when negative PR comes out of a successful hack attempt.

The point is the same, I suppose. For customers it can definitely drive more revenue, but for consumers, beware. Treat these sites just like any other sites since the owners of them don’t appear to be particularly interested in their own security, according to ControlScan. I mean, who could blame them? What’s the real cost to be secure? A $30k audit and then $100k to fix all the holes in the architecture and design? Most companies could never afford that. But they don’t have to if the consumer has a false sense of security.

I got an email today from Gaurav Kumar regarding Zone Alarm’s “Identity Protection” product. It is designed to keep passwords safe from being sent to servers other than the correct one. So you store your password with them and if they detect the plaintext password in transit being sent to a server other than the one you want it to be sent to it alerts you. Here’s his email:

Zone Alarm “Online Fraud Prevention” is severely flawed. Since I knew that Yahoo Mail sends password as MD5 hash, i entered the same password as i had provided to Online Fraud Prevention option. And bingo! no alarms, nothing. Password just went through.

Now i entered the password in other web application and it was caught as expected. So the i thought that best way to bypass Online Fraud Prevention is to scramble the password using JS and send it….but wait, Online Fraud Prevention doesn’t work for HTTPS pages

So next time if someone wants to bypass Online Fraud Prevention, just use HTTPS or scramble the password.

Online Fraud Prevention is nothing more than marketing gimmick.

I have actually not played with this specific product although I have played with similar technology before. There is actually a much larger hole here, depending on the implementation. There are two possible methods for alerting the user. They can alert the user before the password is sent or they can alert the user without interrupting the session. Most people would argue that it is better to interrupt the user before the password is sent, but therein lies a security flaw.

Let’s say I know the username of the victim. If I am able to get him to a site that I control I can create a script to enumerate through passwords. It can simply refresh to itself with a new query string containing possible/common passwords. When the user hits the correct password the dialog pops up and alerts the user that they don’t want to sent their password to a remote site. The user stops, reads the thing and does one of two things. They allow their password to be sent (highly unlikely) or they click cancel and the script stops refreshing to itself.

Now if you look at the logs for that user (you can base user sessions on cookies or IP or whatever you want) you’ll see a huge list of possible but not-bad passwords streaming over your site. Then it will stop at some point or it will never succeed and will run out of passwords. In the case where it stops one of two things happened. Either the user surfed away from the page, or you found the correct password. It’s not the last password in the logs, it’s the next one - the password that was never sent.

This can be further sped up by sending many passwords at the same time (most likely three or more). It stands to reason that one of three passwords is a small enough number that the attacker could log in two times and fail before getting the right password without alerting the website in question. So if the user can create five requests a second and can send three passwords at a time you are talking about 900 passwords a minute. That’s easily enough to test the most common passwords.

In this way you can enumerate/brute force the most sensitive passwords a user has for any customer who uses this product who visits your web-page. It’s only useful if you know their user account too, so the practicality of this attack is rather low. The real risk would be in situations where it was highly targeted against a particular user. I have no idea if Zone Alarm’s product has this particular hole as I’ve never tried it. But yes, Gaurav is correct, looking for plaintext passwords can be easily circumvented by phishers if they chose to. I think the only reason they haven’t is because the market is so small for consumers who use these types of products it’s simply not worth the bother.

AJAX and dynamic HTML in general is such a new technology that most people really don’t get it’s true security implications. It’s nice to see a few articles being written that address the web application security issues found with the various types of dynamic code out there. Today I ran across an article on Help Net Security talking about the “Top 10 Ajax Security Holes and driving factors”. Pretty impressive sounding, but the title is kinda misleading.

Of the actual holes there are only three mentioned, Phishing, XSS and CSRF. He actually misses one of the other major holes like the one Jeremiah found in Google for instance where you can steal any data inside JSON if you visit a malicious web-page (yes, you heard me right, don’t put sensitive information in JSON). But even still, what he does discuss, even if it’s not 10 holes, is 10 ways to create those three holes. Some of them are going to be fairly obvious or impossible to create without some other hole and others are a tad more creative, but still, it’s nice seeing people think about this.

However, I’d like to point out, as I have before that really users should not consider AJAX to be another security risk. It is the same old risk that we have always faced, except there is more client side code that can be circumvented now. The more logic you create on the browser for parsing and security the more you must insure that your backend also protects you at the same time, since all client side security can be circumvented in one way or another.

I’ve said it a number of times but this is tantamount to muddying the security waters. Instead of knowing your single choke point for security issues you now have two or more places that require security thought. Not that that makes you less secure, it simply increases the attack surface area. Anyway, it’s kind of an interesting read.

It was a long weekend and sorry for not posting, but id and I were able to get a lot done this weekend. We got 1 1/2 of the machines up and running out of the three that I had hoped to get running. One machine is having some issues but at least it’s turned on where it was pretty much non-functional as of yesterday. One of my stupid laptops needs to be sold at auction so that I can get another one (that’s the last time I buy a cheap Dell laptop). Anyway, the lab is doing quite a bit better than it was before. Once we get all the software up and running we should see better performance, and less downtime in general.

Speaking of downtime we experienced about 45 minutes of downtime on Saturday morning. A few people posted about it on the forum or emailed us about it so I thought I should mention it. No we weren’t hacked, it was just a runaway process that wasn’t behaving nicely and on top of that it wasn’t giving off any of the obvious signals to help us diagnose the issue. id came to the rescue and we got that one resolved in just a few minutes. From the time I noticed until the time it was back up was only about 15 minutes, cuz he rocks. Hopefully with the new server we’ll notice issues like this faster with some monitoring that I’ve been meaning to build. I’ve built that kind of software before, but those machines and that code is long gone, so I need to do it from scratch.

In web app sec news, we were able to ban in excess of 700 IPs programmatically from attempting to do bad things to the site. The firewall is being updated in somewhat-real-time of things I find particularly annoying. Sort of a self defending network (not to get myself sued). It’s not that they have any hope of getting in, but I hate seeing that crap in my logs. It’s an ongoing process so the site should experience less load from the morons and as a result you might see a small increase in page load time until our traffic load grows again to compensate for any good we may have done to reduce it.

Lastly, id found a rather annoying and very reproducible bug in my Netgear WGT624 wireless router, which caused it to stop routing packets every time he did it. I’ve seen it do this sort of thing in the past but could never consistently reproduce it. I’d tell you how to do it, but it wouldn’t help you because we could only reproduce it over SSH (requiring his keys and the exact server in question to be communicating with one another), and we didn’t have enough time to dump the packets and see what was causing it. Needless to say there definitely is some sort of error on those wireless routers and maybe the next time he’s over we’ll try to figure out exactly what it is. Until then I’ll just put up with it crashing on me every once in a while - as annoying as I find that.

So anyway, it was a productive weekend even if I don’t have a lot to say about it. Hopefully in the next few days or so after we get the bugs ironed out of the servers I can get back to the testing.

id and I were talking today about some of the tests he is performing for some software he is helping to test. Amongst some of the tests he was in charge of some of it required forcing the IDS to alert on some of the vulnerabilities he was performing. You’d think it would be an easy thing to do. He took some of my successful hack attempts as well as some of his probing attacks and still was unsuccessful in creating an event that the server could pick up.

I had sort of thought the network security world had made the attack signatures a commodity. However in hearing his story, after 72 hours of testing he was only able to get his client’s IDS to alert after knowing the exact server signature that would alert and modifying his attack specifically to be detected. Ouch. How can companies feel secure without being able to see these very obvious recon techniques. We aren’t talking about anything more complex than a nmap scan, but still, they are unable to properly assess the attack in question.

Kinda makes me wonder about the state of network security when default IDSs aren’t able to detect or properly classify the most obvious attacks. Maybe it’s time to revisit what people are looking at and reporting on.

There has been an interesting trend on the forums as of late. HACKER SAFE© sites are being targeted to identify the vulnerabilities in them. Ultimately the type of vulnerability assessments performed by Scan Alert has been essentially proven to be ineffective at the 99% rate that they claim. I know I’ve written about this before but this time the name of a security watermark is being used as an effective method for finding vulnerable websites. That’s right, the people on the forum are inventing Google Dorks to locate sites that bear Scan Alert’s watermark as they are probable targets for exploitation.

Not many security companies have the distinction of having such flawed methodology for testing for vulnerabilities that their services are being used as a method for finding vulnerable websites that they certify as being 99% safe, according to their website.

According to Scan Alert they help companies convert 14% better with their logo (thanks to Kyran for the link). Clearly the marketing aspect is worthwhile, even if it makes your company an even larger target to hackers. I encourage anyone using Scan Alert to hire a professional to do a real vulnerability assessment based on the results from the forum and ditch the logo before it makes you an even larger target to the people you are claiming to be safe from.

Over the last several years I’ve noticed a disturbing trend in web application security - the use of email as a form of authentication. Once upon a time web application security was a very obscure concept, and as such it made sense to rely on a simple (although largely inaccurate) assumption which is that users have complete control over their email address. Let’s think about this for a second. How are emails being used today?

According to MAAWG between 80-85% of all email is abusive. Okay, so the user is inundated with spam, viruses, trojans, phishing emails and other scams and that represents the vast majority of email they will receive. That means a pathetic 15-20% of email is actually “good” or non-abusive.

I don’t have any real data to back up how many email accounts worldwide have been compromised but I do have statistics on how many of the top two web mail servers have been compromised with some form of attack. Both Hotmail and Yahoo mail have had issues, but let’s not forget Gmail too. At one point I met with an AOL business person and they told me that the number of account takeovers they had were “in the percentage” range. He was unwilling to tell me how many percent, but even if it’s 1% of users that represents over 500,000 accounts.

Okay, so email is both insecure and highly targeted for malicious activities. Now let’s look at how companies are using it. Many companies still require that users use an email address as the primary username for their accounts for logging in. Companies reference the accounts as such. That makes it extremely easy to identify users, and potentially difficult to guess since there are billions of email addresses out there. However (and here’s the fatal flaw) the servers allow access to their websites by using email as a forgot password function.

So an attacker can get access to your email, (given the flaws in the webmail systems) they can look through the email, (since they have access to it) they can connect to the websites (which you have kept information on), they can use the forgot password function, (which generally asks for nothing more than an email address) and now they have access to your account.

Websites use email as a form of half-factor authentication. While it isn’t something you have, it is something you know that is not normally out of your control. In this way it is very easy to gain access to websites given access to an email account. People don’t generally think of their web mail as being a critical asset. That’s where they sign up for random websites since they don’t want to use their work account while shopping for lingerie. But by putting so much faith in the webmail application they now have risked whatever can be done on any website they they have an account with. A disturbing trend, to be sure.

Jeremiah Grossman has recently come out with a new web application survey. If you remember he did this about a month ago, with some fairly interesting results (I was surprised by a few of the results myself). Like I said, I promised to answer the survey the next time, and so I did, and here they are:

Questions:

1) Who do you perform web application vulnerability assessments for?
a) Security vendor
b) Enterprise
c) Entertainment and/or educational purposes
d) Other (please specify)

b - generally larger companies but a few small ones

2) What is your most common web application vulnerability assessment
methodology?
a) Source code review
b) Black Box
c) Combination of A and B

c - primarily I know nothing about the target in question other than what an attacker would see but afterwards I start asking questions and learn how the system works and then I find the really nasty holes. 70% of all attacks come from the inside, and it stands to reason there are more holes than are visible from the outside.

3) Do you use commercial vulnerability scanner products during your assessments? (Acunetix, Cenzic, Fortify, NTOBJECTives, Ounce Labs, Secure Software, SPI Dynamic, Watchfire, etc.)
a) Never
b) Sometimes
c) 50/50
d) Most of the time
e) Always

a - I have to live on the cheap since I do everything out of pocket these days - although that might change in the future.

4) Do you use open source tools during your assessments? (Paros, Burp, Live HTTP headers, Web Scarab, CAL9000, Nikto, Wikto, etc.)
a) Never
b) Sometimes
c) 50/50
d) Most of the time
e) Always

c - I do use a lot of tools, but just as often I use my bare hands and my own homegrown tools.

5) What is your preferred severity rating system for web application
vulnerabilities?
a) DREAD
b) TRIKE
c) CVSS
d) Proprietary
e) Other

d - I haven’t been super happy with any of the various rating systems, so I use my own based on real world information rather than contrived theorems. I’ve never felt like a one size fits all approach to vulnerability assessment has made sense. I really like to think about the circumstances of a company and the vulnerability to weigh the actual risk to them, not to companies like them or even worse companies that have nothing at all in common to them.

6) What is the single most dangerous and widespread web application vulnerability?
a) Cross-Site Scripting (XSS)
b) Cross-Site Request Forgery (CSRF)
c) PHP Include
d) SQL Injection
e) Other (please specify)

c - Jeremiah and I talked about this one being kinda a weird question as A and B are definitely the most widespread, but C is the most dangerous as it can lead to all the others plus remote server compromise.

7) Are Cross-Site Request Forgeries (CSRF) part of your vulnerability assessment methodology?
a) Yes
b) No
c) Sometimes
d) Huh?

a - I definitely look for and think about it, although it’s difficult to have people take it seriously, and it is harder to detect as it often requires a user account and that’s something I generally don’t do when I am doing high level passes over applications. However it SHOULD be a part of everyone’s testing, since it’s clearly not part of the tests performed by application scanners.

From your vulnerability assessment experience, how many websites have serious web application vulnerabilities? (reveal private information, escalate privileges, or allow remote compromise)
a) All or nearly all
b) Most
c) 50/50
d) Some
e) No idea

c - The reason this rates so high is because of the amount of server vulnerabilities either by stand alone applications that haven’t been patched or via things like PHP includes in open source applications. Yay for open source!

9) How long would it take you find a single serious web application vulnerability in MOST public websites?
a) Few minutes
b) Hour or two
c) Day and a night
d) A few days
e) Don’t know, never tried

a - Thankfully most people (not large companies but most websites in general) use open source, making this job much easier.

10) How long after a web application vulnerability assessment are most of the severe issues resolved?
a) Within hours
b) The next couple days
c) During the next scheduled software update
d) Months from discovery
e) Just before the next annual assessment

c - Generally companies patch whenever they can, I’ve found. It’s fairly rare for them to patch outside of a sanctioned development release. Often times there are regulatory concerns if they don’t do so.

11) What organizational activity MOST improved the security of their websites?
a) Using modern software development frameworks (.NET, J2EE, Ruby on Rails, etc)
b) Secure software and/or awareness training
c) A stronger security presence in the SDLC
d) Compliance to industry regulations
e) Other (please specify)

e - Baseline threats and compare against baseline on a release by release. eventually tying that information into bonus structure for management. Everything else follows nicely.

12) Are you privy to any undisclosed (not made public) malicious attacks made against a web application? (fraud, identify theft, extortion, theft of intellectual property, etc.)
a) No
b) One
c) A few
d) Too many to count

d -

So feel free to take the survey for yourself. He’s posted the survey here for everyone to take if they wish. I really recommend you do if you are a web application security penetration tester because some of these results are pretty fascinating and help all of us make decisions on where to take things in the future.

Jeremiah Grossman and I got to talking today and he reminded me of an old conversation we had had months ago around a way to detect the state of a user who is authenticated on a site. At the time it felt very academic and I didn’t really feel like following through with it, but certain events have made me realize this is slightly more prevalent than either of us had originally thought. You can use files on sites to detect the state of a user.

The sample code is simple enough:

<IMG SRC="http://somesite.com/members/protected.jpg" onerror="alert('not authenticated')">

Let’s assume you have an image that’s inside the members directory as seen above. If the user is authenticated they can see the photo, if not, they can’t and are redirected to a page where they must authenticate. If that’s the case you can automatically detect if the user is logged in. The same holds true if the image changes to say something like “Hello, Bob!” once the user logs in. You can detect the size and use that to verify that the user is logged in.

You can take it further by looking for scripts that are hidden behind protected directories. Admittedly I’ve never seen anything like that, except in basic auth situations but I’m sure there are examples out there. But here’s where the story ends. Neither Jeremiah or I could think of anything off the tops of our heads that would allow this technique to be more prevalent. Ideas?