The Hacker Academy FREE Trial Module is HERE!
November 29, 2010
Man – are we excited about out this, seriously. We spent a great deal of time over the summer, speaking to a lot of you at the conferences we were at like HOPE, Black Hat, and Def Con. We got some awesome feedback from a lot of you, especially on the topic of this post. So without further ado – we know this has been a long time coming…
You Asked, We Listened: Introducing…
The Hacker Academy Free Trial Module
We are now offering 30-day trial access to a FULL module, pulled right from the THA members curriculum. Not only do you have full access to the entire video lesson, but you have access to the full hands-on lab. All for you, at absolutely NO cost, what-so-ever.
If you’ve ever been interested in becoming a member of The Hacker Academy, here is your chance to experience a piece of the THA members’ site. If you’ve never been interested in becoming a member…well – you’re welcome to come get your FREE learning on.
Sign up to receive exclusive, FREE access to this trial module:
As always – if you have any questions about becoming a member, feel free to get get a hold of us; we’d love to help out. Just send an email to hac...@thehackeracademy.com
Cheers,
The Hacker Academy Team
Our Thanksgiving Gift to You
November 22, 2010
Here in America as most know, the 4th Thursday in November each year is Thanksgiving. Traditionally, it has been a time to give thanks for a bountiful harvest and have a ridiculously big meal. The Hacker Academy thought we should celebrate Thanksgiving with a feast as well. We are serving up two new modules on Thanksgiving Day and a free webinar on Wednesday the 24th (the day before Thanksgiving). This is the best way we could think of to give thanks to our members as well as those who are thinking of becoming members. Members will be feasting their eyes and hands (hands-on labs) on Jeremy’s new module “Experimenting with the PDF Launch Action” as well as a new module from Dan Frye on “Metasploit Advanced Topics: Using Meterpreter Scripts Post-Exploit for Evasion and Connecting”.
Members and non-members alike should prepare for a pre-Thanksgiving treat, as Mike Murray will be serving up a free webinar that will cover the mindset of a hacker. Information covered in this webinar is taken and expanded on from the first module within The Hacker Academy.
Here is a brief description of what Mike will cover: Becoming a great hacker is about more than just skill. It takes a strong set of thinking and problem-solving skills as well. This webinar will teach you about the different types of intelligence and problem-solving skills that great hackers require, and will challenge your abilities on those skill sets.
- Convergent and Divergent Thinking
- Inductive and Abductive Reasoning
- Recursion
When: Wednesday, November 24, 2010
Time: 2PM EST
Length: 1 Hour
Where: Online
Cost: Free
To join us for this 1 hour free webinar, Click Here!
We wish everyone who celebrates the holiday a happy Thanksgiving and a wealth of knowledge during this holiday season.
Cheers,
The Hacker Academy
Latest installment of Advanced Metasploit released to THA Members Site
November 13, 2010
The latest in Dan Frye’s Advanced Metasploit series posted to The Hacker Academy Premium Members site!
Dan Frye has been working hard on producing a ton of cutting-edge content based on Advanced Metasploit techniques. This time around, Dan teaches about using Meterpreter post-exploit for recon purposes:
“Meterpreter offers an incredibly flexible approach to performing reconnaissance of a victim post-exploit. This module will review what scripted commands are available and how they can be used to retrieve information from an exploited Windows host..” Become a member to see the rest of the lesson.
Dan will be back near the end of the month with his next installment. Also at the end of the month, Jeremy Conway’s new lesson in his on-going series on PDF attacks will be released. Be sure to be on the look out for both of those.
Not a member? Just take a quick trip over to our membership page and sign up – you’ll have access to the whole gamut of modules available to our members, but the above are great examples.
Cheers,
The Hacker Academy Team
Tooncon: a night out on the ‘toon’
October 8, 2010
On the 1st of October 2010, I had the great pleasure of attending the second ‘Tooncon’ infosec meetup. Named after the town where it is hosted (Newcastle-Upon-Tyne is nicknamed ‘the toon’ after the regional pronunciation of ‘town’), Tooncon is a hacker meet-up where established infosec enterprises share ideas and experience with other businesses and local ethical hacking and computer forensics students.
What is unique about Tooncon compared to the other ‘run-of-the-mill’ hacker meet-ups is the unique dynamic between the students at the local universities who study some variety of infosec course and the local infosec related businesses.
On this occasion, the group met at a local ‘world’ bar called Nancy’s Bordello. Upon arrival, multiple impromptu wireless internet connections were created and a mad scramble for powerports began. Once everyone was nice and comfortable, with a drink in one hand and their backtrack-booting netbook in another, the true magic began.
In what could only be described as not unlike vultures attacking an injured gazelle on the Serengeti Plains; a sizable portion began looking for vulnerabilities in an unnamed, popular web browser, whilst another portion of the group decided to have an in-depth conversation about ARP poisoning.
In some respects we must have looked considerably conspicuous; a group of blatant geeks sat with their laptops out whilst the rest of the room was dancing to the Buena Vista Social Club. Nonetheless, we were left to our own devices, and had a fun, productive meeting.
For those who intend to attend a Tooncon gathering, it is held on the first Friday of every month at Nancy’s Bordello, 13 Argyle Street, Newcastle Upon Tyne, near the Manors metro station.
Cheers,
Matt Hughes
Jr. Instructor
BruCON Brussles 2010
October 8, 2010
From the 23rd of September to the 26th of September, I had the pleasure of visiting the Belgian capital of Brussels for the two day hacker conference that is BruCON.
Held in the breathtaking post-modern architecture of the Belgacom Surfhouse, the hackers that had flocked from five continents to visit were provided with food, beer, a fat-pipe and all the mind-expanding talks they could consume.
Dale Pearson did a fantastic talk on hypnotism, neuro-linguistic programming and how that translates into social engineering; a useful part of any penetration test. Dale is an effective speaker and certainly conveyed points that would normally arouse skepticism.
Paul Assadoorian gave a talk on embedded system hacking. He talked about the importance of embedded systems in our society today, and how they can be exploited to gain world domination. Paul is a naturally charismatic person, and an absolute riot to hang around with. I’ve got massive respect for all the work he does.
Of course, there were more talks than these two, although for the sake of brevity, I’m just going to mention these two. It’d be a fairly lengthy blog post otherwise.
When we got tired, we drank an energy drink native to Germany called ‘Club-Mate’ (pronounced mah-tey), popular with hackers and geeks worldwide. It has an unusual taste, and as its brutally honest tag-line says, ‘you’ll get used to it’.
Infosec podcasting heavyweights such as Paul Assadoorian of Pauldotcom and Chris Nickerson of Exotic Liability were in attendance, along with the SecureIT podcast, Disaster Protocol and EuroTrashSecurity. The culmination of this was the podcasters meetup. To a live audience in the main auditorium, the podcasters thrashed it out in a heated debate about security professional/developer relations and whatever came to their minds.
After all the talks, we all headed to the local bars to hang out, wind down and grab some of the fantastic Belgian beer. It was a pleasure to hang out with the heavyweights in the industry and grab a beer with them, and I look forward to the next years festivities!
Cheers,
Matt Hughes
Jr. Instructor
Friday Rundown – 9/24/2010
September 24, 2010
I’m starting a new thing- a weekly summary of what I’ve found interesting in the security world. Naturally, there’ll be a web app bias, because that’s what I follow. At any rate, here’s a few links and thoughts about what’s going on.
Samy Kamkar (the guy that wrote the Samy Worm) released the Evercookie, demonstrating how to track users based on many unique aspects of their web browers. Most users don’t clear their cookies often enough, but how many also clear their browser cache, their Flash LSOs, and their browser history? Oh, also, the Evercookie can persist across multiple browsers, and multiple sessions (due to Flash’s lack of boundaries, mostly). Wouldn’t be hard to make it work on multiple computers too, and that’d be neat. I’ve been saying for a while that the public fear of cookies is pointless- there are plenty of other ways to track users (and there’s a lot of valid ways to track people that the Evercookie is still missing, like SSL session IDs). At least cookies are easy to get rid of.
Twitter got hit by another XSS worm. That makes 4 this year, by my count. Trust me, this isn’t the last XSS hole in their app, and it surely won’t be the last worm.
At the same time, Stefano Di Paola was trying to report a DOM-based XSS hole in Twitter. They initially ignored it, assuming it was the same hole that was being actively exploited by the worm. When he persisted, they “fixed” it with a poor regular expression, which he quickly bypassed.They patched it again once he’d blogged about it, and still haven’t done a particularly great job of it. I don’t know if the lesson here is that Twitter is bad at security (we already knew this), or that it’s not really that easy to prevent XSS (we already knew this too), but it’s an interesting story at any rate.
It’s actually been a pretty slow week- more people talking about Facebook being down and Twitter being hacked than “serious” security stuff, but Rafal Los brought up some interesting points in a post on code vulnerability metrics. I don’t agree with everything there, so I’ll probably be putting together a full blog post on the subject next week. A lot of people were out at Source Barcelona and now Brucon this week, so there will likely be some good conversations coming from that.
Until then, here’s a tip of the week:
Subscribe to your local OWASP chapter‘s mailing list and go to one of their meetings. You’ll meet smart people, learn a few things, and have fun. If there’s no OWASP activity, find other security groups, or even Linux user groups.
McAf.ee is Stupid
September 21, 2010
McAfee just announced that they are releasing a URL shortener, and it’s currently in beta (well it actually says “This Site is a Beta.”). Honestly, I’m still trying to figure out what it’s actually useful for, and not coming up with much. Did somebody decide it was needed? Did somebody think it would be helpful? Is this just McAfee swinging wildly in the dark at things that vaguely sound security related in order to bloat their product portfolio and brand?
Yeah, that might be it.
At any rate, there’s a few issues I noticed with a quick inspection.
The server doesn’t appear to be prefetching the URL, so it can’t have any idea whether the URL is dangerous or not. Presumably it’s checking the URL against the (admittedly impressive) database of sites that they use for SiteAdvisor, another McAfee product.
It does have some basic Javascript/XSS filtering, but it’s only effective against specific vectors- it filters out some HTML characters (like < and >), but not other XSS vectors: " onload=alert(1)
Most URLs will be placed inside an iframe with some basic information about the target URL. If the URL is deemed harmless (or “green”), the user’s browser can be set to bypass the iframe and go directly to the page. Presumably this is just a convenience– there’s no way this could actually provide any browser security, but if a way to attack this iframe were found, or if the iframe needed to be disabled, an attacker could turn that feature on/off via CSRF:
http://mcaf.ee/api/config?bypass_frames=1
http://mcaf.ee/api/config?bypass_frames=0
The only real information McAfee provides somebody visiting a shortened URL is in the iframe, where it says what kind of website they think you’re visiting (in the case of skeptikal.org, it’s “Software/Hardware Blogs/Wiki”). Interestingly, if the link I provide throws a 302 or other redirect, it still thinks you’re looking at my site. Since they’re not prefetching the page, they have no idea whether I’m redirecting you elsewhere, or attacking you directly. If users are screening pages using McAf.ee, it’s trivial to bait-and-switch them onto another site.
The question I’m still asking is “who thought this would be useful?” It’s really not. First off, they claim to let people create “safe short URLs.” That’s not even close to true, based on what I’ve seen. Second, the whole thing is pointless unless users refuse to click on any other shortened URLs– a ridiculous proposition to begin with. Attackers will just use a different URL shortener. Users will keep clicking on anything, and it’s not the URL shortener’s job to keep them safe at any rate. Not to say that McAf.ee directly causes security issues, but it doesn’t appear to solve any security issues either.
/sigh
The Twitter XSS Post-Game Show
September 7, 2010
Since you’re here, you’ve probably already heard about the Twitter XSS shenanigans from the last few days. The short version: Somebody found a hole in Twitter, and I decided to write a proof of concept. There wasn’t really any motivation, other than the fact that I woke up earlier than usual and felt like coding an exploit. That said, a lot of interesting things came from it, and it spawned a series of related projects that I’ll be working on for months to come. Overall, it was fun.
What Happened
Monday, 4:00 AM: Woke up. Couldn’t sleep, so I logged on to see what was happening in the world. I saw an XSSed.com post for a hole in dev.twitter.com and slapped together the original proof of concept.
The exploit was pretty simple- I created a web page with a button that said “pwn me.” When you clicked it, your browser would be forwarded to the vulnerable page on dev.twitter.com, which would execute arbitrary Javascript, collecting your cookies from the browser and sending them back to my server.
My server would then use your cookies to make requests directly to Twitter, posting a tweet using your session (and by extension, from your account). That tweet, in turn, contained a link to the original exploit page, which all your followers would see. Essentially, this allowed it to spread like any other XSS worm, though as a proof of concept, it did provide ample warning to users about what was going to happen.
4:15: The exploit went live and I tweeted about it. I then went out for breakfast.
Throughout the day, my exploit page was viewed 1823 times. 221 individuals were kind enough to test it and send me unique session cookies. How many of those users didn’t read the warnings and were embarassed by essentially handing me the keys to their Twitter accounts, I can’t say, but only 34 of those tweets are still in the public Twitter feed. Many people tested the exploit, then deleted the resulting tweet. Many more tested the exploit from private accounts. A small group used temporary “test” accounts to play with it.
I wasn’t logging any personal data (I’m not Google, after all), so I only know how many unique, successful exploits took place, which ones are public, and which ones were public, but have disappeared from the timeline.
At some point during the day, a spammer released a “real” version of the same exploit, attacking primarily users in Brazil. Their attack code performed essentially the same cookie theft operation as I did- it is a pretty standard session theft attack, after all. The difference, of course, is that this one was automated, and contained no warning messages for the user. The numbers for this attack are even less reliable than mine, but the malicious bit.ly link currently has over 116 thousand hits. I’m betting the actual compromised sessions are less than half that, given that many users will click the link multiple times, many “clicks” will come from bots, people who aren’t logged into Twitter, etc. The only people who could really say are Twitter, the attacker, and maybe the folks at bit.ly. Regardless, this certainly speaks to the efficiency of automated exploits.
About 4:15 PM: Twitter fixed the original bug, and I took my proof of concept offline.
About 11:30 PM: @kinugawamasato tweeted a second variant of the same exploit. I didn’t see it till the next morning.
Tuesday, about 9:00 AM: I saw the new exploit, adapted my proof of concept, and put it back live. Over the next hour, I collected another dozen sessions, but it didn’t get enough time to pick up steam before things started acting strangely.
12:00 PM: Twitter appeared to have fixed the issue completely, replacing the search form with a standard Google search.
The Technical Details
The original vulnerability was exploited by passing double-urlencoded parameters to the search form on dev.twitter.com. Presumably, those parameters were not normalized properly before the filtering/validation phase, and so malicious Javascript characters could be inserted into the page. This isn’t a remarkably unique vector, or a difficult one to find. I’m surprised it took this long for somebody to look.
When this vulnerability was fixed, the second variant was a bit more arcane, but not really all that different. Parameters sent to the server included UTF-8 encoded characters, which again, were able to squeeze past the filtering/validation phase undetected. Kind of cool, actually.
The server side of how I performed the exploit really isn’t that interesting, but since several people asked to see the code, here it is, in all its bug-ridden, insecure glory. This script does not exist on my servers anymore. 
My Analysis
The big question bouncing around the security media echochamber is “what does this mean?” Lots of people have lots of ideas, and most of them are wrong.
First off, Twitter doesn’t have a very good security track record. I doubt this is shocking to you, but it’s yet more evidence that you should be careful about how much trust you place in Twitter itself, and in the tweets of your friends. Something to keep in mind, at least. (As a side note, Twitter has been trying to hire security people for some time, so if you think you’re up to that particular challenge, I’m sure they’d be happy to talk to you). They’ve done impressive things with scalability, data management, and arguably, created a whole new way of communicating with people. Twitter is a very interesting company, but security isn’t something they do well.
The key to these attacks, of course, was faulty input sanitization. Input sanitization is extremely hard to get right, and there is no reason that Twitter should have been manually patching specific vulnerabilities. If they’d used a decent, standardized sanitization library, the issue could have been fixed once and for all, and probably prevented in the first place. I’m a big fan of OWASP’s ESAPI project, and it probably would have helped here.
It is important to note that Twitter’s session cookies are scoped for the entire *.twitter.com domain. This certainly makes it easier for users to stay logged in between, say, the mobile, static, and regular web sites, but it also opens them up to serious issues.
Another XSS hole on any subdomain of Twitter.com (there are many– subdomains, and XSS holes) can be exploited in the exact manner as these last two. If Twitter intends to keep the wide scope on their session cookies, they really should be much more careful about what other applications live on “twitter.com” domains– particularly domains pointed at third-party servers, such as apiwiki.twitter.com and status.twitter.com. In fact, one of these applications has its own XSS holes, and there’s nothing Twitter can do about it (more details will be coming when I’ve coordinated a fix with the vendor, presumably).
Twitter, by the way, is not alone in this problem- virtually every nontrivial site on the web has sessions scoped the same way, and is vulnerable to similar attacks. Web browsers make trust decisions based on domain names (flawed as that system is), and most website owners are far too blasé about the value of their namespace.
XSS is a massive problem. It’s really a pretty basic attack, which is why it’s not all that interesting to most researchers. It’s trivial to find, trivial to exploit, and we quickly move on to other things. The problem, though, has not gone away. As websites grow, scope widens, and browsers gain more functionality, the XSS problem continues to grow steadily worse.
There is absolutely no excuse for a major website like Twitter to not have gone through a serious application security review process, quarantined non-essential applications (such as this developer documentation site) with unique domains and tighter-scoped session controls, and then reviewed the remaining applications for security vulnerabilities. If you build a web property with this much attack surface exposed, trying to find and fix individual bugs is pretty much pointless.
I won’t make any judgment about how smart it was for people to use my exploit, despite the warnings. The fact is, you are vulnerable to these attacks unless you are taking specific measures to prevent them. I’ve seen comments from some people who feel clever about not clicking my (well-labeled) malicious link, but they’re still browsing with Javascript enabled. Trust me: You really can’t trust me. I don’t even browse my own website without both NoScript and RequestPolicy cranked up.
Interestingly, in the times when NoScript is most needed (critical or popular websites that you interact with regularly), you’re the most likely to have it disabled. If you use Twitter’s web interface at all, you have to disable NoScript for that domain– it’s simply not functional without Javascript. The exploit itself didn’t have to use Javascript at all outside the twitter.com domain, so odds are, it could have worked on you even with NoScript installed. Still, NoScript has quite a few other security features that work even when Javascript is enabled, so it’s still useful, even if you globally enable Javascript (though I hope you don’t). I’ve said it before, but for a secure-by-design browser, RequestPolicy is where it’s at.
Final Thoughts
- You really shouldn’t click a link that says “I just got pwned” unless you really know what you’re doing
- XSS attacks are incredibly easy to exploit, and difficult to prevent. This makes them extremely dangerous
- You trust your web browser far too much
- Your web browser trusts me far too much
- NoScript is nice, but when you need it most, you’re probably not using it
- Self-referential hacks are hilarious
–Mike Bailey
Another day, another Twitter XSS
September 6, 2010
It may surprise some, but I really haven’t been big on XSS lately, mostly because it’s a problem that hasn’t changed for years, and the most basic form of it is still brutally simple to exploit. Not a lot of excitement in it, I guess. But that doesn’t mean that it doesn’t deserve attention- in fact, that’s exactly why it does. So when a new Twitter XSS popped up on my feed reader this morning, I took the 10 minutes it takes to write a proof of concept, and put together an exploit.
You can check it out if you like (It won’t bite until you manually click the “pwn me” button, so the link is safe, but don’t take my word for it, use NoScript and RequestPolicy). Frankly, if I wanted to hack you, I’d be doing it silently on this page, not that one.
I’ll post a followup later. This example drives some pretty interesting points home.
Cross-subdomain Session Fixation
September 2, 2010
Last fall I wrote a bit about cross-subdomain cookie attacks. As often as I come across more uses for them, I think that they are a much more serious issue than most people (myself included) have made them sound. Today, I came across a variant which I’d theorized about in the past, but never bothered to find in the wild, and I think it merits some attention.
You may be familiar with Hack Is Wack- a stupid marketing campaign from Norton/Symantec. The premise is simple: users submit videos, which are voted on, and the winner gets to roll with Snoop Dogg…’s manager. You may not know it, but most of Snoop’s music is information security-related. “What’s My Name” is about AuthN, “Drop it like it’s Hot” is about SQL injection, not to mention constant references to cron, gzip, and other unix commands in his lyrics. It’s really a pretty natural match.
At any rate, the Hack is Wack site is chock full of holes. For example, there’s the publicly available, indexed cache directory with all that SQL, JSON and other data. There’s the XSS vulns (HTML5 only, though it should be simple enough to rewrite), CSRF holes, and the Flash upload issues in the video upload script (a Joomla module that appears to have been used without any quality control or review despite the fact that it’s currently in Alpha)
A security company using bad code in a marketing site? Shocking, I know. I’m really not here to harp on them though. I’m over security vendors being full of shit- they all are, it’s not news.
I just found a particular attack vector interesting.
The voting system for uploaded videos is grossly vulnerable to CSRF, and probably much more serious things, based on the format of the “vote” URL (unencoded, for ease of reading):
http://www.hackiswack.com/index.php/home/rate.html?videoid=\'.24.\'&rating=4
This means that I can create image tags in my own website to vote for a specific video and stuff the ballot box. Classic CSRF, right? It’s something I’ve talked about before, but unfortunately, this one isn’t quite so simple. You have to be logged into the site to vote, and they prevent a user from voting twice for the same video, so to manipulate this poll, we really need to create a whole bunch of user accounts. The user registration page is part of the main Joomla codebase, and it uses session-based tokens to prevent CSRF- the way they should.
The interesting thing here, is that the application doesn’t enforce the HTTP Host header. Instead of http://hackiswack.com, there’s no reason you can’t use the application from http://184.106.223.144, or more importantly, http://hackiswack.skeptikal.org (no, this doesn’t actually go there, but there’s no reason it can’t).
Once I have my own domain set up, I can easily force a visitor to skeptikal.org to assume arbitrary session cookies that will also be sent by his browser to hackiswack.skeptikal.org, and with a known session cookie, I can request the page myself and parse it for the CSRF token. I can then embed that token in any forms I force the user to send, bypassing the protections that Joomla so carefully puts in place.
All right, so this is a lot of work, and probably isn’t practical for stuffing ballot boxes, (especially since there are already much more serious vulnerabilities to take advantage of) but as a way of bypassing CSRF protections, it’s perfectly valid. There are plenty of times where a CSRF protection mechanism can be bypassed with a simple session fixation attack. A variation on this was described by RSnake last fall, using DNS rebinding instead of subdomains. It’s probably more potent with DNS rebinding, but a cross-subdomain attack tends to be much simpler to set up.
The key to remember is that in this case, you can’t take over an arbitrary session, so it is of limited use for, say, compromising an Admin. However, if you want to log a user into a website (with known credentials), or otherwise force him to do something on your behalf, it’s a very useful technique. Something to keep in mind, at least, and another reason why websites that don’t require specific Host headers should be considered vulnerable.
-Mike Bailey
Cross-posted from http://skeptikal.org.
Hat tips to The Harmony Guy and Packetwerks for pointing out some of the holes in the Hack is Wack site
