334 0x600
0x640 Log Files..................................................................................................
One of the two most obvious signs of intrusion is the log file. The log file kept
by the tinyweb daemon is one of the first places to look into when trouble-
shooting a problem. Even though the attacker’s exploits were successful,
the log file keeps a painfully obvious record that something is up.tinywebd Log File
reader@hacking:~/booksrc $ sudo cat /var/log/tinywebd.log
07/25/2007 14:55:45> Starting up.
07/25/2007 14:57:00> From 127.0.0.1:38127 "HEAD / HTTP/1.0" 200 OK
07/25/2007 17:49:14> From 127.0.0.1:50201 "GET / HTTP/1.1" 200 OK
07/25/2007 17:49:14> From 127.0.0.1:50202 "GET /image.jpg HTTP/1.1" 200 OK
07/25/2007 17:49:14> From 127.0.0.1:50203 "GET /favicon.ico HTTP/1.1" 404 Not Found
07/25/2007 17:57:21> Shutting down.
08/01/2007 15:43:08> Starting up..
08/01/2007 15:43:41> From 127.0.0.1:45396 "
jfX 1 CRj j jfXCh
f T$ fhzifS j QV C I ? Iy
Rh//shh/bin R S $ $ $ $ $ $
$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $
$ $ $ $ $ $ $ $ " NOT HTTP!
reader@hacking:~/booksrc $
Of course in this case, after the attacker gains a root shell, he can just edit
the log file since it’s on the same system. On secure networks, however, copies
of logs are often sent to another secure server. In extreme cases, logs are sent
to a printer for hard copy, so there is a physical record. These types of counter-
measures prevent tampering with the logs after successful exploitation.0x641 Blend In with the Crowd
Even though the log files themselves cannot be changed, occasionally what
gets logged can be. Log files usually contain many valid entries, whereas
exploit attempts stick out like a sore thumb. The tinyweb daemon program
can be tricked into logging a valid-looking entry for an exploit attempt.
Look at the source code and see if you can figure out how to do this before
continuing on. The idea is to make the log entry look like a valid web request,
like the following:07/22/2007 17:57:00> From 127.0.0.1:38127 "HEAD / HTTP/1.0" 200 OK
07/25/2007 14:49:14> From 127.0.0.1:50201 "GET / HTTP/1.1" 200 OK
07/25/2007 14:49:14> From 127.0.0.1:50202 "GET /image.jpg HTTP/1.1" 200 OK
07/25/2007 14:49:14> From 127.0.0.1:50203 "GET /favicon.ico HTTP/1.1" 404 Not Found
This type of camouflage is very effective at large enterprises with extensive
log files, since there are so many valid requests to hide among: It’s easier to
blend in at a crowded mall than an empty street. But how exactly do you hide
a big, ugly exploit buffer in the proverbial sheep’s clothing?