AppSecLive.org

Typically, companies give less security considerations to the web sites that they host internally on the intranet. This is understandable, given that the only users are trusted folks, and probably aren't going to try anything anyway. Most internal users do not have the technical skills to be a 1337 haxx0r and perform SQLi attacks on vulnerable web forms, and store XSS scripts on company knowledge bases. Now, I know what you are thinking.

 

 

 

“we aren't supposed to make assumptions about things like this”

 

No, we aren't. However, its much harder to argue with the internal department heads when only 20 people will be using the application, it was developed internally with an access back-end, and the author retired 7 years ago.

 

These are exactly the types of intranet applications that pose a growing risk to companies all over the world.

 

The biggest risk here isn't the user, or even a malicious hacker coming at you from the inside. Wanna know what it is?

 

Bot nets

 

These massive collections of zombie computers have gotten smarter, faster, more effective, and much more dangerous over the last few years. Mostly because we, as security guys, are trying to shut them down. There have been a few highly publicized cases where bot nets were used to compromise thousands of sites by injecting either XSS scripts pointing to malware, or by injecting malware directly into the site DB by way of SQLi.

 

These are a few examples of such:

http://www.networkworld.com/news/2009/061609-nineball-websense-attack.html

http://www.networkworld.com/news/2009/060209-beladen-web-attack.html

https://www.networkworld.com/news/2009/051909-web-attack-that-poisons-google.html (Gumblar)

 

You are probably thinking: “but these are internet apps, publicly accessible from the net”. Yes, they are, but these bot nets could just have easily poked the local intranet ip range for port 80 from within the company. It only takes one infected laptop.

 

Now most companies have antivirus, outbound authenticated proxies, and the like, but I'm afraid these aren't sufficient protections, and here's why:

 

Authenticated proxies stop arbitrary, programmatic, unauthorized requests from exiting the network over 80, 443, and a few other ports (8080, 8081, etc). When an internal user hits a site with an embedded iframe that points to i0wnzz0ru.ru/yougotit.exe, the request will traverse the proxy using the user's credentials. This is because browsers aren't differentiating between intranet proxied applications and external proxied applications. The only protection from this is locking down the browser, creating an internal CA, and distributing certs internally while mandating SSL on all intranet apps. This still isn't rock solid because of the “user” factor, so there is still an educational requirement there.

 

Antivirus is broken, has been for years. I'm not saying turn it off and cancel your Symantec contract, but the fundamentals that surround how AV works is flawed. Signatures require that you know of the threat before it affects you, and that is just unrealistic. As a matter of fact, I wrote a really nasty program just this week in python. (was a poc for something) Between py2exe and pyhook, I can own a windows box within seconds, and there is... Oh yea, ZERO AV detection simply because no one has ever seen it before.

 

Another issue facing companies is that intranet applications are stood up quickly, cheaply, and often with little thought given to security, stability, etc. Because of this, there are often so many of them that it is simply impossible to perform a full security review on them. Interestingly, the only reason your company has fewer externally facing sites is because it is typically a royal pain in the arse to install these. Lots of red-tape, unless its internal only.

 

All of these factors combine to create a seriously nasty scenario. Stay with me here.....

 

Scenario 1 – Bot Net

 

1. One of your brilliant users take his laptop home, gets the latest copy of nineball, courtesy of twitter or myspace or some other social site.

2. This user comes to work the next day, unaware of this problem because his AV doesn't have the signatures yet.

3. The bot on the user's laptop starts probing the local network for web servers.

4. Spiders the first site, finds sql injection, drops a binary in the DB

5. Un-infected user 'b' visits the company's trusted intranet news page, which shares header include files in the same DB as the infected app.

6. Within a few hours, you are running 7 binary distribution points, 1200 infected PCs, and the rest is history.

 

 

Scenario 2 - BHO

 

1. Same brilliant user, running a great, current set of AV sigs. Downloads and installs a new screen saver program that includes a Browser Helper Object. This BHO reads and stores URL patters from the browser, finds strategic entry points, and inserts code in the place of the user data, but with a twist... It's using the user's authenticated session.

2. .. Insert scary story here .. (start with step 4 from previous)

 

 

So, there could be hundreds of variations here, the point is, if your intranet applications were coded securely, there would be minimal chance of success. Are yours coded securely? Do you know?

 

Chances are, no, and you don't. So what can we do???

 

1. Start reviewing your internal apps as they come on the network. You have to start somewhere.

2. Set up an IDS between your users and your web servers and watch your web traffic closely.

3. Source review. This is hugely effective when done correctly, and guess what, intranet code should be accessible to your security team.

 

I'd be interested to hear other suggestions about what countermeasures folks might take on this. Post comments if you do.