Breaking then Fixing...

How to Win Friends and Influence Testing

Yesterday I encountered and interesting issue that demonstrated the real necessity behind good network testing. To give some background on this story, I have previously contacted a testing vendor and have them give a very good presentation on the ins and out of good Q&A testing. The organization that saw this presentation sought this to be a bit much for their environment.

This organization has a pair of IPS Sensors in which are leveraging spanning-tree in order to have fail over. The figure below illustrates the design. 

 

Now the vendor that supplied the IPS code is having a problem with their few latest builds. The vendor's most stable release still has a bug with the SMB portion of their engine. What is interesting is that when a particular type of SMB traffic passes through the engine the engine will fail. Now this particular organization has several tools to view the health of certain things but the IPS sensors are not one of the ones they can easily view. What happened to this particular organization was that the sensors failed, both of them. The primary sensor failed and the secondary sensor failed upon seeing the traffic conditions. It was 9 days different between the primary and secondary failure. 

The beautiful thing about this design is that you leverage spanning-tree to complete fail over and the reason that is important is because the switches and routers are participating in a load sharing mode for increased performance.

The vendor is now suggesting to this team that an engineering release that can be specially developed for them that will address the issue is the way to go. So what does this organization do? Do they install code that is not completed vetted? Can they test the code thoroughly first? Do they rely on blind faith and risk complete IPS failure?

They now see the need for better network and system testing before go live and production. You see they could put the new IPS code on the secondary sensor and see if it crashes the 'passive' node, however they have not run traffic through that release since its a passive node.

This was good opportunity to win friends...and influence testing.

An Intro into Web App Security

For many years we have all come to see the fact that the network systems are flawed. TCP/IP is not perfect and was not designed for secured transmissions. Appletalk or IPX/SPX for all you apple and novell fans waiting around for a comeback will not make things better. There are some that believe that we are getting good at discovery and blocking these types of attacks. After that came the OS attacks, how lovely those easy buffer overflows were to find and exploit. One day you may even here me do my best impression of 'who's a good boy' pet, except instead of my dog it may be to MS03-026, but I digress. Now that we are going further into the stack we keep hearing that one day the web will be our operating system. I am hopeful that won't be the case in a strange way.

Web Application Security is a pretty hefty subject. Let's look at the components first to get a better understanding. The server side can run a multitude of servers to give you the ability to deliver web based content. Apache, IIS, Websphere, and even custom servers all appear frequently. Now this conversation will not pertain to vulnerabilities within the service lets look higher in the stack. In the same token you have a multitude of browsers now, Internet Explorer, Mozilla Firefox, Safari, Opera, Google Chrome and more. They can all render web traffic out of the box. The problem isn't necessarily this architecture but let's dig further.

The web servers are now able to deliver 'dynamic content'. As end users we love dynamic content, as pen-testers we LOVE dynamic content, and as defenders we have NO LOVE for dynamic content. How can we deliver this content? If you are an open source proponent you think, what about LAMP or WAMP. LAMP stands for Linux-Apache-Mysql-PHP/Perl/Python/Etc, and WAMP is the Windows equivalent. Most organizations are now focusing on .NET Framework. For some reason we are still kick around Java.

...Oh yeah AJAX too...

So lets get back to this idea of dynamic content. Computers love code, they LOOOVE to run whatever you give it. In the web application space this becomes precarious because the code that the browser will automatically render and run, or the code that the server will process and run, can actually allow for 'exploitation' without 'exploitation' in a strange sort of way. Since this is an introduction with more 'parts' to come lets explore this.

You have a browser that automatically renders Javascript and PHP code. You have your browser go to a malicious site which allows for an 'attacker' to hook your browser and control its interactions through JavaScript code. Assume that the actions in which the 'attacker' is using to control your browser is now not considered 'dangerous'. It looks like regular http based transactions and will look like perfectly normal javascript and delivered to your device. This type of system will most likely be re-rendered through a proxy, ignored by IPS systems, and if the site is considered 'safe' content filters will allow it as well. In addition most host IPS's will allow for this to pass as long as the content delivered is not doing something 'malicious' to the system like deliver an actual exploit to a service.

So then the question I pose to you is, If a giant multi-billion dollar, multi-national corporation like Microsoft cannot fully fix all the security problems within their paid for software, how are we to expect that custom application code running on web servers and rendered on your browser are not going to have issues? Insecurity Yet?

I welcome feedback and discussion!