Best of the week – 5 febbraio 2012

by Matteo Cavallini on February 5, 2012

in SBN

Italy is frozen, in Rome the snow lays thick on the ground... but bad guys are relentless so, we need to stay informed.

Which are the best security news of the week? Here you can find my answer.

Hope you enjoy it!

@candolin2 FAQ about the VeriSign data breaches | Computerworld New Zealand computerworld.co.nz/news.nsf/secur… via @computerworldnz #verisign

@CiscoGGSG VeriSign hack: Reactions from the security community fb.me/1kSufkczk

@ProfWoodward  New computer incident handling guidelines drafted for comment by NIST in the US: csrc.nist.gov/publications/d… See what you think.

@metalabasia Rare interview with Gulshan Rai, head of CERT-In livemint.com/2012/01/312300… via @livemint #india #malware

@CERTXMCO [Blog XMCO] La cybercriminalité made in France --> cert.xmco.fr/blog/index.php…

@cuoretoro US spy agencies look to cloud computing lnkd.in/vK22iS


{ Comments on this entry are closed }

Links for 2012-02-04 [del.icio.us]

by Dr Anton Chuvakin Blog PERSONAL Blog on February 5, 2012

in SBN

{ Comments on this entry are closed }

Finding Evil: Automating Autoruns Analysis

by davehull on February 4, 2012

in SBN

You can buy appliances to put in your network in an effort to find evil on systems in your enterpise. I know a wicked smart individual who develops one such system and I strongly recommend you check them out, especially if you can afford them. The one I'm thinking of rhymes with "beer."

But let's say you didn't budget for one of these systems this year, there's still something you can cobble together using Autoruns, PsexecCygwin and VirusTotal. It may not be as effective or capable as the system that rhymes with "beer," but it's going to be useful. Let's get to it.

I've written about Autoruns before so if you're not familiar with it, check out the link above and this post about how attackers maintain persistence. Psexec is another Microsoft Sysinternals tool that you can use to execute commands on remote hosts. If you're an incident responder or system administrator, having the ability to "psexec" into remote systems is a must.

Cygwin is "a collection of tools which provide a Linux look and feel environment for Windows." If you follow the outstanding, Command Line Kung Fu Blog, you know well that what's relatively easy at the command line in Linux can be far more difficult to achieve using built in tools in Windows. Installing Cygwin will facilitate our little project here. Alternatively, if you have a Linux box, you can use it instead.

VirusTotal is an great service where you can upload binaries and have them scanned by 40+ antivirus tools to see if any of them recognize the binary as something malicious. Too many people don't know that in lieu of uploading a binary to VirusTotal, you can take an MD5, SHA1 or SHA256 hash of a binary and search for that value on the site. VirusTotal will return a report showing how many antivirus scanners recognize a file with that same hash as a malicious file. See the footnote at the end of this article for a reason why you may not want to immediately upload suspicious binaries to VirusTotal for analysis.

Conveniently, Autoruns can be configured to generate MD5, SHA1 and SHA256 hashes. Combine that chocolate, with the flavor that is VirusTotal and you've got yourself a nice bit of kit for finding evil. Where do Psexec and Cygwin fit into this? With Psexec and a for loop, we can collect Autoruns data from many hosts in a few minutes. Mind the wraps.

for /L %i in (1, 1, 254) do @psexec -s -n 4 -d \\n.n.n.%i cmd /c "net use o: 
\\server\share PASSWORD /user:doman\username &&
\\live.sysinternals.com\tools\autorunsc -a -v -f -c '*' >
o:n.n.n%i.csv && net use o: /delete"


Let's break this down. First the for loop is going to count from 1 to 254 and assign that value to the variable %i. Within the loop we run psexec with -s -n 4 and -d options, these will run commands on the remote system as SYSTEM, timeout after 4 seconds if it can't connect and lastly, -d runs the commands non-interactively, think of it as -d for "dropping" the command on the system and moving on.


