Government

Thwarting Cyber Attacks with Honeypot System for Sigma

June 4, 2019 | Posted by: Sal Ceravolo

What’s the Purpose of Honeypot?

Every device that carries information is worth hacking – even if the device operates behind firewalls, intrusion detection systems, or session border controllers. At REDCOM, we develop secure VoIP platforms that are intended to withstand harsh cyber environments without the protection provided by typical front-facing equipment.

REDCOM Sigma, our flagship product, is a hardware-agnostic, virtual VoIP call controller that is used in tactical and commercial environments where secure communications are critical to mission operations. Our goal with the honeypot system was to capture how Sigma would be attacked when exposed to the real world, and then use that information to improve its security capabilities. We wanted to better understand the following:

  • As Sigma is being attacked, are there any malicious actions that would cause it to crash or hang critical operations?
  • Malformed packets are a common attack vector, so how does Sigma handle them?
  • As we decrease our security levels, how quickly is the system compromised?

cyber-attack

How it’s Set Up

On March 6, 2018, we installed an instance of our VoIP call controller, Sigma, on a U.S.-based, third-party platform with no form of third-party front-end protection such as a session border controller (SBC), an intrusion detection system (IDS), or a firewall. Our only safety net was that Sigma was configured to operate in “extreme” security mode. The extreme security mode is typically used when Sigma is running on a Department of Defense network or on an untrusted physical server, like in a cloud environment that is outside of an agency’s control. The following are some of the software features that are set in this mode:

  • An account is disabled after three consecutive failed log-ins with that account name.
  • An internal firewall is enabled.
  • A password is required to boot into maintenance (single user) mode.
  • All operating system console sign-in abilities are disabled.
  • The configuration key DNS_PERMISSIVE_MODE is set to “no”. This setting prevents a successful DNS resolution unless the domain being looked up has valid DNSSEC information.

Along with the extreme security mode, Sigma was configured with ten SIP lines with three-digit extensions and no authentication, ten SIP lines with three-digit extensions and SIP authentication enabled, and one SIP trunk. Note that the SIP trunk was not connected to another switch or network.

 

Our Initial Findings — System Attacks from Day One

Immediately, our honeypot system was under attack. From reviewing the IP addresses, we noticed that most of the attacks came from overseas. Sources of attacks included China, Ukraine, and even Norway. However, we also noticed that some of the attacks (less than 10%) were local, coming from nearby locations such as Buffalo, NY. Listed below are several of the attack types that were logged:

Attacks on Admin Accounts:

The honeypot system survived thousands of logins attempts over the course of the test. The attempts varied in complexity from default user names and passwords, to what security experts would consider to be sufficiently complex passwords. These results alone are enough motivation to start practicing good password hygiene such as changing passwords often, abiding by proper password rules, etc.

Password Database Attacks:

Attempts were made to read the password files (such as …/…/passwords) in its entirety to do offline brute forcing of password hashes without running into the rate limiting we have imposed on the login page directly.

Input Validation Attacks:

These types of attacks are the root cause of many types of web attacks. Basically, a malicious actor enters invalid data in various fields to determine if the new input can cause the system to crash.

What kept Sigma safe when handling these types of attacks was our strict adherence to DISA’s Secure Technical Implementation Guide (STIG), which is a cybersecurity methodology for standardizing security protocols within a network. When properly implemented, these security guidelines enhance security for software, hardware, and physical and logical architectures to further reduce vulnerabilities.

SIP/SDP Malformed Message Attacks:

In VoIP, SIP is used to establish a session between participants, modify that session, and eventually terminate that session. SDP is used to describe multimedia sessions in a format understood by the participants over a network.

By maliciously manipulating SIP/SDP messages, the attacker can cause denial of service (DoS) types of attacks. Malformed SIP/SDP messages can be sent randomly to selected users or can be part of a man-in-the-middle attack between parties involved in a call. In these types of attacks, the attacker sends a surge of SIP requests or malformed messages to the system to paralyze the parsing process at the SIP server or client. Note that malformed SIP/SDP messages can also be a result of a misconfigured system.

Register-Dial-Unregister-Repeat

Within hours of the honeypot system going online, malicious actors began to successfully register against our three-digit SIP lines that did not have SIP authentication enabled. The following registration event cycle repeated thousands of times during the lifetime of the honeypot:

  • Malicious actors would successfully register.
  • Once registered, attempts to dial out were made. Typically, these were ten- or eleven-digit numbers to the following countries: XXXX XXXX XXXX
  • Once the call failed, since the honeypot was not connecting to the public switched telephone network PSTN, the malicious SIP lines would unregister.

We noticed that failed call attempts to invalid numbers did not show up in the call history. Typically, such information would not be stored because it would add unnecessary noise to the file. However, without this information, a system admin would not know that the system is under attack.

 

Testing the Honeypot

It is one thing to know if the honeypot system is alive, and it’s another thing to know if the system is functional. Since our Sigma honeypot system is a VoIP call controller, one of our lead technicians created an automated SIP testing system that would allow us to determine the overall health of the system. Part of the test included registering and making SIP calls to each phone number.

By looking at the number of calls that the system handled, this testing allowed us to determine if any malicious actors could register and make calls. If more calls were handled than were tested, then we knew that a malicious actor was successful. Our results showed that at no time during this test were any malicious actors successful at making (or even more completing) a call.

 

Lowering Our Defenses

After six months and no successful attacks, we decided to lower Sigma’s defenses by reducing our security mode from “Extreme” to “Medium,” which set the following in the system:

  • Passwords can be 8 characters (must be 14 in extreme)
  • SNMPv1, SNMPv2c, and SNMPv3 are enabled (only SNMPv3 is only enabled in extreme)
  • Firewall is disabled (this is enabled in extreme)

Even with our defenses lowered, we did not see any new types of attacks or any successful penetration of our system. Note that at REDCOM, we do not condone this setup in non-controlled environments. A medium security mode should only be used in controlled environments.

 

Conclusions and Guidance

With the testing that we conducted, we would like to provide recommendations for keeping your call controller secure. We found that most of the attempts came in the form of Register-Dial-Unregister-Repeat. Therefore, make sure that your system can log such events. Left unmonitored, this type of attack can consume system resources. Knowing where the IP address involved in these actions comes from can help your network admin filter unwanted traffic. Login attempts were also a major attack method. Therefore, change your password often and follow NIST SP 800-190 guidelines. When possible, use multi-factor authentication for allowing access.

One key lesson learned was that once a system is online, attacks happen quickly and often. The question is not “When we will get hacked?” but rather “What type of attack are we going to see next?” Malicious actors have evolved greatly from simple login attacks to understanding the network and performing attacks such as malformed messages, DNS spoofing, and SQL injection.

At REDCOM, our vision is to provide the most secure communications solutions in the world when it is critically needed. Our trusted and proven products are designed and supported by our relentless drive for quality, innovation, and world-class customer support.