How To: An Entry Level Guide to Finding and Reading Logs (And Maybe Staying Out of Jail)

Big brother is watching when you're playing around on another system—and big brother is that system. Everything from operating systems to intrusion detection systems to database services are maintaining logs. Sometimes, these are error logs that can show attackers trying various SQL injection vectors over and over. This is especially so if they are using an automated framework like sqlmap that can spam a ton of requests in a short time. More often than not, the access logs are what most amateurs worry about, but there is more to it then just that.

What if you're the admin of a new web server? What should you be looking for? Likewise, if you're a new pentester, what logs can you find to give you information? Or what entries should you delete to cover your tracks?

Good, solid administrators will scan their access logs periodically to make sure that nothing strange is going on in there. If they start getting hundreds or thousands of requests for a page that previously was almost invisible (especially a PHP or CGI page), you better believe they will be looking into it. Sadly, however, not all administrators are solid, but you can learn and gain from their mistakes.

Knowing what logs to delete or check (depending on your side of the ethical coin) is a simple lesson that will save you time, headache, and perhaps even a little bit of jail time. Other times, knowing what logs to dive for will help you uncover information about the machine you are pentesting, leading to other and possibly better targets.

Command Line History

~/.bash_history

Bash is the default UNIX shell and command processor and insofar as the name would hint, this is a history of your typed commands. We can check this out by opening the file in your favorite editor (ahem, vim) and get a list of what has been typed and entered.

Obviously, the limits of reconnaissance here are endless and this file alone can offer a huge amount of raw intel from mistyped passwords to patched software and a lot of things in-between.

As this file is set into the home directory of the user, you would remove it after exploiting that user account to escalate privileges. This prevents the administrator looking back and seeing the commands. Alternatively, you could edit the file and remove the commands you used and anything along with it, if need be.

This is also the source of many hacklogs being released recently, as an easy way to show an (often edited slightly) view of how the hack went down if taken after the fact.

History

The history command also provides a glimpse into the last commands used, as shown here. This is also what stores commands retrievable by pressing the up and down arrow keys to cycle through.

$ history -r
After you are done, this will erase your current session history.

$ history -c
Will erase the entire history.

MySQL

/var/log/mysql/error.log

MySQL is the most popular DBMS on the market, last time I looked, so I will focus here. However, the idea applies across the board.

The error log contains information indicating when mysqld was started and stopped, along with any critical errors that occur while the server is running. From a forensics standpoint, this does not show specifically who an attacker is, like an access log might, but it helps explain what they were doing after the server was compromised.

~/.mysql_history

Functions just like .bash_history above provide a command-by-command detail of what has been accessed and visited. 

Syslog

Syslog is a standard logging facility that collects messages from various programs and services including the kernel and stores them (depending on setup) in a bunch of log files typically under /var/log. There are also possibilities to send the messages to another host over a network, to a serial console, to a database table, etc., depending on the needs.

/var/log

This is not a specific file, but it's a directory of system logs varying from boot messages to hardware failures to system access. The file /etc/rsyslog.conf controls what goes inside some of the log files (/etc/syslog on some distros; rsyslog is the BSD-style syslog with a few notable improvements).

For example, take a look a the image below:

A few of the need-to-know log files follows. Some of these are general and some of them are good for digging around post-compromise and privilege escalation.

• /var/log/boot.log – Contains information that are logged when the system boots.
• /var/log/auth.log – Contains system authorization information, including user logins and authentications that were used.
• /var/log/dmesg – Contains kernel ring buffer information. When the system boots up, it prints a number of messages on the screen that displays information about the hardware devices that the kernel detects during boot process.

Common Log Format

Like so many things with networking and computers, standards are gold. With people free to more or less do what they choose, having a level standard makes it easy to perform tasks on other systems. This idea has been taken to logs with the Common Log Format (CLF). 

This standard format can be produced by many different web servers and read by many log analysis programs. The log file entry sample produced in CLF will look something like this:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

Looks daunting! But it's actually quite simple and can be translated from the following fields of data, populated depending on the event:

host | ident | authuser | date | request | status | bytes

The 'host' portion is the IP address source making the request. This can either be yours or a villa in Mozambique, depending on your proxy settings and depth. If you failed to take any precaution and this was in fact your address, you are now in check. 

Combined Log Format

Another commonly used format string is called the Combined Log Format. It is exactly the same as the Common Log Format, with the addition of two more fields. The access log under this format will look like:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

The additional fields are:

The "Referer" HTTP request header - This gives the site that the client reports having been referred from. 

The "User-Agent" HTTP request header - This is the identifying information that the client browser reports about itself.

Extended Log Format

ELF files, just like CLF files, perform the exact same function and wide reaching compatibility. The only difference is that the extended versions are, well, extended. They contain more data than the compact CLF entries. An example looks like this:

#Version: 1.0
#Date: 12-Jan-2012 12:14:17
#Fields: time cs-method cs-uri
00:34:23 GET /foo/bar.html
12:21:16 GET /foo/bar.html
12:45:52 GET /foo/bar.html
12:57:34 GET /foo/bar.html

In Closing

There are more logs out there and more ways to work around them. Do you know of any? Have any tips or stories you can share? We would love to hear them.

Leave a comment below or visit our forum and start a thread about your swashbuckling adventures in others networks—pentesting, of course!