Pharma Spam on University Websites

Google finds some amazing things if you give it the right query. It's not exactly a secret that with the right google dork or "hack," you can find all sorts of things that weren't meant to be published. This has always been a hobby of mine, if only because the content you find is usually so weird and interesting. If you're interested in this kind of thing, you can check out a guide on advanced operators and the Google Hacking Database.

As I used to work for a fairly large university, I was perusing results for .edu sites the other day when I started running across a fair amount of similar-looking pharmaceutical spam. You can see a pretty huge sample of it by using the following dork:

site:*.edu (intitle:viagra||intitle:cialis)

I contacted a few universities to let them know but after receiving no responses, I figured I'd just throw this one out there.

It's incredibly difficult to police a university-sized network. To make matters worse (for admins), sites in the .edu top level domain are common targets because of their size, crappy student-created webapps, and the google juice that a big .edu can bring to a link farm. Because of this, it's really not uncommon for this kind of thing to happen. Scripts scanning for web vulnerabilities can infect huge swaths of a network in one swoop.

Targeted google dorks seem like an ideal way for edu admins to stay on top of this kind of thing, especially because the googlebot will probably know about it far before you do. A simple google alert can be set up for your domain (such as site:*.msu.edu), and the results will literally just be sent to you. No need to make this difficult, guys.

Checking for HTTPS with JavaScript

SSLStrip is a really sweet tool that came out a couple years ago. While I won't go into detail here, sslstrip allows a man-in-the-middle attack against secured web connections by parsing out all HTTPS links and replacing them with regular HTTP. Sslstrip will even add a lock favicon to help convince the user HTTPS is in use, but most people probably won't even notice, which is why the attack is so brilliant. The server won't see anything out of the ordinary, and unless the target checks their URL, they won't receive any warnings either.

You can learn more about sslstrip here and here.

This attack got me thinking about ways that a website itself could help ensure an encrypted connection. Web browsers themselves are code delivery systems (HTML, JS, etc) are essentially code interpreted by the client), which means web developers should be able to offer at least a little bit of help. (MITM detection software exists, but usually proactively needs to be installed and ran by the user.)

It should be noted that many "secure" websites will still offer unencrypted connections, on the off-chance that a user's browser doesn't support HTTPS. Most browsers today, however, support secured connections. Even mobile browsers issue warnings, even if they are varied.

Note: the following is best solved by setting HSTS headers, which most browsers are beginning to support. This is just an experiment for a programmatic solution.

In our scenario, we're going to assume we have an HTTPS-only web app with a user who's been MITM'd with sslstrip. The goal was to help slap the user up and make them notice a lack of encryption. To do this, we can send them a piece of embedded javascript to check the current URL. This is a naive detection method, as javascript could be blocked by the attacker or tampered with. To help get our script through to the user, we can heavily obfuscate it on the server-side, and preferably add some element of randomness to help avoid a constant signature that could be regex'd out of our page. This is important, as an attacker that notices what's happening could easily defeat our checks before we get a chance to warn our user.

With fingers crossed, our attacker isn't aware of our code snippet (and is, perhaps, just passively grepping sslstrip output for credentials).

Example JS

//This check should run on pageload
var sslFlag = (window.location.protocol == "https:");
if (!sslFlag) {
alert("This connection isn't secured. An attacker is possibly intercepting traffic.");
}
//If sslFlag returns false or we never receive an AJAX report, make a log and possibly take action, such as a temporary password reset
ajaxReporting(ourDomain, sslFlag);

Homograph Attack
Sslstrip can also perform what's called a homograph attack, wherein the attacker uses look-alike characters to pose as the webpage they are attacking. While the above code wouldn't be very helpful in this scenario (as the connection is still HTTPS), we could instead check the character code of each letter in the URL. If the URL isn't correct, then we could fire off our warnings.

The homograph attack requires the attacker to have targeted a specific site, at least to register their false domain, so the chance of them noticing our code increases significantly.

Summary
I want to make it clear that I am by no means knocking the awesomeness of sslstrip or implying that this is a foolproof detection method. I'm very aware that this can be easily defeated if someone is expecting it. This simply adds one more step that needs to be taken care of for a successfully sneaky attack to take place.

That said, in my experience as a developer, websites often absolve themselves of responsibility for attacks that occur on local networks, and this simply struck me as one possible way to sneak some extra help to users in possibly hostile environments. In a critical situation where it's better to be safe than sorry, any extra layer of warning helps.

Detecting Firebug

Lately I've noticed a few sites that attempt to check if Firebug is enabled. Sometimes this is for legitimate purposes, sometimes not so much. For example, some web apps warn you about performance degradation, while some malicious websites will attempt to attack browsers with debug tools enabled.

Until recently, firebug was easily detectable by the window.console.firebug object, which would return the version of firebug installed, if applicable. This has since been removed by the developers.

Regardless of your intentions, for now you can still detect Firebug by analyzing console properties. Any unique properties that firebug adds to window.console can be used (ex. exception, memoryProfile, memoryProfileEnd). This can be implemented as

if (window.console && (window.console.firebug || window.console.exception)) {
/* firebug is active! alert(), fire ajax, crash browser, redirect, whatever */
}

You can read about this technique in more detail at StackOverflow, as well as some other interesting hacks for detection.

Fun with JIRA

Atlassian's JIRA is an issue tracking system brought to you by the same people who made that-sounds-like-a-disease Confluence. It's used by a wide array of different companies to assign software developers to bug fixes and feature requests. The app itself is Java-based and typically comes bundled with Apache Tomcat. You can read more about the requirements here.

Google Dork
Due to distinct URLs that the JIRA dashboard generates, you can find open systems with a simple search for:

inurl:/secure/Dashboard.jspa

