WikiLeaks has a few day ago (30 June, 2017) released information on a CIA tool named "OutlawCountry". It is targeting Red Hat Enterprise Linux and its derivatives (e.g. Centos) Linux operating systems.
"WikiLeaks begins its new series of leaks on the U.S. Central Intelligence Agency. Code-named "Vault 7" by WikiLeaks, it is the largest ever publication of confidential documents on the agency...Recently, the CIA lost control of the majority of its hacking arsenal including malware, viruses, trojans, weaponized "zero day" exploits, malware remote control systems and associated documentation. This extraordinary collection, which amounts to more than several hundred million lines of code, gives its possessor the entire hacking capacity of the CIA. The archive appears to have been circulated among former U.S. government hackers and contractors in an unauthorized manner, one of whom has provided WikiLeaks with portions of the archive." The text quotes and further informations can be found at https://wikileaks.org/ciav7p1/
The information regarding CIA OutlawCountry - released June 30th 2017 is part of the above mentioned "Vault 7 leak". The information leak includes the "OutlawCountry v1.0 User Manual Rev. A, dated 04 June 2015, - an 8 page instruction written to users (aka hackers) in how-to use the OutlawCountry module.
OutlawCountry sole purpose are to reroute traffic on the target server without the legitimate owner of the server realizing the interception/transmission of the data flow.
For a number of reasons, I have chosen to write a blog entry on OutlawCountry ;
1. it is very unlike other 'tools' disclosed in the Vault 7 leak. OutlawCountry is nothing like a super state-sponsored malware, (in fact it's neither a piece of Malware or even a custom written tool). It is just a small kernel module that creates a hidden netfilter table on a Red Hat Enterprise Linux system. Netfilter is a packet filtering framework inside the Linux kernel. Software commonly associated with netfilter is iptables - the 'de-facto' Linux host-based firewall.
2. it is so simple - unless the Systemadmin/Defender/Blue Team member actual look for this - and know the 'indication of compromise' (IOC) information - it is very hard to spot. However, do remember that to load a module in Linux, you will need to be root (superadmin), so the OutlawCountry attack will only(!) work on a suitable system that already has been deeply compromised.
The user manual says "For operational use, shell access is assumed, and root privileges are required", hence the server has already been fully compromised - with root access privileges you 'own' the system 100% anyway and can do whatever you want.
3. While the attack is simple, there are also some indications that will give the defenders a high confidence of a breach - if the below conditions are present on a server.
4. Red Hat Enterprise Linux (RHEL) is often used in mission critical production environments.
Technical information and IOC
A) Based on the user manual, OutlawCountry works on Red Hat Enterprise Linux (RHEL) 6.x and derivatives (e.g Centos) 64bit default kernel version 2.6.32.
The manual states 'First, select the appropriate kernel module for the target system. For 64-bit CentOS/RHEL 6.x targets, use the “nf_table_6_64.ko” module.'
The naming convention does also give a lot of sense; this module use netfilter's table (nf-table), versus RHEL version 6 (6) - 64 bit (64).
UPDATE: The leaked test plan also mentioned that CentOS/RHEL 5.x i386 kernels are also being targeted! No specific kernel versions mentioned, but runs on the i386 architecture via the "nf_table_5_32.ko" module - so RHEL/Centos version (5) on i386 (32 bit).
B) Based on your inventory list of servers concentrate now on systems with the mention profile above - RHEL/Centos version 5 and 6. In the manual, it is recommended that the module file is being deleted after the module has been loaded - due to 'operational security' (aka don't leave any trails behind).
This leave us with the bunch of IOCs if the attacker has been sloppy (remember that even red team attackers can have a bad Monday morning with small mistakes)
IOC #1 Should you during your active defense activities find any file named 'nf_table_6_64.ko' , 'nf_table_5_32.ko' (or very similar) you may have a breach.
IOC #2 The module file size on nf_table_6_64.ko should according to the user manual be associated withMD5 sum 2CB8954A3E683477AA5A084964D4665D and have a 9672 bytes file size.
Searching the system and finding a MD5 match with a present file on the system will indicate a incident.No such 'signature data' are known on the 'nf_table_5_32.ko' module.
C) One of the problems with user manuals are that people often follow them "by-the-book" - in this case it is a helping hand to the Blue team defenders.
According to the manual "loading the kernel module, a hidden table named “dpxvke8h18” would be created." . Please note that this should be the case regardless if it is kernel module 'nf_table_6_64.ko' or 'nf_table_5_32.ko'
This is interesting for a number of reasons;
These rules take precedence over existing rules , and are only visible to an administrator if the table name is known. So if the table name is truly random a defender will have a hard time to spot this hidden table.
According to the manual the module adds covert DNAT rules to the PREROUTING chain.
IOC #3 Let's list the current rules on table 'dpxvke8h18'
iptables -t dpxvke8h18 -L PREROUTING
If you have some rules displayed you may with high confidence declare that you have a incident involving OutlawCountry.
However, please be aware that this IOC has a build-in flaw. If the table name is not the default mentioned, no routing informations will be given.
But for any dedicated active defender, it is an easy task to write a small script listing random tables names, if the need should arise.
D) Last but not least (given the condition, that the module name has not been modified/changed by the attacker) it is possible to see if the kernel module has been loaded by the Linux kernel
IOC #4 Let's investigate if one of the kernel module has been loaded, by issuing the following command:
lsmod | grep nf_table
Thank you very much for reading this blog entry. The above information has been collected and analyzed to the best of my abilities on the 9 of July, 2017.
In the (likely) case that new information will arise, I will update my blog accordingly on stixfeeds.com/blog . Should you have further info on the topic, comments etc please do feel free to contact me, via the form on the stixfeeds website.
NB; If you are a member of a blue team/defense and works with ICS/SCADA protection - I can highly recommend the SANS ICS515: ICS Active Defense and Incident Response with Robert M. Lee and Mark Bristow
I am very happy to announce, that my 1-day ICS Honeypot special training class has been accepted @ cs3sthlm (previous 4SICS) in Stockholm on 24 Oct.
This 1-day workshop would start with a short general introduction to ICS/SCADA & Honeypots.
Many ICS/SCADA security speakers will be announced soon! Come and join the fun, it is 24-26 October in Stockholm,
*The product; * "The RUGGEDCOM RS900 is a 9-port utility-grade, fully managed Ethernet switch, specifically designed to operate reliably in electrically harsh and climatically demanding environments." Source: http://w3.siemens.com/mcms/industrial-communication/en/rugged-communication/ruggedcom-portfolio/switches-routers-layer-2/compact-switches/Pages/rs900.aspx *Devices affected:* RUGGEDCOM RS900 (however, other models of RUGGEDCOM switches may be affected as well) *Firmware/configuration affected:* RS900 Order Code RS900-HI-D-MT-MT-MT-XX Boot version v3.0.2 Main version 4.2.1 Required Boot 2.20.0 Hardware ID RS900 (v2, 40-00-0066) *Vulnerability type: Denial of Service.* Successful exploiting this vulnerability are very simple - by sending a limited numbers of ICMP packages does the CPU max to 65% load and stop responding during the attack. Via a serial connection to the router diagnostic page, it can be seen that the router CPU max up to 65% and stop responding to e.g. a running ping command. *Overall CVSS Score:* 7.5 (Version3) CVSS Vector CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H **Mitigation/workaround;* None know at the moment. *EXPLOITABILITY* These vulnerabilities could be exploited remotely. *EXISTENCE OF EXPLOIT* No known public exploits specifically target these vulnerabilities. *DIFFICULTY* An attacker with a low skill would be able to exploit these vulnerabilities. *Credits:* This vulnerability was found by Carsten Borup Andersen and Mikael Vingaard, based on the work of the other researchers, who found the Black Nurse vulnerability. For details pls see www.blacknurse.dk
Using trivial reversing of firmware, it possible to retrieve a undocumented backdoor (username/password) from
below mentioned 3G/4G Wimax Cpe Router models. This credential gives - in most cases - full access to the router.
Each firmware are 'service provider centric', and I has even discovered that some providers allows control
with the device with a blank password from a non-rfc 1918 IP address (aka. inside the provider network).
Based on public available firmware, it is found that the following models are affected; (Other HUAWEI models may also be affected.)
Based on the firmware investigated, and general deployment of above models, this vulnerability
most likely affects one (or more) service provider(s) in the following countries;
Indonesia (Confirmed, based on available firmware)
Iran (Confirmed, based on available firmware)
Madagascar (Confirmed, based on available firmware)
Nigeria (Confirmed, based on available firmware)
Ukraine (Confirmed, based on available firmware)
It is most likely that other countries are affected as well, as above models are used, at least, in these countries:
Bahrain,Cote d'Ivoire,Libya, Philippines
Above products has reached "End-of-life" and are not supported by the vendor.
Devices should be decommissioned and replaced with new supported devices.
Communication: This was reported to CERT.org , and the following reference was given: VU#226671
Before starting researching, some credentials was found in a SCADA honeypot.
09. Feb 2016; several different hardcoded credentials found in various firmware versions, multiple device models affected.
09. Feb Initial email, with technical details send to Huawei PSIRT (email@example.com)
10. Feb Confirmation of email received from Huawei PSIRT asking not to disclose issue before they had time to investigate (possible delay due to Chinas new year)
14. Feb Huawei PSIRT writes back and informs that the credential are not undocumented, they are just in a undisclosed documentation strictly for vendors, hence they are closing the case.
14. Feb Notified CERT.org of issue, and advised I was in dialogue with Huawei PSIRT.
14. Feb Wrote Huawei PSIRT with further technical information for additional findings and asked if I could be allowed to see the documentation.
15. Feb Cert.org assigns vulnerabilities to VU#226671
24. Feb wrote a kind reminder to Huawei PSIRT asking for status.
25. Feb Huawei PSIRT advises that I am not allowed to see the documentation (only for vendors) and technical staff investigates other findings.
29. Feb Huawei PSIRT advise that items are "not to worry". I replies and thanks for the assistance, and that I will make a blog entry.
As alway in my findings, I will encourage people to change devices from "End-Of-Life" to newer supported devices.
02. Mar Blog entry published.
During the last weeks, an interesting trend in the network of honeypot servers.
The logs shows an increasing numbers of failed SSH (TCP:port 22) logins attempts.
The attacker first tries the following combination of password and user name:
username: PlcmSpIp password: PlcmSpIp
Above combination are the factory default access for many Polycom.com's products
e.g. the SoundPoint SIP (VOIP) phones.
Immediately afterwards the attacker tries the combination of root:TANDBERG
This happens to be the default password/user name on Tandberg/Cisco boardroom
videoconferencing systems. The attackers comes from a few network ranges based
in China ('home based/private users' ISP), but the behavior has been spotted on several honeypots
spread over several geographical locations (both in the US and in Europe).
The best way to avoid this types of compromises are to change the default password(s)
before putting such system on-line.
It has been a time since I have posted, Life has been busy and I have just returned from the EnergySec conference.
I am now getting ready for the 4SICS (4 SCADA, Industrial Control System) in Stockholm , where I am looking forward
to present another SCADA research project "Who controls your industrial control systems?”,
Qouting from the website 4SICS.se - home of 4SICS:
"4SICS – Stockholm international summit on cyber-security in SCADA and Industrial Control Systems.
4SICS is an annual summit that gather the most important ICS/SCADA cyber security stakeholders across critical industries (i.e.
energy, oil & gas, water, transportation and smartgrid etc).
I am so trilled to see a SCADA conference in the Nordics and do hope to see you there - it an amazing lineup of speakers :-)
I am very happy to have been invited to speak at EnergySec's 11th Anniversary Security Summit
To qoute from the website: " Since 2005, there have been many security conferences established in the energy sector tackling everything from technical SCADA security topics to security legislation and compliance to plant physical security. We believe we are one of the oldest and most mature summits, bringing the most relevant and timely security topics to the forefront of discussion."
The Presentation are titled "Please, Come and Hack my SCADA System!" and will deals with HoneyPot's in the Energy sector.
University of Michigan - SCADA Scanning -
I noticed a interesting trend in the log files of the honeypot networks I am handling.
A /24 network range belonging to University of Michigan, showed a interest for e.g ModBus (port 502/TCP) The scans was found across many of my different honeypots placed in Europe/US.
In reply to my abuse rapport, i did receive the following;
"These connections are part of an Internet-wide research study being conducted by computer scientists at the University of Michigan. The research involves making benign connection attempts to every public IP address. By measuring the entire public address space, we are able to analyze global patterns and trends in protocol deployment and security.
If our scans are causing problems, we would be happy to exclude your host or network from future research scans from the University of Michigan. Simply send us your IP address or CIDR prefix.
Alternatively, you can configure your firewall to drop traffic from the subnets we use for scanning:
184.108.40.206/24 and 220.127.116.11/24"
My suggestion: You might consider to block above network ranges, unless you (and your SCADA equipment) want to participate in University of Michigan's SCADA Research.