Third encounters with a web comment spammer

In my previous two posts, I wrote about a web comment spam application that has been hitting one of my personal web sites. I set up a bit of an agility test for the bots to figure out what they were, and were not, capable of doing. Eventually I was able to put together a fairly good operational profile of one of the spam application's functionality. In this post, I want to review the operation of another spam application that I happen to encounter during my test...one that seems far more capable than the original one I aimed to report on.

To briefly recap my previous two articles, there was one particular application that repeatedly kept visiting my site. It should send a bunch of bogus links in various different formats as a comment in a web form; since the links were entirely random, I hypothesized that these submissions were mere probes to some other future means and not the overall end purpose. Anyways, the operational profile that I constructed for the application looks like:

• It recognized a few form field names and attempted to submit appropriately formatted data to them, but all other fields were filled with random garbage (unless an existing form field already held a value); specifically:
  
  
  
  • It put an email address in the 'email' field, but not the 'eml' field
  
  
  • It put a URL in the 'url' field, but not the 'link' field
  
  
  • It did nothing special with the name, address, and phone fields


• It supported cookies during the submission process


• It did not support Javascript


• Hidden form fields were properly submitted/included


• It could support multi-step submissions


• The User-Agent seems configurable, but is mostly left as the same value


• Many uses of this application against my site have originated from the same Class C public Internet network

During my experiment, another spam application wandered onto my site and partook in my little agility test. This particular application stood out exceptionally different than the previously profiled application. Here’s an example of what the application actually sent (which can be compared against the raw data contained in my previous post). I’ve modified the domain names; I assure you the originals used live/real URLs.

eml: korch_poposk@xxx.yy

email: korch_poposk@xxx.yy

name: DoorieHoohona

phone: 123456

address: http://xxx.yyy.com/Avalide/map.html

url: http://xxx.yyy.com/Bust-Enhancer/map.html

link: http://xxx.yyy.com/L-Glutamine/map.html

comment: Wellbutrin XL what is celebrex clonidine medicine bupropion and weight loss <a href=http://xxx.yyy.com/Female-Libido-Patch/new-scientist.html>new scientist</a> <a href=http://xxx.yyy.com/Evegen/evegen-reviews.html>evegen reviews</a>... [truncated for brevity]

Just looking at the values submitted in these fields, there is a night-and-day difference when compared to the previously mentioned spam application I was tracking. This new application was significantly more successful at putting contextually-correct information in the right fields: email addresses were submitted for both 'email' and 'eml' fields; something that resembled an actual human name was submitted in 'name' field; the 'phone' field was numeric; both 'link' and 'url' fields held URLs. The value of the 'address' field is debatable...perhaps the application is coded to believe 'address' is akin to a web site address, i.e. URL. Or, maybe this particular app shoves URLs into fields it does not recognize (and thus the URL values in the 'address', 'url', and 'link' fields were actually just dumb luck). The links submitted within the comment only used one format (proper HTML <A> tag), so it's not as robust as the other application in abusing web applications that allow the use of popular forum code markup (i.e. the [url] and [link] pseudo-tags). But overall, the level of contextual awareness of this application is far more interesting than the previously profiled spam application.

So the current operational profile of this spam application is:

• It has shown to be very successful at putting the right contextual/formatted information into a variety of different form fields; specifically:
  


• It put email addresses into the 'email' and 'eml' fields


• It put a human name into the 'name' field


• It put a numeric number into the 'phone' field


• It put URLs into the 'address', 'url', and 'link' fields


• It supported cookies during the submission process


• It did not support Javascript


• Hidden form fields were properly submitted/included


• The application does not appear to support multi-step submissions; or at least, it didn't care about verifying that the submission worked


• The User-Agent string submitted is extremely easy to spot: "Mozilla/4.0 (compatible; MSIE 6.0; Update a; AOL 6.0; Windows 98)"

Unfortunately this particular application only visited my site once, so I don't have multiple submissions at hand to aggregate into a more comprehensive profile. I'll sure be on the lookout for the next time it comes back around.

Until then,
- Jeff

The Malware Tea Leaves

When parents want to know what's cool, they turn to the experts - their kids. Parents are shielded from coolness by structure and routine. They've worked hard to establish a delicate balance between work, family and finances and the last thing they want is change. Kids on the other hand are unencumbered by structure and quickly adapt. What was trendy yesterday is passé tomorrow.

