|
Ihr Spezialist fĂĽr komplexe IT-Systeme
|
|
Ihr Spezialist fĂĽr komplexe IT-Systeme
|
To perform bug hunting in networked systems you generally have to follow four steps.
First of all you have to understand the underlying network protocols and how client and server interact together.
Next you have to identify the different parts of the transfered requests and responses, especially the fix and variable parts. The variable parts are made up by the provided user input. You may also notice check sum or length fields in the network packages. During this phase you will work a lot with programs like tcpdump, ethereal or ngrep.
Ok, we have done the basics and it is time to start hacking. You now try to inject anomalies into the analyzed requests. Some people program Perl scripts or C programs to perform this step. Others use programs like Spike, SpikeProxy or WebScarb for the injections.
But injection alone is not enough, you also need to monitor the system you are injection the requests to. You can do this by analyzing the response (e.g. for error messages or changes of the provided output) or by observing the server process with debuggers etc.
Let us start with an example. The example is based on WebGoat an online security tutorial which demonstrates several classes of security problems in web applications.
POST /WebGoat/attack HTTP/1.1 Host: localhost:8080 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost:8080/WebGoat/attack?Screen=28 Cookie: JSESSIONID=751D36509E80137D3776B9FE4ADE6FC4 Content-Length:18 account_number=101
The section above shows an typical HTTP-POST request, I captured it using SpikeProxy. You see the header of the request as well as one parameter (account_number) and the value (101). Please also notice the header field Content-Length, when we start to alter the body-parameters, you may also want to modify this length field. You could of course also start to experiment with wrong content-length fields. But that is an different focus, modifying the value of body arguments affects the web application behind the web server. If you start sending faked HTTP requests with an wrong content-length you are testing the web server itself.
POST /WebGoat/attack HTTP/1.1 Host: localhost:8080 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost:8080/WebGoat/attack?Screen=28 Cookie: JSESSIONID=751D36509E80137D3776B9FE4ADE6FC4 Content-Length:29 account_number=101' or 1%3D'1
Above you see the modified HTTP request. The value of the argument account_number was changed and accordingly the content-length field was adjusted. The modification shows an typical pattern to test for SQL injection possibilities.
HTTP is a very commonly used protocol and therefore a lot of people try to find security holes in web applications. Capturing and altering HTTP requests by hand is very boring, so people started to use special HTTP Proxies to do it.
The picture above is not so much different from normal HTTP Proxy setups. So you configure your web browser to use your proxy and then you start to browse through the web application you want to test. All HTTP requests made during this session are captured and you can modify them after wards using the GUI frontend of the HTTP Proxy.
Fuzzing: Automatic Injection of Anomalies to break Applications or Protocols
Anomalies: Byte Sequences that are known to cause Problems within Applications
Well, it would be much to easy to just startup some kind of fuzzer program and find all the buffer overflows within some minutes. So to make it completely clear, fuzzer programs can help you find bugs. BUT the real work has still be done by people using their minds!
Just to mention a few problems related to fuzzers:
