Mozilla has released Firefox 10, inclusive of critical security fixes.

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

New: VMSA-2012-0001

Updated: VMSA-2011-0004.3

One practice I strongly suggest you undertake, for both yourselves and your organizations, is Open Source Intelligence (OSINT) gathering. OSINT is actively utilized as part of the reconnaissance phase for penetration testing. Assume the bad guys are doing it too, so add it to the list of tactics in which you need to be proficient so as to better defend yourselves. Per Sec. 931 of Public Law 109-163, or the National Defense Authorization Act for Fiscal Year 2006, OSINT is “intelligence that is produced from publicly available information and is collected, exploited, and disseminated in a timely manner to an appropriate audience for the purpose of addressing a specific intelligence requirement.” As a tool aficionado and regular author on tool topics I am occasionally faced with a scenario we in the information security practices struggle with at times. Some of the tools I discuss and espouse are as easily used for evil as they are for good.  I’ve seen very recent evidence of this as it pertains to articles I’ve written about OSINT tools FOCA and Maltego.  Quoting the Roman philosopher Seneca the Younger, “A sword never kills anybody; it’s a tool in the killer’s hand.” As one who would rather see the sword in the good guy’s hand, I was recently asked by a fellow white hat if there is an elegant way to export FOCA results for direct import into Maltego. The short answer is no, so I endeavored to solve the problem. FOCA includes the option to Save log to File resulting in a tab separated values text file inclusive of Time, Source, Severity, and Message. As an example, from a FOCA analysis of my domain, log file output resembles:

11:25:23 PM   ShodanSearch   medium   Found IP Information 70.40.197.37

8:50:18 AM   DNSCommonNames   medium   [74.220.195.31] Found subdomain blog.holisticinfosec.org

The fundamental challenge with taking this output from FOCA and importing it into Maltego is that there are no readily consumable entities. Maltego now imports CSV files quite nicely but again the CSV must be formatted accordingly where column content matches an entity type in order to conduct transforms To solve this little problem I wrote two down and dirty little PowerShell scripts using regex to parse unique IP addresses (ipAddress.ps1) or unique domain names (URI.ps1) from a FOCA log and write results to a CSV for import into Maltego. Grab them from the foca2maltego CodePlex project site. Yes, PowerShell favors Windows users; feel free to rip and replace for use in Python or your preferred scripting venue.

1. From a PowerShell prompt run .\ipAddress.ps1 or .\URI.ps1. You’ll be asked to provide the path to your FOCA log file then the script will write a CSV file to your working directory (IP_parsed.csv or domain_parsed.csv).
2. In Maltego, click the Maltego menu icon then Import | Import graph from table… | select CSV from the file type drop down menu | select CSV created by script | click on unmapped column to highlight it & select appropriate entity type (Domain,  DNS Name, IPv4 Address, etc.) then Next | keep default in Sampling window & click Next | click Finish.
3. Once all the entities populate the Maltego UI (there may be many if your FOCA output was extensive), you can select them in groups or as individuals to conduct further analysis and establish possible relationships.

The regex is really lean and probably overly simple. As an example \b(?:[a-z0-9]+(?:-[a-z0-9]+)*\.)+[a-z]{2,}\b for domain name parsing misinterprets .txt or .pdf in a full URI for a file as a TLD. As such, I built a not match exclusion for PDF, as an example. Feel free to expand on it as you see fit. I also dropped the ShodanHQ name space and URLs from the FOCA output as there is an entire Shodan toolkit for Maltego. Given my poor excuse for scripting and development skills you may likely find shortcomings or better ways to solve the task. Do feel free to enlighten me and our readers via the comments form. I’ll keep tuning, look for other entity opportunities, and create similar Python options to add to the project site; you’re welcome to contribute. 

A reader (Thanks Jim!) mentioned earlier today that his SSH logs were showing access attempts utilising elements of the reverse DNS name of the IP address being accessed.  For example using  isc.sans.org results in the userids isc, sans and org. This may be cause a number of hosting providers use the domain name itself as the userid for shell access for customers.  In light of the breach at dreamhost earlier this week http://blog.dreamhost.com/2012/01/21/security-update/ this may be what is going on. 

If you are noticing the same in your logs and you can share some log lines please send some in as I'd be interested in taking a peek.

Mark H

In case you missed it there is a vulnerability in the CISCO Ironport telnet service. Details can be found here http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120126-ironport

