@dangoodin001 over at ArsTechnica dropped a fabulously spooky tale today of "mysterious Mac and PC malware that jumps airgaps." If you follow @dragosr (Dragos Ruiu) via Twitter you've probably heard about #badBIOS, but if you don't you have some reading to do.

Meet “badBIOS,” the mysterious Mac and PC malware that jumps airgaps - ArsTechnica

#badBIOS features explained - Errata Security

#badBIOS - Security Artwork

Its been three years now that this issue has plagued Dragos, the CanSecWest and PacSec conferences organizer, and the founder of the Pwn2Own hacking competition, who as Dan states "is no doubt an attractive target to state-sponsored spies and financially motivated hackers."

While the Internet Storm Center is not yet in possession of enough information (We can neither confirm nor deny, Senator) to confirm with absolute certainty, this is a real humdinger in the context of immediately recent reports alleging that the Russian Gov Slipped a Little Bit of Malware in G20 Attendees Gift Bags. Additionally, let me lay some propositional logic on you:

If Dragos is smart, then #badBIOS is a legitimate malware threat.
Dragos is smart.
Therefore, #badBIOS is a legitimate malware threat.

To quote directly from the close of Dan's article as he cites Dragos: "It looks like the state of the art in intrusion stuff is a lot more advanced than we assumed it was," Ruiu concluded in an interview. "The take-away from this is a lot of our forensic procedures are weak when faced with challenges like this. A lot of companies have to take a lot more care when they use forensic data if they're faced with sophisticated attackers."

ISC would love reader feedback via comments regarding thoughts on detection and mitigation as more details on this surface.

Happy Halloween and enjoy the ghost hunt. :-)

No, it's not because I work for MSFT and want you to upgrade for selfish reasons. :-) It's because it really is time.

If you need a strong supporting argument and five good reasons to upgrade, look no further than the Microsoft Security Intelligence Report v15 released today. All you need to do is CTRL+F this doc and search for Windows XP to see what I'm talking about. Here, I'll help, as ripped directy from the SIR v15:

1. 9.1 computers cleaned per 1000 scanned by the Malicious Software Removal Tool (MSRT) were Windows XP SP3 32-bit, more than any other system cleaned.
2. Windows XP SP3 holds the top spot for infection rate (9.1 CCM)  even though it actually has a lower encounter rate (percent of reporting computers) than Windows 7 SP1.
3. The disparity between the two metrics above highlights the importance of moving away from older operating system versions to newer, more secure ones. Computers running Windows XP in the first half of 2013 encountered about 31 percent more malware worldwide than computers running Windows 8, but their infection rate was more than 5 times as high.
4. #1 threat family affecting Windows XP SP3? INF/Autorun. Yes, that autorun, used by worms when spreading to local, network, or removable drives. Doesn't work on modern versions of Windows in their default configuration.
5. Windows XP extended support ends April 8, 2014. That means no more patches, people.

As I sat in the dentist chair today for my cleaning and viewed my X-rays on a Windows XP machine I thought about a comment from Tim Rains of Microsoft's Trustworthy Computing organization: "XP has been a beloved operating system for millions and millions of people around the world, but after 12 years of service it simply can't mitigate the threats we're seeing modern-day attackers use." Survival rate for systems running Windows XP after support ends? Non-existent. Don't believe me? Also per Tim: "In the two years after Windows XP Service Pack 2 went out of support, its malware infection rate was 66 percent higher than Windows XP Service Pack 3 - the last supported version of Windows XP."

It's time, folks. It's going to be hard for doctors and dentists to be certain :-), but migration is in order. What would Patton say (thanks TJ)? "A violent executed plan today is better than a perfect plan expected next week." That should be your plan to migrate off Windows XP.

When ISC reader Yin reported earlier today that one of their servers had been hacked via the Apache Struts remote command execution vulnerability (CVE-2013-2251), at first this was flagged as "business as usual". Said vulnerability, after all, is known since July, and we've been seeing exploit attempts since early August (diary here). So it wasn't quite a surprise to see an unpatched internet-exposed server subverted. Given the rampant scanning, it was more a surprise that it had survived unscathed until now.

As a result of a successful attack, the bad guys modify the core index.jsp on the affected server, to include a snippet like the following:

The associated site is still live, which is why the above is an image and not a clickable URL. If you still insist to go looking, be careful, and don't blame us!  Leaving the web server and Struts vulnerability aspect of things, let's now look at what's lurking on that namu-in site:

Yup, there's an APPLET tag. A Java exploit again, it seems. Oracle Java is the true gift that keeps on giving...!

daniel@foo3:~/malware$ ls -al Init.jar
-rw-r--r-- 1 daniel users 49019 Oct 24 16:04 Init.jar
daniel@foo3:~/malware$ md5sum Init.jar
714ef7f35f2bac61c4bace8706f88b98  Init.jar

daniel@foo3:~/malware$ unzip Init.jar
Archive:  Init.jar
  inflating: META-INF/MANIFEST.MF
  inflating: Print.class
  inflating: Init$MyColorModel.class
  inflating: Init$MyColorSpace.class
  inflating: Init.class

The presence of the "MyColorModel" and "MyColorSpace" files in the JAR archive suggests that this could be an exploit for CVE-2013-2465, the 2D/AWT vulnerability which affects all Java Versions up to 1.7_21. On closer investigation, this is confirmed, Init.class indeed exploits CVE-2013-2465, and then calls Print.class, which in turn seems to create a file named "mspaints.exe":

The content of the file is drawn from the variable "data" or "data1", depending on the OS version encountered. Both these variables are defined within the "Print.class":

Sequences of 7777... are kinda rare in real world EXEs. A corresponding series of zeros (00) would be a lot more common. And look how the file starts with "3A2D".. if this is a real EXE then these first two bytes would have to be "MZ" (5A4D). So .. this "data" array is probably just XORed with 0x77?  Let's try:

daniel@foo3:~/malware$ echo "3A2D" | perl -pe 's/(..)/chr(hex($1)^0x77)/ge'
MZ

Busted! :)

Feeding the entire two "data" arrays through the same Perl operation turns the hexadecimal set into binary files, all while XOR-ing every byte with 0x77:
daniel@foo3:~/malware$ cat data.hex | perl -pe 's/(..)/chr(hex($1)^0x77)/ge' > data.exe
daniel@foo3:~/malware$ file data.exe
data.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
daniel@foo3:~/malware$ md5sum data.exe
cd2dd181257375c840f13988c8c7b6d5  data.exe

Searching for this MD5 hash on VirusTotal https://www.virustotal.com/#search gives us a result with a rather dismal 3/47 detection rate. But at least someone else already uploaded it earlier today.

The next stage of the analysis is now on the two EXE files, data.exe and data1.exe. This task is - commonly - quite a bit more tricky than just reverse-engineering JavaScript or Java, because static analysis (like we did on the Applet) can be quite reliably thwarted on an EXE, and dynamic analysis (= actually running the file) can be full of "surprises".  Case in point:

daniel@foo3:~/malware$ strings data.exe | grep -i Debug
OutputDebugStringA
IsDebuggerPresent

Looks like our EXE invokes the Windows API method "IsDebuggerPresent" to verify whether a debugger is currently running. Chances are, the EXE will behave differently when is suspects that someone (like a malware analyst :) is watching its every move. In this case here it is nonetheless quite readily possible to determine what the two EXEs are doing: They are, as so often, simply "downloaders" that fetch the next stage of the attack code. There are four downloaded files, and all come from www-sandulsori-co-kr.