Next is the IP address of the remote host -- \\n.n.n.%i. You can run this loop inside another loop to cover more than one octet at a time (i.e. \\n.n.%j.%i and so on). Next comes the command we want to run on the remote host, in this case it is a compound command (i.e. a command shell followed by another command (i.e. cmd /c...)). In this case, the compound command that follows first maps a drive to some share somewhere in your environment, this may require that you supply credentials, depending on how your environment is configured.


Having mapped the drive, we call Autorunsc (note the trailing c there indicates the command line version). The flags and arguments provided here, -a -v -f -c '*', have the following effects respectively: collect all Autoruns, verify certificates for signed code, create file hashes, write the output as comma separated values and lastly gather Autoruns data for all profiles on the system. We redirect the output to the drive that we mapped, naming the file for the IP address of the system that it came from and lastly, we delete the drive mapping.

Depending on how you do this, you'll have a single system's Autoruns data or the data from many systems. Now we want to analyze all of this data to see if we can find any malicious binaries in the mix. Since we told Autorunsc to verify signed code, we can make a possibly horrible decision and direct our attention to only the unsigned code. The assumption here is that only legit code will be signed and that malicious code will be unsigned. There have been examples of malicious code that was signed and I suspect the future will bring more and more of the same. But for demonstration purposes, I'm only going to analyze unsigned code.

If you have a single Autoruns output file, rename it to aruns.csv and drop it into the same directory as the following script, which you can download from my git repo. You'll need Cygwin or a system with bash, grep, awk and wget for this:
#!/bin/bash
# A working proof of concept, lacking many features

# Gather all hashes for unsigned code from autoruns csv output file named aruns.csv
grep -i "(Not Verified)" aruns.csv | awk -F, '{print $(NF-2)}' | sort | uniq > aruns_hashes

# Reduce the data set to hashes that aren't in our good list
if [ -e hashes_cleared ]; then
grep -vif hashes_cleared aruns_hashes > hashes2check
else
mv aruns_hashes hashes2check
fi

# Should create a list of bad hashes and check against it too
if [ -e hashes_evil ]; then
grep -if hashes_evil hashes2check > aruns_malware_hashes
fi

# Remove malware hashes from hashes2check
if [ -e aruns_malware_hashes ]; then
grep -vif aruns_malware_hashes hashes2check > vtsubmissions
else
mv hashes2check vtsubmissions
fi

# Search VirusTotal for reports on remaining hashes
echo "[+] $(wc -l vtsubmissions) hashes to check with Virus Total"
sleep 2
for i in $(cat vtsubmissions); do wget --header= -O $i.html --no-check-certificate \
https://www.virustotal.com/latest-scan/$i; sleep 15; done

# Check results for malware
grep -l "[1-9][0-9]* / " *.html | awk -F. '{print $1}' | tee -a aruns_malware_hashes \
>> hashes_evil

# Pull out malware entries from aruns.csv
grep -if aruns_malware_hashes aruns.csv > aruns_malware

# Check results for non-malicious files
grep -l "0 / " *.html | awk -F. '{print $1}' >> hashes_cleared

# Check for results tnat are unknown to VT
grep -li "not found" *.html | awk -F. '{print $1}' >> unknowns

# Pull unkown entries from aruns.csv
grep -if unknowns aruns.csv > aruns_unknown

# Report results
let j=$(wc -l aruns_malware)
echo "[+] VirusTotal shows $j Autoruns entries may be malicious."
echo "[+] Check the aruns_malware file for details."
let j=$(wc -l aruns_unknown)
echo "[+] VirusTotal has never seen $j Autoruns entries."
echo "[+] Check the aruns_unknown file for details."
echo
If you have a bunch of Autoruns output from multiple hosts, you can combine them with a little command line foo as follows:
cat n.n.n.* | sort | uniq > aruns.csv 
You'll need to edit this aruns.csv file and remove the header line created by Autorunsc, search for MD5 to find the header line. Now place that file in the same directory as the script above and you'll be all set.

