Package: kako
This project provides honeypots for a number of well known and deployed
embedded device vulnerabilities.This project is intended for use in cataloging attack sources, droppers
and payloads. The default configuration will run a given set of
simulations and capture information relating to the origin of the
requests, the body of the request, and attempt to process and collect
the payload - if supported.DependenciesThe following Python packages are required for Kako to function
correctly:click- Command-line argument processing.boto3- Amazon AWS integration.requests- HTTP request library.cerberus- Validation of messages and other documents.Once these modules are installed, a valid configuration file is
required. See theConfigurationsection for more information.ConfigurationThe configuration for Kako is performed via a YAML document - namedkako.yamlby default.OutputTwo output formats are supported by Kako at this time: AWS SNS, and
flat-file JSON. The former is intended for environments which may be
part of a wider distributed deployment, whereas the latter allows for
easy integration into existing environments which may also collect other
honeypot logs from disk via something like Logstash.File (JSON)Generates a new JSON document for each captured interaction with the
honeypot, this is then appended to a file in the provided destination
directory. Each line of this file should be processed as a new JSON
document, as writing a new file per interaction can quickly yield a
massive number of small documents on disk.AWS SNSFor use with SNS output, Kako assumes thatboto3is able to
enumerate credentials to access the configured SNS and S3 resources
without intervention. This may be via~/.aws/credentialsfile, IAM
Instance Profiles (when deployed in AWS), environment variables, or
otherwise.There is currently no ability to provide AWS access keys directly.AWS ConfigurationIn order for Kako to operate properly, an SNS topic should be configured
inside of AWS. The ARN for this topic will need to be provided as part
of the Kako configuration, and a set of access-keys with permission to
Publish to this SNS Topic ARN will be required to be present per the
above section (‘AWS API’). Further to this, the ‘results->topic’
attribute in the Kako configuration should be set to the ARN for this
AWS SNS topic.The output from the SNS Topic can be configured as desired. However,
this has been successfully deployed using SNS to push messages into an
SQS queue from which an external process consumes messages.PoliciesThe following provides an example IAM policy which can be used to create
and grant a user access to publish to the SNS topic - for use with Kako:{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sns:Publish"
            ],
            "Resource": [
                "arn:aws:sns:us-west-2:<ACCOUNT_NUMBER>:<SNS_TOPIC>"
            ]
        }
    ]
}SimulationsA number of example simulations can be found in the following
repository:https://www.github.com/darkarnium/kako-simulations/ServersIn order to simplify implementation of a new simulation, a number of
servers are included. These servers implement the minimum required
functionality to bind sockets, accept connections and read / write to
the client.The following servers are currently included:TelnetAccepts any username / password pair for login.Simulates aBusyBoxtelnet service with basic shell commands.Records full interaction on disconnect / exit - viacapture().HTTPSimulates auhttpdHTTP service with no routes.Records request on server response - viacapture().HTTPSThe same as HTTP but has an SSL listener though use ofssl.wrap_socket().The above servers can also be extended without too much effort to
implement required functionality for the given vulnerable service.InstallationInstallation and configuration of a new simulation can be performed in
the following manner:Add a new simulation into the configured simulation directory - with
a file suffix of.yaml.Start / Restart Kako.Done! :)SSLFor services that require SSL an SSL certificate and private key are
required. These can easily be generated with the following command:openssl req -new -subj '/C=US/ST=California/L=San Jose/O=NETGEAR/OU=Home Consumer Products/CN=www.routerlogin.net' \
  -x509 -keyout conf/routerlogin.pem -out conf/routerlogin.pem -days 3650 -nodesFAQWhy not X, Y, Z already existing Honeypot project(s)?This project was primarily developed as a learning exercise :)It was developed in response to receiving a number of packet captures
from production networks being probed by machines attempting to exploit
a number of IoT vulnerabilities en masse. Although the captures
contained information about the method(s) of infection - such as HTTP
requests - the payloads themselves were missing. As a result a number of
simulations were built and deployed in a number of regions in order to
catalog and retrieve these payloads as well as document the associated
origins and droppers for later analysis.The use of AWS SQS / SNS on the back-end allows for easy deployment and
aggregation of captures back into a central location (ElasticSearch) via
HTTPS.Additional ReadingExample and common Kako simulationshttps://www.github.com/darkarnium/kako-simulations/Ogawa project for consuming data from AWS SQS into ElasticSearch.https://www.github.com/darkarnium/ogawa/