Chirag Bablani
OWASP GSoC 2020 The Honeypot project
3 min readAug 30, 2020

--

GSoC’20: The Honeypot Project with OWASP

Three months ago, I was selected as a Google Summer of Code intern 2020 for OWASP to work on the project ‘The Honeypot Project’. The journey was amazing, I enjoyed and learned a lot working under the organization.

In Computer Security terms, a cyber honeypot is something which baits the hackers. It is a sacrificial computer system that is intended to attract cyber-attacks, like a decoy. For example, a honeypot could mimic a company`s customer billing system — a frequent target of attack for criminals who wanted to find credit card numbers.

The main goal of the project was to include the functionality of the Honeypot into the well-known CMS (Content Management System).

The Architecture of the Project

The overall design consists of the WordPress CMS and its module which must be installed.

The module lays various honey-traps to gather information about the Attacker and also to detect bots. Based on the aspects of security, we have the following features that the module consists of:

  1. Hidden form field: This is an add-on functionality for the module Contact-form-7. This module was developed to manage multiple forms and customize it based on the users need. Now the add-on adds a hidden field to the form, thus labeling it creatively will prevent the bots to fill the form.
  2. Failed Login attempts log: With quite a bit of analyzing we get to know that if an attacker finds its way to the admin dashboard of the CMS, then there could occur some serious threat to the website. So, the motive was to gather information about the attack which tries to break into the privileged area of the CMS. The module creates a log file that stores the wrong credentials used by the person and also the timestamp so that the brute force could be detected easily.
  3. Changing the permalink of the login page: Some users do not customize their login page to the admin dashboard of the CMS, hence the permalink of their dashboard would be known and could be a target of some brute force attack. Like, the WordPress has it’s default login at /wp-login or also could be accessed from /wp-admin. The idea was to change the URL to something that is not easily guessed by the attacker. Thus, the feature was implemented in the module.
  4. Fake Login Page: Here comes our major honey-trap which could easily lure the attacker. As we can change the permalink of the original login to something else. We still have a chance to set up a fake page at a slug maybe where the attacker is looking. This feature has the flexibility of the user to customize at any page or post of his/her website. And whenever someone tries to surf the page, then as we all know that it would be logged at the same log file where failed login attempts were logged.

To do (Plan post-GSoC)

  1. Using PHPUnit for unit testing with the module for more code coverage.
  2. Integrating the module with OWASP Honeypot and sharing the Attack information with the community using MISP.

Acknowledgment

  1. I would like to thank my mentor Felipe Zipitría and Adrian Winckles for helping and guiding me in the project throughout the journey of GSoC.
  2. I am thankful to Google Summer of Code for providing me an opportunity to work with OWASP.

Demo Video:

https://youtu.be/xErhNuOn5dA

Relevant Links

Setup Instructions:

GitHub Link

Commits:

  1. Hidden form field — #commitb04d0f9
  2. Failed Login Attempts Log — #commitc9ae0df
  3. Changing the login slug — #commitb856f2e
  4. Fake Login Page — #commit8fc4ef0

--

--