#HackerKast 18 Bonus Round: Password Cracking

Hey Everybody! Thanks for checking out this week’s bonus footage. We like to do these to not just focus on current events but to also get our hands dirty with some technical demos. This week, we decided to talk about password cracking.

You hear news stories all the time about passwords being stolen and you may have heard of password hashes being cracked. What this means is that somebody got a hashed copy of a lot of passwords out of a database and are running programs against it to get the plain text password out.

For those of you familiar with password cracking this will be super boring but we decided to actually show what this looks like for those who haven’t seen it. I decided to use John the Ripper for this demo but could have used a ton of others like OCL Hashcat. Kali Linux has a few of these installed by default for those who want to play.

Since we are web app guys here at WhiteHat I decided to pick on some password hashes that make sense in our world, WordPress. Most password cracking demos you’ll see are running against local machine password files so instead of that I made a few of my own WordPress password hashes. The giveaway showing that these are WordPress hashed passwords is that they use a PHPass algorithm which results in a hash that always starts with $P$B.

The passwords I chose were pretty easy ones just to prove to you guys how easy cracking easy passwords is. Anything in the top couple of 1000 used passwords will be cracked in seconds with the help of a word list, as you’ll see in the video.

The other major point I wanted to make is that seemingly “good” passwords that follow all the rules of a websites password strength requirements can actually be pretty weak. The example I used was “Jeremiah29:11″ as a password passes most requirements. It’s over 8-10 characters, it is has upper and lower case letters, has numbers, and special characters. Seems great right? Well since it is a popular bible verse, this took less than 30 min. to crack on my laptop and would take seconds on a computer built for password cracking.

Check out the end of the video for some of our tips on secure password selection. Let us know what you think!

#HackerKast #18: Verizon Tracking Cookie, NSA tracking via mobile ads, hackers for hire, AppSec Program Quick Start Guide

Hey Everybody! Can’t believe we’ve done 18 of these. Lets get right into it.

We started off this week by chatting a bit about Verizon. The headline kind of speaks for itself: “Remember That Undeletable Super Cookie Verizon Claimed Wouldn’t Be Abused? Yeah, Well, Funny Story…” Turns out Verizon will set a cookie in your browser and can track you across IP address, and all sorts of nastiness. Robert has some recommendations on how to work around this if you are worried about it. News flash, advertisers aren’t working in the user’s best interest.

Another news flash, NSA is tracking people. The newest revelation is that the NSA is using ads in mobile platforms to track users. This avenue is useful for them because the geo location is sent through a lot of these mobile apps ads so not only can they track users’ usage preferences but also physical location! Repeat after me, ads are bad.

Funny little website popped up recently called Hackers List. For those familiar with O-Desk this is the same thing but for hacking. This website is acting as a medium for people to post requests and a dollar amount for hacking services. Some of my favorite entries include, “Change my grades – $300″ and “Hack Facebook account ASAP – $200″, among others. We got into a bit of discussion of the legality of all of this and some possible loopholes that they are using to keep this website up and kicking. Consensus is that this will most likely be taken down, fast.

Finally, with some shameless self promotion, we chatted about a new OWASP project started by a few of us WhiteHat folk called the Application Security Program Quick Start Guide. Our goal here was some quick rule of thumb points on starting an AppSec program from scratch. Nothing like this existed to our knowledge so we tried to fill what we saw as a void. It is completely open license and free to download so feel free to use and abuse! Check out our blog outlining it and let us know what you think!

Notable stories this week that didn’t make the cut:
How to protect yourself against Verizon’s Mobile Tracking”>
New York Post Twitter Feed Hacked – declares we are at war
Obama sides with Cameron in Encryption Fight
Against DNSSEC
Why Not DANE in Browsers
Someone in China MitM’d Outlook.com Traffic With Fake SSL Certificate
Reflected XSS in PayPal

Remember That Undeletable Super Cookie Verizon Claimed Wouldn’t Be Abused?
New Snowden documents show that the NSA and its allies are laughing at the rest of the world
Hacker’s List allows you to hire a hacker anonymously and quickly
OWASP Application Security Program Quick Start Guide Project
5 Days to Setting Up an Application Security Program

Web Security For the Tech-Impaired: The Dangers of Email

