Network Security: Beware! (Part 1)

This one is the first in a series that highlights various aspects of n/w security that goes un-attended or needs still more attention!

I was going thru some articles on N/w security as part of my daily Security-dose. As a developer working on products that uses the word "Security" day-in-day-out... I feel that we sometimes overlook the importance of this word in our security products' implementation.
There's this book Stealing the Network: How to Own the Box that reveals (in a fictional story telling way, and i like it) different ways of gaining unauthorized access to secure Networks and computer systems. Another read about writing secure code, adresses why programmers write in-secure code. It also highlights common and well understood exploits/issues of the past (due to C being unsafe in certain areas) that still go un-checked in every 2nd release.

Not all the ownership lies with the developer looking at the fact that Strategic enhancements/design/architecture is still a work of a few evangelists in the field, but as far as the hacks caused by bugs in the code are concerned they go much in number; big names in the security products industry seem have a direct proportion b/w the brand value and the no. of exploits in their product.

Avenues of attack:
As far as avenues of attack within the secure n/w are concerned Printers now-a-days are not behind. Like our ever-increasing-powerful PC, printers (read multi-function devices with copy-fax-print-send_fax_as_email) too are becoming intelligent agents in the enterprise. What if they started out as passive devices like the old character/line/chain printers, printers have now evolved into actively managed network agents that run pretty neat OS kernels which supports the network stack software and very well understand the Enterprise n/w hierarchy allowing identity-managed print jobs, authorised administration using print-servers etc.
There is still a tendency to take them as the passive utility devices that explains the negligible network security on a printer. Since the printer can communicate with the rest of the network, it can serve as a platform for attack (as a network proxy if nothing else).

As Bruce Schneier mentions in his foreword to Building Secure Software: How to Avoid Security Problems the Right Way:
"We wouldn't have to spend so much time, money, and effort on network security if we didn't have such bad software security. Think about the most recent security vulnerability about which you've read. Maybe it's a killer packet that allows an attacker to crash some server by sending it a particular packet. Maybe it's one of the gazillions of buffer overflows that allow an attacker to take control of a computer by sending it a particular malformed message. Maybe it's an encryption vulnerability that allows an attacker to read an encrypted message or to fool an authentication system. These are all software issues."

At the 2007 RSA Conference, Bruce puts another point: Human beings aren't evolved for security in the modern world, and particularly the IT security world. There is a gap between the reality of security and the emotional feel of security due to the way our brains have evolved. This leads to people making bad choices.

Towards this state of N/w security, a lot can be attributed to software bugs; the way we've been writing OS, N/w applications and middle-tier code.

The language used to develop most of the OS's (not only Win, UNIX/Linux but also OS's that run on the routers, printers, ATM's etc.) had been C/C++ that had limitations in terms of memory leaks (GC features),compiled range checks etc. (although we've a lot of evolved features now in the language). For e.g.: Buffer overflow attack results (mostly) due the missing compiled range checks in C/C++
With range check capability a buffer (array) overflow can be caught at runtime.
Java compiler inserts code that checks access to a buffer (array) is within the bounds of the allocated memory. If the access goes past the end of the buffer a runtime error should occur. It's better to error/exit/raise an exception in the software rather than let the intruder gain access to the system.

char mySockBuffer[SOME_DEFINED_SIZE];
while (!read_my_socket(mySockBuffer)) {
do_something();
}
The code reads a stream of text from an input connected to a TCP/IP socket. A stream of text longer than 80 characters will overwrite data which is stored following mySockBuffer. A text stream of just the right size may overwrite the return address for a function (possibly the function that called the current function), allowing the attacker to insert and execute his own code.
This can result in a potential BOEP and can even let an attacker write over the legitimate instructions to get a malicious code executed on the machine.
A typical example is a code where the developer has a 256 characters array to hold a login username for a web based back-end system.
A hacker sends 300 characters with code that will be executed by the server, and voila, he has broken in. Hackers can find these bugs in many ways.
1) the source code for a lot of services (GNU based are popular) is available on the net. Hackers routinely look through this code searching for programs that have buffer overflow problems.
2) hackers may look at the programs themselves to see if such a problem exists, though reading assembly output is really difficult.
3) hackers will examine every place the program has input and try to overflow it with random data. If the program crashes, there is a good chance that carefully constructed input will allow the hacker to break in.

An intruder would try using unexpected combinations of input on web based forms to break in. Most of the apps today use multiple layers of code, that includes API calls to the underlying operating system as the bottom most layer. An intruder can send the input that is interpreted as a string by one layer, but taken as a meaningful command by another. For e.g. PERL is mostly used for processing user inputs on web based systems. PERL usually sends this input to other programs for further evaluation. A common hacking technique would be to enter something like "| mail < /etc/passwd". This gets executed because PERL asks the operating system to launch an additional program with that input. However, the operating system intercepts the pipe '|' character and launches the 'mail' program as well, which causes the password file to be emailed to the intruder (although not so easy as it looks). I've seen instances where intruders have tried breaking in by this route where they can execute their malicious code as a legitimate piece of response to an event on a system.
Exceptions and Unhandled input: Most programs are written to handle valid input with known preconditions and evaluations. A developer won't always consider what happens when someone enters input that doesn't match the specification. This could become a security hole that an intruder can exploit for an unexpected program behavior during unhandled input scenarios.

There are certain other scenarios and known exploits for Network security apps, OS and n/w configuration. There are design flaws in N/W protocols and loop-holes in the way OS security system works. Just think about TCP/IP... it was designed earlier when there was not much of a wide-spread intrusion/hacking concern thus leaving enuf ways for intruders like: smurf attacks, ICMP Unreachable disconnects, IP spoofing, and SYN floods. The biggest problem is that the IP protocol itself is very "trusting": anyone can forge and change IP data with impunity. IPsec (IP security) has been designed to overcome many of these flaws, but it is not yet widely used.

What next: I'll be compiling some programming tips, DO's and DONT's etc. on n/w security and putting them all in the next post on this series. Bugs too will make it to the next one.
For more similar reads refer:
http://www.linuxsecurity.com/resource_files/intrusion_detection/network-intrusion-detection.html
http://www.embedded.com/design/202300629?pgno=1