It appears that the Firefox extention “Fizzle” is vulnerable to being taken over using HTML entities of all things. Because it converts HTML entities into their more dangerous equivalents CrYpTiC_MauleR found was able to create a proof of concept exploit that reads cookies, steals files, and so on. The proof of concept can be found here.

This really just another for of RSS hacking that we’ve all come to know and love, although this one is a little more tragic as it actually gives you much higher access that you can find through a normal HTML RSS feed aggregator. Although this may only affect a few thousand users, there are a few things to note about this. Firstly, there is no standard way to inform users that they are using dangerous plugins. Second, even if something is in an HTML entity, it can cause problems if you start converting the text. Lastly, this is not Firefox’s fault directly, but that doesn’t matter.

If you allow plugins to perform actions outside of the normal security model, you are taking big risks with your user’s security. Nice job, CrYpTiC_MauleR!

I’ve always thought that any tool that does lookups and returns any data is subject to abuse. Mainly I’ve focused on how to abuse proxies, but there have been a number of weird quirks in how the Internet Archive has functioned over the years that have opened it up for abuse. Most of which are probably still there. But any time someone puts your content on their page they are taking a risk. Any any time a robot does your bidding you are taking a risk. It’s just dangerous. WhiteAcid sent me this email on yet another abuse of the Internet Archive. This time he turned it into a port scanner:

Today I noticed that the web archive had crawled my IP and robots.txt returned a 403 error (as does everything output /public on my laptop). Anyway… some research later and I was seeing what archive.org had stored on my IP. As it turned out, nothing, but when I created a request for my IP I saw this in apache’s logs:

208.70.29.186 - - [23/Mar/2007:12:38:24 +0000] “GET /robots.txt HTTP/1.1″ 403 212 “-” “ia_archiver-web.archive.org”

I played around searching for m.y.i.p:21 and this appeared in the ftp logs:
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> Connected, sending welcome message…
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> 220 Welcome to
pirate.sourceforge.net
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> GET /robots.txt HTTP/1.1
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> 500 Syntax error, command unrecognized.
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> TE: deflate,gzip;q=0.3
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> 500 Syntax error, command unrecognized.
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> Connection: TE, close
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> 500 Syntax error, command unrecognized.
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> Host: 87.194.204.55:21
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> 500 Syntax error, command unrecognized.
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> User-Agent: ia_archiver-web.archive.org
(000033) 23/03/2007 12:40:33 - (not logged in) (208.70.29.90)> 500 Syntax error, command unrecognized.
(000033) 23/03/2007 12:40:58 - (not logged in) (208.70.29.90)> disconnected.

I was then wondering how someone could try to determine if the connection worked or not. The returned HTML page doesn’t give anything away, but I found the the time it takes to load varies. If a web server exists on that port the request would take me under 6-9 seconds (occasionally up to 14). If nothing existed on that port the request would take around 23-25 seconds. Sometimes connecting to FTP servers would take just over 30 seconds, which I assume is their timeout.

This means that you can write a basic port scanner. It can only do TCP and you can’t tell what is running, but as long as the reply didn’t take 23-25 seconds there’s something running there.

There are other bad things you can do, like make it perform PHP include attacks, or run various other exploits against the server on your behalf. Of course they log everything so if you actually compromise the security of a system you haven’t helped yourself much as I’m fairly certain they’d give up their logs to anyone with a badge who asked. Yet still, this sort of abuse of systems is pretty bad. Perhaps the internet archive should be limited to what it can crawl on it’s own, rather than blindly following the direction of whomever asks.

digi7al64 and Rahul both alerted me to a really good writeup on the Gozi trojan written by Don Jackson. Not only is is a good writeup but it’s extremely thorough on all the details from the transmission to how the code operates, to what it does once installed, etc… etc… Very good writeup indeed. The major scary part about this trojan is that it is specifically designed to steal information that would otherwise be invisible to an attacker due to SSL.

I think my only beef with the writeup (and this is a nit pick, really) is that the example output is from Wireshark instead of a HTTP proxy, so it’s difficult to read what’s going on, and parts of the header are cut off. Wireshark is a great program, it’s just really not ideal for looking at HTTP traffic in an intelligible way (although that could be a nice feature enhancement to it - or even turning it into a HTTP MITM itself). Again, that’s a nit-pick, because this is a great writeup.