Editor’s Note: The following post is the first in a series of blasts that we will be sharing for readers who are – or who know people that are – not technically savvy. We will touch on topics that we in the security community are very aware of and attempt to break them down into language that those who are not as internet skilled may understand. If you have suggestions for topics you wish for us to cover in this series, please share in the comments.

You’ve all been there. You open your email and your mom has sent you something. You see the two letters you dread: FW. Oh look, it’s an email with a link to a YouTube video about a cat who just can’t seem to figure out that the sliding glass door is a solid object. You contemplate sending back an email saying ‘Come on Mom, you should know to never ever click on links in emails,’ but you don’t want to ruin her fun — and more than likely she won’t understand WHY clicking on links in emails is a bad thing. You could try to explain it to her, but you’re afraid her brain will explode if you start talking about things like “Cross Site Scripting”. Well folks, I’m going to try and help you out. In this new blog series, I am aiming to provide tips and advice that you can share with your less-than-tech-savvy friends and family – whether its your mom, grandpa, cousin Vinny or whomever. These are posts that I intend for you to FW: (uh oh, there are those letters again) the links to your mom (or whomever) so that they can get a non technical explanation of the dangers of the ‘internets.’ Now begins the non-technical explanation, here we go!

Hello there! You’re no doubt reading this as a result of your son/daughter/grandson/granddaughter having sent you here for guidance. Fear not, I will help guide you through the dangers of the internet and help you be more secure with your personal information. No doubt you’ve heard of recent credit card breaches in stores you visit every day. You’ve also probably heard about ‘phishing’ emails that ask for your personal information in an email or ask you to click some link. You may have seen emails that say ‘Your credit card has been stolen, please email your Social Security number, mother’s maiden name and birthdate to this email address.’ The good news is that you can prevent yourself from being a victim of these scams.

The first thing you’ll need to know is that you should be very, VERY paranoid about anything you get in an email. If someone knocks on your front door, you’re always skeptical about what they want; the same principle should be applied to email. Anyone and everyone can email you and not all emails should be trusted, particularly from contacts that you do not know or that ask you for personal information. Most businesses make it a point to not request such information over email, so if you get such a request, it is quite likely a scam. Secondly it is very easy to fake the sender of an email. Just because it says ‘admin@bankofamerica.com’ doesn’t mean it is. Never trust that your email is coming from the business that it purports to be coming from.

Furthermore, links and attachments in emails can be bad news. Just as it’s very easy to make it look like an email is coming from someone else, it’s just as easy to make a link in an email look different. I can easily make it look like it’s going to ‘www.youtube.com/someFunnyCatVideo’ but really when you click on the link it will take you to ‘www.ImSoEvil.com/LookAtHowEvilIAm.’ Fake sites are set up under the guise of seemingly legitimate URLs in an effort to get you to click on them which could lead to theft of personal information or worse. Attachments in emails from unknown sources are also bad news. You could be unknowingly downloading malware — software that can interfere with the proper functioning of your computer, damage your privacy or even install the dreaded virus.

All this sounds pretty frightening already. You may think you now need to go make a tin foil hat and build a bunker in your backyard. But with this knowledge you are well-armed to combat identity thieves. Here are a few simple things you can do to help protect yourself:

* Never give your personal information to anyone. No legitimate business will ask you to email them your Social Security number, credit card number, passwords, date of births, etc., over email. If they’re asking for that information it is 99.9% likely that it’s a scam. Sometimes an attacker will send an email that makes it sound like there’s an emergency — if you don’t do what they’re asking for right away something horrible will happen! Instead of doing what the email says, if it looks like it might be from a legitimate business – like a bank that you do actually have an account with – contact that business directly. Don’t use any links from that email. Let them know what email you received and that you want to confirm whether or not it was a legitimate email.

* Never click on a link in an email — it’s just asking for trouble. If you really want to watch that cat video, copy the link address into your browser window so you can be sure you’re sending your browser where you actually want it to go.

* If you receive an email that has an attachment and you were not specifically expecting that person to send you that attachment, contact them directly and confirm that they sent it and it’s a legitimate attachment. More than once a friend of mine has found out that their email account was hacked because I contacted them about a suspicious attachment.

