There’s an interesting thread on sla.ckers about how Firefox overwrites attributes. The short of it is if you have attribute=”false” followed by attribute=”true” the second attribute overwrites the first. This is definitely not the first time I’ve come across this, and if you think about it, it makes sense - one of them has to win, so it’s a tossup as to which one should. So for the most part I totally ignored that phenomena, chalking it up to potentially problematic, but difficult or impossible to exploit in any useful way. However, that was until this thread.

One thing that MySpace does, for instance, is add the attribute allowScriptAccess=”never” to any object tags, neutering their effectiveness in an attack. However, if you immediately follow it up with your own attribute allowScriptAccess=”always” it will override MySpace’s security settings (I don’t know if there is a working exploit out there for this - it’s just an example as far as I know). However, now it’s clear that there could be situations where there are other attributes that users are allowed to write into, that in all other ways prevent XSS, but allow you to change the functionality of the tag you are within. Clever attack!

Update: Apparently this is super old, but no one noticed. I guess not that many people use that service because it’s been around since Feb. Which also means some of these may have been pointing to us at that time - so maybe Dean isn’t as inept as I initially thought he was - except for the whole thinking we are spreading destruction without warning people ahead of time. Uhm, ya.

Here we go again. People who have been reading this blog for a while will remember that we have been told we were hacking websites by hosting JavaScript and we have been marked as a phishing site as well. Well, as Michael pointed out, McAfee has marked ha.ckers.org as a site that attempts to exploit you. Way to go guys, very nice indeed.

So let’s dissect what I think happened here. At some point someone looked at one of the examples and said, “Wow this site is bad.” because they are clueless and didn’t bother to even look at the rest of the site. A gentleman by the name of “mr.anderson” then put up a stunning review of the site:

Exploit server

Wow… amazingly thorough review! I wish they would at least put which page they thought was owning them, that would have been amusing to make fun of him at least. But alas, no such luck. Then the big gun arrived. His name is dean and he has been marked as a “experienced reviewer”. Thank god, I’m saved, right? Someone who knows what they’re doing at least?

What mr.anderson said… According to Exploit Prevention Labs’ LinkScanner, this site contains malicious code. The IP address of this domain is 69.12.144.65 and it is shared by seven other domains. These sites are listed below:

advicegalaxy.com
barbarycoastfilms.com
fthe.net
mydickisbiggerthanyours.com
s-alchemy.com
secureseo.com
seodymanics.com

And then just to make sure he’s gotten his point across dean writes:

I forgot to add in my previous review that the other sites listed also contain exploits.

Wow. Just. Wow. Let’s actually take a look at this great find here that dean, our experienced reviewer came up with. Let’s look at advicegalaxy.com:

Name: advicegalaxy.com
Address: 8.15.231.1

Uhm… doesn’t appear to be on 69.12.144.65 to me and it looks like some domain squatter. But maybe that’s just an anomaly. Let’s look at another one:

Name: barbarycoastfilms.com
Address: 69.12.144.101

At least this one is on the right subnet, but still, wrong IP. And it appears to be a movie review site. Alas, not the malware spewing site I had hoped to find.

Name: fthe.net
Address: 69.12.144.99

Again! Close! But alas, wrong IP and even still, it’s a site that is supposed to be funny (we do try, but alas, sometimes we just fail miserably). Hardly the browser exploit factory.

Name: mydickisbiggerthanyours.com
Address: 69.12.144.101

Yes, id sure does have a good sense of humor, doesn’t he? Same deal as fthe.net.

Name: s-alchemy.com
Address: 69.12.144.65

There we go! Finally a match with the IP address that dean listed. Let’s go check it out. Wait, nothing there? How is it going to spread malware when it’s not even alive? Strange….

Name: secureseo.com
Address: 69.12.144.99

Okay, now we’re getting somewhere. It’s at least talking about browsers. But wait, it’s only got a few posts and alas one of them is about helping browser companies detect blackhat SEO tactics. Weird. There has GOT to be malware here! Dean said so! And that man is experienced!

Name: seodymanics.com
Address: 69.25.212.153