The month of MySpace Bugs is fast approaching. It’s targeted to begin April 1st (and no, it’s not a joke). Mondo Armando and Mustachio (not their real names, as you may have already guessed) are planning on releasing one or more vulnerabilities in the site per day as sort of a dig at the month of bugs stuff as well as a dig at MySpace who apparently they dislike. I’ve talked with Mondo and actually sent a few bugs over myself, so at minimum they’ll have a few bugs!

I think month of bugs are actually a great thing in a lot of ways. Primarily they raise awareness of the issues. The PHP month of bugs has really raised people’s awareness of how flawed certain things are in PHP and forced a lot of upgrades. You saw what happened in the month of browser bugs and now we are here. Although the month of MySpace bugs is a joke in a lot of ways, it does raise the real issue that a determined attacker can find 30 or more vulnerabilities in a system in a relatively short period of time, raising some real questions about the state of security of even the largest enterprises out there. And it’s not like this is the first time in MySpace’s history that they have been hit, so it’s not like they aren’t warned of the risks ahead of time. It should be interesting to watch. There’s more on this thread and Mondo himself posted to sla.ckers if anyone’s interested.

Jeremiah sent me this link to Don Park’s blog, discussing a new tool released by SPI Dynamics called Jikto. Jikto is a play on the words JavaScript and Nikto (the web vulnerability scanning tool). It is essentially a mashup of a lot of other people’s tools that acts as a framework for exploiting anyone who visits any site that you have control over. Now the question isn’t so much can it be done, because we all know it can. The question Don poses is SHOULD it be done.

One very narrow line that we all must face is where the distinction between security research and building script kiddy tools comes into play. I think a lot of us have fallen victim to writing tools to make our own lives easier, while also making script kiddie’s lives easier. In this case Jikto doesn’t make a security researcher’s life easier, except perhaps to demonstrate how bad script kiddies can be if given that exact tool.

However, don’t be fooled by the quote in the article, “This is going to drastically change the scope of evil things you can do with JavaScript.” Although this is an interesting take, it does NOT change the scope of evil things that can be done with JavaScript. However, from my understanding of the tool it does nicely package up a lot of known vulnerabilities. So which is it? A tool for good or a tool for evil?

I got 290ish trackback spams last night, and that’s after quite a bit of anti-spam filters. For some reason spammers think I’ll approve their spam through excessive volume. Well, they couldn’t be more wrong. In fact, I’ve been thinking of interesting ways to detect them. For those of you who don’t run blogs, trackback spam is when robots pretend to be other blogs linking to my site. My site picks up the post requests from the robot, who tells it a few things, like the link to the site and a title and some sample text. Trackback spam is difficult to stop because it is doesn’t act like normal traffic (even when it’s working normally). So today I came up with a few semi-clever tactics to end the madness.

The first is the IP address. This is one thing the robot cannot fake. The robot normally must run from the webserver that the trackback is coming from. If it isn’t, that’s a huge signal that it’s a robot. So what if I connect to the same IP address on port 80 and look for a webserver? If I don’t see one, I can be 99% sure it’s fake traffic. The only way that wouldn’t be true is if the site just temporarily went down or the server is on another port. Either way, do I really care?

Next is the IP address of the link. The link itself should match the IP address. Why would a site be doing a trackback link for some other website? That makes no sense, and therefore again is 99% spam. The only way the spammers could get around this is to temporarily spoof the DNS entry to my server, but even still they’d have to be running a webserver on that IP address. In this way, you can quickly exhaust the number of sites they can spam from because they must run a webserver on it to get it to work (which they do in less than 1% of the cases I’ve looked at thus far). And even still they must also link to that same server. That greatly increases the work of a spammer to even get a link to show up in my moderation queue, and I can simply ban that IP address going forward, since I know it is truly the same IP as the spam site that I don’t care to see anyway.

It’ll be fun writing the software. They spammed the wrong guy 290 times!

Giorgio Maone, the author of the NoScript Firefox plugin has recently been posting to the boards about a new experimental version of the plugin that intends to protect against XSS. The concept of the tool change is to detect when one site is attempting to send you to another site with XSS within the query string. Obviously there are more ways to XSS sites than the query string, so this mostly relates to certain forms of reflected XSS.

Giorgio is open to comments, so I would recommend that anyone interested in testing out the tool download it and give their feedback. Thus far there are a number of bugs, since it is very restrictive in what it attempts to stop, but being experimental there is lots of room for comments and improvements where they make sense. A big thanks to Giorgio for taking the time to let us all test his code. I, for one, have got a lot more testing to do!