daniel@foo3:~/malware$ ls -al *
-rw-r--r-- 1 daniel users 55296 Oct 24 12:21 common.gif
-rw-r--r-- 1 daniel users 71680 Oct 24 12:21 common.png
-rw-r--r-- 1 daniel users  7680 Oct 21 08:08 favicon1.ico
-rw-r--r-- 1 daniel users 79872 Oct 17 09:44 favicon.ico
daniel@foo3:~/malware$ md5sum *
e2004ec5fef378b2e41f6eef6931650b  common.gif
3fed1004befb9834b699a88ccdce757e  common.png
c85f70642ad402077c6447dc6ad6f7bb  favicon1.ico
93a2dc2dcdb4bb17ae168cb60cff2e9b  favicon.ico
daniel@foo3:~/malware$ file *
common.gif:   PE32 executable for MS Windows (console) Intel 80386 32-bit
common.png:   PE32+ executable for MS Windows (console) Mono/.Net assembly
favicon1.ico: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
favicon.ico:  PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit

Note how all four files claim to be an image, even though they are an EXE. The two files named "common" contain the Windows EPathObj exploit (CVE-2013-3660) which results in SYSTEM privileges on versions of Windows that don't have Patch MS13-053 (July 2013). Analysis of the two favicon files is still ongoing. The involved domains (overall) are: www-namu-in-com, currently at 110.45.165.42 for Stage#1, www-sandulsori-co-kr, currently at 111.92.188.21 for Stage#2, and www-staticscount-com, currently at 74.82.173.187 for the Command&Ccontrol (C&C).  These sites and IP blocks are not necessarily hostile per se, they could also be victims of an earlier hack / take-over.

The moral of the story is that all of the above is based on Exploits of vulnerabilities that have patches available since about three months. If your patching of OS and Applications is lagging behind to this extent because of lack of resources or priority, you'll need to catch up asap. As shown above, the bad guys are delivering exploit cocktails that provide SYSTEM level privileges on Windows machines which lack the necessary patches, and current anti-virus patterns offer little coverage against it.

ISC received a submission from Zach of a Perl/Shellbot.B trojan served by fallencrafts[.]info/download/himad.png[1]. The trojan has limited detection on Virustotal [2] and the script contains a “hostauth” of sosick[.]net[3] and the IRC server where the compromised systems are connecting to is located at 89.248.172.144. What we have so far, it appears it is exploiting older version of Plesk.

md5: bca0b2a88338427ba2e8729e710122cd  himad.png
sha-256: 07f968e3996994465f0ec642a5104c0a81b75b0b0ada4005c8c9e3cfb0c51ff9  himad.png

[1] https://dns.robtex.com/fallencrafts.info.html#graph
[2] https://www.virustotal.com/en/url/79654fc688b48211ccc24a14d815c41dba0b1dfbefc2c51d38ed88b481242e9b/analysis/1382747124/
[3] https://dns.robtex.com/sosick.net.html#records

-----------

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

One of our readers has alerted us to the fact that Kaspersky AV has identified tcpip.sys as malware on his Windows 7 32bit hosts - the file is flagged as "HEUR:Trojan.Win32.Generic"

Fortunately, Microsoft's Windows File Protection feature ( http://support.microsoft.com/kb/222193 ) prevented it from quarantining this critical file, but his end users were all treated to the error message (both from the AV and from the OS I'm guessing)

His version of Kaspersky is the OEM Checkpoint version, but it appears to be a Kaspersky issue, not Checkpoint specific.

Kaspersky has verified ( https://twitter.com/kaspersky/status/393777843341393920 )  that this is resolved in their latest update.  If you're seeing this issue, get your AV to "phone home" for the fix!

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

Yesterday, it was discovered that the php.net website had been compromised. At this point, the php.net team believes the servers were compromised for several days, and at least one file was altered to deliver malware. The current summary suggests that the attacker may have had access to the servers secret SSL key, which suggests the attacker had root access. [1]

Probably the most valuable asset present on the php.net site and it's mirrors is the PHP source code distribution which is used by sites worldwide. At this point, there is no indication that the attacker modified the file. But I want to focus on the user downloading a file, like the php source code. How to you verify that the file is authentic and didn't get tampered with?

PHP.net publishes MD5 hashes on its site, that a user may use to verify the binary. Never mind that MD5 isn't the strongest hashing algorithm. It is probably good enough for this purpose. But the real problem is that there is no digital signature. An attacker could swap the source code AND the md5 hash if the attacker has access to the server, and as in this case appeareantly is able to alter files. A digital signature would be created using a secret key FAR removed from the server, maybe even kept offline. This way, an attacker would be able to change the signature, but not using the authorized key, and an end user bothering to verify digital signatures would have a fighting chance to detect the compromise. Sadly, too many projects only use hashes (again: Doesn't matter WHAT hash you use. The can all be replaced).

[1] http://php.net 

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

We are looking for small "brick and mortar" companies that got affected by a DoS attack agains their website. Recently, we heard from a couple of non-internet local businesses whose websites experienced substantial DoS attacks, and we would like to see if this was just an "outlier" or a new trend.

Pleaes use our contact form: https://isc.sans.edu/contact.html

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

Update: Barracuda posted a more detailed analysis and packet capture showing that php.net may indeed have been compromissed and delivered a malicious flash file: http://barracudalabs.com/2013/10/php-net-compromise/ (thx David for pointing to this)

Earlier today, Google had php.net added to its list of malicious sites. The listing was the result of a false positive triggered by an obfuscated javascript file that is a legitimate part of the php.net site. At this point, the false positive appears to be resolved. 

Sadly, Google is notoriously slow in removing false positives like this. It helps if the site's administrator is signed up with Google Webmaster tools. In this case, a request for review can be filed via webmaster tools, and the administrator will be notified via e-mail if the site is added to the blocklist.

For more details, see:

https://productforums.google.com/forum/#!topic/webmasters/puLmvjtK0m8%5B1-25-false%5D

------

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

Introduction

This virtual machine comes to you care of $DayJob frustrations and the need to generate logs. This month we are covering log entries and in my lab at work there was a need to trigger some alarms. So I set out to build an OpenVAS [1][5] suite in order to trigger several different detection systems.

The Greenbone Security Manager [2] provided an excellent, albeit not ‘as’ intuitive as I like, interface for scheduling scans and basically sending out network and application nastiness.

Prep

It had been a while since I had last set up an OpenVAS Suite so “to the Google Batman” ... In doing a quick search I located several blog entries on different distribution installs [3] [4] [5] as well as the OpenVAS Docs [6]. In this prep I also was looking for the smoothest distribution for install as this was going to sit as a virtual machine in my $DayJob lab. After searching forums the easiest seems to be Ubuntu on 12.04 LTS, however I ended up on CentOS 6.4. There are some caveats for installing on CentOS but just seemed to perform better.

CentOS Caveats

If you are going to install on CentOS, a couple of observations:

There will likely end up being some errors ( see [7] ) to work through.
If you manage to get it working and don’t see traffic leaving yet Greenbone says your job is running? “Audit2Allow [8] is your friend!” It is likely (Almost 99.9999%) SELinux.

For those that want to take the lazy way out :) the file you are looking for is in /etc/selinux and is config:

/etc/selinux/config

Make sure to run a rebuild after the install process, see [5] and look for the notes on openvasmd --rebuild

General Install Caveats

Syncing from OpenVAS can take a very ...... very long time. Just be patient if you build your own, the initial sync can take a great deal of time (hours occasionally). If you don’t want to take the time to install your own, you can download the below Greenbone VM.

Running a Job




The Greenbone VM

File: http://handlers.sans.org/rporter/greenbone.7z
File Size: 764 MB
Type: OVF Template
OS: CentOS 6.4 (patched as of 22 OCT 2013)
SHA1: a80c8a1da92c68d38202b23f382acbc46b3fb850

Virtual Machine vHardware Settings

RAM 2GB
HD 8GB
NIC Bridged

System Account: root
System Password: sanstraining

Greenbone Account: admin
Greenbone Password: sanstraining

All passwords will be sanstraining

VM Is set for DHCP on Boot.


References:

