I’ve been asking about this for years now, but I finally got my answer, yes, the US government is going to test the state of cyber-security in the event of a cyber war. The goal is to identify weaknesses and come up with solutions to a large scale network attack. I was bitching about this when I was a member of the IT-ISAC - there was no one working on this at the time, and it was scaring the crap out of me. Apparently someone was listening!

I have no idea how the test is going to play out, but to anyone who is involved, let me reiterate this issue - the attacks often come from within. It’s not only outside threats we are going to have to contend with (and furthermore once something is inside a network it’s hard to get out). So is the case with viruses, XSS worms, botnets, etc…. You may be able to kill the command and control but that relies on one critical assumption - that there is one. Anyway, I’ll be very interested to see the results of these tests if they are ever published.

I ran across this article today at Wired about how MySpace shut down SecLists.org by contacting Godaddy. Apparently MySpace was annoyed that someone had posted to one of the lists a bunch of MySpace passwords from one of the successful phishing attacks a while back. Instead of contacting Fyodor, who I’m sure would have reacted appropriately, they went right to the Registrar (Godaddy).

The site was down at some point, but is back online now. But it does make me scratch my head a little knowing how close his site and our sites really are. Are we at risk for ToS, because it’s objectionable materials? Even if it’s totally defensible is Godaddy simply going to nuke our sites because some company issues a cease and desist? Did Godaddy even verify the nasty content? What if someone else uploaded malicious content to the site (XSS, SQL Injection, or straight old hacking into the machine). It’s troubling to say the least.

ntp published an interesting conversation today on sla.ckers.org discussing IP trust relationships that web applications often have. It might sound crazy that one site should trust anything at all, but I’ve seen countless examples where certain IPs are simply ignored by security systems, purely because they are believed to be secure. First of all, insiders represent a majority of corporate hacks. Secondly, every day, on this website and on sla.ckers.org we are finding IPs that are untrustworthy, regardless of the brand associated with them.

To elaborate on ntp’s thoughts, let me give you a 95% real world scenario that I’ve actually seen. There is an online credit card processor that actually uses IP based authentication for adding user accounts to your database. Not only is that scary, but it’s highly probable that the usernames could include SQL injection. Not because the credit card processor would allow that through, but because the scripts that run on your server trust whatever is sent through the credit card processor. Now let’s assume for a second that the credit card processor’s machine is a windows box, and runs a remote desktop.

Someone at that company could easily be subverted into clicking a link (I tell them that for some reason I can’t get a connection between their server and my own so they must log in to verify it). When they click the link, it performs actions on their behalf (beyond connecting to my machine). Normally that wouldn’t be a big deal. They aren’t authenticated to anything, and they may have never used that account before. However, because of IP trust relationships between their IP and every one of the merchants that they service, I now can add user accounts to as many accounts as I can reasonably do in the time the browser is left open. Not only that, but I can do SQL injection and pull other user accounts, delete databases or whatever I choose to the database.

Suddenly the trust relationship has allowed major security issues, due to the privileged nature of the credit card processor. Nasty. There are all sorts of these IP based trust relationships on the Internet, because there is really no other good way to know who a user is before they have authenticated. Nasty, and a very overlooked attack vector.

I really was dumbfounded when I read that Microsoft confirmed that the NSA had helped them develop Windows Vista. Not so much because I didn’t think it was possible (I’ve heard it all at this point) but that they admitted it. First of all, most of the reason you have a spy agency help develop something is so it will be better at spying, second of all telling someone how you intend to spy on them pretty much kills the whole concept of it. It’s not like I’m talking out of school here either, Microsoft fully admitted it to the press.

There are two possible backlashes from this. 1) The backdoor will be found and either used against the US government or used against it’s citizens. 2) Foreign governments and security/privacy experts will avoid using Vista for anything sensitive. Either way it could completely defeat the purpose of the collaboration. You’d think after the NSAKEY issue that came up several years back they would have learned how people react to hearing this kind of thing.

