An analysis of Glutton — All Eating honeypot

Glutton is the “all eating honeypot” (written in GO Lang) which can act as a proxy between attacker and other honeypots and provides the facility to capture, log and analyze the traffic sent between attacker and the honey pot. It basically listens to all the ports and then act according to a rule file (rules.yaml). It currently have proxy support for SSH and TCP and an additional logging support for the SSH protocol only. It is to be noted that Glutton only creates a fake SSH session not the full session which allows the user to manipulate files through SSH. According to the project member (@glaslos) comment:

“Glutton only supports the username/password handshake in ssh and then disconnects. If you want a proper ssh honeypot, you have to connect Glutton to something like cowrie or bifrozt.”

Important External Libraries

Some external libraries used by Glutton are as follows:

Major Libraries

• freki
  This library is used for controlling all the traffic on the base of rules.yaml
• x/crypto/ssh
  This library is used to write pseudo SSH Handler
• docpot-go
• zap
• zapcore
• viper
• go-uuid
• com
• vtclean

Generic Program Flow of Glutton

Programming starts with main() function which is in the server.go file. Following is the generic program flow of that function which is followed whatever the case is.

1. Create New Instance of Glutton Class

The Glutton class is the main class which does all the work. Creating new instance involves the calling of method glutton.New which setup a new instance of glutton. It does this by following steps:

1. Generate a new Sensor ID for the current instance
2. Initialize the logger
3. Load configuration file(conf.yaml) using config.go class
4. Open Rules file (rules.yaml) and load rules into program
5. Create instance of ‘freki’ which takes the above mentioned rules data and sets up the proxy part of glutton
6. Initialize the ‘freki’ instance

2. Initialize the New Instance of Glutton

Then comes the initialization of newly created instance of glutton. It involves setting up the program according to configuration file and loading handlers. The detailed flow is as follows:

1. Setup the server’s SSH port so that SSH service should keep working as usual (Mostly it is 5001)
2. Enable ‘Gollum’ for logging
3. Map all the protocol handlers
4. Register protocol handlers in the current instance of freki
5. Although there are other handlers written but this function will only register handler which are either TCP or SSH. Other handler are currently being ignored.
6. Now initialize the current instance of freki so it comes in to running condition with newly registered handlers

3. Start the monitoring process

Now, this is the final step when everything is ready and glutton can now monitor and handle the traffic according to registered handlers. This involves only two steps.

1. Register the “Control-C” handler so glutton can be exited
2. Call the freki’s function to start monitoring the traffic

Working of SSH Proxy

This is the complete (not actually) SSH handler that can handle all the SSH connections transparently. As already mentioned, it does not have ability to handle all the SSH operations like browsing and manipulating files. It can only start an SSH session and then closes it immediately. But it has the ability to redirect the SSH session to any SSH honeypot (or machine) like cowrie to continue the session further. Most of the work is done by the built in GO Lang SSH Library. This library is responsible for and creating and validating SSH connection. Following are the things which this handler is taking care of:

1. Initialize the logger for SSH
2. Get host information for creating a virtual SSH Server
3. Generate RSA Key to create a new SSH Server
4. Setting up the connection information like destination host, port number, username password etc. for fake SSH server.
5. Create a virtual SSH Client for communicating with SSH honeypot
6. Initialize the logger and SSH Library
7. Fetch the user request using the SSH Library
8. Fetch response from the Server using the Client Instance on the basis of information received to Fake SSH Server Instance
9. Send the response to the user using fake SSH Server Instance
10. On successful validation of password it break the connection unless it is forwarded to a SSH honeypot

SSL Off-loading in action

SSL Off-loading (more appropriately “SSL Stripping”) is a process in which an intermediate server receives a connection from client act as a proxy for the SSL connections. It does this by stripping the original header from the client, adds a custom SSL header and redirects the request to specified server. Get the response from server. Remove the SSL header again, renovate it with its own SSL Header and forward the response to client.

In glutton, all this is being done by SSH Proxy Handler (proxy_ssh.go) with the help of the built-in go library of SSH mentioned above. The flow is already mentioned in the above section so here I am mentioning only some important points.

• The SSH honeypot must be placed after the glutton otherwise the connection with end as soon as the SSH connection establish successfully.
• The credentials registered in the glutton for SSH and the credentials for the SSH honeypot should be same otherwise connection will not establish after authentication
• Although the SSH handler is managing the traffic but the actual processing of SSH protocol and SSL Stripping is done by the SSL library of Go Language.
• Here is the concept diagram of SSL Stripping:

Conclusion

Glutton is good honeypot that can be used for the proxy for other honeypots and can be used to monitor traffic. Although it only provides facility of logging only for SSH but we can extend its functionality by writing other handlers as well.

Originally published at cybersec.com.pk by @cstayyab on June 14, 2018.