What does the script above do? It pulls out all of the MD5 hashes for unsigned Autoruns, compares them against a list of known good hashes from previous runs, if this is your first run through with the script, the file won't exist and this will be skipped. Next it compares those hashes against hashes of known malicious files, again, if this is your first run, there will be nothing to compare against and this step will be skipped. Known malicious hashes will removed from the list and saved for later notification. Whatever hashes are left will be submitted to VirusTotal as search strings at the public API rate of four hashes per minute, the results from VirusTotal will be written to files named for the hashes with .html extensions added.

Once all the hashes have been submitted to VirusTotal, the script will search through all the results looking for any that were reported as malicious by the antivirus products. Those hashes will be written to the same file as any that had previously been marked as malicious.

Then the script looks through the html files for results where none of the antivirus products found the hash to match a malicious file, these hashes are saved into the hashes_cleared file and they will not be submitted to VirusTotal on future runs.

The script then searches through the results from VirusTotal for any reports that indicate no file with the provided hash has been submitted for analysis. These hashes are marked as unknowns and may warrant further analysis, possibly even submitting the files to VirusTotal (see the footnote below).

Finally, the script reports to the user how many of the hashes were reported to match malicious files and how many were unknown. It pulls these Autoruns entries from the aruns.csv file so you can have the reduced data set for analysis.

Below are some screen shots of the script, which I'm calling "lamelyzer.sh," pronounced lame-ah-lyzer:
Figure 1: lamelyzer's first run as evidenced by the lack of data files.
Figure 2: lamelyzer reports there are 114 hashes to submit to VirusTotal and begins making requests
Figure 3: Directory listing while lamelyzer is in progress. Each html file is a VirusTotal report.
Figure 4: lamelyzer has finished and is showing results.
Figure 5: Post execution directory listing of non-html files.

Figure 5 shows a directory listing after the lamelyzer script has finished. When we started there were two files, the script itself and the aruns.csv file. Now we have several new files, aruns_malware will contain the Autoruns entries that some antivirus product recognized as malicious; aruns_malware_hashes contains the hashes for those files; aruns_unknown contains those Autoruns entries that had MD5 hashes that didn't match any files that VirusTotal had seen before, these may warrant further investigation; hashes_cleared contains a list of hashes that have been scanned by antivirus products at VirusTotal and the results came back clean, in future runs, hashes matching entries in this file will not be submitted to VirusTotal; hashes_evil contains the hashes for files that VirusTotal said were malicious, in future runs hashes matching entries in this file will not be submitted to VirusTotal, they will however be reported to the user; unknowns contains the hashes for files VirusTotal hasn't seen before; and vtsubmissions contains the list of hashes that were submitted to VirusTotal.

On subsequent runs hashes will be appended to hashes_cleared and hashes_evil as appropriate. All the other data files will be overwritten. If you want to see what VirusTotal says about a particular file, open the corresponding html file in a web browser. When you're finished reviewing the results, delete the html files. The next time you need to analyze Autoruns output, copy it into the directory as aruns.csv and run lamelyzer again. Known good and bad files will be filtered out and reported accordingly, all others will be submitted to VirusTotal with results reported accordingly.

Figure 6: A subsequent run of lamelyzer with an aruns.csv with 838 entries, only 77 will be submitted to VirusTotal.

In Figure 6, I've collected another set of Autoruns data from multiple systems, 838 entries in total, but due to the existence of the hashes_evil and hashes_cleared files, only 77 of the 838 entries will have their hashes submitted to VirusTotal.

If you compile many sets of Autoruns data into one aruns.csv file, as I have, you can map a particular entry back to the host(s) that it came from by grepping through the original csv files for the hashes in question. Recall near the beginning of this post, the for loop that wrote Autoruns data to files named for the IP addresses of the hosts they came from, simply grep through those files for the hash in question.