This is all but the beginning of your training and you should come back to this blog often to hear more helpful (and hopefully easy to understand) advice on how to better protect yourself on the internet. Go forth and click on!

Blackhat – A Review

Editor’s Note: Dan Lacey is a TRC Training Supervisor at WhiteHat Security and he recently blogged about the new move ‘Blackhat’ which was released in the theaters on Jan. 16 on his own personal blog. We have republished his movie review here as we are sure that many of our readers might be considering this movie as part of their upcoming entertainment plans. Please note, there are some spoilers in the following post. Enjoy!

As a WhiteHat hacker, I knew I needed to see a movie called Blackhat. As a movie buff, I dreaded seeing a movie that looked, frankly, bad. Fortunately, I work for WhiteHat, who rented out a theater so that we could all see Hollywood’s latest portrayal of our profession. Watching it in company made the experience a whole lot more enjoyable!

Some of you know that I write movie reviews. I also know that not all of you joined us for the screening of Blackhat. To save you the wasted time, here is my review. Feel free to share. Link is http://www.whitefoxmoviereviews.com/2015/01/blackhat.html

Movies that are released in January are awful. Hacking movies are awful. Blackhat is a hacking movie released in January. It should be no surprise, therefore, that it is awful. What is a surprise is that the depiction of hacking was not one of the worst parts of the movie. The plot, editing, and cinematography are far worse.

The inciting incident (the nuclear power plant breach, which was shown in the trailer) isn’t actually particularly farfetched. Last year hackers did serious damage to a German steel factory by hacking with the controllers to a blast furnace, which melted down. The Stuxnet work destroyed a whole lot of Iranian centrifuges around 2010 (meta-source). Most of the rest of the hacking shown is phishing or social engineering, most of which is technically reasonable (though if I were designing a bank’s network, I would not connect the machines at the front desk to the financial systems).

Unfortunately, the plot wrapped around the hacking is not nearly as reasonable. The main characters all suffer from Jack Ryan Syndrome, in which an analyst or other technical asset suddenly turns into a competent field agent, including the ability to make long-distance pistol shots while under fire better than trained assassins. Nearly everything about who they are and what they do strains credulity. The villain has no motivation beyond “crazy” – and while that can be done well, this is not. The romance subplot is laughably bad. Wei Tang does a fine job of acting the character which was given to her, but that character exists in the plot for the sole reason of being the romantic interest, which is pretty pathetic. None of the other performances are worth mentioning, mostly because the characters are not interesting in the slightest.

Blackhat is 2 hours and 13 minutes long, and I’m not sure why. I think there might have been about an hour and a half of plot, maybe an hour 45 if I’m generous. Nearly every shot lasts ten seconds or so more than it needs to, though, which makes the movie drag terribly. Some of those shots are completely out of focus for no reason whatesoever. Action movies should not be boring, but this one is.

Worst of all, every single shot is so shaky that the movie is almost unwatchable. Long-time readers will know that I am not a fan of shakycam; this is some of the worst I’ve seen. Even in shots with no movement, the camera waves around nauseatingly. Action scenes are far, far worse.

There is no reason to watch this movie unless you’re a hacker, want to see how bad it is, are seeing it for free, and want a headache.

I take solace in the strong possibility that every movie I see for the remainder of the year will be better than this one.

#HackerKast 17: UK Bans WhatsApp and iMessage, Instagram Privacy Issues, Cross Site Content Hijacking (XSCH), Amazon S3 Bitcoin Hack

Howdy Partners! Hope you all are in full swing in the new year and taking names. I know for a fact that a ton of you are busy since every hotel in Santa Clara, Calif., was sold out this month just as Robert and I were trying to visit the mothership.

Anywho… we started this week’s HackerKast chatting about how our blog post of the North Korean Web Browser got so much traffic that it DoS’d us. The ol’ Reddit hug of death got us and our poor IT department was thrilled with us.

The first news story we covered was the brilliant discussion going on across the pond in the UK about banning a ton of encrypted messaging services, including WhatsApp and iMessage. We all feel this is a silly reactionary measure to try to thwart terrorist communications but will have repercussions that will be wide-reaching. Knowing our audience, I’m probably preaching to the choir, but there are plenty of legitimate reasons for strong encryption protected messaging services. I think another side of my feelings were best summed up by a tweet:

Next, we brought up some Instagram news about a privacy problem they had over there. Turns out that if you ever had your Instagram profile set to public, no matter what your current privacy settings, your photos are accessible via direct URL. This is a thinly veiled illusion of privacy and further proves that if you don’t want a photo seen, you shouldn’t put it on the Internet at all.

Robert followed this up by mentioning briefly some new attack research that was published recently that was dubbed Cross Site Content Hijacking. We need another acronym like we need a hole in the head but this research could prove to be very interesting. The thing that perked our ears up about this type of vuln was that it might be possible to read arbitrary HTTP Headers across domain. This includes referring URLs which are widely used as a CSRF protection in many web applications including the Django framework. We haven’t dug deeply into this one but wanted to bring it up as a potentially interesting bit of research for you folks to chew on.

Some news about an Amazon S3 hack bubbled to the top this week which we’ve heard about before but is still super fun to talk about and – more importantly – to learn to protect yourself from. We all know our private keys are an important thing to keep private but with the ever-growing popularity of programmatically spinning up and down virtual instances in Amazon it is becoming easy to forget those private keys in your code. If you are using these keys in development and you accidentally leave them in your code when you push it up to a GitHub repo, those keys are now public. GitHub and Amazon do a good job of trolling the Internet keeping an eye out for this happening but it still happens, even to the best of us. A popular (mis)use case of this kind of hack is using your private key to spin up instances that start mining bitcoins for the attacker. This usually doesn’t get caught until the victim gets the big bill in the mail for the CPU time.

“Kid hacks into school’s website to shame them for making them go to school when the roads were covered in snow” has to be our favorite headline of the week. We’d love to include the screenshots from this website defacement but they are pretty NSFW. The kids hacking school stories are always a lot of fun because I think it resonates with a lot of us who have memories of being bored in school and playing with computers just wondering if you could switch your grades. Not that any of us did such a thing.

Notable stories this week that didn’t make the cut:
Iran oders 3 communication apps blocked (LINE, WhatsApp and Tango)
AT&T is going to start supporting webrtc
Silk Road Reloaded moving to I2p instead of Tor
Obama proposal: Hacked companies have 30 days to fess up

WhatsApp and iMessage could be banned under new surveillance plans
Iran orders 3 communication apps blocked
Your private Instagrams weren’t as private as you thought they were
Content hijacking proof-of-concept using Flash, PDF and Silverlight
Dev put AWS keys on Github. Then BAD THINGS happened
Angry Student Hacks County’s Website to Apologize for Snow Day

5 Days to Setting Up an Application Security Program

Congratulations! You now have the responsibility of ensuring your web applications are secure. This is the reality that modern day CISOs and security professionals address every day. You may have even lobbied for and championed this initiative because you are acutely aware of the risk that vulnerable web applications present to the business. Or as is often the case in reaction to a breach or an attack (aka a “security event”), web applications have now appeared on the radar of your senior management team. So, where to begin? Where’s the playbook?

To assist you in this endeavor, we have created an “Application Security Program Quick Start Guide.” WhiteHat has years of combined web application and security management experience which came in very handy for this undertaking. This guide is essentially a playbook that is both easy-to-consume yet prescriptive-enough that the reader is able to walk away with concrete action items to set in motion.

Web application testing is not a fledging security activity by any measure. That said, finding resources to help navigate the process of building a web application security program are scarce and often too high-level. In practice, there is no shortage of tools or services to perform web application testing, but testing alone is not a substitute for a comprehensive web application security program. To be successful, we should aim for a program that is more than simply testing sites and delivering results to stake holders. Those activities represent just two of the many inputs and outputs necessary to reduce the risk associated with web applications.

Today we are releasing this “Application Security Program Quick Start Guide” in the hopes that it will help CISOs in their ongoing work to ensure the security of their organization’s web applications and mission-critical information. In addition, we have donated the guide under a Creative Commons license to the OWASP community for everyone to use.

You can download the guide here: https://whitehatsec.com/whitepaper/2015/01/12/whitepaper_appsec_quickstartguide.html

The OWASP project page can be found here: https://www.owasp.org/index.php/OWASP_Application_Security_Program_Quick_Start_Guide_Project

