The sensationalized stories about the hacking of PR Newswire Association, LLC., Business Wire, and Marketwired, L.P. (the Newswires) are interesting but not entirely complete. The articles that we’ve read so far paint the Newswires as victims of some high-talent criminal hacking group. This might be true if the Newswires actually maintained a strong security posture, but they didn’t. Instead their security posture was insufficiently robust to protect the confidentiality, integrity or availability of the data contained within their networks. We know this because enough telling details about the breach were made public (see the referenced document at the end of this article).
In this article we first provide a critical analysis of the breaches based on public information primarily from the published record. We do make assumptions based on the information provide and our own experience with network penetration to fill in some of the gaps. We call out the issues that we believe allowed the hackers to achieve compromise and cause damage to the Newswires. Later we provide solutions that could have been used (and can be used by others) to prevent this type of breach from happening again. If we miss something, or if we can add to the solutions that we provide please feel free to comment and we will update this article accordingly.
From the published record we know that Marketwired was hacked via the exploitation of SQL Injection vulnerabilities. We know that the hacking was ongoing for a three-year period. Additionally, according to the records the SQL Injection attacks happened on at least 390 different occasions over a three-month span (between April 24th 2012 and July 20th, 2012). We assume that Marketwired was unaware of this activity because no responsive measures were taken until years after the initial breach and well after damage was apparently realized.
With regards to SQL Injection, an attacker usually needs build the attack through a process of trial and error, which generates an abundance of suspicious error logs. In rare cases when an attacker doesn’t need to build the attack the actual attack will still generate a wealth of suspicious log events. Moreover, SQL Injection made its debut 17 years ago in a 1998 release of phrack magazine, a popular hacking zine. Today SQL Injection is a well-known issue and relatively easy to mitigate, detect, and/or defeat. In fact almost all modern firewalls and security appliances have SQL Injection detection / prevention built in. When considering normally overt nature of SQL Injection, the extended timeframe of the activity, and the apparent lack of detection by Marketwired, it strongly suggests that Marketwired’s security was (and may still be) exceptionally deficient.
It is Netragard’s experience from delivering Platinum level (realistic threat) Penetration Tests that businesses have a 30-minute to 1-hour window in which to detect and respond to an initial breach. When Netragard’s team breaches a customer network, if the customer fails to detect and revoke Netragard’s access within the aforementioned timeframe then the customer will likely not be able to forcefully expel Netragard from its network. Within a 30-minute window of initial penetration Netragard is 89% likely to compromise its customers domain controller(s) and achieve total network dominance. Within a 1-hour window of initial penetration Netragard in 98% likely to compromise its customers domain controller(s) and achieve total network dominance.
We know that Marketwired’s failure to detect the initial breach (and subsequent attacks) provided the hackers with ample time to metastasize their penetration throughout the network. The published record states that the hackers “installed multiple reverse shells”. The record also states “in or about March 2012, the Hackers launched an intrusion into the networks of Marketwired whereby they obtained contact and log-in credential information for Marketwired’s employees, clients, and business partners.” We assume that the compromise of “log-in credential information” means that the hackers successfully compromised Marketwired’s domain controllers and exfiltrated / cracked their database of employee usernames and passwords. Given the fact that people tend to use the same passwords in multiple places (discussed later as well) the potential impact of this almost immeasurable.
While considerably less information about the breach into PRN’s network is available, the information that is public outlines significant security deficiencies existed. According to the published record PRN detected the intrusions into their network well after the network was breached which represents a failure at effective incident detection. Moreover, it appears that PRN’s response was largely ineffective because PRN ejected the hackers from the network but the hacker’s regained access. According to the record it appears that the dance of ejection and re-breach happened at least three times.
The third breach into PRN is very telling. This time the hackers purchased a list of logins taken from a compromised social networking website. The hackers then “reviewed and collected usernames and logins for PRN employees” from that list and used the collected information “to access the Virtual Private Network (“VPN”) or PRN”. Clearly PRN did not use two-factor authentication for its VPN, which would have prevented this method of penetration. It is also important to note that two-factor authentication is necessary to satisfy some regulatory requirements. Additionally, PRN’s policy around password usage and password security is seriously deficient or not being adhered to. Specifically, PRN employees were using the same passwords on social media websites (and possibly other places) as they were for PRN’s network. As with Marketwired’s breach, PRN’s were very likely preventable.
Even less information is available about Business Wire’s breach. According to the records Business Wire’s network was initially breached via SQL Injection (like Marketwired) by another hacker at an earlier time. Iermolovych (the name of the hacker who hacked the Newswires) purchased access to Business Wire’s network from the other hacker. As with Marketwired and PRN, Business Wire’s own detection and response capabilities were (and may still be) lacking. It is unclear from the record as to how long the hackers were able to operate within Business Wire’s network but it is clear that the initial SQL Injection attack and subsequent breach was not detected or responded to in a timely manner.
Unfortunately, based on our own experience, most businesses are as vulnerable as the Newswires. The reasons for this are multifaceted we may cover them in another article at a later time. For now, we’ll focus on what could have been done to prevent the damages that resulted from this breach. It’s important to stress that every network will be breached at some point during its lifetime. The question is will the Incident Response be effective at detecting the breach and preventing it from becoming damaging.
To understand the solution we must first understand the problem. Damaging breaches have two common characteristics, which are poor network security and ineffective Incident Response. We know from studying historical breach data from the Verizon DBIR and OWASP that approximately 99.8% of all breaches are the product of the exploitation of known vulnerabilities for which CVE’s have already been published (may for over one year). This validates our first characteristic. The second characteristic is validated by the ever increasing number of damaging braches that are reported each year. The fact that these breaches are damaging shows that Incident Response has failed.
Most of the reported breaches in the past decade could have been avoided by proactively countering the two aforementioned points of failure. Countering these failure points requires actionable intelligence about how a threat will align with the unique risks of each associated network and how sensitive data will be accessed. The best method of assembling this intelligence is to become the victim of a breach not through malicious hacking but instead through high-quality, realistic-threat penetration testing. Unfortunately this isn’t as easy as it sounds. The industry standard penetration test is a vetted vulnerability scan which is far from realistic and provides no real protective benefit. There are a few realistic threat penetration-testing vendors in operation but finding them can be a challenge.
Some of the characteristics of a realistic threat penetration test include but are not limited to social engineering with solid pretexts, undetectable malware, the non-automated identification and exploitation of network and web application vulnerabilities, exploit customizations, and stealth penetration. A realistic penetration testing team will never request that its IP addresses be whitelisted nor will they request credentials (unless perhaps for web application testing). The team will similarly not be dependent on (and may elect not to even use) automated tools like Nessus, Nexpose, The Metasploit Framwork, etc. Automated tools are useful for basic security & maintenance purposes but not for the production of realistic threats. Do you think the hackers that hacked Target, Sony, Hannaford, LinkedIn, The Homedepot, Ashley Madison, or The Newswires used those scanners?
The report generated by a realistic penetration test should cover the full spectrum of vulnerabilities as well as the Path to Compromise (PTC). The PTC represents the path(s) that an attacker must follow to compromise sensitive data from a defined source (Internet, LAN, etc.). Identifying the PTC is arguably more important from a defensive perspective than vulnerability identification. This is because it is technically impossible to identify every vulnerability that exists in a network (or in software) and so there will always exist some level of gap. Identifying the PTC allows a business mitigate this gap by creating an effective IR plan capable of detecting and responding to a breach before it becomes damaging. Netragard’s platinum level Network Penetration Testing services produce a high-detail PTC for exactly this reason.
The Newswires (and many other businesses) could likely have prevented their breach if they had done the following.
- Deployed a response-capable Web Application Firewall and configured the firewall specifically for the application(s) that it was protecting. This would have prevented the SQL Injection attacks from being successful.
- Deployed a Network Intrusion Detection / Prevention solution to monitor network traffic bidirectionally. This would likely have enabled them to detect the reverse-shells.
- Deployed a Data Loss Prevention solution. This would likely have prevented some if not all of the released from being exfiltrated.
- Deployed a SEIM capable of receiving, correlating and analyzing feeds from system logs, security appliances, firewalls, etc. This would likely have allowed the Newswires to detect and respond to the initial attacks before breach and well before damage.
- Purchased realistic-threat penetration testing that produced a report containing a detailed PTC and then implemented the suggested methods for mitigation, remediation, and hardening provided in the report. The test would enable them to measure the effectiveness of their existing security solutions and to close any gaps that might exist.
- To deploy an internal honeypot solution (like Netragard’s) that would detect lateral movement (Distributed Metastasis) inside of their networks and allow the Newswires to respond prior to experiencing any damage.
Records for reference
