Linux Server – Task 3: Solve HoneyNet Scan of the Month 15

Course
Linux palvelimena [Linux server] by Tero Karvinen at Haaga-Helia University of Applied Sciences

Task
Solve HoneyNet Scan of the Month 15. Explain one attack type from the OWASP top 10.

Testing environment
OS: Ubuntu Linux 12.10 “Quantal Quetzal” 32-bit Live CD
System: HP EliteBook 2570p Notebook PC

HoneyNet Scan of the Month 15
I began by downloading the scan of the month 15 tarball. Then I extracted it into a folder named HoneyNet I had created in my home directory. The extraction process in the terminal: $ tar -xf honeynet.tar.gz. Result: a folder named honeynet containing all the files included in the tarball.

File recovery
Next I needed to recover the deleted files to begin my search for the rootkit – Tero Karvinen’s forensic file recovery with Linux article came in handy here. I created a new folders for the file recovery process by entering $ mkdir allocated deleted in the terminal.

I recovered the normal, allocated files with $ tsk_recover -a honeypot.hda8.dd allocated/, after installing Sleuth Kit, an open source digital investigation kit, with $ sudo apt-get install sleuth-kit. The result: 1614 files recovered. I then proceeded to recover the deleted, unallocated files by entering $ tsk_recover honeypot.hda8.dd deleted/ in the terminal. The result: 37 files recovered.

Creating a timeline
To create a timeline with the deleted files included, I entered the following commands in the terminal:

$ tsk_gettimes honeypot.hda8.dd >rawtimes
$ mactime -b rawtimes|less

The search
According to the challenge, on 15 March. 2001, a Linux honeypot was successfully compromised. That seemed like a logical place to start looking for the rootkit, so I navigated to that date in the timeline by pressing enter and typing in /Mar 15 2001, and then pressing enter again.

I kept scrolling the timeline forwards and backwards, not being able to locate anything of interest besides an odd bunch of $OrphanFiles/OrphanFile-205* (deleted) entries ranging from October 22nd 2000 to March 3rd 2001. I decided that these entries were my best (and only) clue so far, so I proceeded to check the recovered files for something on these entries by entering $ ls -l allocated/ deleted/ in the terminal.

The command listed all the recovered deleted files, and on the list was an item named $OrphanFiles. I couldn’t figure out how to open it at the time. According to Sleuth Kit, “when you encounter an unallocated metadata entry, there may no longer be a file name structure that points to it. These are called orphan files.”

The conclusion
There was an archive listed along with the other files (see screenshow above) named lk.tgz. It only really caught my eye because of the terminal color scheme I was using, but I figured I could take a look at random, given how the other option was to call it quits.

I navigated to Ubuntu/HoneyPot/honeypot/deleted/ and entered $ tar -xf lk.tgz to extract the archive. I checked with $ ls and found a folder named last. I opened it with $ cd last and checked the contents with $ ls again.

The files seemed a bit suspicious – obviously I was looking for anything out of the ordinary, given the nature of the challenge. I opened the cleaner and logclear files with $ less, and here’s what was in them:

This seemed to be a cleaner utility shell script, possibly for covering up rootkit tracks. The “alles sauber mein Meister !” part (everything clean my Master !) indicated that there was a high probability that this is a part of the rootkit, even if the phrase itself is bordering on cliche.

Here I located a log cleaner. It first kills all active linsniffer packet sniffer daemons (linsniffer is present in the folder as well), and then erases the tcp.log and creates a blank copy of it.

At this point I was confident that I had found the rootkit files and concluded the challenge.

OWASP top 10: A5 – security misconfiguration
To guarantee good security, every component involved must be properly configured. This includes but isn’t limited to: application servers, web servers (e.g. Apache), database servers (e.g. MySQL), and applications. The default settings aren’t secure for most componenents, so therefore it’s crucial to define the correct security settings for all components, and strictly implement and maintain the said settings. All software should always be updated to its most recent version, including things like code libraries, which are sometimes overlooked.

Both insider and outsider attacks should be prepared for. If there’s any kind of security misconfiguration, it’s fairly easy for the attacker to take advantage of it and gain access to the system. The attack itself is common, but fortunately it’s easy to detect, as long as developers and admins work together to ensure that all the layers of the stack are secure. Automated scanners can be used to detect security misconfigurations on many levels.

The impact of such an attack is usually moderate, giving the attacker access to some part of the system, but it can also result in complete system compromise, if the flaws are many and remain there for an extended period of time. An attack like this could have a serious impact on business decisions, as the system and the data within it could be vulnerable and compromised without any knowledge of the owner.

References
Sleuth Kit (http://www.sleuthkit.org/)
HoneyNet Scan of the Month 15 (http://old.honeynet.org/scans/scan15/)
OWASP Top 10 (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)
Karvinen, Tero: Forensic File Recovery with Linux (http://terokarvinen.com/2013/forensic-file-recovery-with-linux)
Karvinen, Tero: Lessons 2014-2-3, Linux palvelimena [Linux server] (http://terokarvinen.com/2013/aikataulu-%E2%80%93-linux-palvelimena-ict4tn003-11-ja-12-kevaalla-2014)

About
This document can be copied and edited according to the GNU General Public License (version 3 or newer). http://www.gnu.org/licenses/gpl.html
Based on a course by Tero Karvinen, http://www.iki.fi/karvinen