Bittorrent is a great tool to download large files. If the transfer is interrupted you haven't lost anything. The transfer will continue once you restart the download. There is however the other use of bit torrent and let's face it, probably one of the biggest uses of bit torrent, is to download copyrighted movies, music, books, etc.  Now regardless of where you stand on the issue of artist rights , music/movie distributors, etc, etc, as security professionals you are in the position of having to control traffic in and out of your organisation, including torrent traffic.
So what are your options? We will get the easy answer out of the way first, block all outbound traffic or proxy everything via a proxy server, but that doesn't solve all of our problems.  The first challenge is that many torrent applications proxy over http or https, how do we detect these? The second problem is that there will be people in your  organisation that will have a static IP and direct access to the Internet. Some applications just, don't play well with proxies and exemptions have to be made. How do you prevent these users from accessing torrents? How do you control torrent downloads that are legit and should be permitted and prevent the bad?

If you have a commercial content filter, then it may be able to detect torrent traffic in http or https. If you have an IDS or IPS it may be able to alert on p2p traffic in the environment. If you have application aware firewalls there may be a signature that can be applied to traffic to detect torrent traffic. If you have traffic shaping devices they may be able to distinguish torrent traffic on the network and take some action.  You can control user desktops and prevent them from installing applications, although many torrent apps will run with just the executable and don't need installation or can be run off a USB.
Distinguishing between a good torrent and a bad one? I haven't found anything that works well. URL filtering gives some measure of control, but isn't fool proof.

What measures do you take and are they working for you?  Let us know.

Mark H

ISC reader Keith reports a "strange packet" on his network. He gets the following alert

9/28/2010 2:09 PM : C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET 272: Sep 28 19:09:41: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 5 times)Packet received with invalid source MAC address (45:42:55:47:3D:57) on port Po1 in vlan 24

and the following packet to go with it:

0000 3d 3d 4b 56 3d 44 45 42 55 47 3d 57 26 4c 3d 3d
0010 64 61 79 6c 69 67 68 74 20 72 65 6b 69 63 6b 21
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00

No surprise really that this packet is "illegal". When parsed into plain ASCII, it reads

==KV=DEBUG=W&L==
daylight rekick!

Has anyone seen this before and might know what sort of device could be burping out these non-IP packets directly onto the VLAN?

Microsoft Bulletin MS10-070 has been released. An update is now available that addresses the ASP.NET "information disclosure" vulnerability (CVE-2010-3332) that we reported on earlier 

The core piece in the advisory is probably in the section that reads

"In Microsoft .NET Framework 3.5 Service Pack 1 and above, this vulnerability can be used by an attacker to retrieve the contents of any file within the ASP.NET application, including web.config"

Translated, this means that the vulnerability undermines basic web application security. I suspect that online shops and such might rate the risk that "an attacker can read any file" on their web application server a bit higher than just "important".

According to the bulletin, MSFT are aware of "active attacks".

In combination, this sure sounds like PATCH NOW! to me.

While the media at large is all agog at Stuxnet, they probably would do better to keep their writers looking at Zeus. Zeus/Zbot must be one of the most successful banking trojans ever. It's been around for three (four?) years, and no doubt has made some of its originators very very rich. McAfee last week published a write-up on the capabilities that come with the recent Zeus Build-kit. Yes, there's an actual application that allows to create custom versions of Zeus. If you're an online banking user who feels safe because your online bank uses one-time passwords, or because it sports one of these cute "on-screen keyboards", think again: Zeus got them all in the bag. Brian Krebs regularly reports about the latest frauds linked to this family of malware. Recently, he wrote about a church that lost 600k$ from their accounts to key-logging malware. 

Somehow, it looks like the banks either don't care, or don't grasp the concept of "defense in depth", or both. Here's four simple measures that would make online banking fraud a whole lot harder:

* Changing my email address / mobile phone number on file can only be done by visiting my bank branch in person
* Changing them triggers an email/SMS to the old address
* Adding a new payee that was never before used triggers an email/SMS
* A new payee can only be used for a payment or transfer 7 days after it has been added

There, dear banks: All of this can be implemented basically for free. You can even allow your customers to opt-in voluntarily. You'll be surprised how many of them do so - you know, folks and organizations who actually earn their money the hard way seem to oddly enough care a whole lot about keeping it safe.  

I have no doubts that a new Zeus version would find a way around these measures eventually. But if you don't fight, you already lost. Banks, get off your collective behinds, and evolve, please.

Microsoft is going to release an Out-of-Band Security bulletin tomorrow, 28 September 2010, which will address a security vulnerability in ASP.Net affecting all current versions of Windows.

References:

http://www.microsoft.com/technet/security/advisory/2416728.mspx

http://blogs.msdn.com/b/sharepoint/archive/2010/09/21/security-advisory-2416728-vulnerability-in-asp-net-and-sharepoint.aspx

http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx

Keep an eye on this one folks! More information is surely to follow.

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

Didier Stevens (of pdf-parser.py fame) has published a 23-page paper on how to analyze nasty PDFs. While the content is a bit dated and the attackers have added more insidious exploit obfuscation to their arsenal since, the document explains all the concepts that are still valid and useful whenever you encounter a suspicious PDF today.  If you're into PDF analysis (and even if you aren't :), this is a must-read.  http://blog.didierstevens.com/2010/09/26/free-malicious-pdf-analysis-e-book/

Corporations and institutions are spending a lot of money to keep their data and voice networks protected against unauthorized access. Surprisingly enough, a lot of them seem to care a whole let less about which wireless head-sets their staff uses. A wireless head-set is, by definition, wireless, which means that anyone else in range of the signal can potentially listen in. The same rules as with WiFi apply: If the signal is not encrypted, or the encryption can be trivially broken, you are basically playing broadcast radio station for your neighborhood. All that's needed for the attacker is a 100$ "Scanner" available at every *mart and *shack.

