David Naylor (a semi-reformed SEO Blackhat) has an interesting writeup on how to stop badly behaving robots from spidering your site. I would hardly call this technique new (I’ve seen this scripts in one form or another for nearly a decade). However, it’s a good primer for anyone who runs a big website and who is otherwise powerless to stop people from doing it.

This technique doesn’t just work on robots though. Often people during manual assessments will look at the source code of a page and if they find hidden links or commented out pieces of code they will follow them, hoping to find something interesting from a security perspective. One alternative is to trap them and either put them into the matrix or ban them or otherwise log the activity. David’s article is worth a read if you are unfamiliar with how this stuff works.

Last night I visited professor Giovanni Vigna and his post-grad computer security research assistants at UCSB. Giovanni invited me to come any participate in a small Q&A session with his students. They are a group of very smart individuals and it was fun talking with them. Quite a few things were talked about, some things more interesting than others, but there was one thing I wanted to share because I thought it was very clever.

Giovanni and a few of his students started building a new WAF. Despite my back and forth love/hate relationship I thought there was one thing pretty innovative about their tool (granted I haven’t played with it personally yet). It was the concept of invariable parameters. In it’s most simple context, think about this example from a URL:

list-price=500&quantity=10&total=5000

Using machine learning, the tool begins to understand how certain parameters relate to one another. In the above example it is very trivial to tamper with the parameter and change the total price to something else:

list-price=500&quantity=10&total=1

Using anomaly detection it can see that the total has been tampered with because the product of 500 and 10 is not 1. Of course that’s an overly simple example, but you can at least see what they are talking about. Pretty interesting stuff. Although I still have my reservations I’m glad smart people are thinking about the problem. I had a great time with Giovanni and his class, and I hope to meet up with them again sometime!

For those of you who don’t know him, Sid, or WhiteAcid has been a frequent poster to the boards and has contributed several tools to the webappsec space, including the POST forwarder tool and the community cookie logger. Recently he found a vulnerability in BeThere’s (his ISP) customer routers, allowing compromise of a lot of people’s home networks. Yes, that’s bad. WhiteAcid’s full disclosure was actually posted here. There’s also a news article at the Register about it.

This was an interesting case from a full disclosure perspective. WhiteAcid was able to demonstrate the issue, and informed the public, to get his ISP off their butts to fix the issue. Granted, it’s not a way to make friends, but their reaction was interesting. First came a cease and desist, then they booted him off their network. Basically, they threatened legal action against him. Here’s a snippet of an email to me from him about this (edited slightly for read-ability):

As for why… Finding the flaw was sort of accidental and once I had it I had to release it. I’ve always thought Full disclosure was a good way to do things, the best way to get companies off their lazy behinds and in gear, that’s why I posted everything publicly. I don’t regret any of it, in fact, if anything I only regret censoring at my ISPs request.

I know a lot of people have said I shouldn’t have released the passwords, that that was pointless. But I felt I should give out all the information, bad guys can get the password easily anyway. Besides, had I not released the password, virus (a friend of mine) may never had bothered writing the perl script (which he commented to the blog) which would fix the flaw.

This was interesting because their reaction was not to immediately alert their customer base of the flaw, but rather to kick WhiteAcid off their network. I’ve seen this sort of behavior more times that I can count. Companies feel that by putting the crook behind bars their unlocked door no longer matters and the bank is now secure. Not only that they spend countless hours in legal fees, PR headaches, dealing with authorities, etc… and none of it makes them any more secure.

In this case, especially given their reaction, I would doubt that many researchers will release anything about their state of security - not to say they will be more secure - far from it. All they did was make themselves a target. Would I stay with their ISP given this information? Doubtful, since they are more interested in their public image than customer security. Clearly, they have a lot to learn about damage control.

Alla Bezroutchko released a tool yesterday to do automated XSS testing against webmail clients. It is heavily based off of the cross site scripting cheat sheet, but ties that in with a series of emails that attempt to override the built in validation engines built into various web-mail implementations. I am literally the first to admit that I have never looked at webmail in depth. The only time I did, in the case of Roundcube I didn’t even have to go past the first page (it’s now been fixed).

