ISC Feature of the Week: How to Submit Firewall Logs

Published: 2012-01-03
Last Updated: 2012-01-04 14:43:30 UTC
by Adam Swanger (Version: 1)
2 comment(s)

Each week, usually on Tuesday, we are going to highlight an ISC/DShield site feature so all our users become more aware of all the great functionality that is available!

This week's ISC/DShield feature is How To Submit Your Firewall Logs To DShield and can be found at https://www.dshield.org/howto.html

Much of the reporting on the ISC/DShield websites is from data collected from users submitting firewall logs. There are many existing scripts and services available so chances are high that all you have to do to get started is a quick download and cron on your firewall.

 

Here's how it's done:

1. Signup is recommended for maximum benefits but not required. See the link below for all the added features an account will give you.

www.dshield.org/howto.html#signup

2. Find an existing script to load and cron on your firewall.

www.dshield.org/howto.html#clients

3. If, by chance, you don't find an existing client, you can write your own.

www.dshield.org/specs.html

 

Using the data:

1. Access the data and feeds.

www.dshield.org/feeds_doc.html

2. Browse the data results.

www.dshield.org/reports.html

 

That's a quick link list to get you started. If you can't find the details you're looking for on the website or have a question or comment, please drop us a note in the contact form isc.sans.edu/contact.html

--
Adam Swanger, Web Developer (GWEB)
Internet Storm Center (http://isc.sans.edu)

Keywords: ISC feature
2 comment(s)

The tale of obfuscated JavaScript continues

Published: 2012-01-03
Last Updated: 2012-01-03 09:37:04 UTC
by Bojan Zdrnja (Version: 1)
4 comment(s)

What better way to start a new year than with some JavaScript deobfuscation!

Couple of weeks ago, one of our readers, Rick, found a compromised server with an interesting “addon” planted by the attacker. The attacker added a relatively simple PHP script – nothing we have not seen before. The PHP script was more or less standard for such attacks: the first part checks the submitted User Agent as well as if the request came from a list of predefined network ranges (you probably guessed it – those that belong to search engines and AV companies). If this is true, the PHP script just displays a fake 404 not found error page.

You can see that part of the code, which is self explanatory in the picture below:

IP/UA checking part

Now, if this test passed, an interesting part comes. The PHP script simply prints a huge, heavily obfuscated and very nasty JavaScript blob.

This huge part is about 300 kb in size (!!!) so, as the first thing when encountering such JavaScript, I always try to use the wonderful Wepawet service (available at http://wepawet.iseclab.org/). In case you aren’t familiar with Wepawet, it allows you to submit JavaScript (and PDF and Flash) files for automatic analysis. During years, Wepawet became increasingly good in deobfuscation of such files so I was surprised to see that it failed to analyze the submitted JavaScript file. VirusTotal was no good either (as expected, 0/42). So time for some hacking ...

After trying typical tricks with defining parts of the document object (see more about these methods in Lenny’s diary at http://isc.sans.edu/diary.html?storyid=12157) I noticed that the JavaScript file I was analyzing depended on way too many properties/methods from the document object. While it is certainly possible to define all them, I decided to skip that tedious part and go directly with a debugger – after all, nothing gives you more thrills than the possibility to infect your own machine :) (of course, this was done in an isolated VM).

While people usually do not like analyzing such potentially malicious JavaScript files in Internet Explorer, I have to admit that I like the Internet Explorer’s developer tools addon *a lot*. So, to get this into a debugger, I normally paste the JavaScript file into a very simple HTML document that just defines the body. I also add the keyword “debugger;” to make sure that the debugger will stop at the beginning (so I don’t end up infecting my own machine). After this has been done, we just need to start debugging and open the HTML file in Internet Explorer. The Developer Tools will automatically break at the beginning:

Developer Tools

We can now easily go through the code, setup further break points and use all the Developer Tools’ powerful debugging options such as variable and call stack inspection. When I reached the end I was a bit disappointed – the JavaScript file tried to retrieve an URL that was not available any more. It also depended on certain elements in the original web page which was unavailable to me as well.

Back to obfuscation – while it managed to evade analysis in Wepawet, I remember that I’ve seen such methods before. If you have been a constant reader of SANS ISC you maybe remember the diary I wrote back in 2009: http://isc.sans.edu/diary.html?storyid=6142. The attackers used the same method here – very, very long and complex if/then/else statements which end up calling various DOM methods and properties. While this method has been known for a while, it is obviously still very effective, especially since it allows practically unlimited combinations that an attacker can use in order to obfuscate their malicious JavaScript code.

--
Bojan
INFIGO IS

 

4 comment(s)

Analysis of the Stratfor Password List

Published: 2012-01-03
Last Updated: 2012-01-03 02:50:05 UTC
by Rick Wanner (Version: 1)
11 comment(s)

As reported at the isc.sans.edu on Christmas Day by Deb Hale, Stratfor had personal data of its customers compromised, including a list of 860,000 passwords hashes. Today Steve Ragan over at thetechherald.com published an analysis of the password list.   There is nothing original about the methodology used.  It is very similar to what Marc Hofman described in his diary from late 2010 on measuring password security and most likely very similar to what the bad guys will use. Unfortunately Steve Ragan's analysis shows how poor Stratfor's password policy was, and how poor the passwords were in general. Nearly 10% of the passwords succumbed to cracking in under 5 hours. More importantly, this analysis reiterates the weakness of passwords in general, and the general failure of user education in good password creation and management, highlighting that the weakest link in security is the user.

It is clear that we need to continue to work on educating the users. The minimum we need to instil on our users is:

  • reiterate good password creation and management processes
  • discourage password reuse
  • promote the use of tools like Password Safe or Keepass

It may be a difficult battle, but lets try and win it one user at a time!

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

11 comment(s)

nmap 5.61TEST4 released

Published: 2012-01-03
Last Updated: 2012-01-03 02:11:20 UTC
by Rick Wanner (Version: 1)
0 comment(s)

For those of you following the development stream of nmap, an interesting release today.  nmap 5.61TEST4 has a number of interesting features.

  • a spidering library and associated scripts for  crawling websites.
  • 51 new NSE scripts, bringing the total to 297.
  • a substantial decrease in the size of the Mac OS X installer due to the removal of PPC support.
  • a new vulnerability management library which stores and reports found vulnerabilities.

More information can be found in the release notes.

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

Keywords: nmap
0 comment(s)

Comments


Diary Archives