This is by no means a new problem, but one that is still quite prevalent. And I'm not talking about the baby monitors that broadcast your neighbor's kid's annoyance over its first tooth, even though these can be a serious privacy concern, too. I'm talking about hospital, university, corporate wireless head-sets, bought in the cheap, without any regard to what sort of signal and transmission security these products actually use. If this sounds like your firm or institution, it might be a good idea to spend an hour on Monday to google for the products in use and and to find out for sure if your phone equipment acts as a broadcast radio station.

Both Egosurfing and Googledorks are nothing new, of course. Large corporations nowadays retain marketing firms to do search engine analysis for them, but these marketing firms focus on, well, marketing and branding issues only. They are unlikely to ever tell you that your web site shares that Excel with the customer names or that student application form with the SSNs.

To make sure, go ego-surfing for your company or organization every now and then. Search for the domain name ("site:mydomain.com") and then narrow down the results by using Google's advanced search operators, like "filetype:xls". GoogleGuide has a good list and description of the search operators that Google supports.

You can also use the basic exclusion technique ("-hay -grass -weeds") to whittle down the haystack until only the needles are left. This approach works particularly well if you don't quite know what you are looking for.

One caveat: Keep at this for long enough, and Google's dork-defense will kick in, and refuse to answer your search queries because they think you are a bad guy out looking for ways to attack your organization. So, just in case, do not perform these searches over an internet access that you share with others, as its IP address might become temporarily blocked by Google.

For a change of pace today I am presenting a guest diary.  This diary provides a brief summary of work done by Andrew Hunt, a recent GIAC Gold Paper author.    His paper, Visualizing the Hosting Patterns of Modern Cybercriminals, is currently featured in the SANS InfoSec Reading Room. It describes tools and techniques that can be used to mine and visualize DNS information to aid in analyzing and potentially blocking malicious traffic.  His work builds on work done by Chris Lee of Georgia Tech and fellow handler Bojan Zdrnja of University of Auckland.

---

Andrew Hunt is a seasoned information security practitioner of more than ten years across government, health, and private sectors. A graduate of Arizona State University, he also holds GCIH, GCFA, GREM and CISSP certifications. Andrew has contributed information in support of several SANS Internet Storm Center diaries and a short section on Javascript deobfuscation to Lenny Zeltser's SANS Reverse Engineering Malware course.

----

Criminals operating on the Internet face little recourse for their actions. Hosted IP addresses are inexpensive and easy to acquire. Domain names are trivial to register and change. However, criminals are like most business people, pursuing the most efficient path to profit with the least amount of reinvestment. This indicates that their patterns of hosting may be mapped, and perhaps even predicted.

When passive authoritative domain query responses, cached BGP data, and geolocation information are married together, it becomes apparent that malicious hosters employ the same techniques as their legitimate counterparts to maximize profits: shared services, redundancy, favored service providers and favored jurisdictions. Visualizing these commonalities can intimate the repuation of services from the macro ASN to micro IP layers. Having this information combined with the typical access patterns and policies of their organization, an anlayst can make a more appropriate decision as to what actions are most effective to deal with an identified threat and its potential relations.

For example when seed data pulled from Malware Domains is correlated with passive DNS and ASN data, then visualized, it is possible to see how the majority of the authoritative nameservers are hosted in the same network block. This dependence indicates an investment by the aggressor into a particular hosting company and can provide an effective network-level block at relatively low cost. As always, be aware of potential collateral damage when blocking a network portion that may also contain legitimate IP hosting space.

If you are interested in more information on how this analysis was performed please see the full version of the paper, "Visualizing the Hosting Patterns of Modern Cybercriminals" at the SANS Reading Room.

 

 UPDATE: It turns out there is a minor error in Andrews paper.  His paper references malwaredomainSlist.com instead of malwaredomainlist.com.  The latter is the correct address.  The former URL has in the past had some naughtiness accompanying it, but it has been abandoned. Andrew has registered this domain and plans to redirect it to malwaredomainlist.com.

 

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

Since the news of Stuxnet has reached the popular media, it's probably time for a quick diary on the subject. Securnia has write-ups on two of the unpatched security vulnerabilities that allow privilege escalation that Stuxnet relies on here and here.  Symantec also has a series on Stuxnet that you can read up on here.  While Stuxnet does use the LNK vulnerability, it existed before then using other modes of infection (for instance, via USB keys).  Another interesting note is that it exploited one of the same vulnerabilities that Conficker did.  Among other things, Conficker was a real problem for embedded systems (particularly those embedded systems that ran Windows).  Hospitals and health care facilities had a lot of trouble with Conficker, for instance, with their equipment.

One of the working theories is that Stuxnet was designed to attack Iranian facilities and may have had it's origin in Israel.  It's important to note that initial statistics showed that India and Indonesia made up a higher precentage of compromises than Iran but around the end of July, Iran had the bulk of infections. 

Assuming it is an attempt to attack the Iranian facilities, I suppose it's better to launch a cyberattack than to go all Osirak circa 1981.  But the moral and philosophical implications are probably best for another venue. 

An important thing to note when it comes to cyberwar, there is a lot of hype that attempts to make this a more dangerous threat than it probably is (at this specific point in time).  A healthy dose of skepticism is warranted, in part, because with any cyberattack it is very difficult to determine who is really behind an attack or why.  Incident responders only have (and can only get) a piece of the information, what the attack attempts to do and the forensic details of that attack.  Forensically examining a botnet C&C to determine who was behind it and what happened historically gets to be much more difficult. The reasons for that are as much legal and practical as they are technical.  Simply put, most "bad people" know to operate in jurisdictions least likely to cooperate with "the good guys".

What we do know is that many countries and organizations are looking for ways to use electronic ifnrastructure to cripple opponents and that this is not a new development.  Information systems have always been a rich target for espionage.  Sabotage has always been an element of covert warfare as well.  In so far as elements of our critical infrastructure depend and/or are controlled by information systems, electronic sabotage becomes a more real possibility.  In the current case, however, Stuxnet being a tool of cyber-sabotage is a theory that fits the facts but far from the only theory.  In short, the jury is still out.