Anyway, this sort of tool is pretty critical and probably should be integrated with large scale web-app scanning, since it doesn’t matter how the data ends up there (via HTML POST or by mail is irrelevant). The only thing that matters is that the client can run the JavaScript once they get there. It’s sort of an interesting union where people are tunneling more and more apps over port 80. Webmail is often mis-classified in people’s minds as normal mail, but really it is another web-app with lots more problems waiting to be uncovered. Anyway, it’s interesting tool, and I’m sure it will spawn more conversations.

I had the pleasure to meet Dan Kuykendall from NTObjectives yesterday for the first time and while I was there Dan interviewed me for his Podcast. We didn’t delve into too much of of the technical stuff, but we did talk about sort of the state of affairs on web application security, XSS and network security of all things. It was a really fun interview to do (totally unscripted and neither of us knew where it was going to go).

Apparently Dan used the wrong mic so the quality isn’t as good as it is usually. But, I have to say, it was a really interesting day with Dan, and I am sure there will end up being a few posts coming out of that in the not too distant future. I want to thank Dan for being so cool, and hopefully this will kick start him into doing more podcasts - we’ll see if we can’t shame him into doing it more often.

In an interesting email that was sent to me I was asked to take a peek at a new software tool, not yet released to the public called Vidoop (there is an interesting article on it here). While I was unable to actually take a look at the software, I’ve got a pretty good idea of how it works from the Wired article. After downloading a software certificate that allows you to use their software basically you say, “I like animals” and it shows you pictures of horses and cats and dogs all mixed in with a bunch of non-animal photos. You choose the the correct photos (a la kittenauth CAPTCHA) and you are granted access.

So here are the major problems with this that I see. Firstly, it’s probably not accessible (meaning there aren’t alt tags on the images) because if there were it would take only a few guesses to get in since the computer could build databases of “like” things. So basically, like in kittenauth, the blind are screwed (which we have talked about a dozen times and I really don’t want to start another conversation on it, I’m just sayin’). Secondly, it’s non-portable because you have to have the software installed on the computer you want to use. That means you can only use it from one computer (forget going over to a friend’s house and logging in) and if that one computer gets hosed you need to find an alternate path for getting the software installed (which is often the least secure part of these systems). This type of design is a lot less portable than tokens and for a consumer tokens are nearly unusable too.

Also something that makes me uncomfortable from a security perspective is the concept of single sign-in. I’ve always thought single sign-on was a great usability improvement but often terrible from a security perspective. Like the old motivational adage - you’re only as strong as your weakest link - the same is often true with single sign-on. You are often at the mercy of the weakest security model. If any one site is insecure you can (in many of the cases of single sign-on that I have seen) end up compromising all the other trusted sites. Perhaps Vidoop has a great way to solve that issue that revolutionizes the way authentication works and never opens itself up for attack under any scenario. Without looking at it, there’s no way for me to know.

Lastly, because Vidoop uses a relatively small set of photos to choose from, there are only a few general choices from which to brute force (otherwise you’d run into overlap and false positives). If I know the target is a male, chances are they aren’t going to pick the fuzzy animals. If I know the target is a 13 year old girl, chances are they aren’t going to pick photos of computers or sports cars and so on. Anyway, you see the problems with this, Unlike passwords, which are user specific (and still guessable), this is highly un-arbitrary. Does it stop phishing, keystroke logging, cure cancer or any other magical things? I can’t say without looking at it. Will I be using it for large scale mission critical secure production installs? Doubtful.

Rich McIver sent over an article on itsecurity.com entitled 103 Free Security Tools. It’s actually a pretty thorough list. Of course it’s not everything, but it actually covered quite a few programs that I personally have used.