Whoah, not even close to the right IP range, and also looks like domain squatting. Alas, nothing to do with us. So now let’s look at ha.ckers.org since that appears to be the offending site.

Name: ckers.org
Address: 69.12.144.99

But wait! Dean clearly said ha.ckers.org was living on .65, not on .99! Maybe they have the wrong site? Now I’m just confused! Just because you use handy dandy outdated IP to hostname lookup and correlation tools doesn’t make you experienced. In fact, it makes you lazy and wrong it turns out. However, let’s get back to the matter at hand. Apparently Exploit Prevention Labs’ LinkScanner thinks I’m a bad bad man. So I go ahead and run it against every URL on ha.ckers.org I think could possibly be scaring it. Alas, nothing. Everything I can think to test comes up as thumbs up, as nice as rainbows and lollipops.

Okay, enough sarcasm. Herein lies some serious problems. How one site can maintain the reputation of other sites in such a way obviously leads to all sorts of false positives and false negatives. Even if you think this site is bad, without contacting me, or explaining what exactly is wrong with the site, how can I even fix the problem to get it up to snuff?

Now we are relying on the reputation of someone named, “dean” and “mr.anderson” to make judgment calls, when it’s clear the more experienced of the two doesn’t have a clue about the site he is reviewing or the other sites (all of the sites listed have now been reviewed as bad by dean including s-alchemy which is not even online and hasn’t been since our server crash months ago). Great job guys. I hope someone at McAfee is reading this and fixes it. Also, if anyone has a copy of Exploit Prevention Labs’ LinkScanner Pro, I’d appreciate a heads up as to what it found on ha.ckers.org that it thinks is bad.

Until we get to the bottom of this, maybe you should take McAfee’s word for it and steer clear of this site and the .65 IP address - they wouldn’t mark this site bad if it weren’t. If I can’t figure out how we’re exploiting you, you should be afraid - very afraid!

This paper is a long time in coming, and I apologize for not getting it out sooner, but I’ve been very swamped. We all have known for a long time that we can force websites like Google to perform attacks on our behalf by getting them to surf random websites and perform RFI attacks, for instance. That’s bad. But what if we were to turn the concept around and instead use it to hack intranets? Herein lies the basis for intranet hacking using websites. I threw the paper up on SecTheory for anyone who wants to read it.

If you recall all our intranet-hacking-with-browsers conversations over the last two years, this will look really familiar, because it’s using all the same tactics, except instead it’s the webserver doing the attacking, rather than the web-browser. The paper draws on techniques and tactics we’ve all know and love so there shouldn’t be anything surprising in here. So the next question is how prevalent is this stuff? Well, I’ve seen it exactly one time. But I’ve only tried it a handful, so it’s really hard for me to estimate how often it happens. My guess is that it is somewhat rare, but using Google dorks to identify potentially vulnerable sites would prove to speed up non targeted attacks. Kinda nasty.

Dave Shanley has an interesting post on how you can steal protected music from MySpace. It’s pretty straight forward and demonstrative, so I probably don’t need to say much beyond read the post. I’ve actually known about this for a few days, but there was some back and forth regarding how to disclose the issue. Honestly, this probably isn’t that bad, given how many users have had their usernames and passwords stolen from MySpace anyway, but there you have it.

However, what is a little disturbing is the fact that we are seeing so many of these lately. It’s really hard to protect yourself if you rely on a company to do it for you. id and I were talking to someone about this very fact just a few days ago. Should this person put their music on MySpace. If you put any information online you should expect that information to be treated like public knowledge. If your significant other, your boss, your priest, or the judge at your arraignment would disapprove you probably shouldn’t put it online. If it’s a piece of music, cut it off in the middle, or upload a significantly degraded quality version. Find a way to retain the rights to it knowing that security vulnerabilities do and will happen. Relying on companies to do it for you is taking on a pretty big personal risk.

Fredrick Young send an interesting tidbit over to me today. Apparently all sites that run Urchin’s console are vulnerable to XSS. Urchin (recently bought by Google) is web tracking software designed for log analysis. It’s actually some of the best software out there in terms of speed of log analysis. I heard rumors that lots of the backend was originally coded in assembler. Cool stuff. Anyway, after a few minutes of looking I found an example of this out on the web. Click here for an example. This brings up a few interesting points.