At this point, most common malware detection tools will detect this. However, one of the key infection mechanisms early-on was USB keys.  A popular mode of pen-testers to test an organization is to drop USB keys in a parking lot, send "free" keys in with vendor logos and the like to get individuals in an organization to plug USB keys into the organizations network.  This is an easy to defect vector of attack by employing security education, USB port security and disabling AutoRun.  It's trivial to use USB keys and to create custom malware that will bypass all AV.  It's also easy (but not trivial) to shut down this vector.  For larger organizations, the solution may be to simply distribute your own "branded" USB keys for users to move data around which may be a proper balance between security and usability.

--
John Bambenek
bambenek at gmail /dot/ com

How can I possibly try to out-do the great diary Rob posted?  I can't so I'm not even going to try.

Instead, and because it's been sl .. err, qu ... err ... not particularly eventful, not that we're superstitious or anything, here is a quick forensic challenge for everyone.

The first person to correctly identify this and tell me the three things that are wrong will win fame, fortune, the undying admiration of everyone who visits us and, best of all .. a ISC sticker!  ;)

000000000   EB 52 90 4E 54 46 53 20  20 20 20 00 02 08 00 00
000000010   00 00 00 00 00 F8 00 00  01 00 01 00 00 00 00 00
000000020   00 00 00 00 80 00 80 00  FF FD FF 00 00 00 00 00
000000030   00 00 0C 00 00 00 00 00  DF FF 0F 00 00 00 00 00
000000040   F6 00 00 00 01 00 00 00  01 8A F4 BC D1 F4 BC FA
000000050   00 00 00 00 FA 33 C0 8E  D0 BC 00 7C FB 68 C0 07
000000060   1F 1E 68 66 00 CB 88 16  0E 00 66 81 3E 03 00 4E
000000070   54 46 53 75 15 B4 41 BB  AA 55 CD 13 72 0C 81 FB
000000080   55 AA 75 06 F7 C1 01 00  75 03 E9 D2 00 1E 83 EC
000000090   18 68 1A 00 B4 48 8A 16  0E 00 8B F4 16 1F CD 13
0000000A0   9F 83 C4 18 9E 58 1F 72  E1 3B 06 0B 00 75 DB A3
0000000B0   0F 00 C1 2E 0F 00 04 1E  5A 33 DB B9 00 20 2B C8
0000000C0   66 FF 06 11 00 03 16 0F  00 8E C2 FF 06 16 00 E8
0000000D0   40 00 2B C8 77 EF B8 00  BB CD 1A 66 23 C0 75 2D
0000000E0   66 81 FB 54 43 50 41 75  24 81 F9 02 01 72 1E 16
0000000F0   68 07 BB 16 68 70 0E 16  68 09 00 66 53 66 53 66
000000100   55 16 16 16 68 B8 01 66  61 0E 07 CD 1A E9 6A 01
000000110   90 90 66 60 1E 06 66 A1  11 00 66 03 06 1C 00 1E
000000120   66 68 00 00 00 00 66 50  06 53 68 01 00 68 10 00
000000130   B4 42 8A 16 0E 00 16 1F  8B F4 CD 13 66 59 5B 5A
000000140   66 59 66 59 1F 0F 82 16  00 66 FF 06 11 00 03 16
000000150   0F 00 8E C2 FF 0E 16 00  75 BC 07 1F 66 61 C3 A0
000000160   F8 01 E8 08 00 A0 FB 01  E8 02 00 EB FE B4 01 8B
000000170   F0 AC 3C 00 74 09 B4 0E  BB 07 00 CD 10 EB F2 C3
000000180   0D 0A 41 20 64 69 73 6B  20 72 65 61 64 20 65 72
000000190   72 6F 72 20 6F 63 63 75  72 72 65 64 00 0D 0A 42
0000001A0   4F 4F 54 4D 47 52 20 69  73 20 6D 69 73 73 69 6E
0000001B0   67 00 0D 0A 42 4F 4F 54  4D 47 52 20 69 73 20 72
0000001C0   65 73 02 63 6F 6D 73 65  64 00 0D 0A 50 72 65 73
0000001D0   73 20 43 74 72 6C 2B 41  6C 74 2B 44 65 6C 20 74
0000001E0   6F 20 72 65 73 74 61 72  74 0D 0A 00 00 00 00 00
0000001F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

Christopher Carboni - Handler On Duty - isc dot chris at gmail dot com

As a self confessed and self described "Network Person", I design and build redundant systems every day.  The kind of  systems where you can lose entire racks and still be up, where you can do upgrades and reboots without down time.  What  struck me recently is two things: 

A big part of this job lately seems to be in education - going over redundancy and recovery mechanisms and options with clients in  advance of doing a design, and certainly well before a build.  While many of these mechanisms have been with us for years,  in many large companies decision makers don't seem to be aware of what is available to them, native on the box and for free.

The other thing that struck me is that even when I'm "preaching to the choir" - when the folks I'm working with know what  their gear can do, and in many cases have already built their infrastructure the right way - people aren't aware of the  security implications of the tools we use to make our infrastructure reliable and/or redundant.  Each thing we do to make  things better gives an attacker another method to attack or compromise things.

I recently heard this described as "Thinking  Backwards", and can't think of a better way to describe this aspect of things.  (from SANS SEC542 Audio, Kevin Johnson and an unnamed student)

While I seem to be drawing the same "Enterprise 101" diagram a few times per week, lately it's been a coin toss whether it's  been for an "Enterprise 101" discussion, or an "Enterprise Attack / Defense 101" whiteboard talk.  This entire ball of worms seems like a good discussion for an ISC Diary.  I'll start the conversation with an "Enterprise  101" review, outlining each of the mechanisms we'll discuss.  In upcoming diaries, we'll tackle each of the reliability  methods, and discuss how they're sometimes not as reliable as you think they are, what security pieces they are missing, why defaults are BAD, and how  to secure them (if possible).

I'm hoping that our readers will help out.  If I've missed a topic you'd like to see, please let us know in the comment  form.  If I've overlooked a topic, or if I haven't explained things completely (or just plain errored out or otherwise  missed the boat), please use our comment form and fill us all in. 