[1] http://www.openvas.org/
[2] http://www.greenbone.net/technology/openvas.html
[3] http://hackertarget.com/install-openvas-5-in-ubuntu-12-04/
[4] http://samiux.blogspot.com/2013/05/howto-openvas-on-ubuntu-desktop-1204-lts.html
[5] http://www.securitygrit.com/2013/05/openvas-6-and-centos-64.html
[6] http://www.openvas.org/install-packages-v5.html
[7] http://comments.gmane.org/gmane.comp.security.openvas.users/4889
[8] http://fedoraproject.org/wiki/SELinux/audit2allow

Richard Porter || @packetalien || rporter at isc dot sans dot edu || blog: packetalien.com

It was briefly mentioned in a previous posting, but the Cryptolocker ransomware is still going strong.  In essence, post infection is encrypts all of your "document" files based on file extension and then gives the user 72 hours to pay the ransom ($300 USD or 2 BTC).  It is one f the few pieces of ransomware that does encryption right so at present, short of paying the ransom, there is no other means to decrypt.  Bleeping Computer has a good write up, but below are the TL;DR highlights.

If you are infected and your files are encrypted (and you have no backups) there is a very limited means to restore files using Microsoft's Shadow Volume Copies (Windows XP SP2 or better).  In essence, previous versions of files still persist on a system and can be recovered manually or by using a tool like Shadow Explorer. 

Other than that, there is no means currently available for recovery (besides paying).  Reinfecting once the timer runs out does not reset the timer and there have been no reports of recovery after an appreciable amount of time has passed after the 72 hours.  (Some limited amount of clock games might help at the margins, but the bad guys say they delete and purge keys and there is no evidence this is not true).

There are some GPO settings you can deploy to prevent this kind of infection and for the most part, some of these settings are best practices independently of Cryptolocker.  Basically you can prevent execution of executibles in temp directories the details of which are at Bleeping Computer.

There are varying ways that systems become infected, at one point it was UPS/FedEx style spam, now it seems coming down with zbot and other associated tools.  At this point anti-virus has decent detection so keeping that up to date is a significant help.

Apparently the attackers are also paying attention to various forums but there is no direct way to communicate with them.

REQUEST: If you or your organization has paid the ransom to decrypt, we would like to talk to you (anonymously) about the experience.  Please write in directly to bambenek /at/ gmail.com

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

This is a guest diary submitted by Basil Alawi. 

What is NetFlow?

NetFlow is a traffic-summarization format that was first implemented by Cisco Systems, primarily for billing purposes. Network flow data (or Network flow) is a generalization of NetFlow.

Network flow collection differs from direct packet capture, such as tcpdump, in that it builds a summary of communications between sources and destinations on a network. This summary covers all traffic matching seven particular keys that are relevant for addressing: the source and destination IP addresses, the source and destination ports, the protocol type, the type of service, and the interface on the router[i].

SiLK

SiLK is a suite of network traffic collection and analysis tools developed and maintained by the CERT Network Situational Awareness Team (CERT NetSA) at Carnegie Mellon University to facilitate security analysis of large networks. The SiLK tool suite supports the efficient collection, storage, and analysis of network flow data, enabling network security analysts to rapidly query large historical traffic data sets[ii].

Netflow on VMware ESXi:

NetFlow is available in vSphere distributed switch version 5 or later as well as in Cisco Nexus 1000v. VMware vSphere 5 supports NetFlow v5 while Cisco Nexus 1000v support Netflow v5 as well as Netflow v9.

Running netflow on a vSphere environment will provide visibility of the following:

·      Intrahost virtual machine traffic (virtual machine–to–virtual machine traffic on the same host)

·      Interhost virtual machine traffic (virtual machine–to–virtual machine traffic on different hosts)

·      Virtual machine to physical infrastructure traffic

Test Lab

The test lab consist of  Vmware ESXi 5.1 as a host ,Ubuntu 13.04  as netflow collector and analysis workstation , Kali Linux with an IP of 192.168.207.30 , Linux#1 server with an IP 192.168.207.12 , Linux#2 with an IP of 192.168.207 and Cisco Nexus 1000v switch with an IP of 192.168.207.139. 

SiLK Installation

For this diary the SiLK will be running on a fresh Ubuntu 13.04 installation. Here is a step by step instruction on how to install SiLK on Ubuntu Linux.

1-Install gcc , gcc-c++, glib2, glib2-devel, libpcap, libpcap-devel, python and python-devel

2-Download Silk and fixbuf. Latest version can be found at http://tools.netsa.cert.org/

3-Install fixbuf

3-Install Yaf

Recently, two papers independently outlined new attacks against DNS, undermining some of the security features protecting us from DNS spoofing.

As Dan Kaminsky showed [1], 16 bit query IDs are an insufficient protection against DNS spoofing. As a result, DNS servers started to randomize the source port of DNS queries in order to make DNS spoofing harder. This was never meant to "fix" DNS spoofing, but worked well enough for DNSSEC to be pushed back yet again.

Overall, to successfully spoof DNS, the attacker has to overcome various challenges:

• reply before the valid reply arrives: This can easily be done starting to flood replies even before the query was sent.
• Guess the DNS Query ID and the source port of the query: Currently, this challenge is considered the major stumbling block.
• Once the valid query arrives, the attacker is "locked out" from attempting another spoofing attempt until the TTL of the record expires (Dan Kaminsky showed how this can be overcome by asking for non existing records)

The new attacks are using two more modern DNS features:

Reply Rate Limiting (RRL)

DNS spoofing isn't the only DNS problem we need to defend against. DNS servers may be abused as reflectors in denial of service (DoS) attacks. Even if a DNS server is only answering queries for which it is authoritative, it may still be abused by asking for records for which it is authoritative for. Modern DNS servers (e.g. BIND 9) implemented a feature to limit how many responses a DNS server will send. If the limit is reached, the DNS server may either not respond at all, or reply with an empty truncated reply. The empty truncated reply will force the source of the query to return via TCP. If the query was spoofed, then this will not happen. BIND by default skips every second reply in this scenario. 

The problem arrises if the attacker floods an authoritative DNS server to prevent it from sending responses. This will provide more time to send spoofed responses back. Researchers have shown that this can lead to DNS spoofing. But it requires a lot of packets (100 MBit for 8 hrs) to be successful as the Query ID and the source port needs to be brute forced. [2]

To defend against this attack, while still maintaining a RRL, it is sufficient to adjust the slip value which governs how frequently the DNS server will skip a DNS reply while under distress. A slip value of  "1" will not skip any replies.

Fragmented EDNS0 replies

Originally, DNS replies were limited to 512 bytes to avoid fragmentations. Any larger responses had to be requested via TCP. However, TCP requires significant higher overhead and the query needs to be sent twice. Modern DNS tends to use larger replies with IPv6 and DNSSEC records, as well as the use of DNS for load balancing. In response, a new feature, EDNS0, was introduced. If enabled, the DNS server may signal a maximum response size that is larger then 512 bytes. A typical value is 4096 bytes. As a result, these responses are frequently fragmented.

If the response is fragmented, all values used to "authenticate" the response are in the first fragment (query id and udp ports). It is now possible for an attacker to spoof the additional fragments. All the attacker has to guess is the fragment offset and the fragment ID. The fragment offset can be guessed assuming that the MTU is 1500 bytes (or it can be derived from the MSS if a TCP packet from the DNS server is received by the attacker). The fragment ID (or IP ID) is frequently incremented from packet to packet, so it can be easily guessed. If it is random, it is still only 16 bit long. [3]

There is no decent defense against this attack so far. Disabling EDNS0 may work, but it will lead to problems with DNSSEC which requires EDNS0. Your operating system may allow you to randomize the query ID and this should probably be a minimum protecting for now.

DNSSEC of course remains the only REAL protection against these attacks.