To mitigate the risk (if you can't upgrade just yet) is to switch off telnet on the device and use SSH to manage it instead.

Mark H

Symantec released a patch for pcAnywhere products that fixes couple of vulnerabilities, among which the most dangerous one allows remote code execution. You can see Symantec’s advisory here.

Now, for last couple of weeks there have been a lot of rumors about source code of several Symantec’s products that got stolen by yet unknown hackers. Besides a post that listed file names nothing else has been released in public yet, as far as we know.

However, Symantec also released a document (available here) that details security recommendations for pcAnywhere users. It is obvious that Symantec is aware of how critical published vulnerabilities are. It makes us wonder if there already have been active exploitation of the published vulnerabilities or Symantec is just extra careful?

We’ll keep an eye on this, and if you are a pcAnywhere user – PATCH NOW.

Update

And a short update: according to DShield data it appears that someone started scanning around for services on port 5631 (pcAnywhere). While the number of sources is still relatively low (indicating a single scanner, or a small number of them), the number of targets is pretty high. See for yourself here.

Update 2

Just further to the information Bojan has already provided.  Keep in mind that pcAnywhere is part of a number of Symantec products including backup, security and of course it is part of the Altiris management suite. - MH

--
Bojan
INFIGO IS

Overview
Need to attribute information to ISC? Want to provide users with an avenue to visit the ISC site? Want to link directly to the ISC Stormcast, Infocon or other information? These methods and more are listed on out ISC Linkback Page! https://isc.sans.edu/linkback.html

Features

• Various text only links and terms: ISC, Stormcast, Log Submission http://isc.sans.edu/linkback.html#text

• Show an ISC image logo for your link back to ISC: Homepage, Stormcast http://isc.sans.edu/linkback.html#image

• ISC Inforcon status image http://isc.sans.edu/linkback.html#other

Note
This works as DShield also. Just view the dshield.org url http://dshield.org/linkback.html

Don't see a link you'd like to use? Suggest in the comments section below or send any questions or comments in the contact form https://isc.sans.edu/contact.html

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

NetBIOS, and its weaknesses that allow extremely easy spoofing have been well known all the way since 2005. I recently discussed NetBIOS with a colleague of mine, Arcel, and this discussion prompted me to see if anything changed with NetBIOS and recent Windows releases.

While I was almost certain that the old NetBIOS spoofing attacks do not work any more, I was stunned to see that even the latest and greatest Windows 7 still enable NetBIOS over TCP/IP by default.

In today’s interconnected world, where we jump from one (wireless) network to another, this might have serious impacts on our security. The question is it time to get rid of NetBIOS sounds logical. Let’s see what’s happening here.
Starting with Windows 2000, all Windows operating systems (XP, 2003, Vista, 7, 2008) depend mainly on DNS to resolve network names. However, if DNS is not working, or the name cannot be resolved, Windows will try to use NetBIOS to resolve such network name.

Now, if a WINS server has been configured this should not be a problem, but in case when a WINS server is not present (or available), Windows will still try to use NetBIOS to resolve a network name. In such cases, Windows will send a NetBIOS Name Query packet, which is an UDP packet sent to a broadcast address. You can see one such packet in the screenshot below:

You can probably guess what an attacker can do – since this is a broadcast packet, the attacker does not even need to perform other initial attacks such as ARP poisoning. He can simply send a NetBIOS Name Query Response with any contents he wants! As a matter of fact, even a Metasploit module exists that does this automatically (see auxiliary/spoof/nbns/nbns_response).

Now, the question that we have to think about is what attack scenarios are we dealing with here? Here come a few, judge for yourself how serious they are:

1. Whenever a user mistypes a network name, the attacker can spoof the response. Depending on what the user tries to access (i.e. a SMB share or a web page), the attacker can use another Metasploit module in order to catch exchanged credentials. Keep in mind, though, that only hashes are exchanged here so the attacker still needs to crack the original user’s password (or try to perform some relaying attacks).
    
2. One of the names that is particularly sensitive is WPAD. It is used by web browsers for automatic retrieval of proxy settings. In a scenario where we connect to an open wireless network, where the local DNS server does not have this name registered, an attacker can spoof the WPAD’s entry’s IP address and further even serve a fake wpad.dat file. This would allow him to inspect the victim’s web traffic!
    
3. A lot of companies like to set their user’s home page in browsers (i.e. Internet Explorer’s home page). Now, when the user opens Internet Explorer on a malicious network, Internet Explorer will try to resolve that name. Since that name is usually something like “intranet” or “intranetweb” DNS will , of course, fail to resolve it. This gives the attacker an opportunity to fake this name. And what’s even worse, Internet Explorer will automatically send user’s credentials to the resolved web page, since it will consider it to be in the Local Intranet zone. The picture below shows my fully patched Windows 7 machine falling prey for this attack and trying to retrieve wpad.dat as well as giving my test account’s credentials when I opened http://intranet:

As you can see from the scenarios mentioned above, this “vulnerability” can be extremely serious. To make things even worse, if you use an older operating system such as Windows XP, and you haven’t disabled LANMAN (LM) hashes, cracking them in such a case is trivial. Luckily, as you can see in the picture above, Windows Vista and above disable LANMAN hashes by default, so only much stronger NTLMv2 is used. Still, if your password policy is inadequate, an attacker can crack such passwords.

So what can we do to protect ourselves and our users against this? This is one of those times when auditors that bug you about settings and configuration are really right:

1. Unless you moved everything to Windows Vista or newer, make sure you disable LANMAN hashes. They are insecure and should not be used under any circumstances.
    
2. Disable NetBIOS over TCP/IP. I don’t think that anything really uses this any more (if I’m wrong let us know please!)

If you want to learn more about this attack, read the excellent post at http://www.packetstan.com/2011/03/nbns-spoofing-on-your-way-to-world.html and, once you get scared enough, take care of your network and users.

--
Bojan
INFIGO IS

We got an email to the list today that got me to thinking.  Alyce was concerned because of "Attacks" toward her computer that were being logged by the firewall that is part of the locally installed antivirus suite.  Alyce wisely checks the history and logs section on a fairly regular basis but admits to being a novice.  Recently Alyce observed that about every ten minutes the same IP was trying different attacks to gain access to the computer.  As was stated in the email "I know that no one is going to jump through my computer screen, but it is scaring me..."

It is scary to know traffic coming toward your system is not friendly.  The internet is not a safe, nice place where you can leave your computer open and no one will bother it.  However, if you keep your system patched, run antivirus software and have your firewall turned on, you are pretty safe from the externally initiated attacks that are aimed at your system.  Most tools are automated and are looking for home systems with vulnerabilities.  There are far to many open and unprotected system's out there to go after then trying to compromise one that takes effort.

The bigger worry actually comes from what the user at the keyboard is doing.  Currently as I write this, I have to make a decision as to whether I should rebuild my box.  I keep it patched and locked down to what I need.  I don't run as administrator and I run a firewall and antivirus software.  All of this it seems, could not save my computer from one of my kids who got on it to surf around the internet. It appears they have picked up something on their travels as my computer is not running right.  Even through all the lectures of not clicking on every link out there just because Google returned it, the message still did not get through.  The attackers don't have to break in if you open the door for them. 

Trying to teach the user community to be careful of where they go and what they click on seems to be a never ending saga.  How many years have we spent trying to educate the end users?  I have a couple of family members that unintentionally keep creating their own malware zoo on their computers.  No matter how much I try to caution and explain, it obviously isn't getting through.  I'm sure many of you have the same problem and similar users.  The problem is trying to bridge the gap between those who work in the computer world and those who just use it.  So, I would like to compile a simple, best practice list for safe internet travels for the "non computer savvy" home/work user.  If you have any recommendations for best practices/advice for this list, please send them in and I will compile the results.  I'll post the results of this in a diary next week.      

  Last week's denial of service attack agains the Department of Justice (justice.gov), the FBI (fbi.gov) and other sites didn't just rely on Anonymous's favorite tool Low Orbit Ion Canon. Instead, a new method was employed to recruit denial of service clients.

  The new method uses some pretty simple javascript to launch the attack. The folowers are usually requested to visit a particular web page. The page includes a simple form to adjust the denial of service attack parameters but just launches the attack with default parameters as the page is opened in the browser.

  IMPORTANT: The script will start running as soon as the user vists the page. You do not have to press the "fire" button.

  Javascript code retrieving the parameters:

var fireInterval;
var isFiring = false;
var currentTime = new Date()
var lastSuccess = currentTime.getTime();
var requestedCtrNode = document.getElementById("requestedCtr"),
succeededCtrNode = document.getElementById("succeededCtr"),
failedCtrNode = document.getElementById("failedCtr"),
targetURLNode = document.getElementById("targetURL")
...

   an unused part of the code hints at plans to implement a hash table, likely to exploit the recently discussed hashtable denial of service vulnerability

var requestsHT = {}; // requests hash table, may come in handy later

  Originally, I figured the attack may take advantage of XMLHTTPRequest. Instead, the code takes a simpler route. It just changes an image URL to a URL on the attacked page. I suspect that this method is more reliable as it does not require the client to implement XMLHTTPrequest Level 2 or XDomainrequest but should work with pretty much any client.

It will not necessarily retrieve an actual image, but just whatever URL was targeted, followed by an "id" parameter and a "msg" (which is also set by the user). This format should make it pretty easy to filter the attacks at a web application firewall. Even other content sensitive firewalls should be able to deal with this.

Sample weblog:

GET /?id=1327271393334&msg=No%20A%20la%20CENSURA%20EN%20INTERNET%A1%A1%A1 
 HTTP/1.1" 200 8395 

  In order to prevent crashing the browser, the script will limit the number of outstanding requests. The script attempts to send 5,000 requests per second. I tested it directing my requests to a lab web server across a pretty slow VPN connection. It managed to create about 5 requests per second. The referer for the request will be the URL of the attack page. The user's user agent is not altered. 

 Update: Spiderlabs did a nice analysis of this tool, including other "LOIC" variants just about a year ago: blog.spiderlabs.com/2011/01/loic-ddos-analysis-and-detection.html

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

In October 2011 [1], I released an update for the main parser script used to generate the BIND/PowerDNS configuration files. This release of the sinkhole_parser.sh script contains some important fixes, including a rewrite of the section that parses the multiple sites into 2 separate lists: site_specific_sinkhole.conf (host web list) and entire_domain_sinkhole.conf (domain wildcard web list). The script contains new lists that were not part of the 7 July 2011 release.

The script contains a fix for parsing and loading records into PowerDNS database where sometimes it would fail indicating that a record was already loaded. It has been fixed in both the sinkhole_parser.sh and powerdns_sinkhole_logs.sh (located in /usr/local/sbin) used in Webmin to load records from the GUI.

A new script, search.sh (/root/scripts) has been added to provide a search capability in Webmin (two files copied to /etc/webmin/dns-sinkhole) of the BIND DNS Sinkhole lists to verify if a particular host or domain is listed in the sinkhole.

The script is available on the handler's server here with the MD5 here. You can either untar the tarball in / or move the scripts in the location indicated in this diary.

[1] http://isc.sans.edu/diary.html?storyid=11818
[2] http://handlers.dshield.org/gbruneau/
[3] http://handlers.dshield.org/gbruneau/dns-sinkhole/dns-sinkhole-scripts.tgz

-----------

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

A comment on one of the articles earlier this week prompted me to dig around privacy legislation from various part of the planet, only to realise what a mess it is and I should probably just have mowed the lawn instead. It would have been easier on the brain.  So just to give you something to think about over the weekend, or discuss at a BBQ. Is an IP address personal data? If you are in a rush, the conclusion I came to was "it depends".    

Just before we go on I will start all of this with "I am not a lawyer" (IANAL), just a security guy trying to make sense of things and likely getting some of it wrong. So if you have a need to know for sure, I suggest you ask a lawyer.

Before we get to IP addresses we'll need to define what personal data is. This seems to be fairly consistent between countries. This is likely because most privacy legislation is based on the OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data  first adopted in 1980 after almost 10 years of discussion.  Generally the definition of Personal data boils down to any information that can identify a particular individual.  Some countries expand this by explicitly stating things such as race, religion, sex and other information that most of us would consider personal. 

From an IP address perspective, do IP addresses fit that definition? This is where it starts getting very muddy. It appears that in some countries the answer is yes and in others it is no. To add a third option, some countries go with, only if it is combined with other items that identify a person. 

When we started discussing this Swa, one of the other handlers pointed out this document "Study of case law on the circumstances in which IP addresses are considered personal data"   It is a study of the various laws in the EU and how they relate to the EU directives regarding privacy (page 16 especially).   The rest of the document is a good read, but the table on page 16 makes it very clear how confused privacy laws can be.  The table shows, for example that in Austria there is no doubt, IP addresses are personal data. In the Netherlands they are not. In Bulgaria it is when combined with other information. In Italy it most certainly is. As for the rest of the world? In the US the answer seems to be no it isn't.  In AU, the approach tends to be, when combined with other personal data it is. If you happened to know your local situation add it to the comments.

When I read the study from Timelex other questions popped into my head. So if IP addresses are Personal Data can I have web logs? Can I use a third party to track visits? Probably not, at least not if I'm based in those countries that say IP Addresses are personal data. Mind you many countries do have exemptions for research and security related activities, so sharing log extract, etc is still OK (remember IANAL so check if you need to be certain).

Other questions that popped in. Can I outsource to other countries? Maybe I can share the data with them, but can they give it back? Whose laws apply when I place stuff in the cloud? For example the ammendments to India's laws, according to informationweek.com,  applies to data collected in India, but also data provided by overseas companies. What if you are a multinational? Which privacy laws apply?

Plenty to think about and I'm not suggesting that we should all become privacy experts or international privacy lawyers. What I am suggesting, however, is that you may need to point out that it needs to be thought about. After all our job is to help protect the organisation from risk. 

If you want more info Wikipedia has some good links from their Privacy Law page.  Some of the other resources around:

• OECD Privacy Principles
• OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data
• AU - http://www.privacy.gov.au
• EU - http://europa.eu/legislation_summaries/information_society/data_protection/l14012_en.htm
• UK - http://www.ico.gov.uk/
• HK - http://www.pcpd.org.hk
• CA - http://www.priv.gc.ca/

If you have some resources, preferably from official bodies, that you think others should know about, add them to the comments or send them in.

Enjoy the weekend.

Mark H

You’ve rocked up to work ready to start the day and get on with the list of jobs the boss has graciously gifted you with, when your daily routing of reviewing the logs brings the normal sigh as x.x.x.x is externally scanning and probing for open ports on the perimeter.

Depending on the security stance or care factor the offending IP address may go in a block list, be ignored, be investigated further or none of the above. Let’s say that you want to report this so you do a quick WHOIS lookup on the offending IP address. There are plenty of web sites that offer WHOIS lookups but if you want to perform searches from the command line Swa Frantzen’s guide [1] is a great refresher.

This is where you can run in to a very frustrating road block of the Useless Contact Email Details. The two worst offenders are the fake email addresses (none@nowhere.com being a favourite) or the horribly out of date email address of that goes deep into cyber space never to be seen again. One of the fun parts about being on the defensive team is trying to work out if it’s worthwhile telling someone their computers aren’t playing nice any more. So make it easy for them to do that and if someone makes that effort, be a good internet citizen and have a valid, current email address on the WHOIS record.

NOTE – Before the screaming and tearing of hair occurs because I’m advocating putting a valid email address that can be use be the evil smurfs gain information on you or the company, feel free to use on of the numerous WHOIS protection services that shields your email behind one of their email addresses. As long as the email gets to you, that’s all that matters.

Fixing WHOIS record details is easy and straightforward*, so get it done and tick off that New Year’s resolution to help out the internet.

Oh, and should you get a call from someone notifying that something might be wrong with your systems, fellow handler Tom Liston came up with a fairly comprehensive list on how not to response to someone giving you the heads up [2].


[1] http://isc.sans.edu/diary.html?storyid=9325
[2] http://isc.sans.edu/diary.html?storyid=1260

* Unless you work for a big, very big company, so get raised a work ticket and have some poor soul work out how to do it and treat yourself to something nice.

Chris Mohan --- Internet Storm Center Handler on Duty

   In my DNS server query logs, I am starting to see more queries using mixed case, like for example:

jOHanNEs.HoMePC.OrG
www.HOMEPC.ORg
wWW.Homepc.org
Www.HoMepC.ORg
WwW.homepc.ORg
WwW.HOmepc.oRG
WWw.homePc.oRg

   These queries appear to be the result of DNS servers supporting a relatively new DNS security mechanism, "0x20 Bit encoding". The approach got its name from encoding a bit value using the case of letters. if bit 0x20 is set in a byte, the letter is lower case. If it is cleared, the letter is upper case.

For example, the first value show above ( www.HOMEPC.ORg ) represents a value of 11100000001 . How does this help DNS security? Host names are not case sensitive. However, the case is maintained. The answer will use the same mixed case as the query. For example:

> dig WwW.HoMePc.OrG 

; <<>> DiG 9.7.3-P3 <<>> WwW.HoMePc.OrG 
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15335
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;WwW.HoMePc.OrG. IN A

;; ANSWER SECTION:
WwW.HoMePc.OrG. 100 IN A 70.91.145.9
.. [rest of answer omited] ...

As it turns out, almost all DNS servers follow this behaviour. The new part is that now some DNS servers start to deliveratly encode a random value into each query they send, and then verify if the value is maintained in the response. This in effect adds additional bits to the query id.

While this is clearly a "hack", it is a pretty attractive one. If your DNS server supports this feature, it will automatically gain a few more bits of "spoofing resistance". The DNS servers it connects to do not need to change anything. Unlike for DNSSEC, which is of course the real fix, but requires extensive work to configure,and has to be configured for each zone.

Right now, none of the major DNS servers appear to support this feature. A Google search only found two pieces of software that do:

Unbound: https://calomel.org/unbound_dns.html: see "use-caps-for-id"
pydig: http://www.huque.com/software/pydig/ 

I would be interested to learn if there are other DNS servers (or DNS related software) that supports this method.

References:
http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
http://courses.isi.jhu.edu/netsec/papers/increased_dns_resistance.pdf

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

The 404Project is a simple snippet of code you add to your 404 error page that submits information back to ISC for reporting. The main purpose of this project is to trend the web pages crawlers and automated bots are trying to access. A public report page will be available when enough data had been collected. isc.sans.edu/tools/404project.html

Overview
The 404Project submits URI, IP and USER AGENT. Additionally, date, time and your credentials are stored along with the data. Your personal information is protected https://isc.sans.edu/privacy.html#4 and your specific user information is not shared with third parties. https://isc.sans.edu/privacy.html#1
 

Instructions
- You must have an ISC Portal ID and Identification Key to use this tool. https://isc.sans.edu/login.html
- Once logged in and submitting data, you can view your 404 summary information. https://isc.sans.edu/my404.html
- Get started! https://isc.sans.edu/tools/404project.html#instructions

Our skilled users have ported the 404Project to many languages! At the time of this writing, in addition to the original PHP, there is also Perl, Python, .NET and even Javascript! https://isc.sans.edu/tools/404project.html#alternatives

You can leave comments in the section below or send any questions or comments in the contact form https://isc.sans.edu/contact.html

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

The online retailer Zappos announced yesterday a breach to their systems and has expired all password accounts on zappos.com.  There is a letter to employees from Zappos CEO available on zappos.com.[1]  They are urging all customers to change their zappos account password immediately [2], also do so on accounts elsewhere if your password is in sync.  

It is also being reported they have turned off company phones and request inquires be sent to email, as their phone system capacity is not capable of the high volume.[3]   ISC Handlers outside the US have reported they are unable to get to the Zappos.com sites.  It appears they have opened things back up for some non-US traffic, but all traffic is not open as of this writing.

I have not read any report on this issue that indicates what day the incident was discovered.  There are also no avaialble details on how long the breach was active before being discovered by Zappos staff.  However, if basic incident handling protocols are being used for this incident, then it appears the discovery of the incident is only "days" old, and not "weeks" or more.  If this is true, I applaud Zappos for coming clean as quickly as possible.  Far too many companies wait too long to notify their customer base. 

If anyone has details they can share or reports that provide any further info, then feel free to post a comment or send it in to us directly.    

[1] http://blogs.zappos.com/securityemai
[2] http://www.zappos.com/passwordchange
[3] http://www.eweek.com/c/a/Security/Zappos-Latest-Company-Hit-by-Data-Breach-581979/
  

Antony Elmar owns quite a few domain names. He lives in a lovely city called "Kansas, US", but seems to make his home there on a park bench, because he doesn't have a street address. On the upside, the park bench does have a phone extension, but one with a phone number that is a tad odd for "Kansas, US" and has a dial prefix that looks more like Italy:

Domain Name:EVORMCORP  .IN
Created On:14-Jan-2012 00:01:08 UTC
Last Updated On:14-Jan-2012 00:01:10 UTC
Expiration Date:14-Jan-2013 00:01:08 UTC
Registrar:Directi Web Services Pvt. Ltd. (R118-AFIN)
Registrant Name:Antony Elmar
Registrant Organization:N/A
Registrant Street1:none
Registrant City:Kansas
Registrant State/Province:
Registrant Postal Code:67420
Registrant Country:US
Registrant Phone:+3.976639877

None of this fazes the domain name registrar "Directi Web Services" in Mumbai, India, to the least. And Antony has been busy - he bought a dozen or so new domains over the past two days, and managed to bring them live within a matter of minutes after purchase.

His new domains currently point to 89.187.53.237, in Moldova. Yup, ol'Antony is quite the international business executive, conducting his trade on three continents with equal ease! The IP used seems to change about once per week, until past Thursday, Antony's virtual HQ was at the neighboring IP, 89.187.53.238.

His latest new domains include

cyberendbaj .in
cyberevorm .in
endbaj .in
endbajcomp .in
evorm .in
evormhost .in
evormcorp .in

and provide a generous helping of malware to users unlucky enough to get redirected there via what appears to be poisoned ads on legitimate web pages. Antony's toys currently seem to use URLs with a certain pattern that you can search for in your web logs with a command like egrep -E '\/.{8}\/\?[[:xdigit:]]{60}'

Example result from earlier today: 
http://endbajcomp. in/rgy9hcgw/?1a4c39a0370ad0f641cc790b5d0acdb24eba0f2d2483b98b4076689a4684

Caveat - that regexp might of course also match on perfectly benign web site URLs.

The malware uses CVE-2010-0842 (javax.sound.midi) and CVE-2011-3544 (Rhino script engine) and when successful seems to download an executable off a URL that matches egrep -E '\/.{8}\/\?[[:xdigit:]]{60};[0-9];[0-9]'

If you find anything of interest in your logs, please let us know via the contact form, or comment below. 

We have received some strange DNS traffic sample Type A query that isn't your typical DNS format. The DNS query has some fields that do change are marked with a X (see DNS query pattern). Other format/pattern may exist since the capture was based on a very short capture. We are trying to establish what this traffic maybe doing, whether it is a messed up DNS resolver, some sort of command and control or covert channel.

If you have seen this type of DNS query with this kind of behavior, we would like to hear from you.

DNS Query Pattern

XXXXXXaaaaXXX0000pjaaaabaafaejam

Sample Queries

omchikaaaaerd0000pjaaaabaafaejam: type A, class IN
ibjegdaaaaerd0000pjaaaabaafaejam: type A, class IN
ehjjafaaaaesx0000pjaaaabaafaejam: type A, class IN
dlegnhaaaaern0000pjaaaabaafaejam: type A, class IN
cfdnnoaaaaern0000pjaaaabaafaejam: type A, class IN

-----------

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

Yesterday ICANN started accepting applications for new generic top-level domains (gTLDs). "The world of .com, .gov, .org and 19 other gTLDs will soon be expanded to include all types of words in many different languages. For the first time generic TLDs can include words in non-Latin languages, such as Cyrillic, Chinese or Arabic." [1]

Last month, the US Federal Trade Commission indicated it has concerns with this change, they are concerned that consumer protection safeguard against bad actors that could lead to potential risk of abuse through existing scams such as phishing sites. [2]

Do you see these changes have a potential for concern and abuse or just business as usual?

[1] http://www.icann.org/en/announcements/announcement-11jan12-en.htm
[2] http://www.ftc.gov/os/closings/publicltrs/111216letter-to-icann.pdf
[3] http://newgtlds.icann.org/en/
 

-----------

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

Say you’re writing a long Windows CMD script, something like an audit script that’ll take a good 20-30 minutes to complete.

Now say the whole script is being redirected to a report file - as scripts get more complicated, I'm finding that almost everything I write ends up doing this.  Something like below (just to pick a random SEC579 example):

audit-esx.cmd servername userid password > reportfile.html

If all goes well, you see *nothing* on your screen for the next 20+ minutes (unless you’ve got a good port of tee available) – but if it gets stuck, it's going to be 20+ minutes, or likely longer, before you realize that your script is borked …

What to do? What to do? - - Use STDERR !

As the script goes through, insert an echo for each test (or meaningful phase) in your script to STDERR:

echo Audit Check SomeMeaningfulName >&2

or, if you’ve parameterized your script enough:

echo Check %CHK% >&2

"&2" means "send this to STDERR".

So, instead of a blank screen as the audit runs, the screen will be a show you useful info on it's progress:

C:\sans\sec579\audit>audit-vms esx01.sec579.com root Passw0rd > esx01-audit-vms.html
Audit Check VMX01
Audit Check VMX02
Audit Check VMX10
Audit Check VMX11
Audit Check VMX12
Audit Check VMX20
Audit Check VMX21
Audit Check VMX22
… and so on, until it's done

Another neat trick will allow you to echo to a file AND to STDERR in windows.  The example below will take the output of "somecommand", echo it to STDERR (which you'll see on the screen), and also echo it to the file "outputfile.txt"

somecommand > &2 > outputfile.txt

In linux, I'd normally do this using "tee" as mentioned, mostly because I'm lazy.  The problem in this case with using tee is that it goes to STDOUT, rather than to STDERR, so if you're using it in combination with other redirection, you may not get what you expect:

somecommand | tee outputfile.txt

To fix this, you might string your command serially with cat, but that means that you won't see the command output on STDERR until the command is completely finished, rather than in (more or less) real time.

somecommand > outputfile.txt ; cat outputfile.txt >&2

To see everything at the same time, I'll still use tee, but we'll also use a temp file descriptor (3) and dump the STDOUT output of tee to STDERR, as shown below

(somecommand | tee outfile.txt) 3>&2

I hope this was useful - if you've got a neat take on using STDERR, or STDIN or STDOUT for that matter, in Windows (or *nix) scripts, by all means pass them along in our comment form !

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

This is a follow-on to last week's How to Submit Firewall Logs feature (https://isc.sans.edu/diary/ISC+Feature+of+the+Week+How+to+Submit+Firewall+Logs/12316). This week we detail how to access data with the DShield API and its components. Last week was the HOW, this week highlights the WHY you should setup a DShield log submission script.

Our API gives you a look at detail and summary data from the DShield system plus a few extras from ISC! In order to make accessing all this data easier, the API interface you can use manually or script. Be careful, repeated excessive access might get ya locked out so please use responsibly. :)

Overview
There are four(4) output formats (xml, json, text, php) available by adding ?[format] to the end of the API url. For example if you want plain text to parse in a script, you would add ?text like http://isc.sans.edu/api/handler?text

The main page lists all the functions, parameters and description https://isc.sans.edu/api/ Here's a quick list of what's currently available.

Functions
  1. backscatter - only includes "syn ack" data and is summarized by source port
  2. handler - current Handler of the Day
  3. infocon - current infocon level
  4. ip - summary info of a given IP
  5. port - summary info of a given port
  6. portdate - summary for a given port on a given date
  7. topports - summary info for top ports on a given date
  8. topips - summary info for top IPs on a given date
  9. porthistory - summary info per port for a given date range

As a bonus, Dr. J will be highlighting the API as part of this months ISC Threat Update at https://www.sans.org/webcasts/isc-threat-update-20120111-94999 (If you miss the live broadcast, you can watch the recording at a later time)

You can leave comments in the section below or send any questions or comments in the contact form isc.sans.edu/contact.html

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

Adobe has released 1 bulletin today.

This updates Adobe products to the following versions:

• Adobe Reader and Acrobat
  • 10.1.1 and previous

APSB11-30 and APSA11-04 were also updated.

Next scheduled Adobe security update is 10 April 2012.

Cheers,
Adrien de Beaupré
intru-shun.ca

Overview of the January 2012 Microsoft patches and their status.

Cheers,
Adrien de Beaupré
intru-shun.ca

If you have not patched yet for vulnerability MS11-100 you might want to do it ASAP, because the DoS PoC exploit for this vulnerability has been published two days ago.

More information about the vulnerability and patches at http://technet.microsoft.com/en-us/security/bulletin/ms11-100

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

One of the major concerns of a public utility security issues applicable to securing SCADA systems of energy, gas and water supply. Manufacturers have responded slowly to this challenge and we can see traffic assurance deployments like HP with its TippingPoint IPS and Fortinet. The complex point of these solutions is that their cost is quite remarkable and some of them do not have enough functionality.

Fortunately, the Sourcefire guys began to include support for SCADA protocols within Snort from version 2.9.2 and started with the electrical substations protocols DNP3 and Modbus.

Check out one of my previous SCADA diary for basic definitions. I made some test myself with this functionality and I found very useful the following features to increase the valuable alerts within the SCADA Network:

•  Check for broadcast messages: DNP3 protocol talks to each device within the system and perform specific functions on it. Broadcast messages can be dangerous specially if they have a "turn off" command to all the Remote Terminal Unit (RTU) that controls its own energy substation. You can check this with the following snort rule:

alert tcp any 20000 -> any any (msg:"All RTU being contacted using DNP3"; dnp3_ind:all_stations; sid:1;)
 

• Check for write or delete operations not being sent by the master station: We definitely don't want someone else to write or delete to the RTU on behalf of the official Human-Machine Interface (HMI). The following snort rule can be used to check this behavior, assuming that HMI ip address is 1.1.1.1:

alert tcp !1.1.1.1 any -> any any (msg:"Someone trying to write or delete to RTU"; dnp3_func:write,delete_file; sid:1;)
 

• Check for "save configuration" commands not being sent by the master station: If someone writes to the RTU and then tries to save the configuration on behalf of the official HMI, could already have control of the RTU devices and make sure we no longer can send commands to them. The following snort rule can be used to check this behavior, assuming that HMI ip address is 1.1.1.1:

alert tcp !1.1.1.1 any -> any any (msg:"Someone trying to save the configuration of a RTU device"; dnp3_func:save_config; sid:1;)
 

• Check for "stop applications" commands not being sent by the master station: This is very dangerous if sent broadcast to all RTU. The following snort rule can be used to check this behavior, assuming that HMI ip address is 1.1.1.1:

alert tcp !1.1.1.1 any -> any any (msg:"Someone trying to stop the applications of an RTU device"; dnp3_func:stop_appl; sid:1;)
 

I would include a couple of special wishlist to the Sourcefire guys to include in next versions: IEC60870-5 and Bristol Standard Asynchronous Protocol (BSAP), used in water supply SCADA systems.

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

Many of our readers use Data Loss Prevention products as a mechanism to identify sensitive data-at-rest on workstations, servers, databases and similar.  Earlier today, I stumbled across an open source application known as OpenDLP.  I professionally recommend that users have a DLP product in your toolkit.  As many of the tools are commercial in nature, this product may be a excellent choice for home use (or at least when you head home for holidays and are asked to fix the family computer).

While reviewing information on the OpenDLP website, I saw that the developers released a new version of OpenDLP and a virtual machine OpenDLP that corrects a small number of glitches.

More information on this product is available at code.google.com/p/opendlp/ .  Any of our readers use this product and able to comment on how well it works, false positives and the like?

Scott Fendley ISC Handler

For those who weren't watching on Thursday, Google released a new revision of Chrome.  There were a small number of high severity security issues which were corrected in version 16.0.912.75.  More information on these bugs is located at googlechromereleases.blogspot.com/2012/01/stable-channel-update.html. 

Most Chrome users will receive the newest version automatically. However, many Enterprise customers may change the update policy to disable this feature.  We would recommend that these customers push the update after any appropriate testing.

Scott Fendley ISC Handler

If you are avid users of tcpflow, Simson Garfinkel has just released a public beta of tcpflow which contains significant changes. If you want to participate in the beta testing, the tool is available for download here which include several prebuild packages are also available for download. A list of the changes is posted here. A final release is planned within the next two weeks.

[1] http://afflib.org/software/tcpflow
[2] http://old.nabble.com/tcpflow-1.1.0-beta1-td33081226.html

-----------

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

It is a brand new year and this upcoming Tuesday Microsoft is releasing seven bulletins ranging from Important (6) to critical (1) affecting all Windows OS. Detailed information can be found in the advance notification bulletin.

[1] http://technet.microsoft.com/en-us/security/bulletin/ms12-jan

-----------

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

OpenSSL has addressed six vulnerabilities in OpenSSL 1.0.0f and 0.9.8s.

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)

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:

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:

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

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)

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)