Enterprise 101 - "The Good"

I'll start off this week with the textbook descriptions.  What the more common reliability methods are, what they do, why you  might implement them.  This discussion will be a tad non-technical, but don't worry, when we start breaking stuff in later diaries, we'll get to see some configuration examples, "real" tools and in some cases packets.  Even this high level conversation I think has a lot of value - lots of folks aren't aware of basic mechanisms for ensuring network availability.  With information security often defined in the context of the CIA triad (Confidentiality, Integrity and Availability), I find that we often neglect the "Availability" aspect - we tend to consider it as more of an operational thing than a security thing.  We'll base our discussion on the diagram below.  Again, if you'd like to see something added, please use our comment form - I'll update this diary based on comments.

At the heart of many of these protocols and methods is either a primary/backup concept, or an active/active pairing.  You'll start this as a pretty consistent pattern as we go through them.

Layer 3: HSRP / VRRP

What these protocols give you is layer 3 redundancy.  If the default gateway on a subnet should go offline, then no-one on  that subnet can access resources off of that network.  If things like DNS servers are affected in such an outage, it's  likely that even resources on that same subnet won't be accessible.  HSRP and VRRP are two protocols that allow you to set up another router (or layer 3  switch) as a backup to the primary.  If the primary fails, the backup takes over the gateway IP, and the clients on that subnet are none the wiser.  On most days what this means to the network maintainer is that hardware or software upgrades can be  done with minimal interruption, often during business hours (we all get enough late nights in this biz).

HSRP (Hot Standby Router Protocol) has been around forever, it's the Cisco answer to this problem.  VRRP (Virtual Router  Redundancy Protocol) is the open standards answer to this - the current version is defined in RFC5798 (previously in RFC3768  and before that in RFC2338).

Layer 2: Spanning Tree (and TRILL)

What spanning tree does is prevent loops in the network.  If a layer 2 frame is sent out on the wire, and the switch does  not have the destination MAC address in it's local table, it sends the packet to all of it's ports in hopes that somebody  will claim the packet and reply to it.  In a single switch environment, that's the end of it.  In a muliple switch  environment, this broadcast is potentially repeated on every switch in the environment.  The problem is that if you form a  loop  - in the simplest case, having two wires connecting a pair of switches - this process can easily repeat infinitely.   The frame will come in one port from switch A to B, then get forwarded back to switch A on the other link, then back to B  and so on.  In short order the network "melts" and becomes unusable, as these frames never go away.  In a complex network  loops may not be so simple or obvious, but the bigger the network the bigger the impact.   What spanning tree does is  simplify this - it defines a "root bridge", and creates a single, least cost path with no loops between all the switches.  Path "costs"  are determined in an algorithm based mostly on hop count and port speed, but can be overridden by configuration on the  boxes.  With a single path (the designated path) to every bridge on the network, frames to unknown destinations transit each  switch once, then eventually die if the destination host is not on the network.

In the case of a link failure on a designated path, the switches detect that the failure occurred, and one of the backup  links takes over (this gets a lot more complicated, stay tuned).

The obvious downside to this is that we tend to connect switches together using our fastest, most expensive links.  A pair  of 10GB links can really add up, cost wise, and even 1GB links can be expensive if it's over single mode fiber or long reach ethernet.  Plus it  seems a real shame to leave all that bandwidth idle "just in case".  The answer to this is a new standard called TRILL  (Transparent Interconnection of Lots of Links).  In a TRILL config, all of these links are live, and in it's simplest  explanation the switches discover and maintain an SPF (Shortest Path First) table of MAC addresses, which defines the best path in a multihop  environment from any source to any destination MAC address.  TRILL is bright-shiny-new, and is not yet widely deployed.  Some vendors have TRILL compliance  in their highest-end products, look for TRILL to show up in smaller switches over the next few years.

Layer 2: Etherchannel / LACP (802.3ad) / PAGP

Etherchannel is a common method of taking a few network links and "ganging them up" to make a faster link.  For instance, 4  100mbps links can be combined to make a faster channel.  The common misconception is that combining these links simply adds  them up - in our example, you'd think that 4x100 = 400Mpbs, but that's not the case.  What happens is that for every source  and destination, a path is chosen.  So all the traffic from host A to host B will take one link, and all the traffic from  Host A to C might take another.  This means that, in our example of 4 links, each conversation has 100 Mbps available to it, but 4 conversations can happen at once. 

The source and destination can be defined in several ways, commonly by IP address or MAC  address.  So if you have one large file copy or backup job, it'll likely only use one link.  Using Source/Destination MAC address for balancing etherchannel links is generally easier on the hardware, but keep in mind that the default gateway on any subnet has a single MAC, so if you're  communicating off your subnet, source/destination IP address might make better use of your multiple paths.

Spanning tree is disabled on Etherchannel links.  PaGP (Port Aggregation Protocol) is the Cisco implementation of  etherchannel.  LACP is the standards based protocol (802.3ad).

Layer 1/2 Redundancy on Servers - NIC Teaming

NIC teaming is redundancy at the hardware level for servers.  This is usually implemented by installing additional drivers, creating a virtual NIC, then adding the physical NICs to that to create a "team".  In most cases the team operates as an active/passive pair, where the passive NIC only kicks in if link fails (ie the cable is pulled) on the active.  However, there are usually more advanced options, up to and including support for 802.3ad (see etherchannel above).

Layer 3 Redundancy - Routing Protocol

Routing protocols offer LOTS of avenues for redundant paths and path selection based on various metrics.  They give us lots of ways of defining best paths between networks, combining links for performance and detecting and routing around failed links.

They also are, almost without exception, based on the "I trust you" model.  If you speak their language, you can reroute or hijack any traffic you want.  From an attackers perspective, the trick is to then send the traffic back on it's way, so that you can capture a useful datastream - simply being a black hole for packets doesn't accomplish anything, unless you are trying to DOS someone. 

