Amazon is experiencing an outage of its S3 service ("Simple Storage Service") for a few hours. According to the Amazon status dashboard[1], only the US-EAST-1 area is affected. Many other Amazon services relying on S3, this outage could have impacts on many websites and web services.

[1] https://status.aws.amazon.com/

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

This is a guest diary submitted by Remco Verhoef.

The cloud is bringing a lot of interesting opportunities, enabling you to scale your server farm up and down depending on the load. Everything is being taken care of automatically by auto scale groups.There is nothing to worry about anymore.

But this brings me to the following point, in particular, because IPv4 addresses are harder and harder to come by: How quickly are public IP addresses being reused and what if I can collect requests, specifically HTTP(s) requests, intended for a prior user of the IP.

Easily said. I’ve created a server which will just store all requests in an Elasticsearch cluster, a client who does nothing more than just listening for http and https (with an expired self signed certificate) and a userdata script that automatically starts the client, waits for about 10 minutes and then shuts it down again. I’ve configured spot instances in multiple regions and kept it running for a while. When spot instances are being shut down (because of the price, or because the instance shuts itself down), it will automatically start a new instances if it is still within the given pricing range.

About the results: I’ve loaded the Elasticsearch dataset into R for easy visualisation and querying and together with good old awk, sed, wc and grep I’ve been able to draw some interesting results.

Within the dataset we found several occurrences with Amazon in the User-Agent. This leads to the following Amazon related user-agents:

• Amazon Route 53 Health Check Service
• Amazon Simple Notification Service Agent
• Amazon CloudFront

The health check service checks if the host is online and if it returns the expected result (statuscode 200), it will include this server to the dns based load balancing configuration.

Simple Notification Service Agent is being used to send notifications to the server. We’ve received several notifications, like cache keys expired, varnish flush caches, but also a load of messages containing userdata.

The Amazon CloudFront traffic is traffic originated to the original webservers, of data that needs to be cached for a longer period of time. This is interesting as well, because you’ll be able to poison the cache for a long amount of time.

An analysis on the other useragents gave some interesting results as well. We’ve seen the following useragents:

• Stripe (the url being called was a webhook and contained information about a updated subscription.
• GitHub-Hookshot (a webhook being called)
• com.google.* (the user-agents are being used by Google applications) for example docs, gmail, ios
  • com.google.chrome.ios
  • com.google.Classroom
  • com.google.Docs
  • com.google.Gmail
  • com.google.GoogleMobile
  • com.google.hangouts
  • com.google.hangouts_iOS
  • com.google.ios.youtube
  • com.google.Slides
• Gmail
• GmailHybrid
• Google
• Google.Docs
• Google.Drive
• Google.DriveExtension
• Google.Slides
• GoogleAnalytics
• GoogleCsi
• Hangouts
• SLGoogleAuthService
• com.apple.appstored is the useragent being used by the apple store application)
• FBiOSSDK is facebook app
• FitbitMobile is the fitbit app
• Haiku%20Learning
• Instagram the instagram app
• Spotify

In total we’ve found 159 different user agents (with the version number stripped off). Which is a lot. The complete dataset contained ~80k requests.

Those useragents are strange, not the variety I had expected. This seems just normal traffic passing a proxy or a gateway. Let’s look at the hostnames, in total we have encountered 578 different hostnames, containing a lot of interesting hosts . This is just a subset.

• Minecraftprod.rtep.msgamestudios.com:443
• www.googleapis.com:443
• apis.google.com:443
• inbox.google.com:443
• global.bing.com
• api-global.netflix.com
• m.baidu.com
• www.fitbit.com:443
• audio-sv5-t1-1-v4v6.pandora.com
• s3.amazonaws.com:443
• pagead2.googlesyndication.com
• maps.googleapis.com:443
• www.google.com.tw:443
• d1e5xacotudrwg.cloudfront.net
• www.google.pl
• www.wikipedia.org
• admin.brightcove.com
• crt.usertrust.com
• www.twitter.com:443
• oauth.vk.com:443
• en-US.appex-rf.msn.com
• 4-edge-chat.facebook.com:443
• tados-s.westeurope.cloudapp.azure.com:15002
• google.com:443
• m.google.com:443
• www.baidu.com:443
• www.bing.com
• s3-us-std-102-prod-contentmover.prod-digitalhub.com.akadns.net
• i.instagram.com:443
• localhost
• mail.google.com:443
• itunes.apple.com:443

So this is really strange. What about the X-Forwarded-For headers, if it should have been destined to a proxy server, we should be able to find those. Looking at this traffic we didn’t see really awkward things, most of them were from left over dns entries for other hosts. One super weird thing though, is this traffic destined for www.datapool.vn.

X-Forwarded-For: 25.34.94.111, 197.191.79.83, 162.63.120.125, 149.133.46.21, 21.186.158.233, 214.148.185.253, 249.166.69.42, 20.90.2.104

Host: www.datapool.vn

Remote Address: 103.9.158.76

Where the remote address is from somewhere in Vietnam, but the X-Forwarded-For explains the request has been forwarded by 8! different proxy servers. If you look up the block owners of these proxy servers you’ll find these organizations:

• UBS AG (UBSAG)
• DoD Network Information Center (DNIC)
• DoD Network Information Center (DNIC)
• Computer Sciences Corporation (CSC-68)
• UK Ministry of Defence
• Airtel Ghana
• The Swatch Group Ltd

So traffic from a vietnamese client address, via my Amazon server, with in the X-Forwarded-For the UK Defense as the Department of Defense with a vietnamese website as destination. Interesting. Don’t know how to position this, any ideas are welcome.

Now I’m looking at the requesting addresses, retrieving all the netblock owners of the requesting addresses. This is not 100% solid, because netblock could change ownership in time. But lets see what it brings us. To have some focus, I’ve filtered out all the traffic with the com.google.* user-agents. This is traffic I wouldn’t expect to arrive at my systems. The netblock owners are the following:

• AT&T Internet Services (SIS-80)
• Cellco Partnership DBA Verizon Wireless (CLLC)
• Gestion de direccionamiento UniNet
• Hawaiian Telcom Services Company, Inc. (HAWAI-3)
• McAllen Independent School District (MISD-15)
• PSINet, Inc. (PSI)
• San Diego County Office of Education (SDCS)
• Time Warner Cable Internet LLC (RCSW)
• Time Warner Cable Internet LLC (RRMA)
• Time Warner Cable Internet LLC (RRMA)
• Time Warner Cable Internet LLC (RRSW)
• Time Warner Cable Internet LLC (RRSW)
• Time Warner Cable Internet LLC (RRWE)
• Time Warner Cable Internet LLC (RRWE)
• T-Mobile USA, Inc. (TMOBI)
• WideOpenWest Finance LLC (WOPW)

In total there were 95 different originating ip addresses, with 1446 requests (with useragent com.google.*), which is just a small sample of the complete set. AT&T and Time Warner have done the most requests.

So with all the data we’ve crunched, we’ve found the following cases:

• we receive data from client addresses mapped to telecom and internet providers, with http method CONNECT and with traffic destined for Google, Microsoft and much more.
• we receive data for Amazon Route 53 health checks, Amazon Simple Notification Service Agent and Cloudfront. Many of the SNS messages contain privacy related information.
• we receive many more requests from left over ip addresses, these consist of GET requests, but also POST requests containing data as tokens, keys and logs.

This leaves us with the following attack scenarios:

• proxy the traffic on our server with the real destination, with for example a falsely generated certificate. Many apps will reject the certificate, but we all know the troubles CAs have with incorrect issued certificates. So at least in theory it will be possible to man in the middle traffic with accepted certificates.

• For the left over hosts it will be even possible to request a real lets https certificate with a bit of timing and luck, because the challenge response works via http.

• Another important issue to worry about is that it is possible as well to get accepted as a server into the load balancing configuration of Route 53, by just returning valid response status codes. As long as we’ll return valid status codes, it will be as long as someone notices part of the configuration.

• And last but not least, the amount of data we were getting on our http endpoints, like the sns notifications, webhooks and all. This could be circumvented easily by just enforcing valid https certificates.

Disclosure Timeline

We’ve disclosed our findings with Amazon and Amazon has implemented an IP cooldown feature, which should fix those issues.

2016/10/13: issue reported to Amazon. AWS confirms receipt of the report, and reaches out requesting additional information
2016/10/27: AWS Security requests additional details to further the investigation, and sets up time for an initial telephone sync
2016/11/08: Conference call confirmed for 2016/11/11
2016/11/11: Telephone sync takes place to provide additional technical information. AWS confirmed that it is possible for traffic configured with a destination IP to be received by any instance with that public IP regardless of attachment. Shared that AWS would be adding a cooldown period before an IP is reassigned to reduce the likelihood of an IP being reused while traffic destined for it was in flight. This would be delivered in early 2017
2017/02/24: IP cooldown feature released

Disclaimer: it is possible that the dataset has been manipulated by forged requests, but as no-one knows about this research and the launch of spot instances where to random I don’t expect that to be the case.

If you have any more questions just let me know. I’ll be happy to answer them. You can contact me using:

@remco_verhoef
github.com/dutchcoders/
remco@dutchsec.nl

With the huge surface attack provided by CMS like Drupal or Wordpress, webshells remain a classic attack scenario. A few months ago, I wrote a diary about the power of webshells[1]. A few days ago, a friend of mine asked me some help about an incident he was investigating. A website was compromised (no magic - very bad admin password) and a backdoor was dropped. He sent a copy of the malicious file. It was quite small (only 5250 bytes) and nicely obfuscated:

<?php ${"\x47L\x4f\x42\x41L\x53"}["\x62u\x6d\x66\x7a\x78"]="a\x75\x74h";${"\x47LOBAL\x53"}["\x71\x70b\x78\x67\x70\x69\x65\x71b\x78"]="\x76\x61\x6c\x75\x65";${"GLO\x42\x41\x4c\x53"}
["e\x6e\x79p\x75\x74\x68d\x6c\x6bk"]="k\x65\x79";${"\x47L\x4
...

The file was already uploaded on VT one month ago[2] and had a detection score of 0/54. I decided to have a deep look at the file and to deobfuscate it. Several steps were required:

Step 1 - Lot of characters are replaced by their hexadecimal encoding (\xx).  Such characters can be replaced with a few lines of Python:

f = open(’sample.php')
w = open(’sample-out', ‘w’)
d = f.read()
d2 = d.strip()
w.write(d2.decode('string-escape’))

The result is:

<?php ${"GLOBALS"}["bumfzx"]="auth";${"GLOBALS"}["qpbxgpieqbx"]="value";${"GLOBALS"}["enyputhdlkk"]="key”;
${"GLOBALS"}["pwhuehui"]="j";${"GLOBALS"}["pbkqpwkeuthu"]="i";${"GLOBALS"}["tkoqjcwbcj"]="value”;
$udborfbq="data";${"GLOBALS"}["bdylpnwgwuyn"]="data_key";${"GLOBALS"}["knxtwihmugi"]="data”;
...

Step 2 - We see that the PHP code makes references to variables using the ${“GLOBALS”} notification[3]. This helps us to better understant the script and we can replace the global variables with their equivalent defined at the beginning of the script:

${“GLOBALS”}[“foo”] = “bar”;

Could be read as:

$bar;

We can search/replace all occurrences of global variables to make the code more readable.

The last step was to beautify the code to make it human readable. The final backdoor version is available on pastebin[4]. In the code, you can see the $auth variable used to encrypt/decrypt the payload passed to the backdoor. Surprisingly, I found many occurrences of the same string on Google. This reveals that the code is not new and has already been referenced one year ago around July 2015. Practically, what does it do?

Compared to full-features webshell, there are no nice features here. It just accepts PHP commands that are passed to an eval(). Data are passed through a POST HTTP request or cookies. The following arguments must be passed to the script:

‘ak’ is the authentication key, ‘a’ is the command and ‘d’ contains the PHP commands to execute. They are two commands available: 

‘i’ returns the PHP and script versions:

Array
(
    [ak] => authentication key;
    [a] => i
)
a:2:{s:2:"pv";s:18:"5.3.10-1ubuntu3.26";s:2:"sv";s:5:"1.0-1";}nsdfjk

‘e’ executes the code passed in ‘d’ via eval():

Array
(
    [ak] => authentication key;
    [d] => system("uname -a");
    [a] => e
)
Linux shiva 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

What can we learn from this backdoor?

• Don’t loose time by reversing what has already by performed. Google for some strings in the obfuscated code to find relevant material.
• Most of them are used by “script kiddies” who don’t even take the time to change the encryption keys.
• It is not easy to detect with classic log files.

Such backdoor is stealthy and not easy to spot in classic web servers log files: No POST data not cookies are not logged/stored in log files. You can log POST data using modsecurity[5]. You can also search for peaks of POST requests in your log files.

[1] https://isc.sans.edu/forums/diary/The+Power+of+Web+Shells/21257/
[2] https://www.virustotal.com/en/file/416409e9ec38d2f740cef5404cb3241b3d04365ec72a0ae45be4f4c8d1be8472/analysis/
[3] http://php.net/manual/en/reserved.variables.globals.php
[4] http://pastebin.com/BBQ7mscr
[5] https://isc.sans.edu/forums/diary/Tracking+HTTP+POST+data+with+ELK/20345/

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

Last week I ran across a very successful phishing campaign, what’s odd in most ways it was nothing special. The attacker was using this more like a worm, where stolen credentials would be used within the hour to start sending out a mass amount of more phishes. I've decided to call this "Dynamite Phishing" because there is nothing quiet about this at all. It seems about 40% of the credentials were used for more mailings, and the other account's credentials had not been used.

The initial phishes came in from a K12 domain from several affected individuals. The email subject was  “You have an Incoming Document Share With You Via Google Docs”. The contents of the email were base64 encoded, while it appears to be common Content-Transfer-Encoding, it's not something I typically run into especially when looking at Phishes.

Here is what the Document rendered as.

 

 

The link in the document went to "hxxp://bit.ly/2kZJbW3" which went to hxxp://jamesrichardsquest.co.nf/lib

The landing page was setup as a generic Outlook Web Access 2013 login page.

Some of the headers had the below client listed.  It appears the EM_Client is a pretty popular email client, but it maybe something you can block on depending on your environment.

user-agent: eM_Client/7.0.27943.0

While most people have good protections from Emails coming from external entities into their email environment, many don’t push the same protections intra-domain.  The volume of email sent from the Phished accounts to other Internal accounts is what made this so successful.

 

Lessons Learned:

• Two-factor Authentication to Email services.
• Don’t trust internal-to-internal email
• Rate limit or block emails with X-number of recipients inbound and outbount

 

 

--

Tom Webb

@twsecblog

I took a look at Guy's diary entry from yesterday. This malicious document contains macros that launch a PowerShell command.

Like it is often the case with such documents, the PowerShell command will download and execute an executable: MD5 e2d5d1bf5d69a942d99c8ea45fe28ac2.

The PowerShell command is encoded and stored in Form1 objects:

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

This week I received an email looking very realistic with a Word document that made it through the AV gateway from the Canadian Revenue Agency, it is tax season after all and everyone must be extra vigilant. The Word document got me curious since it is from CRA and named SecureDoc.doc, after all, when you hear SecureDoc you think of WinMagic[1], in this case, it has no relation.

I examined a copy of the file using Didier Stevens oledump.py[2] to find out if there was anything I could get from this file. I dumped the content and saw it contains 3 macros (identified by the M).

I checked each of the macro sections 12, 13 & 14 and 13 displayed strange results similar that the results of this sandbox[3].

And last I check for and PE files in the document with no avail. The file is malicious and is detect by 23/55 AV engine on Virustotal.

[1] https://www.winmagic.com
[2] https://blog.didierstevens.com/2014/12/17/introducing-oledump-py/
[3] https://www.hybrid-analysis.com/sample/caec8c4e5cfbc59b34bd64b87cec0f10bcfecee11a79f05d9a2e37c26230ca9d?environmentId=100
[4] https://www.virustotal.com/en/file/fcd0eef7dec8141df9704da6fcf6543d6b18526ef2944b2a225b36883c7a0b4a/analysis/1487945938/

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

Microsoft Edge and Internet Explorer can be exploited by a type confusion in HandleColumnBreakOnColumnSpanningElement. A POC was released here.

[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=1011#c2

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

The ISC has received several requests asking us to weigh in on the ramifications of the Cloudflare data leak, also being referred to by some as CloudBleed.

The short version of the vulnerability is that in rare situations, a bug in Cloudflare's edge servers could be triggered, which would cause a buffer overrun to occur. When these buffer overruns occurred, random data would be returned in the replies from the Cloudflare servers. Private chat messages, user logins and passwords, and many other bits of data were found in the random data. This data would be data from any of Cloudflare's customer applications, which is a very big list of some of the most popular sites on the Internet.  Potentially over 4 million domains. (Partial list of popular sites and the full list are available here).  Most seriously, these pages, containing random data, were cached to Google's search results (those results have now been scrubbed of Cloudflare data).  

It is believed that this vulnerability was present from 22 Sept, 2016 until 18 Feb. 2017.

What does this mean to you?  Unfortunately, the data leak means that this needs to be treated as another data breach. If you have an account on any Cloudflare hosted application, which we almost certainly all do, it is time to go and change your passwords.  I would also strongly recommend that you use this as an opportunity to enable 2-factor authentication on any application that supports it.

UPDATE 20170224 17:45 UTC: It appears Cloudflare customers have started sending out password change requests. I just received my first a few minutes ago.

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

Google has announced that they have succeeded in developing a technique which makes it practical to craft two PDF files with the same SHA-1 digital signature.

Of course like all new vulnerabilities/attacks in this decade it needs a web page and a cool logo.  Not to disappoint they can be found here.

What does this mean to you?  The fact is nothing has changed since yesterday.  This is still a difficult attack. For most applications SHA-1 will still be an adequate level of protection.  This does highlight a significant risk to high-trust applications such as banking, legal contracts and digital signatures.  Theoretical attacks against SHA-1 have been hypothesized since 2005 and SHA-1 was deprecated by NIST in 2011, so most high-trust uses of SHA-1 should be long since upgraded to more secure methods.

SHA-1 is still commmonly used for file integrity hashes, and is used for that purpose in Git and most vendor signatures, so there wil be some work to do.

Google is following their disclosure guidelines so the details of the attack will not be released for 90 days.  Leaving time for applications that are still using SHA-1 to move to more secure hashing methods such as SHA-3 or SHA-256.

Further reading below: 

Google -> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

ARSTechnica -> https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/

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

GarageBand 10.1.6 is released today, fixing an arbitrary code execution bug in Yosemite 10.10 and later (CVE-2017-2374)

There's also second patch for Logic Pro X 10.3.1.  Unfortunately, it's got the text for the Garageband patch in it's notes, so it's not clear what is fixed in this update.

As always, all Apple security patches are hosted here: https://support.apple.com/kb/HT201222

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

Microsoft released the patch for MS017-005 today, to patch a remote code execution vulnerability in Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, Windows 10, and Windows Server 2016.  The MS Bulletin is posted here: https://technet.microsoft.com/en-us/library/security/MS17-005, but is not yet posted on the main feed (https://technet.microsoft.com/en-us/security/bulletins.aspx)

The matching Adobe technote is APSB17-04, found here: https://helpx.adobe.com/security/products/flash-player/apsb17-04.html

This is a remote code execution issue, so it's a definite "PATCH NOW" issue.

** Update: the Microsoft feed has caught up now with the patch release, https://technet.microsoft.com/en-us/security/bulletins.aspx is now correct.

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

From time to time, we see spikes on some odd port in our data and we want to figure out what the bad guys are trying to do. Even just capturing the first packet or two of data can help us figure out what they are looking for, even if we don't initially give the proper response to capture the entire exploit. Sometimes, we can get lucky and the whole exploit is a single packet (yes, I remember SQL Slammer very well). It seems like everyone has their favorite way to capture the traffic, but they all seem to have weaknesses. So, I figured I'd ask you, our loyal readers, for your favorites and any pros and cons to your favorite method. Do you put up a netcat listener (in a loop, so it continues to listen after the first connection attempt)? Do you use socat? Do you have a favorite perl or python (or bash or powershell) script? In my Truman-based automated malware analysis environment, I simply redirected every port to my IRC server perl script, but that isn't appropriate if we're actually facing the internet. So, let me know what you think.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

I'll be teaching FOR610: Reverse-Engineering Malware in Columbia, MD in June (https://www.sans.org/community/event/for610-columbia-jun-2017)
and in Ottawa, ON in Sep (https://www.sans.org/community/event/for610-ottawa-sep-2017)

Last week, I was working with a client on a web-filtering solution, using one of their organization's laptops.  We happened to notice the long-long-LONG list of SSIDs that were on this machine, may of them open SSIDs.  The host we were looking at had the default "dlink" and "linksys" SSIDs as auto-connect, so not a great situation.  Coincidentally, this was the same day Xavier posted his diary about collecting this same information (the ssid list) from live machines (https://isc.sans.edu/forums/diary/How+was+your+stay+at+the+Hotel+La+Playa/22069/).  It really seems like people still have a pathological need to connect up to free WiFi.

I got to thinking about how to collect this information in an Active Directory domain using PowerShell.  It's quite easy for Windows 10, but not so much for Windows 7 clients. For the "older environment" case, I ended up falling back to:
netsh wlan show profiles  to get the list of wireless profiles
netsh wlan show profiles name=PROFILENAME  to get the details for the profile "PROFILENAME"
Combine that up with psexec (because psexec *always* works - well, almost always), and some text manipulation, and you have the code below.
Yes, I do know that this could have been done by pulling everything out of the registry, but in this case perfect is the enemy of "done" - I had a few clients who wanted this done quickly, and this approach got it done in that "quickly" time frame.

The resulting script will list all wireless profiles across an AD domain.  I did have a "test connection" line in there, but enough organizations have ping disabled now that I took that out. 

How to use this information?  For most organizations, this is a chance to do some outreach, some end-user education about safer computing.  In most cases, this means that we recommend that they tether to their phone rather than connect to random free SSIDs.

In a more security conscious environment, say if it's a bank or if clearances are involved, what this can be used for is as a simple audit.  In higher security shops, it's more common to see Group Policy be used to say "only this short list of SSIDs are permitted", where the list is the organizations' "real" wireless networks, as well as (in some cases) a pre-configured cell phone "tethered" network.

As always, let us know how this code works out.  There are a few errors I'm still trying to suppress, and it can take quite a long time to run this, but the clients that I've used this with have gotten good use out of the information.

The code (recommend PowerShell 4.0 or better):
$nodenets = @()
$domainmembers = get-adcomputer -filter *
foreach ($node in $domainmembers) {
    $netlist = iex ("./psexec /accepteula \\"+$node.name +" netsh wlan show profiles") 2>./a | Select-String -Pattern ": "
    if(($netlist -like "*was not found*") -or ($netlist.length -eq 0)) { write-host "No Wireless on host " $node.name }
    else {
      write-host "Assessing Wireless on host " $node.name
      foreach ($net in $netlist) {
        [console]::write(".")
        $netprf = ($net -split(": "))[1]
        $cmd = "./psexec /accepteula \\"+$node.name +" netsh wlan show profiles name="+ "`'"+$netprf+"`'"
        $netparmlist = iex $cmd 2>./a
        $netparmlist2 = $netparmlist | select-string -pattern ": " | select-string -pattern "Applied" -NotMatch | select-string -pattern "Profile" -NotMatch
        $x = New-Object psobject
        $x | add-member -membertype NoteProperty -name "Node" -Value $node.name
        foreach($parm in $netparmlist2) {
          $t1 = $parm -split ": "
          $x | add-member –membertype NoteProperty –name ($t1[0].trim(" ")) –Value ($t1[1]) ;
          }
        $nodenets += $x
        }
      }
  }
$nodenets | select Node, Name, "Connection Mode", "SSID Name", Authentication, Cipher, "Security Key" | Out-GridView

(watch for updates over the next few days at https://github.com/robvandenbrink/opw )

The output (you could just as easily output to CSV for use in Excel):

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

Yesterday, I read an interesting blog post about exploiting XXE (XML eXternal Entity) flaws to send e-mails [1]. In short: It is possible to trick the application to connect to an FTP server, but since mail servers tend to be forgiving enough, they will just accept e-mail if you use the FTP client to connect to port 25 on a mail server. The mail server will of course initially see the "USER" and "PASS" commands, but it will ignore them.

Initially, I considered this a lesser issue. A similar attack has been used in the past via HTTP proxies. HTTP proxies can also connect to port 25, and relay mail connections that way. But from my experience, mail servers tend to ignore them. For example:

220 mail.dshield.org ESMTP
GET
221 2.7.0 Error: I can break rules, too. Goodbye.
Connection closed by foreign host.

However, (and thanks to Alexander, the author of the blog for pointing this out), it looks like the list of blocked command is limited to HTTP verbs:

smtpd_forbidden_commands (default: CONNECT, GET, POST)

List of commands that cause the Postfix SMTP server to immediately terminate the session with a 221 code. This can be used to disconnect clients that obviously attempt to abuse the system. In addition to the commands listed in this parameter, commands that follow the "Label:" format of message headers will also cause a disconnect.

This feature is available in Postfix 2.2 and later.

Only CONNECT, GET, and POST will be blocked by default. To extend the list, use the following line in your main.cf file for postfix:

smtpd_forbidden_commands = CONNECT,GET,POST,USER,PASS

I don't think either USER or PASS is ever used legitimately in SMTP. Instead, SMTP uses "AUTH" to log in a user. To test, just connect to the mail server via telnet or netcat:

$ nc localhost 25
220 mail.dshield.org ESMTP
USER
221 2.7.0 Error: I can break rules, too. Goodbye.

 [1] https://shiftordie.de/blog/2017/02/18/smtp-over-xxe/

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

Introduction

Nothing really exciting this week, so let's review malicious spam (malspam) we received at our ISC handers email distro. The message is in Portuguese, and it claims to be from Detran.  Detran is an abbreviation for Departamento Estadual de Trânsito, an institution responsible for supervision of ground vehicles in Brazil.  The malspam concerns a ticket for running a red light, but the message is ultimately a vehicle for transporting AutoIt-based malware.

Shown above:  Brazilian malspam disguised as a message from Detran.

I received a zip file from a link in the email, and it easily infected a Windows computer on Friday 2017-02-17.  Let's take a closer look at this infection.

Shown above:  Flowchart for the infection.

Translation

Original message text in Portuguese:

Subject: Detran "Prezado(a) Condutor(a) Informe Detran (Notificacao *2 via Multa Transito*) - ***** (58825)

Infração de Trânsito, Notificação da Autuação.

A multa por avançar o farol vermelho, está descrita no artigo 208 do Código de Trânsito Brasileiro.

Ja pode Baixar o Aplicativo do Sistema de Notificação Eletrônica (SNE DETRAN), que permite receber as notificações a qualquer momento e lugar, oferecendo ainda desconto de 40% no valor da multa para pagamento até a data de vencimento da mesma.

Detran 2017 - Todos os direitos reservados - Aspectos Legais e Responsabilidades.

Google translation:

Subject: Detran "Dear Conductor Report Detran (Notification * 2 via Fine Traffic *) - ***** (58825)

Traffic Infringement, Notification of the Assessment.

The fine for advancing the red light is described in article 208 of the Brazilian Traffic Code.

You can download the application of the Electronic Notification System (SNE DETRAN), which allows you to receive notifications at any time and place, also offering a 40% discount on the fine for payment until the expiration date of the same.

Detran 2017 - All rights reserved - Legal Aspects and Responsibilities.

The download

Clicking on the link presented a zip archive.  I tried several times and saw at least seven different file names for the zip archive.  They all contained the a .js file inside with the same file hash, regardless of the actual file name.

Shown above:  What I got after clicking the link.

Shown above:  The zip archive contained a .js file.

I emailed abuse@dropbox.com to notify them of the URLs I found.  The following HTTPS URLs over TCP port 443 provided the initial zip archive:

• www.dropbox.com - GET /s/m9vu2mwquasfhr3/%5BAvancar-Sinal%5D.zip?dl=1
• www.dropbox.com - GET /s/7dwinqclpdxt6q8/Infracao%5BMulta%5D.zip?dl=1
• www.dropbox.com - GET /s/b9u8rdqigk5ycnr/INFR-SG%5BMulta%5D.zip?dl=1
• www.dropbox.com - GET /s/lpbxa75s9vutq6r/FDWS%5BInfracao%5D.zip?dl=1
• www.dropbox.com - GET /s/d3k0u4ircpyt861/Informe%7BMulta-Recebida%7D.zip?dl=1
• www.dropbox.com - GET /s/7ann3m0bno2pe6x/FLSFW%5BMulta%5D.zip?dl=1
• www.dropbox.com - GET /s/e8yqpvl8wb0jpgt/RD793614%5BNotificacao-Multa%5D.zip?dl=1

Traffic

Because the Dropbox URLs were sent encrypted over HTTPS, I didn't see any alerts when downloading the zip archive.  After opening the zip archive and double-clicking the enclosed .js file, my Windows computer became infected.

Shown above:  Traffic of the infection filtered in Wireshark.

The follow-up malware was sent as an 7.9 MB ASCII text file that represented hexadecimal characters for an executable binary.

Shown above:  The follow-up malware sent as ASCII text.

The 7.9 MB of ASCII text was saved to the Windows host as C:\Users[username]\AppData\Local\TaJKgtThuk\KmNgRErtY6.zip.  That fake .zip file was still ASCII text.  It was then converted to a 3.97 MB binary.  The binary was as an .exe saved to the local host, and it was made resident through a Windows registry update.

Shown above:  Follow-up malware saved to the host and made persistent.

The ASCII text (that fake zip file) was deleted during the infection process.  However, I grabbed a copy before it deleted itself, so I could double-check.  I took that 7.9 MB of ASCII text, copied it into a hex editor, and saved the result as an .exe file.  It had the same file hash as the .exe from the infected Windows host.

I only saw one alert on the traffic.  It was an ETPRO rule for Autoit.LOX checkin.  The alert is an older rule that originally appeared back in August 2014 [1].

Shown above:  Alerts on the traffic using Security Onion with Suricata and the ETPRO ruleset.

Indicators of Compromise (IOCs)

The following are malicious URLs associated with this infection:

• 187.17.111.98 port 80 - mktserviceseguro.com - GET /Multa/
• 187.17.111.98 port 80 - mktserviceseguro.com - GET /Multa/Multa.php?ass=[long string of characters]
• 187.17.111.100 port 80 - etevaldomotos.com.br - GET /manhazinha/cedo/osso.dat
• 187.17.111.100 port 80 - etevaldomotos.com.br - GET /manhazinha/cedo/osso.zip
• 191.6.200.92 port 80 - vallfer.com.br - GET /maisvc/notify.php

The extracted .js file:

• SHA256 hash:  ed8d7c4201c4e2a670e3418242cc02f9509e02e2e580f1b77a9ccb6e0455dc80
• File name:  Infracao[Multa].js  (and various other file names)
• File description:  .js file extracted from zip archives associated with this malspam

The followup .exe malware:

• SHA256 hash:  da9172f1e1d81c2a9300a5028bc419ea8d43518bcdb61b022180646aa2539c68
• File location:  C:\Users\[username]\AppData\Local\TaJKgtThuk\KmNgRErtY6.exe
• File description:  Follow-up malware downloaded by .js file

Final words

This malspam wasn't well-targeted.  But our ISC handler email distro occasionally receives this type of malspam, so I like to share when I can.  As usual, my lab environment is designed to be vulnerable to such malware.  By the time you read this, some of the infrastructure for this campaign may already be blocked or taken down.

I don't think many people will become infected by this malspam, but it's always interesting to see what the criminals are putting out there.

From what I understand, AutoIt is a scripting language that's not inherently malicious.  However, it provides a convenient environment that criminals can use to quickly develop malware.  A VirusTotal search for comments tagged #autoit reveals several recent examples of AutoIt-based malware.  A Google search for "autoit malware" returns several articles on the subject.

Pcap and malware for this diary can be found here.

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

References:

[1] https://www.proofpoint.com/us/daily-ruleset-update-summary-2014-08-05

Have you ever been asked for the config of a router or switch you (or someone else) put in so long ago you didn’t remember that device was there?  So long ago that the layer of dust inside that switch is probably why the fan stopped spinning and melted it?

Yup, me too.  So when it comes time to rebuild it, you go to that customer’s CATTOOLS directory (or configuration manager, or whatever backup tool that they have), and find out that:

• They retired that VM and didn’t tell you
• They let the license lapse
• They forgot about that device when they set up their backups
• They “upgraded” the backup tool, but then never started the service?
• They installed something else that broke the backup service

Yes, “stuff” happens, and backups sometimes don’t, for lots of reasons.  This got me to thinking that what I really want (this week) is a PowerShell backup utility for an arbitrary list of network gear at any given client. This beats my previous method of snarfing up cattools directories (when I remember) or backing things up manually whenever I change them (and when I remember) - you see the recurring problem in that method?

Why PowerShell?  There’s so many other approaches with Python, Expect, Ansible and so on (all of which can do way more than just backups) – why build something new in PowerShell?  Mostly because I can run that on any customer Windows machine and expect it to work, without installing anything the client might have a problem with.  Plus I really wanted to play with Carlos Perez’s Posh-SSH code ( https://github.com/darkoperator/Posh-SSH )

So, first, what to back up?  What most of my clients run is some subset of:

• Cisco IOS
• Cisco Nexus
• Cisco ASA
• HP Procurve
• HP Comware
• Palo Alto Networks Firewall

Seems like a reasonable starter list?  OK, now how to back them up?  Again, with the theme of “don’t install anything, don’t change the host you’re running on, and (to quote Ed Skoudis), to 'live off the land' " – this is all in SSH, and all in PowerShell.  Essentially for each device: login, do a “show running-config” (or equivalent for that platform), capture the output and save it to ASCII.  The credentials never get saved, but you can likely scrape them out of memory if you wanted to make a point.

The input file looks like this (a fictional companyname.in is shown):

NAME,IP,DEVTYPE
cisco_ios_router_or_switch,192.168.12.101,1
cisco_asa,192.168.12.102,2
cisco_wireless_controller,192.168.12.103,3
hp_procurvesw01,192.168.12.104,4
hp_comwaresw01,192.168.12.105,5
pan_firewall_set,192.168.12.106,6
pan_firewall_xml,192.168.12.106,7

The code reads the file as a CSV, so populates a “devices” variable with properties of:  devices.name, devices.IP  (which can also be a CN or FQDN, it just needs to resolve), and devices.devtype

The 7 device types are covered in the example.in file above.  Note that the Palo Alto is in there twice, devicetype 6 for “set” commands - the commands to rebuild the box, devicetype 7 for XML output - which you would use for a full backup, or if you wanted to manipulate that file in another app (stay tuned for that).

Running the Code:

If you run the script with no arguments, you of course get help text:

Running it “for real”, it uses get-credential to collect the userid/password for the devices in the input file.  I could save these out, but I’d really rather not leave credentials like this laying around in a file.

The script then motors through the list, device by device.  It takes a few minutes, and I could likely make it faster, but I’d rather it be reliable (and done) than a never ending project that never quite works – I really did write this to collect those backups!

Error checking?  Umm, not so much, or better stated "not yet".  If you specify a device that doesn’t exist, or if the credentials don’t match, it’ll error out on that device and just go on to the next one in the list.  That’d be a good thing for me to get around to fixing (sometime soon maybe)..

The code itself is on my github ->  https://github.com/robvandenbrink/rtrbk

Where do I go from here?  Give the code a spin,and you tell me!  If you’ve got devices you’d like to see added, or other features you’d like to see, please use our comment form to let me know!

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

In November, Heise, a german technology news publisher, broke a story that AVM cable modems included not only the manufacturer's certificate authority certificate as part of the firmware but also the corresponding private key [1]. The news didn't get a lot of attention back then. AVM is the maker of "Fritz!Box" routers and modems which are almost exclusively sold to german speaking countries only. When I read the news initially, I also considered it only a risk to cable modem's in the area AVM operates. But it turns out, that the leak may have larger repercussions, as pointed out in a note published by CableLabs, the organization in charge of the DOCSIS cable modem standard. A reader forwarded us this note:

"All operators globally may be exposed to a security issue related to the EuroDOCSIS PKI and need to take action. AVM cable modems were shipped with the device private key and the AVM CA private key in the firmware which is now publicly exposed. As a result illegitimate cable modems can be created which could cause network problems such as theft of service. Major CMTS vendors ship their product with both the DOCSIS and EuroDOCSIS Root CA installed as a trust anchor in their CMTSs. As a result, CableLabs recommends all operators blocklist (untrust) the compromised AVM CA in their CMTSs, regardless of whether or not they have AVM equipment deployed in their network or they actively use the EuroDOCSIS Root CA." [2]

So what does this all mean? DOCSIS is the standard cable modem operators adopted to allow manufacturers to create interoperable equipment. EuroDOCSIS is the European version of this standard. I will refer to both standards as "DOCSIS" going forward. 

DOCSIS requires that each cable modem contains a unique certificate to authenticate the cable modem to the provider. The certificate is signed by the manufacturers CA, which in turn is signed using the DOCSIS CA. Cable modem operators trust cable modems that can present a properly signed certificate. 

Due to AVM's mistake, the private key for AVM's is now public, and anybody could create new certificates that will be trusted by cable modem ISPs that trust the EuroDOCSIS CA. This could, for example, allow someone to spoof a cable modem owned by a different provider, or create a cable modem with rogue firmware that will not obey configurations sent by the ISP.

Heise in a follow-up story stated that the key was already used in the wild to sign fake certificates [3]. The fake certificates were apparently used well before Heise broke the story.

As an end user, there is nothing you can do. As outlined by the note from CableLabs, ISPs will have to distrust the AVM CA. This could potentially cut service for users who use modems that provide certificates derived from the AVM CA. But most cable modem ISPs will not allow any modem to connect to their network, but only a subset of DOCSIS certified modems that are compatible with the particular head-end equipment used by the ISP. So the impact is likely small. AVM does not distribute cable-modems outside Europe as far as I know, but I may be wrong.

[1] https://www.heise.de/security/meldung/AVM-entweicht-geheimer-FritzBox-Schluessel-3463752.html (German Only)
[2] https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=de49a18c-a9e8-4bb3-8f35-e949fc538831 (Login Required)
[3] https://www.heise.de/security/meldung/Entfleuchter-FritzBox-Schluessel-zum-Ausstellen-falscher-Zertifikate-missbraucht-3465065.html (German Only)

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

OpenSSL released an update for OpenSSL 1.1.0. The latest version is now OpenSSL 1.1.0e. OpenSSL 1.0.2 is not affected.

The vulnerability, %%cve:2017-3733%% can lead to a crash in either clients or servers. In order to trigger the vulnerability, an attacker would first negotiate an SSL connection without the "Encrypt-Then-Mac" extension. Later, the attacker would use the extension during a renegotiation handshake. The vulnerability is rated as "High" by OpenSSL, below the maximum level of "Critical".

I recommend you wait for your respective vendor/Linux distribution to provide an updated OpenSSL library, which should be available shortly if it isn't already available. Not too many systems are using OpenSSL 1.1.0. Many current Linux distribution use the non-vulnerable 1.0.2 branch. So no need to panic.

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

Microsoft earlier today updated its blog post about the "skipped" February patch Tuesday with a note that "We will deliver updates as part of the planned March Update Tuesday, March 14, 2017." March 14th is the March Patch Tuesday date, so February's updates will be combined with the March update. Probably overall the least disruptive solution at this point.

https://blogs.technet.microsoft.com/msrc/2017/02/14/february-2017-security-update-release/

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

I made the following demo for a customer in the scope of a security awareness event. When speaking to non-technical people, it's always difficult to demonstrate how easily attackers can abuse of their devices and data. If successfully popping up a "calc.exe" with an exploit makes a room full of security people crazy, it's not the case for "users". It is mandatory to demonstrate something that will ring a bell in their mind.

As people want to be constantly online, they (ab)use of wireless access points. By default, connected devices keep a history of all used wireless networks and constantly try to find them again. The idea of the demo is simple:

1. Collect all the SSID's broadcasted by mobile devices present in the audience
2. Geolocate the SSID's using the Wigle API
3. Display them on a map

[Note: For privacy reason, this demo must be performed with the authorization of people in the audience]

First, collect SSID's using tshark and a Wireless network card that can be switch into monitoring mode:

# iwconfig $interface mode monitor
# ifconfig $interface up
# tshark -i $interface -n -l subtype probereq | tee -a /tmp/ssids.tmp
Feb   7 18:37:39 Probe Request from 08:ee:8b:xx:xx:xx for SSID 'xxxx Airport'
Feb   7 18:36:54 20:a2:e4:xx:xx:xx trying to associate with 'Free Wireless'
Feb   7 18:36:49 Probe Request from 20:a2:e4:xx:x:xx for SSID 'Free Wireless'
Feb   7 18:36:25 Probe Request from 58:40:4e:xx:xx:xx for SSID 'Free Wireless'
Feb   7 18:36:22 Probe Request from 0c:e7:25:xx:xx:xx for SSID 'Free'
Feb   7 18:36:12 Probe Request from e8:50:8b:xx:xx:xx for SSID 'xxxxx-wifi'
Feb   7 18:36:04 f0:25:b7:xx:xx:xx trying to associate with 'Airport_Free_xxxxxx'
Feb   7 18:36:04 Probe Request from f0:25:b7:xx:xx:xx for SSID 'Airport_Free_WiFi_xxxxxx'
Feb   7 18:35:46 64:9a:be:xx:xx:xx trying to associate with 'swisscom'
Feb   7 18:35:46 Probe Request from 64:9a:be:xx:xx:xx for SSID 'swisscom'
Feb   7 18:35:40 Probe Request from 24:77:03:xx:xx:xx for SSID 'UM'
Feb   7 18:35:38 Probe Request from 24:77:03:xx:xx:xx for SSID 'UM'
Feb   7 18:35:34 Probe Request from 20:a9:9b:xx:xx:xx for SSID 'xxxxx'
Feb   7 18:35:31 Probe Request from 20:a2:e4:xx:xx:xx for SSID 'Free Wireless'
Feb   7 18:35:15 Probe Request from 8c:00:6d:xx:xx:xx for SSID 'xxxxNET'
Feb   7 18:35:15 Probe Request from 80:ea:96:xx:xx:xx for SSID 'Airport_Free_WiFi'
Feb   7 18:35:10 38:ca:da:xx:xx:xx trying to associate with 'xxxxNET'

Let tshark collect SSID's for a few minutes (the list will quickly grow). The next step is to use the Wigle[1] API to get geolocation data. 

[Note: The free API allows only a limited number of queries per day]

I wrote a Python script[2] which queries the API and generates a CSV file:

# grep SSID /tmp/ssids.tmp | awk -F "'" '{ print $(NF-1) }'| sort -u >wigle.data
# python wigle.py
# head wigle.csv
SSID,Lat,Lon
AIRPORT FREE WIFI,50.88093567,7.11556339
AIRPORT FREE WIFI,28.45140457,-13.8698101
AIRPORT FREE WIFI,43.30202866,-8.38176537
xxxxxxxxxxx,43.52931595,5.45100164
xxxxxxxxxxx,36.88293457,10.33142185
xxxxxxxxxxx,48.85987091,2.22434855
xxxxx,40.48699951,-3.58421397
Airport_Free_WiFi,-6.86642265,39.20762634
Airport_Free_WiFi,52.30990219,4.76001358

The last step is to map those coordinates on a world map. Splunk does this with just one query:

| inputcsv wigle.csv | stats count by SSID, Lat, Lon | geostats  latfield=Lat longfield=Lon count by SSID

A zoom on the map may reveal nice locations where your victim could have spent some fun times:

What about the accuracy of those maps? It relies on the Wigle database which is populated by volunteers. Generic SSID's like "Free Wifi" or "Guest" won't give good results but a unique hotel name will make it perfectly. It is not possible to put the broadcasted SSID's on a timeline to track the moves in the past but it's easy to spot two people who met or visited the same place in the past.

Given that people keep their phone default name ("iPhone of John Doe"), this demo generates always a little stress when you ask the victim: "So, Mr Doe, How was your stay at the hotel La Playa?".

[1] https://wigle.net/index
[2] https://github.com/xme/toolbox/blob/master/wigle.py

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

Microsoft delayed the release of all bulletins scheduled for today. Today was supposed to be the first month of Microsoft using its new update process, which meant that we would no longer see a bulletin summary, and patches would be released as monolithic updates vs. individually. It is possible that this change in process caused the delay.

At this point, we do not know when Microsoft will release it's February patches. There is still the unpatched SMB 3 DoS vulnerability that I hoped would be addressed in this round.

https://blogs.technet.microsoft.com/msrc/2017/02/14/february-2017-security-update-release/

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

Packettotal ( http://www.packettotal.com ) is a new site that does some nifty analysis of Packet Captures for you if you're not so familiar with Wireshark or other analysis tools

Out of the gate, this site maps out connections, certificates, encryption algorithms and gives up files that are transfered in the session.  A great start (I accidentally found another app that runs their own private CA with this), we're looking forward to more great things from this site as they get on!  So far everything you can do on Packettotal you can do in Wireshark, but it's as quick and easy as can be on the PT site!

Of course - the standard rules apply - be sure that you're not uploading sensitive informaiton to cloud-based sites of this type!  If you're analyzing client data, you might need permission to upload.   They also still allow http access to their site (oops) - be sure to browse to them using https explicitly until they fix this.

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

With the prevalence of Next-Gen Firewalls, we're seeing a new wave of organizations decrypting traffic at the network edge, between organizations and the public internet.
This is a good thing.  As we see more and more "legit" https traffic, we're also seeing the attackers follow that trend, where malware and attacks are now often encrypted using standards based protocols as well.

How does this look in practice?  Usually something like this:

But as we do the "decrypt / inspect / encrypt" thing, we're also being forced to deal with applications that do things in unexpected ways - stuff like ...

What NOT to Decrypt
There is *always* a list of applications that your don't want to decrypt.  For privacy reasons, you almost never decrypt healthcare sites and banking/financial sites.  Not only is the case that we don't want that information in a log someplace, it's likely either illegal or breaks compliance if we decrypt and inspect tha ttraffic.  Depending on your jurisdiction and industry, that list may of course vary.

Apps that run a Private CA and/or do Certificate Pinning
I've seen some banking terminals (both ATMs and POS platforms) do certificate pinning, which is exactly as you would hope should be going on.  Of course they'll run their own CA, and reject any traffic that is encrypted using a certificate that isn't their own.  And of course, we simply put that banking terminal (ATM or payment card processor) into an exemption list - we don't *want* to decrypt that traffic - if we could decrypt that traffic successfully and still have it operate, we'd report that as an issue to the payment processor.  Where possible though, it's also a good practice to isolate these units, and only allow them to communicate to their payment card "mothership".  You definitely don't want to be the source of an ATM breach, and if they get compromised from some other source, you don't want their attacker to see your network either.

Surprisingly though, I'm seeing the same sort of behaviour in Courier apps.  You know, that desktop app that shipping & receiving (or the office manager, or whoever does shipping in your organisation) runs?  Again, because the private CA is pinned, the only way to deal with it is to exempt the traffic between that workstation and the DN (Directory Name) of the target (*.purolator.com in this case).  Good on them for going the extra mile, but it sure was a surprise to find it in the logs!  We still get to decrypt everything else to and from those machines - they're not isolated, but exempting traffic for that one application is straightforward.

Apps that "Break the Rules"
A more troubling situation is that we do see some applications that break or bend the rules for good encryption.  For instance, apps that accept expired certificates from their server.  
Logmein (the support/remote control application) for instance is currently in that situation.  Their web services back-end currently uses an expired certificate.  Worse yet, their upstream has no fixed IP address (it's in a CDN), and the traffic is over tcp/443.  Without putting some work into the rules, the decryption engine will simply drop the traffic because the cert is expired.  So what this means for perimeter rules is that we need to match on the target DN (there's a list), and for those DN's we have to allow expired certificates.  And right below that rule, we need a second rule that has the same DN's but doesn't allow expired certificates (for when they fix this situation).

We see similar things for applications that use API's inside of SSL or TLS - if they're using weaker ciphers, older protocols or pin certificates, to allow that app to work we need to set the allowed DN's and permit whatever bad habit that app has.  

Other Bad Habits:
We also see lots of file downloads happen for one application or another.  So if your organization blocks downloading JAR files for instance, any Java based app that pulls a JAR will trigger and block, breaking the application.  It's very common for instance to see "all-in-one" helpdesk applications download a package of EXE's, JAR's and MSI's when  a new station is enrolled.  As a side note, it's also common to see these apps pull down older versions of Java, Acrobat Reader and other apps - what could possibly go wrong with that?

Logging is your friend for all of these "something is broken" situations - for any application that doesn't work, have a test user break it "on film" and note the time.  Once you've got it logged, you'll have the info you need to allow that application (and only that application) to do whatever dumb thing (or smart thing) that it needs to do to run, without allowing that behaviour on other applications.

For the helpdesk app example - in some cases we luck out and can set up a local repository, in other cases that "cloudy" nature of the app can't be worked around, and we need to permit exemptions.  

Final advice?  Once you have a smarter perimeter appliance like this in play, be prepared for your users to request that you "whitelist" a never-ending list of websites and applications.  Before you do that, make sure that they're actually blocked for one behaviour or another - in most cases they work just fine. I'm still working out why human nature pushes folks to want a mile-long whitelist rule - one that has a "pass everything, trust it all" permission.  So far, for most of those I leave all the decryption, traffic inspection, IPS and file inspection/sandboxing in play - the list of sites where you *don't* want that going on is pretty short.

If you've gone down the "decrypt/inspect/re-encrypt" road at your network edge, what problems have your found?  How did you work around it?  Please, use our comment form and let us (and everyone else) know!

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

What to do on a cloudy lazy Sunday? You go hunting and review some alerts generated by your robots. Pastebin remains one of my favourite playground and you always find interesting stuff there. In a recent diary, I reported many malicious PE files[1] stored in Base64 but, today, I found a suspicious piece of JavaScript code[2]. It was posted by a valid account but it was its first pastie (with a validity of one month). Here is the sample (beautified):

 1 : var _2519;
 2 : var _6101='34280B84F123A777A741D825 ... stripped data ... F713C589E';
 3 : var _9332=/[\x41\x42\x43\x44\x45\x46]/;
 4 : var _3352=2;
 5 : var _3603=_6101.charAt(_6101.length-1);
 6 : var _9837;
 7 : var _4678=_6101.split(_9332);
 8 : var _4029=[String.fromCharCode,isNaN,parseInt,String];
 9 : _4678[1]=_4029[_3352+1](_4029[_3352](_4678[1])/21);
10 : var _5991=(_3352==4)?String:eval;
11 : _9837='';
12 : _11=_4029[_3352](_4678[0])/_4029[_3352](_4678[1]);
13 :  for(_2519=3;_2519<_11;_2519++)
14 :     _9837+=(_4029[_3352-2]((_4029[_3352](_4678[_2519])+_4029[_3352](_4678[2])+ \
         _4029[_3352](_4678[1]))/_4029[_3352](_4678[1])-_4029[_3352](_4678[2])+_4029[_3352](_4678[1])-1));
15 : var _8383='_1472';
16 : var _2078='_8383=_9837';
17 :
18 : function _6430(_9378)
19 : {
20 :    _5991(_1667);
21 :    _6430(_3473);
22 :    _3473(_2078);
23 :    _6430(_8383);
24 : }
25 :
26 : var _1667='_6430=_5991';
27 : var _3473='_3473=_6430';
28 :
29 : _6430(_3603);

It's an interesting example of code obfuscation but not very complicated to reverse. After a quick check, we may assume that the malicious code is stored in the variable '_6101' (line 2) and that the rest of the code is just used to deobfuscate it. Note also the presence of the string 'eval' in 10. This should get you thinking. Let's review the code line by line:

Line 3, '_9332' contains the following string (hex-encoded): 'ABCDEF'.

Line 5, _3603 contains the last characters of the payload: 'E'.

Line 7, the payload is split based on the separators 'ABCDEF' and stored in _4678. It contains:

34280,84,123,777,741,825,741,813,749,809,773,801,817,585,481,825,741,809,481,689,773,817,785,757,481,597,481,489,621,669,625,629,481,693,665,633,681,645,629,665,625,481,617,709,481,709,741,793,765,593,541,613,601,489,589,393,825,741,809,481,625,757,813,749,809,773,801,817,773,797,793,813,481,597,481,489,489,529,393,481,481,481,481,733,817,757,833,817,481, ...

Line 8: _4029 contains an array of JavaScript functions

Line 9:  _4678[1] contains '4' (String(parseInt(84)/21) = 4)

Line 10: The most important one:  _5991 contains the 'eval' function! (The condition never matches: 2 != 4)

Line 12: _11 contains the length of our payload: 8570. (parseInt(34280)/parseInt(4) = 8570)

Line 13: The main loop will process all integers in _4678 (see above). Deobfuscated characters are stored in _9837:

_9837 += (String.fromCharCode((parseInt(_4678[_2519])+parseInt(123)+parseInt(4))/parseInt(4)-parseInt(123)+parseInt(4)-1))

Starting from line 15, more obfuscation is performed to fool the analyst. The function _6430 is in fact just a call to eval() which executes the code stored in _9837.

function _6430(_9378){
    _5991(_1667); // eval(_6430=eval)
    _6430(_3473); // eval(_3473=eval)
    _3473(_2078); // eval(_8383=_9837)
    _6430(_8383); // eval(_9837)
}

What is stored in the variable _9837? Is it malicious or just suspicious? The payload passed to eval() is a JavaScript code called "CODE UNFRIEND by Yang". It looks to be a script to massively remove friends from a Facebook account. I posted a copy of the de-obfuscated payload on pastebin[3]. If it rings a bell to you, let me know.

[1] https://isc.sans.edu/forums/diary/Many+Malware+Samples+Found+on+Pastebin/22036/
[2] http://pastebin.com/raw/DmxeKdgw
[3] http://pastebin.com/yBWnQQ5P

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

Introduction

It's been one month since my last diary on malcious spam (malspam) with links to malicious Word documents containing Hancitor [1].  Back then, we saw Hancitor use Pony to download Vawtrak malware.  Since then, I've seen indicators for this type of malspam on a near-daily basis.

Recently, these emails have stopped leading to Vawtrak.  Instead, I'm now seeing malware that triggers alerts for Terdot.A [2, 3, 4, 5, 6, 7].  Tools from my employer identify this malware as DELoader, and a Google search indicates Terdot.A and DELoader are the same thing.

For now, I'm keeping my flow chart open on the final malware.  With that in mind, let's take a look at some infection traffic generated on Thursday 2017-02-09 based on one of these emails.

Shown above: Flow chart for the infection process.

The email

These emails generally have different subject lines each day, and they have spoofed sending addresses.  The example I saw on 2017-02-09 was a fake message about a money transfer.  It's similar to a wave of malspam seen the day before.

• Date:  Thursday, 2017-02-09 16:05 UTC
• Received:  from polsinelli.com   [spoofed host name]
• Message-ID:  <879081B3.F4FA76CC@polsinelli.com>
• From:  "Polsinelli LLP" <mlemon@polsinelli.com>   [spoofed sender]
• Subject:  RE:RE: wife tf

The link from the email contains a base64-encoded string representing the recipient's email address.  Based on that string, the downloaded file will have the recipient's name from the email address.  I used a base64 string for a made-up email address and received a file named bofa_statement_marci.jones.doc.

Shown above:  Fake money transfer email with link to a Word document.

The link from the malspam downloaded a Microsoft Word document.  The document contains a malicious VB macro described as Hancitor, Chanitor or Tordal.  I generally call it Hancitor.  If you enable macros, the document retrieves a Pony downloader DLL.  At first, I thought Pony was retrieving the DELoader malware; however, another researcher told me it's Hancitor that grabs DELoader.  I haven't had time to investigate; however, I probably need to update my flowchart.

Shown above:  Retrieving the Hancitor Word document from the email link.

Shown above:  Enabling macros will activate Hancitor.

The traffic

Pattern-wise, URLs from this infection are similar to previous cases of Hancitor/Pony malspam reported I've seen during the past week or two.

Shown above:  Infection traffic after activating macros in the Word document.

Alerts show post-infection traffic for Terdot.A/Zloader, which is consistent with recent infections I've seen for malware identified as DELoader.

Shown above:  Alerts on the traffic using Security Onion with Suricata and the ETPRO ruleset.

Indicators of Compromise (IOCs)

Email link noted on Thursday 2017-02-09 to download the Hancitor Word document:

• 187.17.111.102 port 80 - www.jasa.adv.br - GET /api/get.php?id=[base64 string]

Traffic after enabling macros on the Word document:

• api.ipify.org - GET /   [IP address check]
• 91.226.93.57 port 80 - hadrylego.com - POST /ls5/forum.php   [Hancitor callback]
• 91.226.93.57 port 80 - hadrylego.com - POST /klu/forum.php   [Hancitor callback]
• 98.138.19.143 port 80 - caleduc.com - GET /blog/wp-content/themes/sketch/1   [call for Pony DLL]
• 104.196.224.112 port 80 - main-meats.com - GET /1   [call for Pony DLL]
• 199.204.248.138 port 80 - patsypie.com - GET /wp-content/themes/sketch/1   [call for Pony DLL]
• 98.138.19.143 port 80 - caleduc.com - GET /blog/wp-content/themes/sketch/a1   [call for DELoader]
• 104.196.224.112 port 80 - main-meats.com - GET /a1   [call for DELoader]
• 199.204.248.138 port 80 - patsypie.com - GET /wp-content/themes/sketch/a1   [call for DELoader]
• 91.221.37.160 port 80 - ughtoftritret.ru - POST /bdk/gate.php   [DELoader callback]

Associated file hashes:

• SHA256 hash:  82d4b6676bbff17626aba1a65a9c6ec10ab036c101c8dc5e6e697693ec5a013f   
• File size:  181,248 bytes
• Description:  Word document from link to www.jasa.adv.br

• SHA256 hash:  d2c79954335b579309957c22b1b7976359fd067691626f8beb99779143edaa69   
• File size:  257,024 bytes
• Description:  Terdot.A/DELoader

Final words

As this campaign progresses, IOCs will continue to change, and I'm sure traffic patterns will continue to evolve.

Pcap and malware for this diary can be found here.

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

References:

[1] https://isc.sans.edu/forums/diary/HancitorPonyVawtrak+malspam/21919
[2] http://malware-traffic-analysis.net/2017/01/25/index2.html
[3] http://malware-traffic-analysis.net/2017/01/30/index2.html
[4] http://malware-traffic-analysis.net/2017/01/31/index3.html
[5] http://malware-traffic-analysis.net/2017/02/01/index.html
[6] http://malware-traffic-analysis.net/2017/02/06/index2.html
[7] http://malware-traffic-analysis.net/2017/02/07/index.html

Early today on 2017-02-09, a new vulnerability based on CVE-2016-9244 was announced by f5 affecting the company's Big-IP appliances [1].  According to f5:

A BIG-IP SSL virtual server with the non-default Session Tickets option enabled may leak up to 31 bytes of uninitialized memory.

This new vulnerability has a website (https://ticketbleed.com/) and a logo.  It even has an article on The Register as I write this [2].

Shown above:  A creative logo for yet another vulnerability.

Ticketbleed.com (currently redirects to filippo.io/Ticketbleed) has interesting details about the discovery and timeline.  It also has a link for a complete technical walkthrough on the vulnerability.

At this point, organizations using f5 products will start spinning up their security teams to determine if they are impacted.  As I write this, It's shortly after midnight in the US Central Time Zone.  Later as the business day begins, leadership in many organizations will be asking about Ticketbleed.  Some will find echoes of 2014's Heartbleed vulnerability in this.  As I just heard from a fellow security professional, "There goes my tomorrow."

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

References:

[1] https://support.f5.com/csp/article/K05121675
[2] https://www.theregister.co.uk/2017/02/09/f5s_bigip_leaks_lots_of_little_chunks_of_memory/

Introduction

At the end of January 2017, BleepingComputer published a report about an updated variant of CryptoMix (CryptFile2) ransomware calling itself CryptoShield [1].  It was first discovered by Proofpoint security researcher Kafeine.  At that time, CryptoShield was distributed by the EITest campaign using Rig exploit kit (EK).

Since then, other researchers continued seeing CryptoShield from EITest Rig EK.  I've already documented this Rig EK/CryptoShield combo twice [2, 3], and it shows no signs of stopping.

With that in mind, let's look at a recent infection generated on Wednesday, 2017-02-08.

Traffic

As I've stated before, EK traffic is kicked off by some sort of referer, usually by a compromised website or a malicious online ad (malvertisement) that has injected code leading to an EK landing page [4].

Shown above:  Flow chart for this infection traffic.

I tried the site and saw injected EITest script leading to a Rig EK landing page.  Approximately 35 minutes later, I tried it again and saw a different Rig EK domain using the same IP address.

Shown above:  Injected script from the EITest campaign in a page from the compromised site.

Shown above:  Pcap of traffic from the first infection filtered in Wireshark.

Shown above:  Injected script from the EITest campaign 35 minutes later.

Shown above:  Pcap of traffic from the second infection filtered in Wireshark.

Shortly after viewing the site, the Windows host was infected.  I first saw an application error, then received a User Account Control (UAC) notification.  After clicking through those two popup notifications, the host was fully infected.  The infected Windows host then showed indicators of CryptoShield.  Both a browser window and a text file appeared on the desktop, and they showed the decryption instructions.

Shown above:  The application error popup.

Shown above:  The UAC notification.

Shown above:  Screenshot of the infected Windows host.

Malware

CryptoShield uses .CRYPTOSHIELD as the suffix for any files it encrypts.  Based on the HTML file, the sample I saw (the same sample during both infections) was version 1.1 of the ransomware.  This CryptoShield sample set itself up for persistence in the Windows registry under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.

Shown above:  File extension for the encrypted files.

Shown above:  HTML decryption instructions show this is CryptoShield version 1.1.

Shown above:  Windows Registry update and file location for the ransomware.

Indicators of compromise (IOCs)

Rig EK IP address and domains:

• 194.87.93.53 port 80 - need.southpadreforsale.com
• 194.87.93.53 port 80 - star.southpadrefishingguide.com

Post infection traffic from the CryptoShield sample:

• 45.63.115.214 port 80 - 173.66.46.112 - POST /images/gif_png/gif.php

File information for the Rig EK Flash exploit:

• SHA256 hash:  0c1b3a0131c98032141d2315902b546bd926d5d4365628dafbbfca165f934f12
• File description:  Rig EK flash exploit

File information for the Rig EK payload:

• SHA256 hash:  8ce1ce2e7b15cadee04ce6b32c30531e808e2869200d39e04f43788ec21283ac
• File description:  CryptoShield ransomeware
• File location:  C:\Users\[username]\AppData\Local\Temp\rad4F812.tmp.exe
• File location:  C:\Users\[username]\AppData\Local\Temp\rad1BB53.tmp.exe
• File location:  C:\ProgramData\MicroSoftTMP\system32\winlogon.exe

Final words

Thanks to the people on Twitter who tweet information about compromised websites leading to Rig EK.  Without help from the community, this type of traffic would be much harder to obtain.

Rig EK has been around for a while.  I wrote a diary about Rig EK back in April 2015, and Rig EK was active well before then.  As always, if you follow best security practices (keep your Windows computer up-to-date and patched), your risk of infection is minimal.  Unfortunately, not enough people follow best practices, so it apparently remains profitable for criminals to continue using Rig EK as a method of malware distribution.

For now, CryptoShield ransomware from Rig EK remains a continuing presence in our threat landscape.

Pcaps, malware, and artifacts for this diary are available here.

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

References:

[1] https://www.bleepingcomputer.com/news/security/cryptomix-variant-named-cryptoshield-1-0-ransomware-distributed-by-exploit-kits/
[2] http://www.malware-traffic-analysis.net/2017/01/31/index2.html
[3] http://www.malware-traffic-analysis.net/2017/02/06/index.html
[4] http://researchcenter.paloaltonetworks.com/2016/06/unit42-understanding-angler-exploit-kit-part-1-exploit-kit-fundamentals/

This is a guest diary contributed by Remco Verhoef. Interested in publishing a guest diary? Sent us your idea via our contact form.

Most cloud providers offer metadata using private urls. Those urls are used to retrieve metadata for the current configuration of the instance and passing userdata. The configuration contains data like security groups, public ip addresses, private addresses, public keys configured and event rotating secret keys. The userdata can contain everything like initialization scripts, variables, passwords etc.

The metadata urls will vary per cloud provider, I’ve written a few down together with their metadata url and a link to the documentation.

Google
http://169.254.169.254/computeMetadata/v1/
https://cloud.google.com/compute/docs/storing-retrieving-metadata

Amazon
http://169.254.169.254/latest/meta-data/hostname
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

Openstack
http://169.254.169.254/2009-04-04/meta-data/instance-id
https://blogs.vmware.com/openstack/introducing-the-metadata-service/

Dreamhost
http://169.254.169.254/metadata/v1/hostname
https://developers.digitalocean.com/documentation/metadata/

Azure
http://169.254.169.254/metadata/v1/maintenance

The configuration and userdata is used by scripts, automating tasks and applications, but the danger is that it can be abused to leak information about the current instance. Information an attacker needs to elevate privileges or move laterally. This information can contain usernames, passwords, configuration, keys or scripts.

When your application accepts remote urls as data like a proxy server, vpn server or a web application (think about wordpress plugins for embedding remote content, web screenshotting applications and many more), you need to be sure the metadata url is not accessible. If you install a default squid proxy for example, just executing this command:

$ http_proxy=proxy:3128 curl http://169.254.169.254/latest/dynamic/instance-identity/document                                                                                                                 {
 "devpayProductCodes" : null,
 "privateIp" : "172.31.9.215",
 "availabilityZone" : "eu-west-1c",
 "version" : "2010-08-31",
 "region" : "eu-west-1",
 "instanceId" : "i-*****",
 "billingProducts" : null,
 "pendingTime" : "2017-02-03T20:21:11Z",
 "instanceType" : "m3.medium",
 "accountId" : "*****",
 "architecture" : "x86_64",
 "kernelId" : null,
 "ramdiskId" : null,
 "imageId" : "ami-e31bab90"
}

This will return all metadata of the proxy server.

Anyhow the metadata contains information you don't want to disclose. You’ll be safe when the private ip has been blocked, but this is not always possible (in the case of the rotating secret keys for example). Blocking the requests can be done using good old iptables:

$ iptables -A OUTPUT -m owner ! --uid-owner root -d 169.254.169.254 -j DROP

This will only allow root to access the metadata url, allowing the boot sequence to use the metadata and disallowing the web servers to use the metadata.

When I tried to include the [taco] Unicode characters in the headline to this post, it cut off the headline. Supporting Unicode isn't easy, and often, to avoid security issues arising from Unicode, it is removed or outright blocked.

But in particular, mobile devices make it easy to type Emojis or other Unicode characters. As a "security guy", my next question was if I can use them as part of my password. The quick answer: support varies... and don't count on it. 

One issue I was a bit worried about is that multibyte characters often include the 0x00 byte. This can cause issues since the 0x00 byte is often used to terminate strings. So I set up a quick test page to figure out if any of the PHP or MySQL hashing functions are susceptible to this issue. the Smiley character, for example, has a code of 0x1f600. The "00" byte could terminate the string, and all passwords starting with the Smiley character would result in the same hash. My initial testing hasn't found any issues like this, but I think this is an area that does require a bit more testing, in particular if a salt is added to a password prior to hashing. 

If you want to play, I setup a quick test page with various PHP and MySQL hash functions: https://isc.sans.edu/emojitest.html

(and while you play, I will see if I can make the diary editor "emoji capable" ;-) )

On of the hardest tasks in security, and probably fundamentally an impossible task is to figure out if something is not malicious. Even the code you wrote yourself, once it exceeds a certain complexity, could include backdoors that you as the author missed. They may come in the form of vulnerabilities, or maybe it was bad advice that you followed (ever copied code from Stackoverflow?). Never mind malicious libraries or compilers.

Earlier today, a reader sent me a file asking just that question. Carlos received an anti-malware warning flagging a file as malicious. According to Virustotal, ESET-NOD32 flags it as "a variant of Win32/KingSoft.D potentially unwanted". This is a pretty weak signature. Virustotal also stated that the file is "Probably harmless" and that "There are strong indicators suggesting that this file is safe to use."

Next, I uploaded it to hybrid-analysis. Hybrid-Analysis returned the following risk assessment:

This looks quite a bit more malicious.

Some additional Google searches revealed that the file is likely part of "WPS Office," a free Chinese office suite that appears to be included for free with some HP Laptops.

My advice to Carlos was that the file is likely not malicious, but as long as he doesn't need WPS Office, he is probably better off deleting it to save some disk space. In short: bloatware. 

What would your advice be? Here are the links to the results from Hybrid Analysis and Virustotal:

https://www.hybrid-analysis.com/sample/e3d74b6eb7f941125c35ae0ab2c5bd8d7116e6794f38b3879bddeb4b1570a433?environmentId=100

https://virustotal.com/en/file/e3d74b6eb7f941125c35ae0ab2c5bd8d7116e6794f38b3879bddeb4b1570a433/analysis/

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

I am seeing a steady trickle of scans for %%port:110%% against my honeypot. Initially, I believed that the goal was brute forcing e-mail passwords. But instead, when setting up a quick netcat listener, I am seeing binary content without any obvious purpose. Various POP3 daemons have had vulnerabilities in the past, so maybe there is a way this is exploited? Or someone looking for backdoors that happen to listen on port 110 to disguise themselves. Can anybody help out with any ideas what this is about?

Here is a typical payload:

00000000  16 03 01 01 22 01 00 01  1e 03 03 a2 33 18 56 3f ...."... ....3.V?
00000010  b9 9a 05 1c 33 24 0c 83  03 bf 62 29 a6 37 22 da ....3$.. ..b).7".
00000020  33 e2 ac 9c 3c 44 28 bd  4d 8b d8 00 00 88 c0 30 3...<D(. M......0
00000030  c0 2c c0 28 c0 24 c0 14  c0 0a 00 a3 00 9f 00 6b .,.(.$.. .......k
00000040  00 6a 00 39 00 38 00 88  00 87 c0 32 c0 2e c0 2a .j.9.8.. ...2...*
00000050  c0 26 c0 0f c0 05 00 9d  00 3d 00 35 00 84 c0 12 .&...... .=.5....
00000060  c0 08 00 16 00 13 c0 0d  c0 03 00 0a c0 2f c0 2b ........ ...../.+
00000070  c0 27 c0 23 c0 13 c0 09  00 a2 00 9e 00 67 00 40 .'.#.... .....g.@
00000080  00 33 00 32 00 9a 00 99  00 45 00 44 c0 31 c0 2d .3.2.... .E.D.1.-
00000090  c0 29 c0 25 c0 0e c0 04  00 9c 00 3c 00 2f 00 96 .).%.... ...<./..
000000A0  00 41 c0 11 c0 07 c0 0c  c0 02 00 05 00 04 00 15 .A...... ........
000000B0  00 12 00 09 00 ff 01 00  00 6d 00 0b 00 04 03 00 ........ .m......
000000C0  01 02 00 0a 00 34 00 32  00 0e 00 0d 00 19 00 0b .....4.2 ........
000000D0  00 0c 00 18 00 09 00 0a  00 16 00 17 00 08 00 06 ........ ........
000000E0  00 07 00 14 00 15 00 04  00 05 00 12 00 13 00 01 ........ ........
000000F0  00 02 00 03 00 0f 00 10  00 11 00 23 00 00 00 0d ........ ...#....
00000100  00 20 00 1e 06 01 06 02  06 03 05 01 05 02 05 03 . ...... ........
00000110  04 01 04 02 04 03 03 01  03 02 03 03 02 01 02 02 ........ ........
00000120  02 03 00 0f 00 01 01                             .......

UPDATE

ok.. this was a bit too easy. After a bit of staring at the payload, it looked familiar. Turns out that this is an SSL Client hello (the 0x16 0x03 0x01 preamble gave it away). So now back to giving the attacker an SSL-enabled server to play with.

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

pastebin.com is a wonderful website. I'm scrapping all posted pasties (not only from pastebin.com) and pass them to a bunch of regular expressions. As I said in a previous diary[1], it is a good way to perform open source intelligence. Amongst many configuration files, pieces of code with hardcoded credentials, dumps of databases or passwords, sometimes it pays and you find more interesting data.

For a few days, I'm finding many pasties that contain only Base64 data. The decoded data are malicious PE files. Some files were posted multiple times, others were unique. Some examples from my list:

• hxxp://pastebin.com/cW0zR4St
• hxxp://pastebin.com/QTEd5Eqe
• hxxp://pastebin.com/Zfhtnk9X
• hxxp://pastebin.com/nVRhzRxJ
• hxxp://pastebin.com/8U5beggH

Most of the malicious files are known on VT (submitted a few hours ago), others are unknown. I also detected some obfuscated pasties:The Base64 code is reversed:

• hxxp://pastebin.com/C7YYaUZB

Another technique is the hex-encode the Base64 data:

• hxxp://pastebin.com/GeNX7DYP
• hxxp://pastebin.com/15en56ZE

This technique has already been seen in the past[2]. Powershell or Javascript scripts download malicious content from pastebin.com. But, until now, I was not able to find any reference to the pasties above. Please share with us if you have more information!

In the meantime, it could be a good idea to keep an eye on your logs and search for HTTP requests to these URLs (or globally to pastebin.com if this service is not used in your environment).

[1] https://isc.sans.edu/forums/diary/Hunting+for+Juicy+Information/20555
[2] https://blog.malwarebytes.com/cybercrime/2016/10/get-your-rat-on-pastebin/

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

** Alert 1485478430.1704280: mail  - ossec,syscheck,
2017 Jan 27 01:53:50 (xxxx) x.x.x.x->syscheck
Rule: 551 (level 7) -> 'Integrity checksum changed again (2nd time).'
Integrity checksum changed for: ‘/xxxxxxxx/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php'
Size changed from '43067' to '43621'
Old md5sum was: '05388955522e536cd475bddc2ac2d7fe'
New md5sum is : 'fbd03fc6811db1a5ebb66db48dd6f673'
Old sha1sum was: '57f23ca13bb9a4bdaa2359b7348e42a48cdc9669'
New sha1sum is : '4040a096641c51d8271b542801673414ade62bf9'
What changed:
67a68,73
>                       'args' => array(
>                               'id' => array(
>                                       'description' => __( 'Unique identifier for the user.' ),
>                                       'type'        => 'integer',
>                               ),
>                       ),
328a335,356
>        * Get the user, if the ID is valid.
>        *
>        * @since 4.7.2
>        *
>        * @param int $id Supplied ID.
>        * @return WP_User|WP_Error True if ID is valid, WP_Error otherwise.
>        */
>       protected function get_user( $id ) {
>               $error = new WP_Error( 'rest_user_invalid_id', __( 'Invalid user ID.' ), array( 'status' => 404 ) );
>               if ( (int) $id <= 0 ) {
>                       return $error;
>               }
More changes..

• 20/01/2017 : Sucuri contacted Wordpress
• 25/01/2017 : Sucuri notified trusted peers (TLP:RED)
• 26/01/2017 : Wordpress released 4.7.2
• 27/01/2017 : My wordpress fetched and installed the patch
• 01/02/2017 : Sucuri published the research

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

One of our readers, Dalibor Cerar, sent us an email about an issue impacting Cisco...at this point.  While its a hardware issue, the result if it occurs is a self inflicted Denial of Service.  Cisco released a notice on February 2 that some of its products had an issue with the Clock Signal component manufactured by a supplier.  This was discovered late in November 2016.  According to Cisco:

"Although the Cisco products with this component are currently performing normally, we expect product failures to increase over the years, beginning after the unit has been in operation for approximately 18 months. Once the component has failed, the system will stop functioning, will not boot, and is not recoverable."

Keep in mind, Cisco says the component is used by other companies so I would expect to see this list grow to other vendors.

Here is the current list of the known Cisco/Meraki products and the link to their Field Notice:

Optical Networking:
FN-64230 :  NCS1K-CNTLR  

Routing:
FN-64231 : NCS5500 Line Cards  
FN-64252 : IR809/IR829 Industrial Integrated Services Routers
FN-64253 : ISR4331, ISR4321, ISR4351 and UCS-E120

Security:
FN-64228 : ASA 5506, ASA 5506W, ASA 5506H, ASA 5508, and ASA 5516 
FN-64250 : Cisco ISA3000 Industrial Security Appliance
Meraki Notification - MX 84 

Switches:
FN-64251 - Nexus 9000 Series N9K-C9504-FM-E/N9K-C9508-FM-E/N9K-X9732C-EX 
Meraki Notification - MS350 Series 

The tweet originally announcing this issue stated that Windows 2012 and 2016 is vulnerable. I tested it with a fully patched Windows 10, and got an immediate blue screen of death (see below for screenshot).

A "Proof of Concept" (PoC) Exploit causing a blue screen of death on recent Windows version was released on Github earlier today. The exploit implements an SMBv3 server, and clients connecting to it will be affected. An attacker would have to trick the client to connect to this server. It isn't clear if this is exploitable beyond a denial of service. To be vulnerable, a client needs to support SMBv3, which was introduced in Windows 8 for clients and Windows 2012 on servers.

Right now, I do not see a Microsoft statement regarding this exploit and the vulnerability triggered by it. Of course, it is best practice to block port 445 inbound AND outbound on your firewall, limiting the impact somewhat.

A traffic capture I collected between two virtual machines (Windows 10 victim) can be found here: https://isc.sans.edu/diaryimages/smbexploit.pcap . The exploit can be seen in packet 27 and 28. The long string of "C"s does trigger the buffer overflow. 

After the (normal) "Tree Connect Request" message, the server responds with a crafted "Tree Connect Response" message. The message itself is actually kind of ok, but the length of the message is excessive (1580 Bytes) and includes a long trailer. 

The tree connect response message consists of:

1. NetBIOS header. This just includes the message type (0) and the total length (1580 in this case). 
2. SMB2 header: The usual 64 bytes. The "Command" indicates that this is a tree connect message and the response flag is set.
3. The Three Connect Response Message. This message has a fixed length of 8 bytes in addition to the fixed header. 

This is where the message should end. But apparently, since the total message size according to the NetBIOS header is larger, Windows keeps on decoding in the crafted header (all "C"s in the exploit) which then triggers the buffer overflow. 

Based on this understanding of the exploit (please let me know if I didn't get it right or missed something), I wrote a simple snort signature that looks for Tree Connect messages that exceed 1000 bytes in size. Use this at your own risk. It is in "works for me" state:

alert tcp $EXTERNAL_NET 445 -> $HOME_NET any  (sid: 10001515; msg: "SMB Excessive Large Tree Connect Response"; byte_test: 3,>,1000,1; content: "|fe 53 4d 42 40 00|"; offset: 4; depth: 6; content: "|03 00|"; offset: 16; depth:2 ;)

The exploit can be found here: https://github.com/lgandx

Blue Screen of death after successful exploit:

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

Researchers from University Alliance Ruhr have announced that they have discovered vulnerabilities in popular laser printers including models from HP, Lexmark, Dell, Brother, Konica and Samsung. The announced vulnerabilities have a range of effects, but could permit the contents of print jobs to be captured, permit delivery of buffer overflow exploits, password disclosure or even damage to the printer.

The vulnerabilities are in PostScript and Printer Job Language (PJL) and have been around for decades, exploiting limitations of the languages used by most printers. The vulnerabilities can definitely be exploited from the local network, but it is possible that a malicious website could also use cross-site scripting to exploit the vulnerabilities.

It is estimated that up to 60,000 currently deployed printers may be vulnerable.

More information on the research can be found at hacking-printers.net

The researchers have also developed and set of tools called the Printer Exploitation Toolkit (PRET) which can be used to launch the attacks against these vulnerabilities.

The vulnerability disclosures are:

PostScript printers vulnerable to print job capture

Various HP/OKI/Konica printers file/password disclosure via PostScript/PJL

HP printers restoring factory defaults through PML commands

Multiple vendors buffer overflow in LPD daemon and PJL interpreter

Brother printers vulnerable to memory access via PJL commands

Multiple vendors physical NVRAM damage via PJL commands

I am still digging, but so far I have not been able to find any vendor responses to these vulnerability advisories. If you see any please comment on this diary or through our contact page.

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

While hunting for interesting cases, I found the following phishing email mimicking an UPS delivery notification:

When you click on the link, you are redirected to the following URL:

http://xxxxxxxx/api/get.php?id=zzzzzzzzz

Where zzzzzzzzzz is the Base64 encoded email address of the victim. This link delivers a malicious Microsoft Word file with a macro:

# oledump.py file.tmp
  1:       113 '\x01CompObj'
  2:      4096 '\x05DocumentSummaryInformation'
  3:      4096 '\x05SummaryInformation'
  4:      4096 '1Table'
  5:     46803 'Data'
  6:       525 'Macros/PROJECT'
  7:        86 'Macros/PROJECTwm'
  8: M   10403 'Macros/VBA/ThisDocument'
  9:      8458 'Macros/VBA/_VBA_PROJECT'
 10: m    1156 'Macros/VBA/blush'
 11:       839 'Macros/VBA/dir'
 12: M   16661 'Macros/VBA/fruitage'
 13:        97 'Macros/blush/\x01CompObj'
 14:       288 'Macros/blush/\x03VBFrame'
 15:       102 'Macros/blush/f'
 16:     12296 'Macros/blush/o'
 17:     72591 'WordDocument'

The analysis reveals a malicious file delivering Hancitor[1]. It's the same kind of document that the one analyzed by Brad a few days ago[2]. Besides the malicious code, what was interesting is this case is the fact that the attacker failed to properly protect his files and allowed directory indexing on the web server:

email|filename|ip

The filename is based on the email address (ex: firstname@domain.tld and UPS_firstname.doc). This is confirmed by VirusTotal where the same hash is referenced with multiple names:

It looks that the file visitor.txt contains all the victims who clicked on the link because the file was growing during my investigations. While redacting this diary, the file contains 11587 lines:

The second interesting file is called block.txt and contains IP addresses (1833 lines). It looks to be addresses used by major companies like Google or Amazon. I presume that visitors coming from one of these IP addresses won't be infected and redirected to a safe page.

What about the victims? They are mainly based in the United States:

Here are the top-20 targeted domains:

The most scaring fact is that such attack remains successful and people still visit suspicious websites. For the last 12 hours, I grabbed the file visitor.txt every 5 minutes and the number of victims what continuously growing (187 new lines):

I'll now have a deeper look at the list of blocked IP addresses and see if the content could be useful for another diary.

[1] https://www.virustotal.com/en/file/82e3ec80dde9adb2be1c3abe27c37940b3e0ff3b7f2b80b39e10aae540b1fb7a/analysis/
[2] https://isc.sans.edu/forums/diary/HancitorPonyVawtrak+malspam/21919

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