We hope this initial draft serves to spur the collective insights of those willing to participate.

The Imitation Game – A Review

Warning: Spoiler alert!

I went to go watch “The Imitation Game” this weekend, on a bit of a whim. I know Alan Turing’s story rather well – having spent a lot of time in computer security will do that to you. Overall I thought the movie was really good – the acting, writing, and overall historicity were all very good.


  • The movie spent a lot of time talking about his personal life, and what lead up to his suicide. I’d argue that this was as much a movie about the father of computers as it was about the historical (and unfortunately current) marginalization and criminalization of homosexuality.
  • I was impressed how the movie explained how reduction of keyspace works in rather plain english and simple examples. The math might be improbably difficult for the average person, but they managed to make it accessible.
  • They mention the Turing test – though thankfully there were no CAPTCHAs in sight.
  • The movie spent quite a long time explaining why you cannot use a single signal to make any decisions or the adversary will switch tactics and you’ll lose that one signal. I try to make this point all the time and yet I still people doing things like blocking countries at the firewall by IP address. If you are in security, and you take nothing away from this movie, let it be this – do not use a single signal to identify and stop fraud/hacking. You’re hurting the ecosystem by doing so. Yes, you.

There were a couple cons though… Some cons that actually made me cringe.


  • At one point in the movie Alan Turing made the bear in the woods joke. Just about the time my eyes started rolling the audience burst into laughter – at this point I realized I was extremely jaded and should probably learn to live a little, hug a tree, run like a child or generally do something other than wince at old security jokes. But the reason I hate this joke is that is presumes that you can leave the woods once the bear has eaten your friend. Unless you plan to close up shop and leave the Internet, this analogy has always been a very dangerous one. Bears get stronger, and will get hungry again, and if you’re relying on running faster than an adversary who is dead you’re using the wrong analogy. I prefer the prairie dog analogy if you’re looking for silly analogies.
  • A big motivator throughout the movie was that at the end of the day a buzzer went off that meant that the Nazis had changed their encryption keys. So yesterday’s keys were “useless” and anything they had done had to be scrapped if they couldn’t complete it by midnight. Though it’s an interesting plot device it really doesn’t work that way. Decryption doesn’t stop at the end of the day, just because your key changes. If the adversary has the ciphertext and there is nothing ephemeral about the key, it can still be decrypted. Now if you’re going to make the point that the data loses value the longer it takes to decrypt – yes, I’m on board with that. But the movie didn’t explain that at all.
  • They don’t really talk about Turing’s other accomplishments, like the Turing Halting problem – which more or less describes the problem with blacklists and all kinds of other technologies. As a student of breaking crappy blacklists, this is one of his most useful accomplishments to my daily life. I really wanted to hear them mention it at least once, like they did with the Turing test. Alas!

I’d also point out that there were some other controversies about the historical accuracy as well that didn’t jump out at me as I watched it. Anyway, it was a really wonderful movie, despite the cons. I’d highly recommend it to people who want to know a bit more about our roots, and get a bit more familiarity with some of the core concepts that have brought us to where we are today. I love that we’re seeing more movies about real heroes and not the typical hollywood-manufactured superhero.

Aviator Open Source (Day 1)

We got some interesting feedback from Google in just the first 24 hours of open sourcing Aviator to the community. Interestingly, one of our initial barometers of success was getting to the point where Google had to talk about us, so today was a milestone for us!

The post makes some interesting points around the architecture of our fixes, pointing out that we are behind Google in patches and the fact that there are software security issues. Let me make it clear, we never claimed to be as fast as Google at releasing updates. In fact, that would be nearly impossible for a company of our size. Google gets the benefit of making in excess of $50 billion-a-year from ads by marketing it’s users to advertisers. Therefore, Google has a lot of vested interest in keeping the browser up to par and capable of delivering more ads to those users. To say we are outmatched is an understatement.