By the same token, if we want to identify trends in technology, we should not look to large corporations, saddled with policy and bureaucracy. Even start-ups, while nimble, have to play by the rules. Malware authors on the other hand are completely unencumbered by rules, legal or otherwise. They provide a unique window into technology trends. When the koobface virus was adapted last week to target Facebook users it garnered significant press for attacking a popular social networking site. I on the other hand was intrigued not by the targeted site so much as the koobface author's decision of communication medium. Koobface, like most malware today relies on social engineering to spread. In this case it attempts to convince the victim that their system lacks a particular codec which is required in order to view a video. Once the user downloads and installs the malicious binary, they're infected. Such attacks have historically relied on email to spread and entice new victims. Koobface reveals the shift that we are experiencing in the way that users prefer to communicate. A co-worker recently mentioned to me that he was forced to create a Facebook profile, not because he wanted to, but because it was they only way that he could stay in touch with his niece and nephew - they didn't use email - they didn't need to as they lived in a social networking world. The author of koobface has realized this as well. Email is tired and Facebook is wired.

So what do the malware tea leaves reveal?

Email is Old School - Why send a static message when you can participate in a vibrant conversation, social networking style. Don't expect email to disappear but do expect webmail to be increasingly preferred over traditional email clients. Alternate communication mediums such as social networks, Twitter, etc. also present avenues for compromise and data leakage.

HTTP Consolidation - Malware increasingly uses port 80 as a communication channel, regardless of whether or not the traffic is HTTP. Why? Outbound ports 80 and 443 are always open on corporate firewalls. Intelligent networking applications such as Skype will also try a number of tricks before ultimately reverting to communication on port 80 for this same reason. If you're solely relying on traditional firewalls for protection, you're exposed. Perimeter security applications need to be 'application aware' - ports are meaningless.

End User Empowerment - The Internet was supposed to do away with the desktop and leave us all with thin clients. However, the power of cloud computing has had an unanticipated side effect - it has empowered end users. You no longer need the IT department to deploy a new solution. Instead, you can setup an online account and be up and running in minutes, all without assistance from the techies, or perhaps even without approval. Attackers are all too aware of this and have over the past couple of years significantly shifted their attacks from the server to the client. The defenses are lower and valuable information is either stored there or it's an easy way to grab some authentication credentials and get the goods that live in the cloud.

Who says an old dog can't learn new tricks? Pay attention to patterns in malicious software, there's always something driving a new trend and we can learn a great deal from it. Want to identify the next big thing? Ask an attacker and while you're at it check with your kids before updating your wardrobe.

- michael

Second encounters with a web comment spammer

Earlier I wrote my First Encounters with a Web Comment Spammer piece. In that piece I devised a plan to lay a trap of sorts for the web comment spamming application, in order to test the depth of the application's functionality. Well, it's been a few weeks, and now I have some data to share.

The most interesting thing to note is that a few more comment spam applications/crawlers have made their way to my comment form. These new ones exhibit different behavior than the original one I reported on, thus I believe they are entirely different applications. For now, I’m going to stick to the original application I previously discussed; I'll compare my results to these newer spam apps in a future blog post.

One thing I noticed is that many of these comment spam attempts were coming from systems located on the 94.102.60.0/24 network. A large number of them were also using the User-Agent string "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)". Both of these factors turned out to be good indicators of whether the request was coming from a spam bot.

Anyways, here is an example of one submission I received. The names at the beginning of each line are the name of the form field; all of the fields are text input fields (as in, "<input type=text>"), except for 'other' and 'comment' which are textarea fields.

eml: YkfxeDeZjHR
email: fbkixy@nphddy.com
name: fvkijvn
phone: CdGpbMFbxGDygCwy
address: ouUMHxpoxwn
url: http://vfokgivkywst.com/
link: geEKiJfvkyRC