The only thing I can say now is if you are concerned that a rogue Microsoft user or the government have access to your computer systems, you probably shouldn’t use Vista. I hate having that opinion without even having tried it, but what else can I say? I guess I can’t really have much of an opinion, seeing as how the details of their cooperation are obviously very guarded, other than I think in this particular case insecurity through obscurity would have been a better option.

I had an interesting conversation with a co-worker today. It was actually not security related initially but a side tangent really caught my attention. A friend of a friend does industrial espionage for a living (what a weird job, huh?). One of the tactics that he employs is to pretend he is an executive recruiter trying to hire away someone from the target in question. So he calls the person up, claiming to have a great job with a good company, and he basically sits, asks questions and listens. The people spill their guts. It makes you sick doesn’t it? Social engineering at it’s finest.

But it occurred to me, there is really nothing stopping any social engineer from doing the same thing. Outside of the scope of industrial espionage, of course. There’s no reason I couldn’t call an employee of some big company and claim I am some hotshot recruiter, giving them just enough information to get them enticed and ask exactly the types of questions I need to know. Thus providing me enough, as an attacker, to penetrate the system given the known vulnerabilities that the employee has given me information into. Verrrrrry interesting. Makes you think back to all those recruiter’s phone calls you’ve taken, huh?

There is a concept in web application security that I’ve been toying with for a few years, based off of a common consumer feedback mechanism called waterfall analysis. Typical waterfall analysis is the rate of drop-off from page to page. The easiest way to think about it is a flow that has multiple pages in that flow. Each page represents some user interaction that is required (a registration flow is a perfect example). On each page, the ratio of users is calculated to help diagnose drop-off ratios. If you start with 100% of your userbase, some amount less than that will go to the next page, and some amount less than that will go to the second page and so on.

Now think about it from an attacker’s point of view. Let’s say you were able to separate your good traffic and bad traffic into two distinct buckets perfectly. Let’s also assume we only care about users who completed the flow (causing the function to fire) and so we are only looking at those users. 100% of both good and bad traffic make it to the function, each in their respective buckets. Here’s what it might look like:

When you put it like this it looks pretty obvious (this doesn’t account for users who hit errors and have to re-submit, or multiple path flows, but you get the idea). Using an inverse waterfall you can see that attackers tend not to enter your page through a normal page-flow. They don’t act like normal users because they don’t have to. They simply attack the critical infrastructure directly, performing the malicious function.

This might sound familiar because looking at flow analysis is an old trick used by products like AppShield and used in lots of anti-CSRF functions. But none of them look at it from quite this angle. They look at it from the opposite side, which is that you must have a credential to move on, which is good, because the inverse waterfall can be broken by the attacker simply following all the steps. But because an inverse waterfall does not give off any signals (no obvious cookies/credentials beyond what is required for the flow itself) it becomes far more passive. It is also easy to do regression analysis against your logs to identify possible fraud that has taken place after the fact, which you can’t do with a credential system since credentials are rarely logged. So while it does have flaws, it certainly does have some benefits too.

Anyway, just a thought.

I know I don’t often talk about network security (that’s really more id’s domain than mine anyway), but I got sent this link this morning that I thought I’d share. It’s the small business primer on network security threats. It’s a pretty good brief overview on what you want to do as a small company to make sure you are secure from the more common security threats out there. It’s a pretty good high level read. There are a few things I’d probably have added if I had written it.

Anti-Spyware: spyware is really really nasty, I don’t care what people say, it’s one of the nastiest things out there today. Not just because it can read what you are doing, but because with minor changes they can force your system to download viruses, keyloggers or whatever else they want. It’s nearly impossible to stop without a good anti-spyware program. People may confuse this with a Trojan, but a trojan is something with an implicit back door. With spyware or adware the administrators can inadvertently land you on a site that will make them a few bucks but the other server in question gives you something malicious. It’s not a Trojan by design, but it can act as one.