There have been some noteworthy illustrations of intentional and accidental Denial of Service based on routing protocols - last month's BGP experiment-gone-wrong launched by RIPE-NCC and Duke for instance, or any number of BGP mistakes made by one ISP or another over the years (Pakistan's PieNet DOS of Youtube in 2008 comes to mind for instance).

What's next?

Look for ISC diaries coming up that discuss each of these topics in a lot more depth, from the perspective of defense against an attacker.  We'll try to break each one of them, and discuss how best to protect them from compromise.

I am teaching our Defending Web Applications [1] class this week, and yesterday, one of the students pointed me to a news release about Google implementing two factor authentication for its applications [2].

First of all, the mandatory primer on two factor authentication: Two factors means two authentication method groups. There are typically 3 different groups: Something you know (password), something you have (token), something you are (biometric). If you have for example a laptop login setup via finger print, you are still using single factor unless you also have to enter a password. And of course, two different passwords are not two factor. There is also the problem of users collapsing the tokens, by for example writing the password on the back of the smartcard. Now something you know becomes something you have.

Typically, implementing two factor authentication means buying tokens or smart cards for all of your users. This can be expensive (from what I have seen $50/user is typical in smaller deployments) and it is only manageable for users with whom you have an existing relationship (employees, in some cases customers). 

So how do you implement two factor authentication for "cheap"? Here are a few methods I have seen used:

Smart phone application as token, or other soft tokens

This is the route Google picked. The first time I have seen a system like that was OTP (one time password) tokens on old Palm PDAs. Of course, if you can turn the token into software, you could have a desktop application as well. Google appears to off the smart phone version only. The advantage of course is cost and ease of deployment. Once the application is written, it is pretty easy to deploy and there is no incremental "per user" cost making it ideal for a large deployment like Google. The disadvantage is the fact that it is software. It could be compromised by malware. It is very much possible for malware to "pull tokens" from the software to send them to an attacker. And attacker may even be able to clone the token without the user knowing. Verisign offers a free OpenID based system using phone based one time password tokens [4]. 

SMS Messages

It is pretty much free to send SMS messages via e-mail, in particular in moderate volume. SMS can be used to send a one time password to a phone. The advantage is again that you are using a phone the user already has and that the message travels out of band, at least the last step to the user. The cell phone becomes "something you have". The main disadvantage I have seen is that SMS is not totally reliable. Messages may be delayed or if you don't have reception you don't get the message. One could potentially implement a similar system using voice calls using for example an Asterisk server. This is still pretty cheap but probably not as easy to implement (Phonefactor offers a commercial solution like this [3]). Another problem may be the cost the user has to pay for incoming SMS messages. These days of course one could use a Google voice account to receive the SMS messages, removing the out of band advantage.

Paper based tokens

Print a sheet of paper with one time passwords. This works pretty well. I once had a bank in Germany back in the 80s that used just a system like this, and I believe still does. Very cheap to implement even on a larger scale, and hard to attack by malware. However, easy to attack with a copy machine and you wouldn't even know that you lost it.

Any other methods I missed?

 [1] http://www.sans.org/security-training/defending-web-applications-security-essentials-1442-mid
 [2] http://threatpost.com/en_us/blogs/google-adds-two-factor-authentication-apps-accounts-092010
 [3] http://www.phonefactor.com
 [4] https://pip.verisignlabs.com

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

The Full Disclosure list sponsored by secunia.com published an exploit regarding the CVE-2010-3081 vulnerability. It is triggered because of a stack pointer underflow regarding the function compat_alloc_user_space() inside arch/x86/include/asm/compat.h. This exploit is in the wild and it is highly recommended to implement the patch located at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c41d68a513c71e35a14f66d71782d27a79a81ea6.

You might wonder why do I tell you to patch a vulnerability that has been published 12 days ago, right? Two days ago, the operations team of my company noticed a strange behavior on a specific linux system. First thing I did was to review the latest vulnerabilities for the linux distribution installed on the machine and found CVE-2010-3081. Digging a little bit more let me found  an excellent tool made by Ksplice that told me the machine was exposed to the exploit.

Download the tool here: https://www.ksplice.com/support/diagnose-2010-3081.c. If you want the binary, download it here: https://www.ksplice.com/support/diagnose-2010-3081.

Read the Redhat Bugzilla info associated with CVE-2010-3081 here: https://bugzilla.redhat.com/show_bug.cgi?id=634457.

Read about the exploit here: http://seclists.org/fulldisclosure/2010/Sep/268.

Read more about the vulnerability description here: http://sota.gen.nz/compat1/.

Can't patch right now? Use the following workaround: echo ':32bits:M:0:x7fELFx01::/bin/echo:' > /proc/sys/fs/binfmt_misc/register

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org

I woke up this morning to my Spam box full of email from a variety of people, to a variety of my email boxes, greeting me and checking into my well being.  One example of this is

From: Luella Winkler <sacrilegioush@real-time-vision.com>
Date: Sat, Sep 18, 2010 at 1:03 PM
Subject: hello
To: XXXXXX@XXXXXXX.ca


how are you?

To Luella and the other 54 email addresses that checked up on me...I would just like to thank all of you for caring so much and reassure you that I am quite well.

Seriously though, there is no solicitation, no attempt at phishing, and no embedded crap, just warm regards.  Is this a dry run for something big to come?

UPDATE 2010-09-21:  Today the same IP addresses are delivering emails with subjects such as "Deposit", "demands for payment", "schedule of bridging loan payments", and "June Voice".  They each have a .html attachment and lots of bad English.  I haven't had time to look into the attachment, but if any of you has, safely of course, I would love to hear what you found.

-- Rick Wanner - rwanner at isc dot sans dot org - http://rwanner.blogspot.com/

Microsoft has released a security advisory for ASP.NET (CVE-2010-3332).  It looks like there are no known attacks for this vulnerability at this time, and no patch or workaround has been released. 

To quote the release...