Zach sent me a link to a hackin the box article about how Windows Live is being used by blackhat SEO (search engine optimization) to bring malware links to the top of the search results. This marriage between blackhat SEO and hacking is starting to take off. It’s unclear what tactic they used to get to the top of the search results, but clearly, it worked, as they ended up taking over quite a bit of Live’s Italian site.

Once the users were on the Live.com site apparently they were served up links to malware sites. The search engine itself was used as a conduit for sending people to the malicious search pages. This is yet another reason why search engines shouldn’t index XSS. Even if the site is benign, they would be indexing links to malicious pages on benign sites. Anyway, interesting read, and it’s scary that the SEO community is now dabbling in hacking as well. It was only a matter of time.

Just a forewarning, this is a personal blog entry, and has no technical content. I’ve been blogging on ha.ckers.org for over 500 posts now, and I have done my best to stay honest and give all my readers the facts necessary to make their own decisions about the products they use, the technology they employ and the risks they face. One thing I have said on a number of occasions is that I do not work in security. At the time I wrote that, I was telling the truth, I was working as a director of product management for a publically traded real-estate company. I was making sure the colors of the page match up, and that the search engines had the right business rules taken into account. Business only, no security. That may come as a shock to a lot of people, but I really had nothing to do with security for the last year since I started working there.

Of course, prior to that I worked for a number of big companies leading up security services, building anti-phishing, anti-virus, anti-cross site scripting, and anti-fraud tools and techniques. I’d been involved in security since there really was a web application to secure in the first place (anyone who tells you that they’ve been in security longer than I have is talking about DECs and Alphas and I’m not even sure how those are relevent to modern applications anyway). Regardless, although I didn’t work in security for the last year (since before I started this blog) I definitely have my roots in security. If it’s not obvious, this is my passion, and I’ve been out of it for too long.

So I’m starting a new consulting company called SecTheory with id and a few other part-time contractors. You may have heard wind about it on Slashdot, the Wall Street Journal, Anurag’s blog, press releases by ClickForesics or I may have told you myself in passing, but I never made it clear on this website. The goal is to deal with middle sized companies who need security help with some of their harder problems, but can’t afford to hire someone full time. Also, I have already helped a number of small security startups with their technology strategy - I will continue to do so. That said, I can no longer be considered completely unbiased as I am now a member of the security community again. In the spirit of full disclosure I thought it only fair for me to explain my new company, and what my plans are for it, so there are no secrets and each of you can make your own informed decisions about why I am saying whatever it is I am saying.

So from time to time you may see me reference material that I will be putting on SecTheory (more of the business side most likely). For the time being it’s just a shell of a site, and there’s nothing interesting on it, but over time I’ll grow it (not into a community site, don’t worry) but I’ll put more content up there as time progresses. I plan on keeping ha.ckers.org and sla.ckers.org around for the foreseeable future as I think the community needs to know what’s really happening out there and it’s a way to for me to communicate with all of you as well as the vendor community that I both love and hate.

My only concern with releasing this information is that some people might be upset with my new company (see me as a competitor or a threat) but I assure you that’s not at all how I see it. In fact I see the security community growing with time, not shrinking. The only other threat I see is that I may get into situations where I cannot talk about clients given non-disclosure agreements or whatever. This has already come up in a number of cases, that I would have liked to disclose events that occurred, but I cannot for legal reasons. I have already communicated with a few potential clients that I reserve the rights to talk about anything I learn on my own or talk about them only as “a company.” Wherever possible I will continue that trend to make sure I can share what I learn with the community.

So onward and upward. I’m really glad to be back amongst the ranks. It’s the first time I’ve been really happy since I left. If that’s not a sign, I don’t know what is. If you have questions about the company, feel free to email me off thread and I’ll share what I can. Anyway, let’s get back to the technical meat, shall we?

Awesome Andrew took a crack at writing some VBScript malware that does some of the stuff we have been building in JavaScript. Namely he wrote Jeremiah’s XST and CSS History Hacking script in VBScript. One of the main reasons I think VBScript is nasty beyond the fact that the majority of browsers on the Internet at the moment support it, is that even experienced web application experts often forget about VBScript as an attack vector.

The major disadvantage of VBScript is that it is not cross browser platform, but if you look at the previous post about the Samy worm you can see that this really doesn’t change things much as the Samy worm also wasn’t cross browser. Just getting the bulk of users to execute a vulnerability is the real meat of the issue. This is one reason why I use Windows and Internet Explorer regularly. Knowing what the vast majority of users are going to be vulnerable to is critical to shutting down the holes. Nice job, Awesome Andrew!