Firstly, it’s not running on port 80 so the same origin policy is irrelevant. Secondly, lots of people use this software, and lots of the companies who use it need to be PCI compliant, which means that all of the companies who have exposed this interface are now failing PCI. Not so nice.

Also, when locating this particular example I noticed that I don’t think the password protection actually stops you from viewing the logs directly as you can see here. Bummer. Being able to read logs could lead to disclosure of hidden files, internal IP addresses, and all kinds of other things submitted on the URL. Looks like Urchin needs a few patches. I actually like this software a lot and if I had lots of money I’d probably buy it. It’s the same back end as Google Analytics although minus the fact that Google can spy on you and your users. But it’s got a few issues.

Mark Burnett has a few good articles on my single favorite love-to-hate security measure, the CAPTCHA. Check the articles out here and here. They do a good job at explaining some of the high level problems with CAPTCHAs but don’t be fooled, this is only the tip of the iceburg as I’m sure Matt would agree. If you look on sla.ckers there is post after agonizing post where people are building and then breaking CAPTCHAs.

Jeremiah had a good post on this a year ago describing what makes an effective CAPTCHA. I’d like to go one further. I have actually never seen said mythical beast. I’m not even sure it can be done with the technology we have at our disposal. What I’m getting at is this. People have deficiencies and those deficiencies must be dealt with for them to be able to solve a puzzle. Some deficiencies are pretty dibilitating and include blindness. Okay, so we have audio CAPTCHAs to augment that issue. Then we have colorblind people. They too can use the audio CAPTCHAs.

Then we have things like pwntcha, pron proxies and a whole host of other ways to “break” CAPTCHAs in a way that they were not intended. Bummer. It’s getting to the point, where I cannot even fathom what a good CAPTCHA would look like. Everything is either far too hard for people to solve, or far too easy for computers to solve. The stuff that’s in the middle is usually bad for both. I’m up for an experiment. Can anyone point to a good example of a CAPTCHA anywhere on the Internet - one that meets all the rules outlined by Jeremiah’s post?

I was really hesitant to post this for a few reasons. The first being the sheer number of responses to the last photobucket photo disclosure issue I posted. The second is that really, I have never used photobucket, so don’t particularly care about fixing issues in their system other than the fact that I know there are a lot of people who would probably appreciate not having their private pics all over the Internet. I would have used responsible disclosure, but I was asked to post this and also I tried that last time with Photobucket and didn’t get any response, so I don’t think there is anyone manning the blackhole that my email apparently went into. I was asked to post this by “Anon” who was very concerned about this being live as soon as possible. Apparently the photo disclosure issue been around for more than a year. The email has been snipped and modified in places to hide the identity of the person who sent this to me.

Hi RSnake, there’s a new PhotoBucket vulnerability which has actually be around for about a year now, which allows access to “Private” PhotoBucket accounts. Please publically disclose this on ha.ckers.org.

The vulnerability lies in an XML file, which is stored in the account, which is located on an IP address that resolves to PhotoBucket.com. For instance, http://s0006.photobucket.com/albums/0006/pbhomepage/, which is the PhotoBucket example account, can be changed to http://66.11.55.160/albums/0006/pbhomepage/.album.xml, which displays an XML file displaying all paths, images, videos, and slideshows. It has access to ALL accounts no matter if they are locked or not. By navigating to http://66.11.55.160/albums/0006/.album.xml instead you will find an XML file containing a list of users’ accounts that are available on the selected server.

Again please disclose this immediately, and anonymously (no mention of me please), so that the issue will be patched.

So there you have it, folks. All Photobucket photos marked as private has been visible for a year to at least the people who found out about this issue and didn’t report it. “Anon”, who forwarded this to me felt it should be closed immediately. Hopefully this too is fixed rather quickly, like the last one was. Let the onslaught of comments begin.