There is one program that is missing from this list that I use every day all day long that I personally swear by. It’s Cygwin. In essence it is a Linux shell on top of Windows. It makes the possible to run apache under windows (without another install), wget, ssh, scp, vim, perl, c++, python, php etc… etc… It’s truly one of the most useful tools on my desktop. Also, tools like nmap, unicornscan, fierce etc… are all missing. For the penetration testers out there, these are pretty damn useful to keep on your desktop and all nicely run under cygwin. If you have no access to a Linux/FreeBSD box, this is the next best thing.

Btw, apparently I am behind the times, or wasn’t paying attention but winscp did fix that URL handler vulnerability (changelog can be found here). So if you haven’t updated winscp in a year or more, time to get rid of that vuln and update. Personally I’ve stuck to scp under cygwin, but for the people who never got the hang of command line apps, winscp is a great alternative. And for anyone who doesn’t know what scp is or is otherwise new to security - FTP is vulnerable to man in the middle attacks, scp and sftp use encryption, so while potentially a little slower, they are far more secure.

Someone sent over an interesting issue that I hadn’t seen before. Due to the way people use Google’s calendaring function they are vulnerable to having corporate information leaked - including intranet addresses, dial-in information (including passcodes) as well as anything else they type in. Pretty scary actually as I think most of the people using this think their information is private somehow:

Inspired by http://johnny.ihackstuff.com/ghdb.php I decided to type “passcode intranet” on Google Calendar public search. one of the result is
http://www.google.com/calendar/events?state=mode%3Dweek,7%26date%3D20070415&q=passcode+intranet&ql=&qt=&qtd=&sa=N&page=vl&afp=8690e067387d3463

*Internal Communication Weekly Meeting*
*Agenda:**
http://devcentral.intranet.mckinsey.com/products/PeopleSystems/internal-com

Dial In:

Moderator passcode: 2859485
Participant passcode: 874129

Local - UK, London: +44 (0)20 7784 1013
Local - USA, New York: +1 718 354 1113*

Openly telling ppl about passcode, intranet sites etc.
WoW!

Not so good. This is pretty much exactly the kind of recon necessary to start doing industrial espionage. Weekly meetings that discuss key internal information? Not looking good. Sometimes you see major leaks in the least likely places. In fact, if you search for some of these key words in other corporate acceptable social networking sites, I bet you’d find a lot of the same issues. Nice find!

I’ve ran across this link at some point, and I had thought I had written something about this, however, it appears I never did. If you look at meebo.com you’ll see web2.0 craziness (I guess this got voted one of the top ten Ajax apps out there at some point). Anyway, two thoughts came to mind as I looked at this for the second time.

The first of which is “I bet they don’t have good back end validation because their front end validation is insanely good.” That proved to be right as I now have an account called "<asdf. Secondly, I thought, “If I were going to write an app that allowed me to see everyone’s conversations, this would be it.” Unfortunately, it doesn’t matter how good my security is on my connection. If my girlfriend decides to start using this app, I am basically screwed. Also, this is a pretty great way to bypass corporate firewall restrictions. Interesting app though.

I know this isn’t new, but believe it or not I am finally catching up on some of my really old mail. I ran across the webappsec stats page today, and I thought I’d throw in my two cents, for what it’s worth. Honestly, these numbers, while extremely interesting are only based on what we already know - not on what we don’t know. Seems like a dumb thing to say, but with every new vulnerability, we increase the amount of potential issues in websites.

Secondly, and more interestingly, I noticed that XSS has actually increased in the numbers reported. Previously the scanning companies were saying 70%, now they are at 85% (which is actually higher than what I’ve found, but I believe it, since I hardly check every link and every parameter when I do manual assessments). But I think it’s safe to say it is well above 70% and probably closer to 80-90% as that jives with what I’ve seen (again, I can only comment on what I’ve found, and not on what I didn’t find).

The other thing that was interesting is that nowhere was there a point in the stats that covered how many sites were vulnerable. Clearly at least 85% are vulnerable, but it doesn’t say how many total are vulnerable to any type of vulnerability listed. I would love to get that number as an aggregate score to know the health of the types of people who are proactive enough to ask companies to help them with their security. It’s a sad statement either way, but it’s an important point to make about where we are with the current security landscape.