I’ve been posting on the Binary Revolution Forums a bit lately, mostly in threads with a technical theme. I’m mostly doing it to sort of contribute to a place that’s popular among people just starting out in the field. Today, a link was posted about the recent attacks against MediaDefender, where a large amount of their email and intellectual property has been leaked out.

I gave the situation some thought, and I think I’m going to have to disagree with what seems to be the general consensus among internet users. I wrote up some of my thoughts and posted it, and I liked it enough that I’m adapting it into the blog post for today:

“What’s funny about this is it really exposes a lot of peer-to-peer filesharing advocates’ true position.

The services MediaDefender provide for copyright holders are designed to have a chilling effect on the filesharing of copyrighted content (they also do marketing via P2P, which is legal, and I think a pretty good use of P2P). So we have a company here that recognizes that there are legal and legitimate uses for P2P, and instead of being all “There should be legislation outlawing this”, they do the right thing and provide a technical solution to a technical problem for copyright holders. The fake files and information gathering tactics apply to situations where people are knowingly downloading content for which they have no rights. You’re not going to run into MediaDefender’s mechanisms downloading Linux ISOs and sharing independent music over P2P, like many advocates of P2P technology would have you believe they do.

It’s a neat solution. Gum up the infringing activities of P2P users while letting the protocols and those who don’t abuse them act freely. It’s a useful service for copyright holders. So what is the collective internet P2P geek reaction to them? It can be pretty much summed up as “Screw them, they deserved to get hacked, they are the devil”. Poking around a bit, I can’t really find a positive thing being said about them.

What it boils down is this: most of the people advocating peer-to-peer with the caveat of it being useful for legal content, really just want their copyright infringing uses to be safe under that blanket.”

 

OpenWRT on the Fon Fonera is one of the most popular posts on this site, however there’s a few rough spots, as it’s more of a set of notes from my own personal experience rather than a polished How-to. There’s several places where someone might fall through the cracks if they’re not using a very similar configuration to mine, or simply aren’t reading my mind.

To improve on this, Brett Hoff and Russell Butturini have made some notes of their own, as in-line comments to mine. to clarify some of the things that have changed in newer versions of Kamikaze and the Fon, gotchas with non-Apache web servers, and a few other things you might have problems with. Those notes are available here.

Happy flashing!

 

I like SunbeltBLOG a lot (and I recommend that you add them to your reader), however, like most of the content in my RSS reader that I really like, I occasionally find myself disagreeing with them. Today’s post, For shame: Thawte trusts Gromozon is one of those times. While I can certainly understand people not liking anything that helps out malware, I think this is a case of people’s expectations about what security mechanisms are supposed to provide not matching up with the reality. Another good recent example of this is the embassy password incident, revealing the fact that many people were under the impression that Tor provides privacy (which it doesn’t), when it’s designed to provide anonymity (which is does, if you use it right).

Picking this apart, let’s see what people think code signing is supposed to provide. This is easy: a lot of people are guilty of assuming that something being signed means that it’s safe to install. This comes from impressions that people have formed about what a signature means, and what role the certificate authority takes in the matter. Let’s take a look, starting with the title of the SunbeltBLOG post:

“For shame: Thawte trusts Gromozon”

Certainly sounds shameful, after reading what Gromozon does. But does Thawte really trust Gromozon? Is that really what the certificate means? If you follow the link from SunbeltBLOG to SpywareGuide then you’d be inclined to think so. They spell out what they think the certificate means:

  • The publisher: The software really comes from the publisher who signed it . Publishers most go through a process to verify their identity and that they are who they say they are.
  • The content: The software has not been altered or corrupted, and is therefore safe to install and run.

Hit the brakes there! You’ve gone a little too far. This was right, up until the last bit about “…and is therefore safe to install and run”. The certificate authority does verify the identity of publishers, and the process of signing code, and verifying that signature on the client does mean that it hasn’t been altered or corrupted between the publisher and client. It does not speak for the content, actions, and motives of the software or the publisher! People think that digital signing of code “solves” the problem of malware, however it only means that the malicious code has been there since the publisher signed the code. It may deter people from putting their signature on malicious code, since it can be tracked back to them easily, however this demonstrates that this doesn’t bother or stop some authors.

Go to the horse’s mouth. See what Thawte has to say about their code signing certificates. Having code signed by the publisher “effectively verifies the source of your software before it is downloaded”, and “Ensures that your active content or code cannot be maliciously modified” (“your” referring to the publisher). For the end-user of signed software, it gives them “recourse to the person who published it”. This is all consistent with signing something like Gromozon. The only time it really comes close to speaking of the content of the signed code is when it says that the process “Promotes the Internet as a secure and viable platform for content distribution”. This might be mistaken to mean the end-user’s security from malicious code, but it’s really in reference to the threat of modification by third parties.

So, code signing is a good idea, but people need to understand the problem that it is meant to solve, and the problems that it does not.

 

Last night, a friend pointed out an auction on Ebay Motors that would automatically redirect you to a phishing site. It turns out, the auction had a flash movie embedded that performed the redirect. Here’s the relevant bit of the auction’s code:

I haven’t bothered obfuscating the IP address, so don’t go poking around unless you feel like you know what you’re doing :) . As a matter of fact, for the sake of folks using GooSweep to investigate incidents involving this guy, here’s something for the googlebots to pick up: The IP address 89.34.212.194 is hosting a handful of Ebay Motors phishing sites and flash redirects to those sites..

The host is in Romania, and has been around at least long enough to get its phishing sites indexed by Google. Since there seems to be such a small chance of getting caught and punished for this sort of thing over there, many Romanian attackers are pretty open and carefree about their operations. I wouldn’t be surprised to find out that this box is some old PIII under the phisher’s desk.

Moving on, the flash file itself is pretty interesting. It’s only 172 bytes, and as you can see from the screenshot above, it’s being hosted in a few different places. It may be an attempt to make sure it fails over if the hosting goes down, but I suspect it may be an attempt to throw careless investigators off track. Only the center, highlighted link to 89.34.212.194 ever worked since the time this was spotted. I grabbed the swf, and since it’s so small, my first instinct was to just take a look at it directly:

I don’t know a lot about flash and I didn’t have any flash specific tools on my system, but this is pretty straightforward :) . To make it a bit clearer, I installed flasm (a Flash assembler and dissassembler) out of the Ubuntu repositories and ran it to get the following output:

Again, I don’t know much about Flash, but it’s obviously not rocket science. The attacker defines a function that getURL’s the target, and sets up a call to it in the first frame of the “movie”. It’s pretty trivial to modify this to redirect anywhere, just change the url and use flasm to recompile. I tried this out, so here’s an swf file that’ll redirect you to my blog ;) :

Sample Flash Redirect (.swf)

This is a bad situation for sites like Ebay, with users that demand the ability to have Flash content (such as image galleries, animations, etc.). It’s easy for them to patch up ways to redirect and XSS in the auction’s code itself, but it’s much more difficult to regulate what goes on in Flash objects brought in from other servers. It’s also difficult for Adobe to fix this up in Flash, since I would think that many legitimate sites use the getURL functionality to hop around. I imagine a solution would require sites to have policies on what functionality is allowed and/or disallowed, that the Flash player would have to parse and honor those policies.

 

While looking for something else, I noticed that many of the talks from Defcon 15 were uploaded to Google Video yesterday. I have really been looking forward to seeing some of these talks, and wasn’t expecting them to be online so soon, so it’s a very pleasant surprise :) . Here’s a link to a query that should show all of them:

© 2012 McGrew Security Suffusion theme by Sayontan Sinha