other: TyhYgb <a href="http://xnhqpiemubkx.com/">xnhqpiemubkx</a>, [url=http://fiukrdabbaut.com/]fiukrdabbaut[/url], [link=http://zrywxdmvlfzv.com/]zrywxdmvlfzv[/link], http://klhtciqjlkxr.com/

comment: TyhYgb <a href="http://xnhqpiemubkx.com/">xnhqpiemubkx</a>, [url=http://fiukrdabbaut.com/]fiukrdabbaut[/url], [link=http://zrywxdmvlfzv.com/]zrywxdmvlfzv[/link], http://klhtciqjlkxr.com/

The most obvious things visible from this data are that the application filled in all fields with random garbage. It managed to put something that resembled an email address into the 'email' field, but not the 'eml' field (which is the actual email address field shown to the user for data entry). The application also managed to put a URL into the 'url' field, but not the 'link' field. This makes me believe the application is pre-programmed with a few specific field names where it will submit data of a specific format. Also interesting/notable is that the application submitted the same blob of link garbage to both textarea fields ('other' and 'comment'), and not any of the text input fields.

In addition to the form fields that were submitted, I collected some other pieces of information to gauge the depth of the spamming application. I discovered that cookies were indeed supported--at least, I could set a cookie on the form display page and the bot would carry that cookie over with the form submission. Hidden form fields were not altered and properly submitted with the rest of the form data. I also found that Javascript is not supported by the application...which is no surprise.

Another thing I failed to notice before is that the application does actually have the ability to handle multi-step submissions. I recognized the behavior in my logs: whenever the form was submitted, the same user-agent would then go through every link on the page (in exact order of appearance, none-the-less) and subsequently request it. I assume this behavior is to deal with web applications that return a "thank you for your submission" page along with a link taking you back to the forum/comment area where the new submission will appear.

Interesting info, perhaps. But I’ve found that I grown bored with this particular application and its lack of intelligence; the newer bots I’ve been seeing have actually been doing a lot more interesting things. I will take a deeper look at these new bots, and how they differ, in my next blog post. After that, I'll share a few effective tricks I've been using to tell these spam bots apart from the humans (without CAPTCHAs!).

Until then!
- Jeff

Clickjacking - iPhone Style

In the past, I've blogged about clickjacking and how to defend against it. While Adobe has patched Flash Player to protect against one of the more frightening attacks, which could lead to hijacking of a victim's webcam and microphone, many browsers and applications remain vulnerable. In fact, a few days ago, when Apple released the latest firmware for the iPhone (v2.2), it turns out that they quietly addressed what some consider to be a clickjacking vulnerability in Mobile Safari, the iPhone's web browser. It's definitely a different version of clickjacking and it would be fair to argue that it's a different vulnerability altogether but it is interesting nonetheless, so for the sake of argument (and blog hits) I'll stick with the clickjacking title and describe in greater detail the unique aspects of this vulnerability.

Mobile Safari was not actually vulnerable to the 'traditional' version of clickjacking, but it is susceptible to this new variant, which was discovered by John Resig and reported to Apple (CVE-2008-4232). There is no proper definition for clickjacking, but I'll define it as "obfuscating web page content, in order to social engineer a victim into performing an action other than what was intended". Now I'll split clickjacking into the following categories:

1. Layered Clickjacking - When Jeremiah Grossman and Robert Hansen first discussed clickjacking, they detailed how the use of z-index values in Cascading Style Sheets CSS) could be used to layer content on top of other content. Then, leveraging CSS opacity values, the transparency of the layered content could be adjusted to show content on the bottom, while hiding the content on top, which is actually interacted with. A demonstration of this technique is available here.
2. Overflow Clickjacking - The iPhone vulnerability does not require z-index or opacity values. Instead, the problem stems from the fact that the content of an embedded IFRAME can be forced to overflow it's bounds and spill onto the parent page. This is accomplished by adjusting the size of the IFRAME leveraging CSS transforms, which are supported by the webkit engine.
   

Rather than talking about it, let's see overflow clickjacking in action.

Fig 1 - Not Vulnerable	Fig 2 - Vulnerable

---

iPhone Clickjacking Demo

---

In Fig 1 (not vulnerable), you can see both the IFRAME content and the page content. Both have identical forms for password submission, but the IFRAME form is submitted to the attacker controlled page. In Fig 2 (vulnerable), you can see that the evil IFRAME has overwritten the page contents and we only see one (evil) password submission form.

While this is interesting, in reality, it comes with some very real limitations that will restrict the usefulness of the attack. In order to be valuable, we need a situation where an attacker controls the content of an IFRAME on a targeted page. This could occur with mashups or banner ads. An attacker could deliver IFRAME content to a subscribing web page and overwrite a portion of the parent page. They would however need to know which page was pulling the content in order to properly align the new content in order to make for a convincing attack.

I expect that we'll see a whole host of clickjacking-esque attacks in the coming months, affecting various browsers/applications. The ability to format page content via CSS, DHTML, etc. and improper implementations of these standards leaves plenty of room for error.

Happy Thanksgiving!

- michael

Technical Quickie: building SpiderMonkey on FreeBSD 6.2 AMD64

I wanted to get Didier Stevens modified SpiderMonkey Javascript engine compiled and running on a FreeBSD 6.2 AMD64 box. It turns out the config files shipped with his 1.7.0 version do not include FreeBSD support, so I wound up having to hack something together...and I thought I would share what I did in case others are interested. I assume these instructions would be relatively applicable to later FreeBSD versions as well.

When you go to build the source, config.mk pulls in an appropriate file in config/ to use for your system. On FreeBSD 6.2 AMD64, the output of 'uname –s' and 'uname –r' essentially lead to the config file named 'config/FreeBSD6.2-RELEASE.mk'. So what I wound up doing was go into the config/ directory and copy the 'Linux-All.mk' file to 'FreeBSD6.2-RELEASE.mk'.

If we were building on an x86 (32-bit) FreeBSD platform, that might be all we need to do. However, since we're building on AMD64 (64-bit), this configuration file needs to be modified because the default Linux configuration file references 64-bit CPU architecture as 'x86_64'; on FreeBSD AMD64, the CPU architecture is reported as 'amd64'. Fortunately the fix is simple: just do a find/replace on all values of 'x86_64' and change them to 'amd64'. There are three changes total.

Now that you've made those changes, you should be all set. Just build the application ("gmake –f Makefile.ref") and then grab the 'js' binary out of the 'FreeBSD6.2-RELEASE_DBG.OBJ/' directory.

Enjoy.

- Jeff

Not all P2P is evil

Allow me to step up on this conveniently available box of soap for a minute. I can't tell you the number of discussions I’ve been in where my conversation partner erroneously assumed that "P2P" was strictly synonymous with file sharing, copyright infringement, bandwidth hogging, and corporate time wasting. My viewpoint is that the term "P2P" references a specific network/communication design (i.e. arbitrary peers talk to other peers, rather than clients talk to dedicated servers), and not a particular usage. In other words, P2P is a communication technology platform that is agnostic to the application built on top of it. There are video delivery applications, file sharing applications, VoIP applications, IM applications, and privacy shielding applications that are built using P2P as their communication framework. You cannot define P2P as being any single one of those (particularly file sharing); and there are many legitimate uses for many of those listed applications. In fact, many businesses use functional non-P2P alternatives of those same types of applications on a daily basis.

Now, I completely understand and agree that P2P has received this bad reputation because the earliest adopters of the P2P communication model were applications that many organizations consider questionable. That's why I'm always happy to find uses of P2P that provide a positive benefit. A recent example I ran across was the Network Early Warning System (NEWS), which uses P2P communication to cross-talk and alert about network connectivity and traffic issues. The Northwestern University Aqualab (creators of NEWS) liken NEWS to a "neighborhood watch for the Internet," with particular benefits to ISPs. Aqualab also has many other ongoing projects that relate to improving the performance and scalability of P2P communication models.

There is also Pando, a company that offers what they call a "peer assisted" content delivery service that is targeted to businesses needing to deliver large amounts of media to their users. Basically they have married the traditional CDN concept with a P2P communication and distribution model, resulting in something they say scales significantly better (thus making less costly) than the traditional CDN approach. As an aside, our research shows that Pando is actually a tweaked version of BitTorrent that runs over standard SSL, which allows it to be served over port 443 with ease.

So the next time someone says "P2P is evil," remind them that P2P is just a platform utilized by many different applications, and they should clarify which P2P application(s) they have in mind.

- Jeff

Trusted Computing is Chasing Yesterday's Problems

Earlier this week I was able to stop by the CSI 2008 conference. I was only able to take in a couple of the presentations, including a keynote by Steve Hanna, a Distinguished Engineer at Juniper Networks. Steve was speaking about trusted computing, explaining what it is and how it will tackle some of the security problems that we face. Now I'll confess that I've never been completely sold on the concept of trusted computing. I've tended to view it as somewhat of an ivory tower initiative that might work fine in a structured, high-security environment such as a DoD network, but not overly practical for the 'real world'. That said, Steve made some strong points about the value of Trusted computing and argued that it's closer to becoming a mainstream reality than I'd realized.

Steve detailed three primary layers for his vision of Trusted computing:

1. Trusted hardware - The Trusted Platform Module (TPM) has a unique, secret RSA key burned into it at the time of manufacture and can be used for hardware identification. The TPM specification was developed by the Trusted Computing Group and many chip manufacturers have included a TPM in laptop chip sets since 2006.
2. Tusted Operating System - Projects such as the NSA High Assurance Platform Program seek to leverage the TPM to create the foundation of a secure operating system.
3. Network Access Control - Protecting access to resources or network.

Now I can envision how such a system, if implemented could go a long way towards limiting the spread of malicious code by ensuring that untrusted binaries are simply not permitted to execute on a given system. The problem with such an approach is that it works in opposition to the open nature of the Internet, a principal that we've come to know and love. Would users be willing to be restricted in the applications that can be run on their machines? I don't think so. In general we're willing to accept security risks in favor of an open architecture that allows flexibility. For proof, look no further than the cell phone industry. Cell phones were once inflexible boxes that ran specific applications and if you didn't like it, you could buy another phone. Today however, Telecoms are tripping over one another to show just how open they are and how they welcome third party applications. Will this break down barriers for mobile malicious code? Sure, but consumers don't care. They want flexibility.

My second concern with the vision for trusted computing is that it will do little to prevent web based attacks which don't require binary code execution and threats of this nature will only continue to grow. Take Clickjacking for example. This is really a social engineering attack. You are convincing someone to perform an action which they did not intend to do, because you are able to manipulate the look and feel of the page that they're viewing. Cross Site Request Forgery is another great example. Once again, the attack leverages web functionality as it was designed. No binary execution is required.

After listening to Steve's keynote, I have a better understanding and appreciation for trusted computing. However, I'm more convinced than ever that it's focused on yesterday's attacks, while we as an industry need to be looking to tomorrow.

- michael