After the fallout of the challenge a few interesting things happed. A backup of the .htaccess file was found, an XSS hole through a cookie value pair that I forgot to sanitize and most interestingly a way to actually hack the test! I’ve told people before, there aren’t many people on the Internet who I think could hack just about anything - but Stefan Esser is definitely one of them. He found a rather interesting logic flaw in the test, that I wanted to share.

The challenge dealt quite a bit with cookie tampering. Since some people still may not want to have this spoiled for them, I’m removing the actual values. But what Stefan submitted was "admin=…;admin=…;admin=…;admin=…;admin=…;admin=…;" Why would that work? Well let’s look at the logic of the rather poorly written application (modified slightly for readability and to keep the cookie values cloaked for anyone who still wants to try the test):

…
  if ($cookie_name =~ "admin") {
    if ($value =~ "…") {
      print " - Yes!";
      $answer++;
    } else {
      print " - No. Sorry, try again.";
    }
  } elsif ($cookie_name =~ "NotGettingIt") {
    if ($value =~ "…") {
      print " - Yes!";
      $answer++;
    } else {
      print " - No. Sorry, try again.";
    }
  } …

There are six cookies that need to have the correct value. But if you look at the logic, what happens is that since Stefan put the same value over and over, it never made it to the next question. The value still added up to 6 which is what the application was looking for, and voila - he submitted the answer without ever completing the challenge. He hacked the test (not the server). Very clever. What did I do to fix this? It was just a matter of holding state and not letting it answer the same if statement twice. Pretty trivial to fix. But this test was not designed to be a well written app - faaaar from it.

In fact one of the reasons this is actually fairly relevant is because I’ve seen a few apps written like this in how it looks at cookie values. In particular it looks at the entire cookie string and says if you see some value _anywhere_ in the cookie string it acts one way. This can give you insights into how the application works. So yes, it was a very poorly written app on purpose, but Stefan found one thing that actually wasn’t on purpose so huge props to him. Very cool.

For those of you who are interested, the second ha.ckers.org challenge is underway. Click here to begin the challenge. Every thing you need is under that directory, and even after the contest is finished you are still able to participate, for those of you who don’t like the pressure of doing something in a certain timeframe. The forum is open for people who want to chat about this while they work. For everyone else, good luck!

Update: And the results are in! Pretty amazing times for the first several winners, and I’ll have to post on our “special winner” Stefan who managed to actually hack the test. Congrats to everyone who won! A spoiler is now live for anyone who is completely stumped.

2:04:53: NoS (Sergey Novotarskiy)

2:06:51: Stefan Esser

2:17:50: AviD

2:20:31: Mario Heiderich

2:21:00: christ1an

3:13:14: kuza55

3:17:22: Jibbler

4:32:43: barbarianbob

5:58:31: David Lindsay

6:22:45: fidels

And since he asked so nicely to be mentioned, Jesper came in 11th with a time of 6:28:05. DoctorDan followed at 6:52:11.

It looks like Cenzic is suing SPI Dynamics (now owned by HP) over a patent infringement. Cenzic has patented fault injection. Cenzic obviously feels confident that SPI is infringing on the technology they have patented. It’s a strange move, given how many people have vested interesting in making this patent go away. Now that Cenzic has become litigious it seems like it would be in the best interest of the industry and indeed all companies everywhere that use other scanning technology to get the patent thrown out. At first I didn’t care about this when I first read about it but now that Cenzic has taken to suing companies, I feel compelled to take action.

Personally I hope that SPI wins this and the patent is thrown out for a number of reasons. I think the patent is both obvious, has been done prior to their claims and been invented by dozens of people and companies over the years who have released their findings under various copyrights and licenses (myself included - I built a number of tools that injected specific faults into systems as early as 1995 and let’s not forget SATAN written in 1993 and stuff like the PHF scanning worms in 1996). But most importantly it’s hostile to the industry as a whole. It would only make things far more difficult, inhibit innovation and reduce our ability to secure the Internet as a whole. I have nothing against Cenzic, but this patent must die. In the mean-time, until this patent is thrown out, you are taking a risk if you have built any fault injection scanning technology that does not license Cenzic’s patent. Everyone else, please submit your prior art to the comments of this post or to SPI’s lawyers as you see fit.