We decided to go open source with Aviator and thereby seek assistance from the community. All this being said, we would like to take a moment to respond to some of the points made in the post as well as respond to the advice that was shared:

  1. Yes, there are bugs in our code, just like there were bugs that we inherited from the Chromium code base.
  2. Yes, it is perhaps not an elegant code base like Google Chrome, however Chrome has bugs as well. That’s the nature of such a complex project. The nice thing about bugs is that they can be fixed.
  3. Advising users to not use Aviator misses the bigger picture. To tell people that if they use Chrome, add Disconnect and change some privacy settings you’ll get the same thing as Aviator is not at all accurate. We have made changes in Aviator that are beyond configuration, such as the browser’s ability to stop referring URLs from being sent cross domain as well as always being in private mode by default. But far more importantly, when we talk to average users it becomes clear that consumers can’t actually do what the post is suggesting. Most people do not know the first thing about Disconnect and therefore, they don’t know what they need to do to add it. Our argument all along has been that consumers need better options by default. They don’t even know what to search for to start learning how to protect themselves.

Our reasoning for making Aviator open source was two-fold:

  1. We wanted to be honest with our users and give them a chance to see that we don’t have anything up our sleeves and that we are not (nor were we ever) hiding anything from them. Going open source is painful, but it is good for project transparency, something Google has long refused to do with Chrome. Chrome is not open source.
  2. We wanted to solve Google’s primary issue with us – the lack of development resources necessary to deliver the browser in a timely manner. That’s absolutely a real issue and we have never claimed otherwise. By making it available to the community, we believe that more time and resources will be put towards continuing to improve it and we are excited to see where the community takes it next.

The core issue in all of this is that we set out to create a browser that would provide security and privacy settings by default. We believe that we made very good strides in that effort and when issues around those settings were brought to our attention, we actively made changes, something that Google has been unwilling to do.

I won’t lie, going open source has been hard and only with the help of the community will Aviator continue to improve. It is now up to the community to decide if they’d rather hand over their privacy when they search using other browsers, or stand behind a project that we believe has the user’s best interests as a primary motivator. Only time will tell.

North Korea’s Naenara Web Browser: It’s Weirder Than We Thought

Naenara Browser is the DPRK’s version of Firefox that comes built into Red Star OS, the official operating system of North Korea. I recently got my hands on Naenara Browser version 3.5. My first impression in playing with it is that this is one ancient version of Firefox. Like maybe more than a half dozen major revisions out of date? It’s hard to tell for sure in cursory checking but the menus remind me of something I used to use 5+ years ago. That’s not too surprising; it’s tough to have a browser and update it all the time, especially with such a small team devoted to the project, as I’m sure they have a lot of other things going on.