Network segregation: id could probably go off on this one bullet alone, but by separating your networks (wireless is separate from corporate, etc…) you hugely reduce the liability of having one machine compromised.

Local admin genie: Don’t let the local admin genie out of the bottle. If you give your users local admin rights, they will do way more with the computer than you would want them to. The second you give them higher privileges to install anything, you have opened yourself up to attack. It makes it hugely inconvenient for your users who want to install their favorite MMORPG on your work computers, but it’ll save you tons of hassles.

SSL/SSH/VPN: Encrypt your traffic, even if someone can ARP spoof a switch, they’ll be reading garbage. Don’t let them see your traffic. This is in response to their WiFi honeypot (I think they meant MITM bridge, but you get the idea).

Turn off all unneeded services: It’s a simple one, but this is one of the most important to corporate security. There’s no reason to keep FTP open, if you have SSH - you can SCP things over SSH, so shut down that exploitable outdated WuFTP service.

Email separation: Keep your work and your personal email separate, that way if they get an email from their bank at their work address they’ll be more likely to know it’s fraud. Further, don’t click on links in emails - ever! That’s what we call, bad. If you really want to cause a revolt ban all access to all freemail services, because really, what are you paying them for?

Backups: If you aren’t backing your data up, something as simple as a misplaced cup of coffee can bring your business to a halt. Network security involves good application security as well, and disaster recovery is a key component of that.

Anyway, I’m sure there are dozens of other simple things you can do, but that stuff definitely will help. Interesting read for the IT novices.

On the sla.ckers.org board Lobas asked a question regarding stealing clicks. The short answer is you cannot force a click inside of an iframe on another domain. The cross domain policy prohibits that, especially since inside banner advertizers you never know what the links will be. However, there is another way that Jeremiah Grossman mentioned a while back that I thought was pretty clever. You can actually move the banner ad to be placed immediately below the mouse so that when it’s clicked the user is tricked into sending their click event to the iframe beneath the cursor.

I wrote a sample code off of one of those annoying cursor following scripts to show that you can force text in a div (what could be an iframe to the banner ad) to be placed immediately below the image. What I haven’t shown is that the onclick event handler can be used to make the div appear at the right moment, or that you can make it semi-transparent or any of the other fun tricks. But this proof of concept proves that iframes are not really a particularly good way of protecting from click events. Banner advertisers beware!

I can’t say this really surprises me too much give my own results of other high profile domains, but x90 (NOP) was able to locate MySpace’s administration console. That just sounds like a bad idea - leaving the gateway to your administration publically facing. He was able to get it to error out which provided some interesting results as well.

Fierce is a good first-pass reconnaissance tool, and as you can tell it shows you thinks that aren’t obvious at first blush when you aren’t sure what is hosted at the domain. In just a few minutes of testing you can uncover huge swaths of vulnerable targets to exploit. This is no exception. It’s neat seeing people try it out and see what it can find for you. Let me know if anyone else finds interesting results or case studies. In the meantime, I hope MySpace knows enough to take this server off-line until they can harden it or at minimum move it to a less obvious place.

This is a really upsetting story about how a teenager was infected by a trojan, used as a fileserver for child pornography, and then attempted to be prosecuted as a sex offender. The sex offender charge was based off of a plea charge after admitting to showing other teenaged boys a playboy magazine. The circumstances are so ridiculous it’s just painful to read. The jist is the boy went to visit a porn site that infected his computer, and then the police detected the computer uploading child pornography.

I was asked after being sent this if having a firewall and anti-virus is enough to protect your computer. Unfortunately the answer is no. Let’s think about session riding for a second. It is trivial to get any user to download images from any website that doesn’t protect itself with a simple IMG tag. In this way a user can visit an otherwise benign site, and be forced to download child pornography or perform attacks on servers or whatever the attacker wants by proxy. Very scary.