Some of these JIRA instances require authentication to poke around, others don't. Either way, it's an interesting look into who uses JIRA and what issues they're tracking. Highlights include software components, technologies in use, and developer names.

Server Information
JIRA also supports a charting plugin, built around JFreeChart. You can see an example of one of these charts in the screenshot below.

In version 4.3.4 (I haven't tested any others), you can right-click on this image and select "View Image." This will take you to a URL with a format similar to .../charts?filename=jfreechart-onetime-666hashstuff.png and give you a classy dump of server information.
In the "cause" section you can see the install directory and location of the temp folder used for chart generation. If you dig past the stack trace, you can find things such as:

• JIRA versions
• Build dates
• Install types
• Application server / version
• Memory information
• Java version and JVM
• Username
• Server OS
• Server processor architecture
• Database type / version
• Plugins

As well as a bunch of other random information. This is possibly just the result of a misconfigured error page, but JIRA's own tickets seem to suggest that it's supposed to happen. Regardless, if you happen to notice a JIRA install, it may be worth looking for.

Also worth noting is this ticket, which suggests that some of the generated charts stick around for a while, which could be hard on that old temp directory.

Tumblr Using Amazon S3

Apparently Tumblr uses Amazon S3 for hosting content. Viewing an image on their site recently gave me a URL of:

http://s3.amazonaws.com/data.tumblr.com/tumblr_XXX.jpg?AWSAccessKeyId=XXX&Expires=XXX&Signature=XXX

As opposed to the URLs you normally see when viewing an image on Tumblr:

http://XX.media.tumblr.com/tumblr_XXX.jpg

The original URL is now giving me an "access denied" XML response but there are a bunch of references to it to be found on google. It's also worth noting that the XML response is the same for broken links regardless of which of the two previous URL formats you use. The s3 URLs appear to have been in use since at least 2009 (from some of the googlebot's crawl dates).

I found this interesting because I didn't see any prominent references to S3 storage on any of Tumblr's user agreements or staff blog. As more companies move to cloud storage solutions, users need to be more aware of where their information is going. What additional policies or user agreements, if any, are implied when your data is stored on Amazon? Is information passing country borders and subject to new laws?

On another note, while searching for more about this, I found this article mentioning a leak of Tumblr's API credentials, including their S3 clusters.

Vampire Crabs

A couple weeks ago, my girlfriend and I purchased a trio of Vampire Crabs from a local pet store (Preuss Pets, for those in the Lansing area). They had a sale on 10 gallon aquariums for $10, and it seemed like the perfect opportunity. We had been discussing getting some type of crab for a while, as we wanted to set up a sweet aquarium landscape. Land crabs and brakish/saltwater crabs seemed like too much maintenance for us, but then we got lucky when we spotted these guys. The important thing is that we can now officially tell the world: we have crabs.

We were given a care sheet about them and did some internet homework about 'em here and here. They're fairly easy to care for and are pretty social guys. We decided to name ours after some of our favorite black metal icons (Euronymous, Quorthon, and Count Grishnackh). Plans are currently in the works to pick up another few of them, too.

Vampire crabs are brightly colored freshwater crabs that require a good mixture of shallow water and land. They're pretty small guys, only about an inch or two across, and stay pretty small. Although they're not very territorial (~6 can live the good life in a 10 gallon), I have witnessed a pair of them slap-fighting over a hiding spot. Kids are so cute at that age.

Speaking of which: they like hiding and are somewhat nocturnal. Although Vampire Crabs do come out during the day, they seem far more active in a warmer dusk setting. A nice LED lamp will help them feel at home. Ours have been doing fine at room temperature (around 75f).

Although scavengers, our crabs seem to be picky eaters. Meats and fish food pellets seem to be favorites. It's also worth noting that they do not hunt or bother most aquarium mates. Ammonia and nitrate levels in their water need to be kept low, however, so watch out for any rotting food they've tried to hide. Certain plants can help with this (cryptocoryne species, anubias, java ferns/moss), otherwise clean out the tank a bit every week or so.

JavaScript Obfuscation

Hot on the heels of the last post, I figured I'd quickly talk about the flip-side of beautification.

What?
JavaScript is a client side scripting language that you're probably already somewhat familiar with if you've ever fought a losing war with pop ups. It's often used to add dynamic elements to otherwise static websites, however you can do all sorts of neat junk with it.

Code obfuscation is the sweet, sweet art of making your junk hard to understand. That's right, there's actually a word for it.

This brings us to javascript obfuscation. Because javascript is run "client-side," (as opposed to server side), your computer grabs a copy of it and runs it. When you view a website with javascript in it, you have full access to the script being executed. Besides looking at the actual logic of the code, you can even change how it runs using snazzy tools like firebug or kill it with things like noscript.

In the wild, there are plenty of reasons why you may want to hide your code... But usually there are only two:

1) You worked really hard on your script and you have deep-seated issues about sharing.

2) You're doing bad things and you don't want people to know what the things are.

You may also just write horrible code, but that's usually unintentional so I'm not adding a 3rd.

How?
There are plenty of tools out there to accomplish this or, if you're the industrious type, you can always do it by hand. For those of you who don't want to wait several hours tediously re-writing their scripts, here are two awesomely effective websites to help you out.

The JavaScript Packer - a javascript compressor and obfuscator that'll help make your code smaller and less user-friendly. For some fun stuff, trying switching on the "base62 encode" and "shrink variables" options.

The Free JavaScript Obfuscator - does exactly what it says. More human-unfriendly goodness.

The real awesomeness of these comes when you chain them together. Take a simple alert('yo') script and run it through both of them a few times. Have fun.

Keep in mind, though, that if someone has your script, even if it's obfuscated, they still have your damn script. And if they're good enough, you bet they can figure out what it does and reverse engineer it.