[1] http://dankaminsky.com/2008/07/24/details/
[2] http://www.ssi.gouv.fr/en/the-anssi/publications-109/scientific-publications/conference/abusing-anti-ddos-mechanisms-to-perform-dns-cache-poisoning.html
[3] http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf

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

According to twitter and messages we received directly, it appears that the .QA (Qatar) TLD was compromised last night by the Syrian Electronic Army. Affected domains appear to be returning back to normal at this point.

Google still returns some results for the compromissed pages, including it's own .qa site:

Links to twitter messages about the compromisse (follow at your own risk) : hxxp://twitter.com/Pr0udSyrian/status/391525943035969536/photo/1

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

Update: A patch was released last night. See http://blog.whmcs.com/?t=80223

WHMCS, a popular billing/support/customer management system, is still suffering from critical SQL injection issues. Today, yet another vulnerability, including exploit was released. 

Due to the fact that there is no patch available at this point, I will refrain from linking to any exploit details, but it is pretty trivial to find the respective blog post which includes a script to exploit the vulnerability. WHMCS acknowledged the problem [1]

The root cause of this problem, as well as prior problems with the software, appears to be a lack in understanding of proper controls to prevent SQL injection. Good input validation is just a start, but prepared statements are a must. Instead, the WHMCS developers used a rather complex (and buggy) function to escape user input and assemble dynamic SQL queries.

The bug is in a function used throughout WHMCS, so the exploit is not limited to a particular URL.

[1] http://blog.whmcs.com/?t=80206

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

As part of Cyber-Security Awareness month, one of our readers sent us an extract from their firewall logs.  The events of interest where a regular pattern of internal hosts making DNS requests to a few hosts at iana.org.

So in other words, thousands of outbound DNS Requests to internet hosts that aren't in any DNS or DHCP configuration inside the organization.  What gives?

After a bit of searching, we found our answer in RFC6304 and RFC6305, also http://support.microsoft.com/kb/259922. I especially like RFC6305's title - "I'm Being Attacked by PRISONER.IANA.ORG!"

In plain english, when you don't have reverse DNS zones set up for your internal subnets, each individual workstation will attempt to register their reverse entry with these hosts at iana.  It's just part of how DNS is architected, it's not specific to any one operating system vendor (so it's not "a windows thing").

The solution?  Configure reverse DNS zones for each zone inside your organization. 

While reverse DNS zones have great applications for penetration testers, they are also *very* desirable for a lot of "legit" reasons:

• It helps you identify hostnames from ip addresses that might show up in your firewall and other logs (this is a big one)
• It helps in defining Active Directory "Sites", which will in turn allow you to optimize Domain Controller type queries.  For instance, creating sites for each remote office location in an organization will allow workstations to authenticate to domain controllers in their local office, rather than chewing up WAN bandwidth to authenticate against Domain Controllers at head office.

What other "sysadmin" uses do you routinely use reverse DNS for?  Please let us know using our comment form.

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

VMware released the following security updates. The first one is VMSA-2013-0012 which address multiple vulnerabilities in vCenter Server, vSphere Update Manager, ESXi and ESX. [1]
The second is VMSA-2013-0006.1 which address multiple vulnerabilities in vCenter Server Appliances and vCenter Server running on Windows. [2]
The last is VMSA-2013-0009.1 which address multiple vulnerabilities in vCenter Server, ESX and ESXi that updates third party libraries. [3]

[1] http://www.vmware.com/security/advisories/VMSA-2013-0012.html
[2] http://www.vmware.com/security/advisories/VMSA-2013-0006.html
[3] http://www.vmware.com/security/advisories/VMSA-2013-0009.html

-----------

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

Spammers have long relied on bots, compromised webmail accounts, or open SMTP relays to send their dastardly payloads to our mailboxes. This new trend is a variation on the theme. The spammer sets up a vanity domain, and then send spam through it. The interesting bit here is that it is not hotmail.com or outlook.com but onmicrosoft.com being used. The format is as follows: <UserName>@<Vanity-name>.onmicrosoft.com. One reader Melvin has seen quite a few of these and asked me to write this up. To quote Melvin "So, spammers are registering *WITH* Microsoft for domain-hosting and web-hosting, and then abusing Microsoft's own mail-servers ("six-nines-availability/reliability")to distribute their spam/scam messages." <sarcasm>Awesome business plan! </sarcasm>

Is your IDS/IPS, anti-spam, or email gateway allowing these through, alerting on them, or blocking them?

Here are some samples:

Date: Wed, 16 Oct 2013 20:49:20 +0100
Subject: (none)
From: Uk National <001@tanlan.onmicrosoft.com>
Reply-To: <claimsagent845@yahoo.com.hk>

Your Email Id Have Won 1,000,000.00 GBP in Uk National Lottery ...
______________

Date: Mon, 7 Oct 2013 20:13:23 +0530
Subject: BARCLAY'S BANK
From: BARCLAY'SBANK <pp7@lines.onmicrosoft.com>
Reply-To: <barclaysbnnkplclondon@zing.vn

What luck! The handlers list just received a really well done phish. No awkward grammar, no typos. The URL points to the following link

hxxp://innovativeair.org/wp-info/microsoft/index.htm

From the format it would appear to be a compromised WordPress site. It has already been reported to the anti-phishing groups and the built in phishing and malware protection in Firefox detects the page as phishing. The only thing that is unusual is how well done the email is, and that it bypassed the anti-spam filter to arrive in my mailbox.

Ask yourself, would your users click?

Let's be careful out there!

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

We have received a request from a research group to let everyone know that they will be conducting Internet wide scanning of DNS servers. This is their request:

"Our team at the Network Architectures and Services Dept. (I8) of TU München, Germany, has started a DNS scan. This has similar goals as the scans that we have conducted for SSL and SSH in the past months. Once again, the purpose is purely scientific. The scanning machine is 131.159.14.42. We are querying DNS servers to resolve host names. We do not in any way try to compromise the servers. Additionally, the load caused by our activities should be very low on a single server. The idea of our queries is to get a better understanding of the inner workings of DNS, one of the most ubiquitous protocols of the Internet. We would it appreciate it very much if you added a comment in your database. Please note that we respond to every complaint and are happy to blocklist systems with annoyed admins." 

Their purpose is scientific research. Interesting, I call scanning without permission unethical, and rude. Here is what I recommend if you do not want to be part of the research, that you block all DNS requests from that IP address. They have performed similar SSH and SSL scans in the past, from different IP addresses. What do you think? Let us know via our Contact Us page or in comments below.

Let's be careful out there!

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

If you are surfing the Internet, minding your own business, and receive an access denied message, you might understandably wonder why. As one Internet surfer discovered, he was trying to go to a legitimate web site to book a service in a country he was planning on visiting. Imagine his surprise when he see the image below in his web browser!

Hmm, whatever could that mean? If I were him I would try to contact Dshield. It is almost as though the company was using a blocklist or blocklist that this user had been placed on by attacking other people on the Internet. As SANS Internet Storm Center Handlers we have access to the Dshield database, and can query it. Our recommended block list is public and located here:

https://isc.sans.edu/block.txt

However the IP address of our web surfer is not on that list. A query of Dshield does result in some hits, in fact there are 9, all from the 11th of October for port 80. Not exactly an aggressive attacker hacking his way across the Internet. My guess would be clicking on invalid links where there used to be web servers, leading to reports of dropped traffic from that IP address.

What we know is that a certain vendor that shall remain nameless for the time being is making use of Dshield data incorrectly and inappropriately, and they should stop. If you recognize this error message you know who you are. If you make use of this vendors equipment or software be advised that whatever feature you have turned on is blocking completely innocent users trying to buy your services. It is not making you any more secure at all. I am not fond of blocklists or blocklists at all, and this misuse is not a particularly good idea.

Let's be careful out there!

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