I have to admit that lamelyzer was given its name because it was a hastily assembled proof of concept for a more robust tool I've been working on, but some folks that I'd talked to about it wanted more information on what I was planning to do. Rather than put together slides or whiteboard it, I spent a few minutes putting this script together. It works well enough, that I think many could put it to good use. I will still work on a more robust tool with more options, but wanted to get this out.

If you have any questions or comments, please don't hesitate to let me know.

* There are reasons why you should not immediately upload a potentially malicious file to VirusTotal. If I'm an attacker and I'm targeting your organization, I may create custom malware or repackage some existing malware in such a way that it has a unique set of MD5, SHA1 and SHA256 hashes. Once I've dropped my kit in your network, I can monitor VirusTotal by searching for my hashes. If VirusTotal comes back with a report for any one of those hashes, then I know someone has submitted the binary to VirusTotal (or there's a collision with another file) and therefore, I know that your organization has found my kit and that it's time for me to switch things up.

{ Comments on this entry are closed }

DNS Changer infrastructure shutdown is a *good* thing

by Chester Wisniewski on February 4, 2012

in SBN

The FBI may shutdown the DNS servers victims of the DNS Changer malware have been using on March 8th. Is this a dangerous action, or is five months to clean up your PC enough?

{ Comments on this entry are closed }

Wow, over a year since my last post. Work has been crazy and personal life is even worse. If any of you are wondering where i have been hiding head over to upSploit. Well I have just rebuilt my laptop to Xubuntu 11.10 as I could not stand the Unity on Ubuntu and decided to [...]

{ Comments on this entry are closed }

Clarifying The Trustwave CA Policy Update

by Nicholas J. Percoco on February 4, 2012

in SBN

We've seen a number of comments and questions on Twitter regarding a recent Trustwave CA Policy Update to our legal repository (https://ssl.trustwave.com/CA). This update discusses a subordinate root revocation. This is a proactive revocation, of the only certificate we issued for these purposes, that is the result of careful consideration in light of recent policy changes and the changing PKI landscape. 

This single certificate was issued for an internal corporate network customer and not to a 'government', 'ISP' or to 'law enforcement'.  It was to be used within a private network within a data loss prevention (DLP) system. The subordinate certificate was subject to a Certification Practice Statement (CPS), Subscriber Agreement and Relying Party Agreement crafted by Trustwave after an audit of the customer physical security, network security, and security policies. 
 
