According to SANS Top Cyber Security Risks (Jul, 2010), attacks against Web applications make up more than 60% of the total number of attempted attacks on the Internet. To better understand these attacks, Lukas Rist and his team put together a low-interaction Web application honeypot – Glastopf.
Glastopf gathers data by emulating 1,000s of vulnerabilities. Unlike many other honeypots, Glastopf focuses on replying the correct response to the attacker exploiting the targeted Web application, and not the specific vulnerability.
Setting Up Glastopf
Glastopf has come a long way since the project started a couple of years back. There are installation guides written specifically for each environment – Debian, Open BSD, OS X, Raspberry Pi and Ubuntu – and all of them can be found at Glastopf’s GitHub repository (https://github.com/glastopf/glastopf/tree/master/docs/source/installation).
By following the installation manual, you should be able to get your Glastopf up and running in just a few minutes.
Playing with Glastopf
I’ve a Ubuntu 12.04.4 LTS machine (192.168.138.155) with Glastopf running, and Debian Jessie machine (192.168.138.153) as my attacking machine.
Once Glastopf is started, a default set of files and directories will be created. Glastopf can be configured by modifying glastopf.cfg.
With Glastopf running on your machine, you can now sit back and watch traffics coming into your Web application. These real-time logs are available at log/glastopf.log.
Capturing Local File Inclusion (LFI) Attacks
Using a Python script made available by ENISA (the European Union Agency for Network and Information Security) in its CERT (Computer Emergency Response Team) Exercise and Training programmes, I performed a local file inclusion attack on my Web application honeypot.
Looking at the real-time logs, you can see that attack traffics are coming into your web application (running on port 80) from 192.168.138.153. The attacker accessed the /etc/ passwd file of the host. The results shown to the attacker are available at data/virtualdocs/linux/etc/ passwd.
On top of these real-time logs, more detailed logs are available at db/glastopf.db which can be accessed using SQLite3.
Similar to the logs you saw previously, here you can see the user-agent used to perform the attack (i.e. Python’s URL library) and Glastopf classified this attack as LFI (i.e. Local File Inclusion).
Here is an example of how ‘normal’ traffic looks like:
Capturing Multiple Attacks
Using a similar Python script I used previously (provided by ENISA), I performed a series of attacks on the Web application. Amongst all, it’s a remote file inclusion (RFI) attack. With that, I had my attacking machine set up as a Web server to serve the malicious file (also provided by ENISA).
Starting with the ‘boring’ attacks, you can see Glastopf picking up the cross-site scripting (XSS) and local file inclusion (LFI) attacks:
On top of these attacks is the remote file inclusion (RFI) attack:
The remote file is hosted at the attacker machine, which can be accessed via port 6985. In such an attack, Glastopf downloaded the PHP-shell code which will be made available at data/files, which can be used for further analysis.
Conclusion
By now, you should have grasped the basic concept and understanding of how Glastopf works. Glastopf is a lot more than these. Do take your time to explore this magnificent piece of work further!
References & Further Readings
The Honeynet Project, Know Your Tools: A dynamic, low-interaction web application honeypot.
Cyber Fast Track, Web Application Honeypot.
For more details on the attacks I performed on my Glastopf honeypot setup, check out ENISA’s Honeypots CERT Exercise Handbook.
Author
Emil Tan, Chapter Lead, The Honeynet Project, Singapore Chapter