Oracle today released updates for pretty much their entire product line.  Updates and patches are released for Oracle Database, Fusion, Enterprise Manager, Peoplesoft, Siebel, Health Scienses Product Suite, FLEXCUBE, Primavera, Java SE, Spark Servers Firmware, Solaris 10 and 11.1, Virtualbox and MySQL

Full Details are here: http://www.oracle.com/technetwork/topics/security/cpuoct2013-1899837.html

If you run any of these products, this release should be of interest to you!

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

I just posted a one-liner on the latest Java Update.  There is a hefty list of security vulnerabilities fixed, but I figured folks could dig into if they were interested, and a one liner would do.

However, the real story, for me at least, is that Oracle is now on a quarterly update schedule, starting with this version.  Going forward, expect regular updates to be released on the Tuesday closest to the 17th day of January, April, July and October. The next four dates are:

    14 January 2014
    15 April 2014
    15 July 2014
    14 October 2014

Not sure if this is good or not, I'd rather see more frequent updates, but that's the schedule.

The release notes for this version (Windows, Linux, Mac and Solaris) are here: http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html         

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

Without a doubt, when discussing Windows logs the most common questions I get from my clients are almost about authentication, in particular about authenticating Wireless or VPN sessions using RADIUS.

Microsoft has supported RADIUS for years as IAS (Internet Authentication Service), and have changed the name to NPS (Network Policy and Access Services) in Windows Server 2008, along with adding a boatload of new features.

Where can you find NPS logs? - in a few places actually.  Many administrators will find NPS logs easiest to access in the Windows Event Viewer, where it's broken out nicely.

Most administrators will also store a text log.  If you're anything like me, using the grep, find or findstr commands are the go-to method of log access.

On to the logs themselves.  The sort of question I normally get with NPS is "why can't this user access the wireless/vpn/whatever network?", especially when other users can.  In almost all cases, the NPS Service logs will tell you exactly why, but the reason isn't always presented as easily as it could be.

For instance:

6273
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.

Looking at a typical log, you'll get a generic "denied" mesage, but you'll also have the ip address of the NAS (Network Access Server), which is usually a vpn gateway, wireless controller or ap - the NAS is often the RADIUS client as well.  You'll often also have the MAC address of the AP too, or if you're running an older wireless infrastructure with no controller, the NAS will be the AP.

If it's a wireless access request, you'll also have the mac address of the calling station (which would be the workstation).

So why exactly did your user get denied access?  In the event viewer message, scroll to the very bottom, and check the Reason Code field and the text associated with it

A really common reason code is 65, especially during the initial setup of a new SSID or Policy:  "The connection attempt failed because network access permission for the user account was denied. To allow network access, enable network access permission for the user account, or, if the user account specifies that access is controlled through the matching network policy, enable network access permission for that network policy."

The easiest way to fix this one is to add a single tick-box in your radius configuration - in the network policy, in the middle of the first page, tick the box that says "Ignore User account dial-in properties"  If you don't do this, every access request will look at the account permissions to see if they have "Allow Access" enabled under their Dial-in / Network Access Permissions setting.

Of course, the other common reason code on error 6273 would be 16:

    Reason Code:            16
    Reason:                Authentication was not successful because an unknown user name or incorrect password was used.

You'll often see this one if you are doing authentication with the workstation's domain Machine Account - if a user who's machine is not in the domain selects that SSID, that account will of course not exist.

And of course, if you see dozens and hundreds of these, you might be seeing an authentication attack against your wireless system.  The common protections against this are account lockout settings, and NEVER EVER putting accounts that don't have account lockout into VPN or Wireless access groups.  The Domain account "Administrator" would be the classic example of this - it's got access to everything in the domain, and by default has the account lockout settings disabled.  "Administrator" is always the target account in both legitimate pentests and real life attacks, so you're best not to permit remote access via this account.  NPS Reason Code 36 indicates that the account in the log message has been locked out.

Especially during setup of a new SSID, you'll see accounts fail authentication when you are sure the account credentials are correct -  in that case check your policy, quite often the NPS Policy will be based on AD groups, but either the user or the machine will need to be in the right group (for instance, "Corporate Wireless").  It's very common to miss this group membership requirement on either or both of these accounts when things are first being put together, or when you are adding new users or machines to the domain.  For instance, in early September we saw a number of schools run into this as they added student accounts.

All NPS reason codes are listed here: http://technet.microsoft.com/en-us/library/dd197570.aspx

What other NPS message IDs will you commonly see in your logs?

What errors or reason codes have you seen in your system?  Please use our comment form to let us know what you've seen in your NPS logs, how the message helped you solve the problem (or not), and what your solution was.

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

A vulnerability appeared in old d-link routers which allows the attacker to gain admin privileges in the router. The following models are affected:

• DIR-100
• DI-524
• DI-524UP
• DI-604S
• DI-604UP
• DI-604+
• TM-G5240
• DIR-615

If your user agent is set to xmlset_roodkcableoj28840ybtide, you will be able to view and change settings in the device. As of today, D-Link has not posted a solution. If you have any wireless router matching the vulnerable models, you need to:

• Avoid unauthorized access to the wireless network: Use WPA2 with a key longer than 10 bytes and random. That will lower the odds of a brute force attack to your router.
• Make sure you give access to your wireless network to somebody you trust while DLINK publish a patch, as you cannot designate a single IP address for admin purposes ;)

When DLINK post a solution, you might want to ensure you are not using any default admin password. Check here for default wireless router passwords and look for DLINK reference. If you have the default password, check this page to look for information on how to access the admin tool to change the password.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

We have had a report of elevated activity on tcp/5901 and 5900, anyone else observing a significant spike in VNC scans?

Richard Porter

--- ISC Handler on Duty

Most of us who regularly look at firewall and other logs get to know the usual targets, 22, 5900, 5060, etc.  Most of the time these are fairly obvious and self explanetory.  However on occasion you do see some that are a bit more unusual.  For example this morning a scan was detected along these lines: 

A port scan looking for PPTP VPN connections, not something you see every day. The next step when a connection is made? not sure,  if you have any packets or logs you can share relating to this that would be much appreciated.  

Another scan picked up was a brute force password guessing attempt with a small change:

Instead of guessing the same userid with many passwords, they are guessing one password with many different userids.  Works more often than you would think and also stays below the lockout threshold.   We saw this about April-May last year, but it looks like it is still going strong. 

Enjoy digging. 

Mark 

DNS for the Malaysian copy of Google (Google.com.my) got appearanty hijacked. Right now, the hostnames google.com.my and www.google.com.my point to a host in Canada (142.4.211.228). 

(thx Alex for capturing the screen shot. My system would not allow me to connect to the IP address anymore). The NS records point to servers that do not appear to be "genuine" as well. Before, the NS records pointed to ns1.google.com and ns2.google.com, which are also authoritative for google.com. Now they point to  sdns1.ovh.ca and ks4003824.ip-142-4-211.net .

The whois information does not reflect that this is a google domain, but it didn't change recently and the site used to host a copy of Google's homepage according to archive.org. It is very much possible that Google uses a third party to operate part of its Malaysia site.

Update (via Twitter from @TheBackpackr): " We're the official co managing the domain for google.com.my @GoogleMsia. We are liaising with MYNIC on the DNS change."

The same group behind this attack also claims to have been successful against other Google country level sites (Burundi and Kenia) recently.

If you haven't yet: start monitoring your DNS data! A quick minimum script to do so in 5 minutes (just cron it... )

#!/bin/sh

TLD='edu';
DOMAIN='sans.edu';
ADMIN='your email';

ns=`dig +short NS $TLD  | tail -1`
dig  NS $DOMAIN @$ns  | grep 'IN\tNS' | grep -v '^;' | sort > .$DOMAIN.new
if [ -f .$DOMAIN.old ]; then
   if ! cmp -s .$DOMAIN.old .$DOMAIN.new; then
       cat .$DOMAIN.new | mail -s "Possible $DOMAIN hijack" $ADMIN
       echo possible $DOMAIN hijack
   fi