The system was created using dedicated hardware device designed for SSL proxy and acceleration, with a FIPS-140-2 Level 3 compliant Hardware Security Module (HSM) (http://en.wikipedia.org/wiki/Hardware_security_module) for subordinate root storage and for the purpose of private key generation of the re-signed SSL certificates. This means that once the trusted subordinate root was placed into the device it could not be extracted.
 
Additionally, when the system would accept an outbound SSL connection from within the customer network, and negotiate the session with the server outside the customers network, the private key for the resulting re-signed SSL certificate (that is presented to the internal network) would be generated in the HSM and only live for the duration of the SSL request. No party had access to the re-signed SSL certificate private keys at any time, nor could they gain access to them. This is what prevented the customer from being able to perform ad hoc issuance of certificate for any domain and use them outside of this hardware and infrastructure.
 
Trustwave has decided to be open about this decision as well as stating that we will no longer enable systems of this type and are effectively ending this short journey into this type of offering.
 
We take information security very seriously as a trusted CA and we felt that a few clarifications were in order to help everyone understand our actions.

{ Comments on this entry are closed }

  I just finished editing a podcast (Episode 10 for release Monday February 6th) where I got to sit down with Gene Kim, the guy who wrote the Visible Ops book - a staple of every good IT manger's bookshelf.  I can't help but write a little bit about one of the topics which just resonated with me based on some of my job history.  The idea of "blending in with the furniture" is one that I know many IT managers follow in organizations and situations where they feel they simply cannot succeed.  Let's break this down because I know many of you are feeling this pain.

{ Comments on this entry are closed }

Publish and/or perish

by p1 on February 4, 2012

in SBN

A new study notes that “scholarly” academic journals are forcing the people who want to publish in them (the journals) to add useless citations to the published articles.  OK, this may sound like more academic infighting.  (Q: Why are academic fights so bitter? A: Because the stakes are so small.)  But it actually has some fairly important implications.  These journals are, in many eyes, the elite of the publishing world.  These articles are peer-reviewed, which means they are tested by other experts before they are even published.  Therefore, many assume that if you see it in one of these journals, it’s so.

(The system isn’t pefect.  Ralph Merkle couldn’t get his paper on asymmetric encryption published because a reviewer felt it “wasn’t interesting.”  The greatest advance in crypto in 4,000 years and it wasn’t interesting?)

These are, of course, the same journals that are lobbying to have their monopoly business protected by the “Research Works Act,” among other things.  (The “Resarch Works Act” is a whole different kettle of anti-[open access|public domain|open source] intellectual property irrationality.)

I was, initially, a bit surprised by the study on forced citations.  After all, these are, supposedly, the guardians of truth.  Yes, OK, that’s naive.  I’ve published in magazines myself.  Not the refereed journals, perhaps: I’m not important enough for that.  But I’ve been asked for articles by many periodicals.  They’ve had all kinds of demands.  The one that I find most consistently annoying is that I provide graphics and images.  I’m a resarcher, not a designer: I don’t do graphics.  But, I recall one time that I was asked to do an article on a subject dear to my heart.  Because I felt strongly about it, I put a lot of work into it.  I was even willing to give them some graphics.  And, in the end, they rejected it.

Not enough quotes from vendors.

This is, of course, the same motivation as the forced citations.  In any periodical, you make money by selling advertising.  In trade rags, the ease of selling advertsing to vendors is determined by how much space you’ve given them in the supposed editorial content.  In the academic journals, the advertising rates are determined by the number of citations to articles you’ve previously published.  Hence, in both cases, the companies with the advertising budgets get to determine what actually gets published.

(As long as we’ve here, I have one more story, somewhat loosely related to publishing, citation, open access, and intellectual property.  On another occasion, I was asked to do a major article cluster on the history of computer viruses.  This topic is very dear to my heart, and I put in lots of time, lots of work, and even lots of graphics.  This group of articles got turned down as well.  The reason given in that case was that they had used a Web-based plagiarism detector on the stuff, and found that it was probably based on materials already on the net.  Well, of course it was.  I wrote most of the stuff on that topic that is already on the Web …)

DiggRedditSlashdotTwitThisSphinnStumbleUpondel.icio.usFacebookGoogleTechnoratiE-mail this story to a friend!

-

Let the experts make sure your website is safe. Vulnerability Assessment is the answer.

{ Comments on this entry are closed }

SSL for less than 7 Euros?! Yup…

by Miguel Almeida on February 4, 2012

in SBN

SSL for less than 7 Euros

As part of the activities that I've been developing for AP2SI I've just found this. And I could not resist sharing.

Yes, it's true that the cost of digital certificates is not, typically, very small. And this is one of the factors that have conditioned the widespread adoption of SSL on web servers, even though this mechanism would allow the authentication of those services, and would ensure the privacy of customer communications.

(The cost is not the only factor limiting the adoption of SSL, but it's surely a major factor, along with the performance.)

If you want to build more confidence in your Internet websites, or even in your intranet sites, Comodo has an offer with an unbeatable price, an offer that doesn't add the same degree of confidence of an EVS certificate, but that may be sufficient to meet your requirements.

Interested? Ok: PositiveSSL, through Namecheap, for less than €7.00 per year: namecheap.com/...

{ Comments on this entry are closed }

Medeco Nexgen XT

by About.com Business Security on February 4, 2012

in SBN

Mechanical locks tell no tales.

While a well thought out key control system is essential to your physical security plan, those mechanical deadbolts and door locks will never tell you who ...

Read Full Post

{ Comments on this entry are closed }