"Microsoft is investigating a new public report of a vulnerability in ASP.NET. An attacker who exploited this vulnerability could view data, such as the View State, which was encrypted by the target server, or read data from files on the target server, such as web.config. This would allow the attacker to tamper with the contents of the data. By sending back the altered contents to an affected server, the attacker could observe the error codes returned by the server. We are not aware of attacks that try to use the reported vulnerabilities or of customer impact at this time."

A few more details are available at Scott Guthrie's Blog

-- Rick Wanner - rwanner at isc dot sans dot org - http://rwanner.blogspot.com/

Several of our readers sent us a heads up about a Linux kernel vulnerability which was previously patched, but has
leaked back into the kernel.
The vulnerability exists in the 32-bit compatibility mode of the kernel and upon execution can result in a local root
compromise.

The Heise security team reportedly obtained a root shell on 64-bit Ubuntu 10.04 using this exploit.

The current workaround involves temporarily disabling the execution of 32-bit applications (See Full-Disclosure and the Redhat article below for details)

Reportedly all current Linux kernels are affected (patch is in the works) as well as backported kernels from vendors like Redhat.

References:
@benhawkes (Deserves the credit for discovering this re-emergence. Not linking as exploit code is provided)
http://xorl.wordpress.com/2009/08/07/cve-2007-4573-linux-kernel-ia32-system-call-emulation-vulnerability/
https://bugzilla.redhat.com/show_bug.cgi?id=634457
https://access.redhat.com/kb/docs/DOC-40265
http://www.heise.de/newsticker/meldung/Luecke-im-Linux-Kernel-ermoeglicht-Root-Rechte-1081195.html (German)
Full-Disclosure

Thanks to Jens Hektor and Dave for bringing this to our attention.

Robert
ISC Handler on Duty

A vulnerability in some "random ad server" software wouldn't be terrible big news, but in this case I decided to spent a couple minutes on it. OpenX is somewhat popular, and used by various sites to server ads. Not only that... the vulnerability is actively being exploited. And to make things worse: The OpenX.com site is down, so you can't download a patch or any details "direct from the source".

We have seen compromised ad servers being used in the past to inject malicious content into various "trusted" pages and I am a bit afraid that we will see some of this with these OpenX vulnerabilities.

For more details: http://blog.sucuri.net/2010/09/openx-users-time-to-upgrade.html

(thanks to David of Sucuri for the heads up)

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

Not traveling this week, I got a bit extra time and decided to put up a couple "packet challenges". If you are following me on twitter, you may have already seen them. If not... here they are:

First one (with solution): http://johannes.homepc.org/packet1.txt

The second one (posted yesterday): http://johannes.homepc.org/packet.txt (I think I only got one decent answer for it so far, so I will keep it up a bit longer...)

A third one will be posted later today. And BTW... got packets? We always like good and interesting packets.

update: just made the new challenge live. again at http://johannes.homepc.org/packet.txt

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

I am seeing a trend on Facebook recently, and I am not sure what to make of it. As we all know just too well, Facebook has a "Like" feature. This feature, a little button associated with a post, allows you to show agreement with a post. Lately however, I am seeing more and more posts like the following:

I covered up the parts identifying the friend of mine who posted this. A few things make these posts look "suspect": The post itself links to a domain "x.co". This is not the only domain used for these posts and it isn't obvious if they are all related (but many are). Another domain associated with x.co is for example thelikepage.com.

Once you click on it, you are offered a large number of other "provocative quotes" and offered to "like" them. At this point, I am mostly asking "what is the point"? Is it just an attempt to direct Facebook users to ad-covered pages? Or is there something more sinister at play? I don't see any exploits like click-jacking or cross-site-request-forging used. These pages also do not phish your credentials like some other similar pages.If you got an opinion or any further inside, please let us know.

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

Shadowserver has published their take on a recent series of DDoS attacks http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20100913. The control domains, victim industries, countries affected, and command communications are all listed in the article. Not a complete analysis of the BlackEnergy bot, and bots are not a new phenomenon, but server to remind that DDoS for hire is still around, botnets are still around, and that their impact can be devastating.

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

Overview of the September 2010 Microsoft Patches and their status.

Adobe has released an advisory for Flash Player 10.1.82.76 and earlier versions for Windows, Macintosh, Linux, Solaris, and Adobe Flash Player 10.1.92.10 for Android, as well as Adobe Reader 9.3.4 for Windows, Macintosh and UNIX, and Adobe Acrobat 9.3.4 and earlier versions for Windows and Macintosh. CVE-2010-2884 has been assigned to the issue, which has an impact of crashing Flash or arbitrary code execution on some affected platforms. There is currently no patch, Adobe has indicated that it should be released in late September and/or early October. There are indications that this previously unknown vulnerability is currently being exploited in the wild by malicious web sites attacking browsers. YYAAAV Yes, Yet Again Another Adobe Vulnerability. Sigh.

Keep an eye out for this one folks. It will take a bit for the anti-virus, IDS/IPS and other vendors to catch up and detect the malware that exploits the vulnerability. Although by that point the box affected may well be compromised as most detect after the exploit has already taken place. Since the vendor has released the advisory after being notified that exploits are already occurring against Windows boxes it is recommended to explore workarounds for mitigation, detection of already compromised hosts, and cleanup.

Adobe PSIRT blog: http://blogs.adobe.com/psirt/2010/09/security-advisory-for-adobe-flash-player-apsa10-03.html

Adobe advisory: http://www.adobe.com/support/security/advisories/apsa10-03.html

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

We have received reports that CVE-2010-2883 is being actively exploited.

There are a couple of interesting analysis done about this vulnerability. Read them at http://community.websense.com/blogs/securitylabs/archive/2010/09/10/brief-analysis-on-adobe-reader-sing-table-parsing-vulnerability-cve-2010-2883.aspx and http://www.attackvector.org/new-adobe-0day-demonstration.

Read the Adobe advisory here.

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org

Handler Daniel wrote a story abot Enhanced Mitigation Experience Toolkit (EMET) in september 2. Microsoft wrote a very interesting paper explaining how EMET can successfuly block Adobe Reader and Acrobat 0-day exploit.