fi

mv .$DOMAIN.new .$DOMAIN.old

(and please change the variable at the top ;-) )

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

Today you may have noticed that the ISC website was down for a few minutes. This was the result of tuning our SSL configuration a bit. Configuring SSL is a bit of a balancing act. First of all, you want to configure SSL as secure as possible, which means limiting yourself to the hardest and most modern ciphers, secondly, you want to make sure that all of your users are still able to connect and that you are not loosing any old browsers that you still need to support. There are hundreds if not thousands of possible combinations (Operating system, browser, ssl library version), which does make it hard to predict what is going to happen.

Luckily, web servers like Apache have a feature to log what cipher is negotiated for a given connection.

In order to enable this feature, you use the "CustomLog" configuration directive. I am using:

CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x %{User-Agent}i

This will log the access time (%t), the client IP address (%h), the SSL protocol ( %{SSL_PROCOL}x ) the SSL cipher ( %{SSL_CIPHER}x ) and the user agent. You could just add this to your normal access log as well, but I prefer to keep it in a separate log.

Here are a couple of lines from the log:

[09/Oct/2013:17:46:21 +0000] x.x.x.x TLSv1 AES-256 Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Win64; x64; Trident/6.0)
[09/Oct/2013:17:46:21 +0000] y.y.y.y TLSv1 AES-256 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
09/Oct/2013:17:54:28 +0000]  z.z.z.z TLSv1 RC4 Motorola

And you will see failed connection that did not manage to negotiate a connection:

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

Adobe released two bulletins today:

APSB13-24: Security update for RoboHelp
http://www.adobe.com/support/security/bulletins/apsb13-24.html

I don't remember seeing a pre-anouncement for this one. The update fixes an arbitrary code execution vulnerability (CVE-2013-5327) . Robohelp is only available for Window.

APSB13-25: Security update for Adobe Acrobat and Adobe Reader
http://www.adobe.com/support/security/bulletins/apsb13-25.html

This update fixes a problem that was introduced in a recent update and effects Javascript security controls. As a result, only version 11.0.4 appears affected, no earlier versions. Only the Windows version of these Adobe tools are affected.

Apple released iTunes 11.1.1 today. The respective security page has not yet been updated, but expect a link to the security content of this update within the next day or so. http://support.apple.com/kb/HT1222 . This update only affects Windows. Patches for iTunes on OS X are usually released as part of OS X updates.

Did I miss any?

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

Overview of the October 2013 Microsoft patches and their status.

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

Our reader Phillip sent in the following log excerpt:

15:53:34.329883 IP 80.82.64.114.44806 > 59.167.x.35.53: 9158+ [1au] ANY? hizbullah.me. (41)
15:53:34.331562 IP 80.82.64.114.44806 > 59.167.x.36.53: 9158+ [1au] ANY? hizbullah.me. (41)
15:53:34.331785 IP 80.82.64.114.44806 > 59.167.x.32.53: 9158+ [1au] ANY? hizbullah.me. (41)
15:53:34.332050 IP 80.82.64.114.44806 > 59.167.x.39.53: 9158+ [1au] ANY? hizbullah.me. (41)
...
15:58:56.288188 IP 122.136.196.116.34195 > 59.167.x.32.53: 17253+ [1au] A? 4fwhk.com. (50)
15:59:23.345810 IP 122.136.196.116.28558 > 59.167.x.34.53: 28322+ [1au] A? 4fwhk.com. (50)
...

There are a couple of indicators that these logs are "odd":

- ANY queries are unusual in normal DNS traffic. While they are valid, they are not often used in "normal" DNS traffic. But for DoS attacks, they provide large responses.
- the source port and the query ID doesn't change
- the speed of these queries is very fast.

The main "feature" of hizbullah.me becomes obvious if you look at the size of the response:

I removed most of the "A" record responses. There are a total of 243 if I counted right. The response is 3992 bytes, almost 100 times the size of the query (41 bytes). You also see at the top how dig indicates that it had to fall back to TCP because the response was too large. Many modern resolvers don't require this, and use EDNS0 to allow larger responses, typically up to 4kBytes in size.

The hizbullah.me domain appears to be set up just to act as a source of large DNS responses to be used in DoS attacks.

The second record no longer resolves. I can only assume that it was used similarly. The "ANY" query is not needed for a domain like hizbullah.me with many A records. Just an A query will result in a huge answer.

------

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

Update