When I first saw an image of the browser I was awe-struck to see that it made a request to an adddress ( upon first run. That may not mean much to someone who doesn’t deal with the Internet much, but it’s a big deal if you want to know how North Korea’s Internet works.

If you want to send a request to a web address across the country, you need to have a hostname or an IP address. Hostnames convert to IP addresses through something called DNS. So if I want to contact www.whitehatsec.com DNS will tell me to go to But there are certain addresses, like those that start in “10.”, “192.168.” and a few others that are reserved and meant only for internal networks – not designed to be routable on the Internet. This is sometimes a security mechanism to allow local machines to talk to one another when you don’t want them to traverse the Internet to do so.

Here’s where things start to go off the rails: what this means is that all of the DPRK’s national network is non-routable IP space. You heard me; they’re treating their entire country like some small to medium business might treat their corporate office. The entire country of North Korea is sitting on one class A network (16,777,216 addresses). I was always under the impression they were just pretending that they owned large blocks of public IP space from a networking perspective, blocking everything and selectively turning on outbound traffic via access control lists. Apparently not!

But it doesn’t stop there! No! No sirrreee… I started digging through their configuration settings and here are some gems:

  1. They use the same tracking system Google uses to create unique keys, except they built their own. That means the microtime of installation is sent to the mothership every single time someone pulls down the anti-phishing and anti-malware lists (from in the browser. This microtime is easily enough information to decloak people, which is presumably the same reason Google built it into the browser.
  2. All crash reports are sent to the mothership ( So every time the browser fails for some reason they get information about it. Useful for debugging and also for finding exploits in Firefox, without necessarily giving that information back to Mozilla – a U.S. company.
  3. All news feeds go back to the mothership in a specially crafted URL: At first it was unclear if that actually does anything or not, since we can’t see the IP address, but it looks like it probably does act as a feed aggregator.
  4. Strangely, the browser adds “.com” instead of “.com.kp” as a suffix when the browser can’t find something. It’s odd because this means in some cases this might accidentally be contacting external hosts when someone typos something in the country. A bad design choice, but perhaps meant for usability since most things live on .com.
  5. There are quite a few references to “.php” on the mothership website. I would be unsurprised if most things on it were written in PHP.
  6. Then I spotted this little number: This is the warning that pops up when users turn on geolocation. But here’s the really crazy part: if you remove the DPRK specific URL part and just leave it as %LOCALE%.www.mozilla.com/%LOCALE%/firefox/geolocation/ and substitute %LOCALE% with “ko” you end up on Mozilla’s site translated into Korean. Could the mothership be acting as a proxy? Is that how people are actually visiting the Internet – through a big proxy server? Can that really be true? It kind of makes sense to do it that way if you want to allow specific URLs through but not others on the same domain. Hm!
  7. More of the same. This time the safe browsing API that Google supports to find phishing/malware stuff — — if you remove the preceding part of the URL and fill in the variables it’s a real site. And there are a bunch more like this.
  8. Apparently they allow some forms of extensions, plugins and themes, though it’s not clear if this is the whole list or their own special brand of allowed add ons:

  9. Apparently all of the mail from the country goes through the single mothership URL. Very strange to build it this way, and obviously vulnerable to man in the middle attacks, sniffing and so on, but I guess no one in DPRK has any secrets, or at least not over email: I found a reference to “evolution” with regards to mail, which means there is a good chance North Korea is using the Evolution project for their country.

  10. Same thing with calendaring? So many sensitive things end up in calendars, like passwords, excel spreadsheets, etc… it’s still very odd that they haven’t bothered using HTTPS internally:

  11. This one blew my mind. Either it’s a mistake or a bizarre quirk of the way DPRK’s network works but the wifi URL for GEO still points to https://www.google.com/loc/json – not only is there no way for this to work since Google hasn’t gone through the country with their wifi cars, and it’s on the public Internet without going through their proxy of doom, but also it’s over HTTPS, meaning that if it were able to be contacted, the DPRK might have a hard time seeing what is being sent. Would they allow outbound HTTPS? More questions than answers it seems.
  12. The offical Naenara search function isn’t Google, and it’s not even clear if it’s a proxy or not. But one thing makes me think it might be – it’s in UTF-8 charcode, and not something that you might expect like BIG5 or ISO-2022-KR or SHIFT_JIS or something. But wait a tick, after a little digging I found a partial match on the URL: /search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1 and where did I find this? Google. Are they proxying Google results? I think so! That means that depending on what Google can put on those pages, they technically can run JavaScript and read the DPRK’s email/calendars, etc. using XMLHTTPRequest, since they are all on the same domain. Whoops!

  13. In looking around at the certificates that they support, I was not surprised to find that they accepted no other certificates as valid – only their own. That means it would be trivial to man in the middle any outbound HTTPS connection, so even if they do allow outbound access to Google’s JSON location API it wouldn’t help, because the connection and contents can be monitored by them. Likewise, no other governments can man in the middle any connections that the North Koreans have (I’m saying that with a bit of tongue in cheek, because of course they can according to Wikileaks docs, but this probably makes the DPRK feel better — and more importantly they probably don’t know how to do it in the same way as the NSA does, so they have to rely on draconian Internet breaking concepts like this).

  14. The browser automatically updates, without letting the browser disable that function. That’s actually a good security measure, but given how old this browser is, I doubt they use it often, and therefore it’s probably not designed to protect the user, but rather allow the government to quickly install malware should they feel the need. Wonderful.
  15. Even if the entire Internet is proxied through North Korean servers, and even if their user agent strings are filtered by the proxy, an adversary can still identify a user using Naenara by looking at it in JavaScript space using navigator.UserAgent. Their user agent is, “Mozilla/5.0 (X11; U; Linux i686; ko-KP; rv: 19.1br) Gecko/20130508 Fedora/1.9.1-2.5.rs3.0 NaenaraBrowser/3.5b4″ So if you see that UserAgent string in JavaScript you could target North Korean users rather easily.
  16. Although the Red Star OS does lock down things like their file manager that only shows you a few directories, disables the command-O (open) feature, removes the omnibar feature and so on, it’s still possible to do whatever you want. Using the browser users can go to file:/// to view files and they can write their own JavaScript using javascript: directives which give them just about any access they want, if they know what they’re doing. Chances are they don’t, but despite their Military’s best efforts the Red Star OS actually isn’t that locked down from a determined user’s perspective.
  17. Snort intrusion detection system is installed by default. It’s either used as an actual security mechanism as it was designed or it could be re-purposed as a way to constantly snoop on people’s computers to see what they are doing when they use the Internet. Even if it didn’t phone home necessarily, the DPRK soldier who broke down your door could fairly easily do forensics and see everything you had done without relying on any IP correlation at the mothership. So using your neighbor’s wifi isn’t a safe alternative for a political dissident using Red Star OS.

My ability to read North Korean is non-existent, so I had to muddle my way through this quite a bit, but I think we have some very good clues as to how this browser and more importantly how North Korea’s Internet works, or doesn’t work as it might be.

It is odd that they can do all of this off of one IP address. Perhaps they have some load balancing but ultimately running anything off of one IP address for a whole country is bad for many reasons. DNS is far more resilient, but it also makes things slower, in a country with Internet connectivity that is probably already pretty slow. If I were to guess, the DPRK probably uses a proxy and splits off core functions by URL to various clusters of machines. A single set of F5s could easily handle this job for the entire country. It would be slow, but it doesn’t seem the country cares much about the comforts of fast Internet anyway.

Ultimately the most interesting takeaway for me personally was what lengths North Korea goes to to limit what their people get to do, see and contribute to — Censorship at a browser and network level embodied in the OS called Red Star 3.0. It’s quite a feat of engineering. Creepy and cool. Download the Red Star OS here.

Aviator Going Open Source

One of the most frequent criticisms we’ve heard at WhiteHat Security about Aviator is that it’s not open source. There were a great many reasons why we didn’t start off that way, not the least of which was getting the legal framework in place to allow it, but we also didn’t want our efforts to be distracted by external pressures while we were still slaving away to make the product work at all.

But now that we’ve been running for a little more than a year, we’re ready to turn over the reins to the public. We’re open sourcing Aviator to allow experts to audit the code and also to let industrious developers contribute to it. Yes, we are actually open sourcing the code completely, not just from a visibility perspective.

Why do this? I suspect many people just want to be able to look at the code, and don’t have a need to – or lack the skills to – contribute to it. But we also received some really compelling questions from the people who have an active interest in the Tor community who expressed an interest in using something based on Chromium, and who also know what a huge pain it is to make something work seamlessly. For them, it would be a lot easier to start with a more secure browser that had removed a lot of the Google specific anti-privacy stuff, than to re-invent the wheel. So why not Aviator? Well, after much work with our legal team the limits of licensing are no longer an issue, so now that is now a real possibility. Aviator is now BSD (free as in beer) licensed!

So we hope that people use the browser and make it their own. We won’t be making any additional changes to the browser; Aviator is now entirely community-driven. We’ll still sign the releases, QA them and push them to production, but the code itself will be community-driven. If the community likes Aviator, it will thrive, and now that we have a critical mass of technical users and people who love it, it should be possible for it to survive on its own without much input from WhiteHat.

As an aside, many commercial organizations discontinue support of their products, but they regularly fail to take the step of open sourcing their products. This is how Windows XP dies a slow death in so many enterprises, unpatched, unsupported and dangerously vulnerable. This is how MMORPG video games die or become completely unplayable once the servers are dismantled. We also see SAAS companies discontinue services and allow only a few weeks or months for mass migrations without any easy alternatives in sight. I understand the financial motives behind planned obsolescence, but it’s bad for the ecosystem and bad for the users. This is something the EFF is working to resolve and something I personally feel that all commercial enterprises should do for their users.

If you have any questions or concerns about Aviator, we’d love to hear from you. Hopefully this is the browser “dream come true” that so many people have been asking for, for so long. Thank you all for supporting the project and we hope you have fun with the code. Aviator’s source code can be found here on Github. You don’t need anything to check it out. If you want to commit to it, shoot me an email with your github account name and we’ll hook you up. Go forth! Aviator is yours!