More information at http://blogs.technet.com/b/srd/archive/2010/09/10/use-emet-2-0-to-block-the-adobe-0-day-exploit.aspx

More details about EMET at http://technet.microsoft.com/en-us/security/ff859539.aspx 

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org

Abysssec posted a very interesting paper analyzing the pushstring memory corruption vulnerability (CVE-2010-2201).

Read the paper at http://www.exploit-db.com/download_pdf/14983. Original Adobe advisory at http://www.adobe.com/support/security/bulletins/apsb10-15.html 

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org

We are aware of the "Here you have" malware that is spreading via email.  As we find out more, we'll update this diary.

Marcus H. Sachs
Director, SANS Internet Storm Center

We just received word that there is a report of a 0-day exploit for Adobe Acrobat/Reader being exploited in the wild. Secunia has a brief write up and here is the link to the original advisory.  The exploit was discovered in a phishing attempt with the subject of "David Leadbetter's One Point Lesson".  Adobe has issued an advisory and references CVE-2010-2883 (which just shows as reserved at this point with no details).  It does effect the latest version of Acrobat/Reader and Adobe is investigation a patch. More to come on that.

The exploit in the wild I'm aware of causes a crash in Acrobat/Reader and then tries to open a decoy file.  So the good news is that, as of right now, it's a "loud exploit".  Early VirusTotal scans also had partial coverage under various forms of "Suspicious PDF" categories.  At this point, standard precautions apply (don't open PDFs from strangers) and this can probably only really be used in a phishing style scenario.  Will update this dairy as needed with developments.

--
John Bambenek
bambenek at gmail /dot/ com

-- John Bambenek bambenek at gmail /dot/ com

We've been writing about SSH brute force attempts for numerous times already. A lot of security researchers are collecting various information about such brute force attacks and numerous other tools exist that can prevent or block them.

DRG (Dragon Research Group), which is a volunteer research organization dedicated to further understanding of online criminality and to provide actionable intelligence for the benefit of the entire Internet community, last month published a very nice paper about such SSH brute force attempts. Among the other things, the paper lists a whole bunch of tools that can be used in order to limit or block SSH brute force attempts, and configuration recommendations that will help you increase security of your SSH installations. Check the paper at http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html

Additionally, DRG is also publishing a list of IP addresses of SSH attackers that were detected on various pods DRG uses, that are spread around the world. This list is available at http://www.dragonresearchgroup.org/insight/sshpwauth.txt.

DRG also created a very cool tag cloud showing most common usernames and passwords that have been tried in latest SSH brute force attacks. The cloud is available at http://www.dragonresearchgroup.org/insight/sshpwauth-cloud.html - check it make sure there aren’t any of your passwords there :). Both the list and the cloud are updated every hour.

More information about DRG is available at http://www.dragonresearchgroup.org/ and I’m sure they could use more pod runners.

--
Bojan
INFIGO IS

A recent article released by the US Department of Defense (DoD) spoke of the worst compromise in DoD history, facilitated by what was said to be the unauthorized use of a USB drive.  As a result of this incident, the US government has seen fit to step up the DoD involvement, working with the US Department of Homeland Security (DHS), in an effort to protect critical national infrastructure.  The full article (requires registration) by WIlliam J. Lynn, Undersecretary of Defense, speaks of the DoD and it's experiences which makes it uniquely qualified for cyberdefense.  "Cyberattacks offer a means for potential adversaries to overcome overwhelming U.S. advantages in conventional military power and to do so in ways that are instantaneous and exceedingly hard to trace. Such attacks may not cause the mass casualties of a nuclear strike, but they could paralyze U.S. society all the same," he wrote. "In the long run, hackers' systematic penetration of U.S. universities and businesses could rob the United States of its intellectual property and competitive edge in the global economy."

The announcement by the DoD that within the last 24 months it had suffered it's worst compromise in history would seem embarrassing, but then to announce in the same week that they will become more involved in the protection of national critical infrastructure is disconcerting.  The DoD is the US arm for defense of national interests, however I do not believe that makes the DoD the best agency for this role. 

I welcome your comment,

tony . carothers at   gmail dot com

"Get off of my lawn!"

I admidt that I have a suspicous, curmedgeonly streak. I view every new feature-update from Facebook like like it's a vulnerability announcement from Microsoft. I'm concerned not only with what the people behind Facebook may be planning with a feature, but moreso with how other groups might repurpose that feature. The recent expansion of the facebook API is one of those things that gives me concern.

What happens when you click "Like?"

When you click the "Like" there's an announcement of this activity on your wall, and it's added to your "Likes" section. People who have common likes can see each other, but only as much as they would share with anyone else who had their Facebook username. That doesn't sound so bad.

What are people "Like"ing?

Normally, a Facebook user could create a group or page to support a product, business or idea such as: Rock Music, Gibson Guitars, or Billy-Bear's Bean Shop. With the update of the Facebook Platform (http://blog.facebook.com/blog.php?post=383404517130) now third party websites can place a "Like" button on their website. Is this a problem? If I like Nike shoes, why not like nike.com itself?

What has been triggering my spiedy sense is over the past couple of weeks, my facebook event log has been filling up with people "like"ing third party pages that are simple messages like: "like if you want a long lasting relationship:)!" or other simple plattitudes. The first thing that attracted my notice was that they were often mean-spirited, hateful, or had some sort of -ism in it. These were surprising messages to read on a friend or family member's page, so I suspected some sort of hijack or other foul play. Unfortunately I haven't turned up anything to support that theory, my frienda and family, are just mean people I guess.

There are a handfull of sites that have been recently set up to take advantage of this new feature in the Facebook Platform. Some that I have seen used recently are:

• golikeus.org, 19-JUN-2010, privately registered
• likealike.co.uk, registered 23-AUG-2010, privately registered
• phrasely.net, registered 26-AUG-2010, privately registered

Each supports a user-created message feature where Facbook users can set up their own message and try to get as many folks to join as possible.

Recently they've updated their posts so that when the "Like" message appears on the users' wall the source is obfuscated behind a heart or musical symbol. I saw one that was even hiding behind a bit.ly link.

So other than the domains being recently registered with no contact information and the simple obfuscation, what evidence do I have that there's evil afoot? None, other than it fires a lot of my rules of thumb I've acquired over the years.

One last example.

This week, one of my family member's had this message pop up on my wall:

"WOW, This GUY Went A Little To FarWITH His REVENGE On His EX GIRLFRIEND! (shocking)"

I was certain that they'd be compromised this time. I set up a system and followed the links, capturing pcaps, just waiting for the prompt to download the fake video codec or whatever boobytrap they had waiting for me. The domain, shocking-revenge.info, was barely a day old, and the links went off to pull down content from other free-hosting providers. It had all the hallmarks of a psychological exploit. So I kept clicking like a sucker waiting for the big reward.

It never came.

Just more advertisements, and whoever's behind it has a nice bit of demographics for marketing purposes and a channel to distribute more lures and ads.

The Impact

So the short story is that there's nothing overtly evil about "like" links. I also don't see shadows of some large privacy violation or exposure when you click the "like" button on Facebook-hosted pages or sites that you trust.

However I do see some risk to clicking on un-trusted third-party "likes"; not because I have any hard data from any cases, but because I've seen this movie before, and I will see it again.

I'm just disappointed that I have friends/family with *isms. I was really hoping it was malware.

This morning we received a report from Holger about a website that was triggering alerts in Google and his anti-virus applications. I wanted to share my response process.

My first step is selecting the right "responder music." You can't have a good incident reponse montage without your jams.

Next, it's a bit of domain analysis. There are a number of helpful sites that host whois and dns details about a suspected site. I use domaintools.com, others swear by robtex.com. In this particular case, the domain was registered in 2004. As a generalization, long-lived domains like that do not raise red flags, but the domain expired 30-AUG-2010 (just a few days ago) which could indicate a window of opportunity for a criminal to acquire a nice bit of "respectable" internet real-estate.

If you want to interact with the suspected website, you should use something safe. It's a little harder to determine which tool-set is safest when dealing with malicious websites since you don't reliably know what they're targeting most of the time. I went with an OSX image that was pretending to be a windows box.

Malware authors are catching on to the old wget-with-a-spoofed-user-agent trick. I've taken to synthesizing victim behavior by first starting with some google-searches so that I can build a convincing referer URL. Googleing for the domain turned up mainly the main website and a lot of traffic analysis of the domain from places like Alexa and trafficestimate. I added the "inurl:" google syntax in the hopes of finding examples where an attacker may have been spamming out links to forums and such to drive attacks to the exploit site. The search didn't turn up many results (something that also didn't raise any red flags,) but when I tried to have Google translatethe site for me (a risky move but I can easily restart the image) I received the Google warning that Holger reported. At this point I have what I need to grab a copy of the potential-exploit. I still use wget, and spoof the user-agent to look like an IE request, and use the referer link from the Google search.

The request worked, but URL that allegely pointed to a .JPG returned HTML. That's a bit unexpected. By glancing through the HTML results the obfuscated javascript jumps out. A handfull of Math.* calls and document.write statements are a pretty solid flag that something odd is going on. In this case its intent was to create a pop-up to an ad-server.

The owners of the website claim that the Google and AV alerts about the site are false. I will grant that the intent behind the obfuscated script wasn't overtly criminal in this case, but I wouldn't call it a false-positive result. I would urge the advertising network to be up-front about what they're advertising and where they're advertising it from. There's no reason to use document.write games to set up your javascript calls to your ads.

Today, Microsoft released a new version of their "Enhanced Mitigation Experience Toolkit".  A rather unwieldy name, but quite interesting technology - with EMET, legacy applications on OS versions as far back as WindowsXP can now also be protected with Data Execution Prevention (DEP), Exception Handler Overwrite Protection (SEHOP) and more, and the application doesn't even have to be DEP-aware.  If you have vulnerable legacy apps on Windows that you need to keep alive for a little while longer, I suggest to take a look at EMETv2.

"We're under a targeted malware attack!", a friend of mine yelled into the phone. "We are getting lots of oddly named PDFs, attached to personalized emails, sent only to certain employees in our firm!". From some past experience with chewing through our nasty malware repository here at SANS ISC, I had learned a thing or two about malicious PDFs, so I agreed to take a look.

One hour later, it was clear that the PDFs in this case were free of any exploit, completely harmless, and contained only the average "I AM A COUSIN OF THE LATE ZESKEKE NGAGWENE" type of Nigerian 419 (advance-fee) fraud spam.

But the whole episode gave me pause. It really looks like the past two years of never ending new waves of PDF exploits have degraded PDF in the mind of every security analyst to a level somewhere at par with ANI and SCR files: No matter what it claims to be, it ain't nothing good.

I very much agree with Stephen Northcutt's comment in SANS Newsbites two months ago. He asked: "Is there an alternative to a .pdf? It was supposed to be a printable image of what you saw on the screen. At least that was the idea 15 years ago. It should not need "launch" functions to do that. Do you remember five or six years ago, you weren't supposed to send an excel spreadsheet or a word document because they might contain malware, you were supposed to send a .pdf. Guess that has changed!"

Time for SDF - the Safe Document Format. You know, one that just supports pixels in various shades of gray, and does not need to include the ability to play a movie in 3D accompanied by surround sound. Just a nice plain document that can be opened, read and printed, without any of the nagging feeling of dread that nowadays accompanies clicking on a PDF.

Anyone?

As a heads up, the Exploit Database (exploit-db.com) is publish a month of undisclosed 0day bugs from Abyssec Research.  Today there are two bugs published one for cPanel (though it seems more of a bug of fantastico) and one on Adobe Reader and Flash.  Expect that the "good ones" will be weaponized quickly as the disclosures are quite technically detailed and don't take too much thought to put into place.  You may wish to keep up with what they publish as awareness for your own networks.

--
John Bambenek
bambenek at gmail /dot/ com