From Avira (http://techblog.avira.com/2013/10/08/major-dns-hijacking-affecting-major-websites-including-avira-com/en/)

-----------

The home page of anti virus company Avira has been defaced, likely by altering the DNS zone for Avira.com. Currently, avira.com uses the following NS records:

$ dig +short avira.com NS
ns2.radioum.com.br.
n1.ezmail.com.br.
ns1.radioum.com.br.
n2.ezmail.com.br.

$ dig +short A avira.com
173.193.136.42

Once an attacker has control of the NS records, they may also change MX records and redirect e-mail, or in the case of an Antivirus company like Avira change the addresses used to download signature updates.

According to domaintools.com, the last address for avira.com was 62.146.210.2 and that address still appears to host Avira's site.

NS1.AVIRA-NS.NET
NS2.AVIRA-NS.DE              195.34.161.132
NS3.AVIRA-NS.NET
NS4.AVIRA-NS.DE              212.7.178.67

Our reader Stuart sent us a screenshot with a similar defacement of Antivirus vendor AVG (avg.com), but the site appears to be back to normal now. I can't tell if that defacement was DNS related or not. Instant messaging software maker Whatsapp was appearently a third victim of this attack. 

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

Another interesting twist was that once it was detected that the packet was dropped they fragmented the packets in order to attempt to circumvent the FW/IPS in place.

If you see similar please let us know.  I'd be interested to compare the samples.  In the mean time these requests will be fairly obvious in your web logs, so should  be easy enough to pick out.  

Happy hunting

Mark  

CSAM Week 1 Recap

We kicked off the tenth annual Cybersecurity Awareness Month with the official theme of ‘Shared Responsibility’.  We all succeed by furthering the education and awareness of the community we live as a whole, not just the technical folks.   Adrien talked earlier this week about how we at the Internet Storm Center are all about logs, and the basis for much of our work has always been the Dshield project.  The Dshield database of information is provided by everyone who contributes, thus supporting the efforts of the ISC. 

The other half of the equation for the ‘Shared Responsibility’ of the Internet Storm Center is the Handlers. The Handlers of the ISC are all volunteers, with day jobs to take up the other half of our brains not committed here.  Of course the ISC is not the only volunteer opportunity that we as security professionals can actively engage to bring our expertise and experience together to share amongst ourselves and others.  One that comes to mind that is active in many areas across the globe is the Information Systems Security Association. 

Where else can we help? Submit your comments to us below, and help spread the word!

Tony d0t Carothers --gmail

A few of us have noticed that there have been no eNotifications from Adobe for account resets or any sort of direct notice. Has any of our readers had 'any' sort of notice/notification or resets sent?

Richard Porter

--- ISC Handler on Duty

The Log today came from a Web Hosting control panel software, the popular cPanel.  

While there are a couple of exploits for the control panel itself, today we will analyze a portion of log generated by the CSF. 

CSF is the ConfigServer Firewall plugin for cPanel. It basically works like a log checker for difference daemons in the system and checks the logs for different services like SSH, STMP, FTP,etc...

Once it identifies possible malicious behavior, it can take some actions like block the offending IP.

The log we received today is below:

lfd: blocked 113.78.38.218 (CN/China/-)
Time:     Fri Oct  4 02:59:09 2013 -0400
IP:       113.78.38.218 (CN/China/-)
Failures: 5 (smtpauth)
Interval: 300 seconds
Blocked:  Yes

Log entries:

2013-10-04 02:58:54 courier_login authenticator failed for (pc07) [113.78.38.218]:2622: 535 Incorrect authentication data (set_id=xedofghj)
2013-10-04 02:58:55 courier_login authenticator failed for (pc07) [113.78.38.218]:2622: 535 Incorrect authentication data (set_id=xedofghj)
2013-10-04 02:58:58 courier_login authenticator failed for (pc07) [113.78.38.218]:2622: 535 Incorrect authentication data (set_id=xedofghj)
2013-10-04 02:59:00 courier_login authenticator failed for (pc07) [113.78.38.218]:2622: 535 Incorrect authentication data (set_id=xedofghj)
2013-10-04 02:59:03 courier_login authenticator failed for (pc07) [113.78.38.218]:2622: 535 Incorrect authentication data (set_id=xedofghj)

--

Basically what it says is that this IP address: 113.78.38.218 was blocked because it had 5 invalid logins in less than 5 minutes (300 seconds).

Lets break the log message to understand it better. 

The first part if about the description of the event:

--

lfd: blocked 113.78.38.218 (CN/China/-)
Time:     Fri Oct  4 02:59:09 2013 -0400
IP:       113.78.38.218 (CN/China/-)
Failures: 5 (smtpauth)
Interval: 300 seconds
Blocked:  Yes

 --

This shows that the IP 113.78.38.218, which according the geolocation belongs to China, had 5 failure attempts to login. The service targeted is the SMTPAUTH, which is used to provide authentication to the SMTP service (email).

The time threshold set in this case is 300 seconds, and the action is to block.

This can be modified at: 

Plugins-> ConfigServer Security & Firewall-> Firewall Configuration-> Login Failure Blocking and Alerts

 If you disable it, remember that you will be unable to detect bruteforce attempts against your system, so you may want to fine tune it before think about disable.

Btw, do you recognize this IP as a bad offender?

--

Pedro Bueno (pbueno /%%/ isc. sans. org)
Twitter: http://twitter.com/besecure

You have probably seen now the stories about Adobe being breached, customer data being exposed and source code leaked. Excellent work by Brian Krebs in uncovering these breach and he has a great write-up about this here: http://krebsonsecurity.com/2013/10/adobe-to-announce-source-code-customer-data-breach/

But what does this mean for you? Does this affect you as an Adobe customer? Here are a couple of questions that keep coming up.

1 - How did they get in?

It appears a vulnerability in Coldfusion was used to breach an Adobe site used for payment processing. The group that breached Adobe appearantly used Coldfusion exploits as one of their favorite tools to breach sites. Again, see Brian's excellent work above for more details.

2 - I am a Coldfusion user. Should I worry?

Yes

3 - How do I protect myself as a Coldfusion user?

Make sure you are patched. Coldfusion had some significant vulnerabilities that were patched a few months ago (in particular the patches released around May). If you haven't patched those problems yet, then you should probably call this an "incident". But then again, Incident Response is so much more exciting then operations.

4 - Should I chang hosting platforms from Coldfusion to something else?

Probably not. It is a ton of work to switch platforms. This time and effort is better spent shoring up your existing infrastructure. What controls do you have in place to detect a breach? How many Coldfusion servers do you have? How are they patched? Do you store confidential information on those servers that you don't really need on those servers?

5 - Do I need to change my passwords?

No. Adobe already changed your password on Adobe's site. If you are still using the same password on multiple sites: You are doing it wrong. Changing your password will help you as little as changing underwear if you don't clean it between uses.

6 - Do Ineed to worry about my credit card if I used it with Adobe?

You should always worry about your credit card. But for the most part, this is your bank's problem. Relax, watch your statements, get a new card if you see odd charges or if your bank notifies you. You used a Debit Card online? Brave! You probably also don't like seatbelts and eat supermarket puffer fish sushi.

------

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

So far, we got pre-announcements from Microsoft and Adobe.

Microsoft promises 8 bulletins, split evenly between critical and important. The critical bulletins affect Windows, Internet Explorer and the .Net framework, while the important bulletins affect Office and Silverlight.

So this sounds like an average, very client heavy patch Tuesday. On the server end, only Sharepoint server (again) and Office Server are affected.

Important: The cumulative IE update included will include a patch for CVE-2013-3893, the currently un-patched but exploited vulnerability in Internet Explorer. This bulletin should be applied as soon as possible once released.

For details, see http://technet.microsoft.com/en-us/security/bulletin/ms13-oct

Adobe pre-announced only one patch for Acrobat and PDF Reader. For details see http://blogs.adobe.com/psirt/2013/10/prenotification-upcoming-security-updates-for-adobe-reader-and-acrobat-apsb13-25.html

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

Today's logs come from a honeypot. The fun part about honeypots is that you don't have to worry about filtering out "normal" logs. Usually I check the honeypot for anything new and interesting first, then look on my real web server to figure out if I see similar attacks. In the real web server, these attack would otherwise drown in the noise.

SSL Conection to a web server not supporting SSL

Invalid method in request \x80w\x01\x03\x01

The first few bytes of the request are interpreted as the method of the request. If SSL is used by the client, but the server "doesn't get it", then the server will just log the first few bytes of the SSL message. In this case, this was \x80w\x01\x03\x01

Odd URLs

File does not exist: /var/www/HNAP1

Frequently you will find attack scripts that try to "hunt" for a particular vulnerability, wether or not you even have the application installed. This is in part behind our 404 project. Above, the attacker looked for "HNAP1", which appears to be vulnerable in some routers (see http://www.cathaycenturies.com/blog/?p=643 for more details about this particular vulnerability.

Odd User Agents

Mozilla/3.0 (compatible; Indy Library)
Mozilla/5.0 (compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij

The first one "Indy Libary" is a standard library used in many web attack tools. The second one is old favorite nmap and the last one is Havij, a script kiddie SQL injection tool (not seeing it as much as I used to). In pretty much all cases it is easy to change the user agent, but most attackers don't bother to.

Sometimes the user agent string itself is the attack. like in this log:

"GET /rssfeed.xml HTTP/1.1" 200 5162 "-" "><script>alert('XSSUserAgent')</script>" "-"

The attacker may hope that the user agent is echoed back to the administrator as part of an admin interface.

Standard SQL Injection Strings

GET /diary.php?storyid=999999.9+union+all+select+0x31303235343830303536--
GET /diary.php?storyid=1480%27
GET /diary.php?storyid=1480+and+1%3D1

Many SQL injection attack tools use similar techniques. The examples above are from Havij. Typically the attacker will try to insted single quotes (%27) or try to issue UNION requests with random parameters to be able to identify any data that may come back. For the union requests, you will see the attack starting with one column and work its way up as the attacker attempts to figure out how many columns your query returns.

Cross Site Scripting

here is a typical XSS attempt:

GET /diary.html?storyid=\"><script>alert(13377331)</script> HTTP/1.0"

Not much obfuscation here. Just a pretty plain XSS attempt. 

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

In the last 24 hours, DomainTools reported to us that over 50 domains related to the US Government Partial Shutdown have been registered.  About a third of those are partisan oriented, most of the rest are parked.  During the same time period, ver 40 domains were registered relating to the Affordable Care Act (colloquially known as Obamacare).  So far, no spam has shown up on either subjects which was surprising to many of us that monitor these trends.

While those specific data points are US-oriented, the lesson generally is not.  Whenever there is a major event there is usually a corresponding uptick in new domains registered related to those events and spam campaigns.  The advice to users is the same, don't click on random emails and if you want to do business online, always affirmatively type in the URLs of known entities instead of using email or website links.  The federal insurance exchange website is healthcare.gov, for instance.  Other sites proclaiming they are *the* federal exchange are likely less than honest, especially if they are anything other than a .gov.

What makes these campaigns successful is an uptick in media coverage and popular awareness, especially if there is a visual component.  One of the most successful campaigns of this type was a spam campaign related to the capture of Osama Bin Laden and links the purported to be pictures or videos of the event.  The Boston bombing is another example.  What makes the potential for Obamacare related scams to work is stability of the new site combined with some confusion to the details of the new law.  Where there isn't clarity, fraud is possible.

The awareness type for those that support users is that any time something like this happens is to review with users the same tips: don't click on links, go only to known websites and let them know online miscreants will use popular interest in subjects to infect them with malware.

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

As Adrien mentioned, we are trying to focus on "interesting" logs during October to celebrate "Cyber Security Awareness Month". For security professionals is is important to be aware of what your logs are trying to tell you. We are no looking for ground breaking new events, but just the "stuff you always wondered about what it meant".

I am starting today with a couple of DNS logs. If you haven't seen logs like this yet: You are not doing your job well protecting your network ;-)

I kept the logs as original as possible, but masked out a few IP addresses using "X" and some hostnames with 'example.com'.

1 - RFC 1918 Response

Oct 2 14:32:36 nsint named[31794]: client X.X.X.X#50873: RFC 1918 response from Internet for 1.10.64.10.in-addr.arpa

In this case, one of my internal hosts tried to reverse reolve the address 10.64.10.1. 10.0.0.0/8 is however reserved address space per RFC 1918, so this lookup just doesn't make much sense. The DNS server (named) is warning me about this lookup.

2 - FORMERR

Oct 2 14:16:01 nsint named[31794]: error (FORMERR) resolving 'ocsp.verisign.net/AAAA/IN': 199.7.59.206#53

One of my hosts tried to connect to ocsp.verisign.net. "OCSP" is a web service used to check if certifiates are valid. You will see connections to this host name from your browser as you visit some HTTPS sites. My network is dual stack, so hosts will attempt IPv4 (A) as well as IPv6 (AAAA) address lookups. Looks like Verisign doesn't support IPv6 and doesn't know what to do with AAAA queries so it is sending a format error (FORMERR) back. This caught my eye because of the security relevance of OCSP. But then again, there is nothing I can or have to do about this error.

3 - DHCP Dynamic Updates

Oct 2 14:27:25 nsint named[31794]: client X.X.X.X#38155: signer "dhcpkey" approved Oct 2 14:27:25 nsint named[31794]: client X.X.X.X#38155: updating zone 'example.com/IN': deleting an RR at laptop.example.com TXT

My DHCP server is configured to update DNS whenever it sees a new host. To authenticate and encrypt these updates, it uses a key (I call it "dhcpkey"). Since the request came from the DHCP server (masked IP address) and was approved, all is well and this is normal. I would be concerned if these requests get rejected and/or came from an IP address different then the DHCP server.

Here is a log entry for a denied update:

Oct 2 14:03:40 nsint named[31794]: client 10.5.0.254#53419: update 'lexample.com/IN' denied

In this case it turned out to be a misconfiguration of the respective zone. Remember: Watching your logs not only keeps attackers out, but also makes your network perform better!

4 - REFUSED

Oct 2 12:47:53 nsint named[31794]: error (unexpected RCODE REFUSED) resolving 'example.com/A/IN': 206.127.24.8#53

Here a name server I connected to to lookup example.com refused the query. Odd, as the domain was valid. Could be a misconfigured DNS server, or a network device (Anti-DoS?) interfering with the query.

Got any other DNS logs?

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

Most of us are familiar with the "microsoft support" call.  A phone call is received, the person states they are from "microsoft support" and they have been alerted that your machine is infected.  The person will assist you by having you install a remote desktop tool such as teamviewer or similar (we have seen many different versions).  

Previously they would install software that would bug you until you paid the "subscription fee".  As the father of a friend found out the other day, when he received a call.  They now install ransomware which will lock the person out of their computer until a fee has been been paid.  In this instance it was done quite early in the "support" call so even disconnecting when smelling a rat it was to late.  

The ransomware itself looks like it replaced some start up paramters to kick in the lockout rather than encrypting the drive or key elements of the machine.  However for most users that would be enough to deny access.  

So in the spirit of Cyber Security Awareness Month make this month one where you let your non-IT friends and family know two things.  Firstly, BACKUP YOUR STUFF.  Secondly, tell them "when you receve a call from "microsoft support", the correct response is to hang up.".    

Cheers

Mark H

Metasploit has just released a module to exploit the currently unpatched CVE-2013-3893 vulnerability in Internet Explorer.  This vulnerability can be used for remote code execution if you can get a user to go to a specifically crafted webpage.  Microsoft has released a FixIt that should be deployed for this vulnerability for 32-bit versions of IE.  EMET is also available as a mitigating control.

With a metasploit module out there, we can now expect commodity exploitation out there available to the low-rent script kiddie community.

See our previous handlers diary on the subject by Russ McRee here.

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

Today is the beginning of Cyber Security Awareness Month. Apparently the month's official theme is "Our Shared Responsibility," We at the SANS Internet Storm Center want your logs! Send us packets, malware, all your logs, log snippets, observations, things that go bump on the 'net, things that make you go HMMMM, or just send us email to discuss InfoSec. What can we do as individuals to increase information security and encourage secure practices among co-workers, friends, and family? Let us know via our Contact Us page, or the comments below.

This year our theme is 'wierd. wonderful, and interesting stuff in logs'. In past years here have been some of our themes:

https://isc.sans.edu/tag.html?tag=Cyber%20Security%20Awareness%20Month%202010 - awareness
https://isc.sans.edu/tag.html?tag=Cyber%20Security%20Awareness%20Month%202011 - critical controls
https://isc.sans.edu/tag.html?tag=Cyber%20Security%20Awareness%20Month%202012 - theme was "standards"

You can watch NCSAM in the USA go live at the following Facebook URI: https://www.facebook.com/staysafeonline/app_142371818162
 

Let's be careful out there!

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

A host may now add a new subflow, and this subflow will be authenticated using a hash derived from the keys exchanged earlier, and nonces that are unique to each new subflow. The MP_JOIN option is used to carry this data. Throughout the connection, hosts may inform each other of newly acquired addresses and they may use the for new subflows. Since each subflow has its own set of sequence numbers, "Data Sequence Signals" are used to communicate how the sequence numbers in the subflow map to the combined data flow. The protocol has a lot of little details that make it well suited for hosts connected to multiple wireless networks. For example, different subflows may have different priorities. One usage scenario is a cell phone connected to a Wifi as well as a cellular network, and roaming between the two. For example, you start a TCP connection at home, and continue using it as you leave the house and your phone switches to the cellular network. As long as both networks are available for a while, MPTCP may drop the Wifi connection and exclusively use the cell phone data connection until you reach another WiFi network. But enough about how the protocol works, here are some packets. A quick BPF to capture these packets (for example with tcpdump):

tcp[12]&0xf0=>0xe0

It is not perfect, but because the options involved are rather large, you will find MPTCP packets by looking for larger TCP header sizes. This filter looks for a header size of 56 and above, with 60 being the maximum (you don't really need the bitmask for the filter). Wireshark and tshark deal rather well with MPTCP. For example, tshark displays for the TCP options:

        Multipath TCP: Multipath Capable
            Kind: Multipath TCP (30)
            Length: 12
            0000 .... = Multipath TCP subtype: Multipath Capable (0)
            .... 0000 = Multipath TCP version: 0
            Multipath TCP flags: 0x01
                0... .... = Checksum required: 0
                .... ...1 = Use HMAC-SHA1: 1
            Multipath TCP Sender's Key: 8848941202347829228

16:44:15.681318 IP 70.91.145.11.57799 > 17.174.8.5.443: Flags [S], seq 847601216, win 65535, options [mss 1460,nop,wscale 3,Unknown Option 3000017acdc123cc42a7ec,nop,nop,TS val 102569696 ecr 0,sackOK,eol], length 0

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