Web Security for the Tech Impaired: What is two factor authentication?

You may have heard the term ‘two-factor’ or ‘multi-factor’ authentication. If you haven’t heard of these terms, chances are you’ve experienced this and not even known it. The interesting thing is that two factor authentication is one of the best ways to protect your accounts from being hacked.

So what exactly is it? Well traditional authentication will ask you for your username and password. This is an example of a system that relies on one factor — something you KNOW — as the sole authentication method to your account. If another person knows your username and password they can also login to your account. This is how many account compromises happen, a hacker simply runs through possible passwords of accounts they want to hack and will eventually guess the correct password through what is known as a ‘brute force’ attack.

In two-factor authentication, we take the concept of security a step further. Instead of only relying on something that you KNOW we also rely on something that you HAVE in your possession. You may have already been doing this and not even realized it — have you logged into your bank or credit card only to see a message like ‘This is the first time you have logged in from this machine; we have sent an authentication code to the cell phone number on file for your account — please enter that number and your password” or words to that effect? That is an example of a site that is using two-factor authentication. By using the cell phone number they have on file to send you a text to confirm that you are who you say you are, they are relying on not only something you KNOW but also something you HAVE. If an attacker were to steal or guess your username and password, they would not be able to successfully login to your account because you would receive a text out of the blue for an account you didn’t login to. At that moment you would know someone is probably trying to login to your account.

This system works with anything you have. Text is the primary means of two factor authentication as most people have easy access to a cell phone and it’s easy to read the code to enter onto the site. This system works just as well with a phone call that provides you with a code or with an email. Anything that you HAVE will work with two factor authentication. You may notice that most sites will only ask you for this information once; typically sites will ask you the very first time you log in from a given device (be it mobile, desktop or tablet). After that, the site will remember what devices you’ve signed on with and allow those devices to login without requiring the second factor, the auth code. If you typically log in with your home computer, and then remember you need to check your balance at work, the site will ask you to log in with two-factor authentication because it does not recognize that device. The thought is that a hacker is unlikely to hack into your account by breaking into your house and using your own computer to login.

Now you may be saying ‘that sounds great! Where do I sign up?’. Unfortunately not all systems support two factor authentication. However, the industry is slowly progressing that way. Sometimes it isn’t enabled by default but is an options in a ‘settings’ or ‘account’ menu on the site. To see a list of common sites and status on supporting two-factor auth, https://twofactorauth.org/ is a great resource. I highly recommend turning this service on for any account that supports it. Typically, it’s extremely quick and easy to do and will make your accounts far more secure then ever before.

#HackerKast 43: Ashley Madison Hacked, Firefox Tracking Services and Cookies, HTML5 Malware Evasion Techniques, Miami Cops Use Waze

Hey Everybody! Welcome to another HackerKast. Lets get right to it!

We had to start off with the big story of the week which was that Ashley Madison got hacked. For those of you fortunate enough to not know what Ashley Madison is, it is a dating website dedicated to members who are in relationships and looking to have affairs. This breach was a twist from most other breaches as the hacker is threatening to release all of the stolen data unless the website shuts its doors for good. Ashley Madison’s upcoming IPO could also be messed up now that the 7 million user’s data are lost and no longer private. Our friend Troy Hunt also posted a business logic flaw that allowed you to harvest registered email addresses from the forgot password functionality that didn’t rely on the leaking of the breach.

Next, in browser news, Robert was looking at an about:config setting in Mozilla Firefox that can turn off tracking services and cookies. Some studies that looked into this measured that, with this flag turned off, load time went down by 44% and bandwidth usage was down 30%. This flag is a small win for privacy but still leaks user info to Google but not to a lot of other sites. Not a perfect option since you can use a lot of browser add-ons that do a better job but this one is baked into Firefox. This is a huge usage statistic that people’s bandwidth and load time improved so drastically.

In related news, an Apple iAd executive left Apple and made some noise on his way out. He seemed to be frustrated that Apple has tons of user’s data and since they respect some level of privacy they are not living up to their full potential. This is good news for you and I who care about privacy. Where it gets worse is that he left to go to a company called Drawbridge which is focused on deanonymizing users based on lots of data of shared wifi networks, unique machine IDs, etc.

I liked this next story since it is a creative business logic issue which are always my favorite. This issue was involved with the mobile GPS directions app called Waze. What Waze does is uses crowd sourcing in order to provide real time traffic data to help reroute users around jams with a more accurate and speedier result. The other major use of Waze is reporting cops and speed traps on the road. Turns out that cops have caught wind of this and I’m assuming it’s hit their fine-based economy bottom line because hundreds of cops in Miami downloaded the app and start submitting fake cop reports. By doing this the information becomes a lot less reliable for users and cops can probably catch more people. We discussed the ethics here and whether Google (who owns Waze) would want to go toe-to-toe on this issue.

Next up, we touched on this year’s State of Application Security Report that is put out by SANS Institute every year. We didn’t go through the whole thing due to time constraints but it is full of interesting data as usual. They broke up this report into 2 major sections that they studied, Builders & Defenders. Some of the major pain points were Asset Management, such as finding every Internet facing web application which is always a challenge. Another was modifying production code and potentially breaking the app in lieu of trying to fix a security issue. The builders on the other hand were basically the inverse which was focused on delivering features and time to market. Builders also feel they are lacking knowledge in security which has been a known issue for a long time.

Last up was some straight up web app research which is always a lot of fun. Some research recently came out and was expanded on that proved that drive by download malware could avoid detection by using some common HTML5 APIs. One popular technique to download malware to a user’s machine is to chunk up the malware upon download and then reassemble it all locally later. A lot of malware detection has caught up to this and it gets detected. The same malware that would be detected using traditional methods was undetected using some combination of HTML5 techniques such as localStorage, Web Workers, etc. Great research! Looking forward to more follow ups on this.

Thanks for listening! Check us out on iTunes if you want an audio only version to your phone. Subscribe Here
Join the conversation over on Twitter at #HackerKast
or write us directly @jeremiahg, @rsnake, @mattjay


Ashely Madison Hacked
Your affairs were never discreet – Ashley Madison always disclosed customer identities
Firefox’s tracking cookie blacklist reduces website load time by 44%
Former iAd exec leaves Apple, suggests company platform is held back by user data privacy policy
Miami Cops Actively Working to Sabotage Waze with Fake Submissions
2015 State of Application Security: Closing the Gap
Researchers prove HTML5 can be used to hide malware

Notable stories this week that didn’t make the cut:

Self Driving Cars Could Destroy Fine Based Economy
Hackers Remotely Kill a Jeep on the Highway—With Me in It
Redstar OS Watermarking
The Death of the SIM card is Nigh
How I got XSS’d by my ad network
FTC Takes Action Against LifeLock for Alleged Violations of 2010 Order
OpenSSH Keyboard Interactive Authentication Brute Force Vuln
NSA releases new security tool

Bayes’ Theorem and What We Do

Back in 2012, The Atlantic Monthly published a behind-the-scenes article about Google Maps. This is the passage that struck me:

The best way to figure out if you can make a left turn at a particular intersection is still to have a person look at a sign — whether that’s a human driving or a human looking at an image generated by a Street View car.

There is an analogy to be made to one of Google’s other impressive projects: Google Translate. What looks like machine intelligence is actually only a recombination of human intelligence. Translate relies on massive bodies of text that have been translated into different languages by humans; it then is able to extract words and phrases that match up. The algorithms are not actually that complex, but they work because of the massive amounts of data (i.e. human intelligence) that go into the task on the front end.

Google Maps has executed a similar operation. Humans are coding every bit of the logic of the road onto a representation of the world so that computers can simply duplicate (infinitely, instantly) the judgments that a person already made…

…I came away convinced that the geographic data Google has assembled is not likely to be matched by any other company. The secret to this success isn’t, as you might expect, Google’s facility with data, but rather its willingness to commit humans to combining and cleaning data about the physical world. Google’s map offerings build in the human intelligence on the front end, and that’s what allows its computers to tell you the best route from San Francisco to Boston.

Even for Google, massive and sophisticated automation is only a first step. Human judgment is also an unavoidable part of documenting web application vulnerabilities. The reason isn’t necessarily obvious: Bayes’ theorem.

Bayes' Theorem Img 1

“P(A|B)” means “the probability of A, given B.”

Wikipedia explains the concept in terms of drug testing:

Suppose a drug test is 99% sensitive and 99% specific. That is, the test will produce 99% true positive results for drug users and 99% true negative results for non-drug users. Suppose that 0.5% of people are users of the drug. If a randomly selected individual tests positive, what is the probability he or she is a user?

Bayes' Theorem Img 2

The reason the correct answer of 33% is counter-intuitive is called base rate neglect. If you have a very accurate test for something that happens infrequently, that test will usually report false positives. That’s worth repeating: if you’re looking for a needle in a haystack, the best possible tests will usually report false positives.

Filtering out false positives is an important part of our service, over and above the scanning technology itself. Because most URLs aren’t vulnerable to most things, we see a lot of false positives. They’re the price of automated scanning.

We also see a lot of duplicates. A website might have a search box on every page that’s vulnerable to cross-site scripting, but it’s not helpful to get a security report that’s more or less a list of the pages on your website. It is helpful to be told there’s a problem with the search box. Once.

Machine learning is getting better every day, but we don’t have time to wait for computers to read and understand websites as well as humans. Here and now, we need to find vulnerabilities, and scanners can cover a site more efficiently than a human. Unfortunately, false positives are an unavoidable part of that.

Someone has to sort them out. When everything is working right, that part of our service is invisible, just like the people hand-correcting Google Maps.

#HackerKast 42: Hacking Team, LastPass Clickjacking, Cowboy Adventure Game Distributes Malware, Droopescan, WhiteHat Acceleration Services

Welcome to the Episode in which we describe the answer to the Ultimate Question of Life, the Universe, and Everything. Maybe we’ll just stick to security but we’ve now done 42 of these things.

Kicking off this week with a gigantic combined story about Hacking Team, the story that keeps on giving. We touched on this breach last week but as people have been plowing through the 400GB of data that was leaked more and more 0-days are being discovered. Seems no operating system of browser is safe and Flash/Java felt the love in full force. At least 3 Flash 0-days have made their way into popular exploit kits so this is fully weaponized and being used in the wild. This, along with Facebook CISO Alex Stamos public statement against Flash, have proved to be a catalyst to both Firefox and Chrome blocking Flash BY DEFAULT. This is amazing. Huge step in the right direction and we are very interested to see where it goes.

Some other crazy revelation from combing through the breach data is, the guys over at Hacking Team were joking around about assassinating ACLU Technologist Chris Soghoian. Chris does a lot of work and public speaking against foreign governments weaponizing exploits which was apparently causing Hacking Team pain. It is a crazy world we live in when we have to accept that the industry we live in is costing enough people enough money that this kind of conversation about assassinations is bound to happen.

Next, some pure awesome web app hacking technique beauty. This week we saw an attack against LastPass password management browser plugin which utilized Clickjacking to steal stored passwords. We love clickjacking and browser security so this story had us all drooling. Before we dove in, props to LastPass security team for being super responsive anytime a security issue is brought to their attention. The PoC used in this case involved Tumblr in an iFrame. The attackers can then fool the user into clicking through the different LastPass prompts which caused the user’s password to be auto-filled into a textbox, which would then be sent to the attacker. Video of the PoC below:

Now if I had a dime for every time I downloaded a Cowboy Adventure game and it caused me problems… Well at least a million Android users would have 10 cents. This super popular game distributed via the Google Play store decided to become malicious and start installing malware onto it’s user’s phones. These mobile apps and devices have tons of permissions which makes these types of malware particularly dangerous as behind the firewall launching points for bigger attacks. Usually we are seeing this type of thing just used to generate ad fraud money for the attacker.

Next, we touched on a new CMS scanning tool that came out called Droopescan which is geared toward Drupal sites. Think, WPScan or CMS Map type tools but for Drupal. This is wildly important tool to exist as, if you’re a regular listener to HackerKast, you’ll know that CMS plugins and old versions are full of holes and have a huge target on their backs. These things are also very easy to find by scanning the entire Internet.

Lastly, we did some shameless self promotion of a project I’ve been working on under my rock for the past few months, WhiteHat Acceleration Services. When we look at our stats report year after year, and the time to fix vulnerabilities is astronomical and isn’t getting much better. This year our customers averaged 193 days to fix any given vulnerability that we identified. We’ve now set out to help that problem out. WhiteHat has been finding vulnerabilities in websites for over 10 years. Today we start helping you FIX them also.

This is the first of 6 new “Acceleration Services” offerings I’ve been tasked with launching this year. Check it out.

Thanks for listening! Check us out on iTunes if you want an audio only version to your phone. Subscribe Here
Join the conversation over on Twitter at #HackerKast
or write us directly @jeremiahg, @rsnake, @mattjay


Adobe Flash Zero Day CVE 2015
Third Hacking Team Zero Day Found
Pawn Storm uses Exploit for Unpached Java Flaw
Mozilla Blocks All Versions of Adobe Flash Until Publicly Known Security Vulns are Fixed
Google and Mozilla Pull Adobe Flash
Hacking Team Employee Jokes about Assassinating ACLU Technologist Chris Soghoian
Stealing Lastpass Passwords With Clickjacking
Cowboy Adventure Game Malware Affecting 1MM Android Users
WhiteHat Acceleration Services

Notable stories this week that didn’t make the cut:

Google accidentally reveals data on ‘right to be forgotten’ requests
Michael DeKort’s Jumbawumba
University Rolls Out Adblock Plus, Saves 40 Percent Network Bandwidth
XSSYA 2.0 Released
OPM Hack of Fingerprints breaks Biometrics
Federal Judge overturns Arizona’s Nude Photo Law
Top Five Takeaways Todays Hearings Encryption
XKeyscore Exposé Reaffirms the Need to Rid the Web of Tracking Cookies
Land Rover recalls 65,000 cars because of software bug that could lead to theft

Lowering Defenses to Increase Security

Starting at WhiteHat was a career change for me. I wasn’t sure exactly what to expect, but I knew there was a lot of unfamiliar terminology: “MD5 signature”, “base64″, “cross-site request forgery”, “‘Referer’ header”, to name a few.

When I started testing real websites, I was surprised that a lot of what I was doing looked like this:


Everything was definitely not that simple…but a lot of things were. How could I be correcting the work of people who knew so much more about computers than me? I’d talk to customers on the phone, and they already knew how to fix the vulnerabilities. In fact, they were even already aware of them, in some cases! Periodically, WhiteHat publishes statistics about how long it takes vulnerabilities to get fixed in the real world, and how many known vulnerabilities are ever fixed. The most recent report is available here, with an introduction by Jeremiah Grossman here.

SQL injection was first publicly described in 1998, and we’re still seeing it after 17 years. Somehow, the social aspects of the problem are more difficult than the technical aspects. This has been true since the very beginning of modern computing:

Apart from some less-than-ideal inherent characteristics of the Enigma, in practice the system’s greatest weakness was the way that it was used. The basic principle of this sort of enciphering machine is that it should deliver a very long stream of transformations that are difficult for a cryptanalyst to predict. Some of the instructions to operators, however, and their sloppy habits, had the opposite effect. Without these operating shortcomings, Enigma would, almost certainly, not have been broken.

Speaking of the beginning of computing, The Psychology of Computer Programming (1971) has the following passage about John von Neumann:

John von Neumann himself was perhaps the first programmer to recognize his inadequacies with respect to examination of his own work. Those who knew him have said that he was constantly asserting what a lousy programmer he was, and that he incessantly pushed his programs on other people to read for errors and clumsiness. Yet the common image today of von Neumann is of the unparalleled computer genius: flawless in his every action. And indeed, there can be no doubt of von Neumann’s genius. His very ability to realize his human limitations put him head and shoulders above the average programmer today.

Average people can be trained to accept their humanity – their inability to function like a machine – to value it and work with others so as to keep it under the kind of control needed if programming is to be successful.

The passage above is from a section of the book called “Egoless Programming.” It goes on to describe an anecdote in which a programmer named Bill is having a bad day, and calls Marilyn over to look at his code. After she finds 17 bugs in 13 statements, he responds by seeing the humor in the situation and telling everyone about it. In turn, Marilyn thinks that there must be more bugs if she could spot 17, and 3 more were spotted by others. The code was put into production and had no problems for 9 years.

The author of the book, Gerald Weinberg, made another interesting observation:

Now, what cognitive dissonance has to do with our programming conflict should be vividly clear. A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. On the contrary, he is going to be trying to prove that the program is correct, even if this means the oversight of errors which are monstrous to another eye. All programmers are familiar with the symptoms of this dissonance resolution — in others, of course…And let there be no mistake about it: the human eye has an almost infinite capacity for not seeing what it does not want to see. People who have specialized in debugging other people’s programs can verify this assertion with literally thousands of cases. Programmers, if left to their own devices, will ignore the most glaring errors in their output—errors that anyone else can see in an instant. Thus, if we are going to attack the problem of making good programs, and if we are going to start at the fundamental level of meeting specifications, we are going to have to do something about the perfectly normal human tendency to believe that one’s “own” program is correct in the face of hard physical evidence to the contrary.

What is to be done about the problem of the ego in programming? A typical text on management would say that the manager should exhort all his programmers to redouble their efforts to find their errors. Perhaps he would go around asking them to show him their errors each day. This method, however, would fail by going precisely in the opposite direction to what our knowledge of psychology would dictate, for the average person is going to view such an investigation as a personal trial. Besides, not all programmers have managers — or managers who would know an error even if they saw one outlined in red.

No, the solution to this problem lies not in a direct attack — for attack can only lead to defense, and defense is what we are trying to eliminate. Instead, the problem of the ego must be overcome by a restructuring of the social environment and, through this means, a restructuring of the value system of the programmers in that environment.

By the nature of what we do, WhiteHat does try to find mistakes in other people’s work. It’s not personal, and those mistakes are rarely unique! In the big picture, what brought us computers was the scientific method, that is, the willingness to learn from mistakes.

#HackerKast 41: HackingTeam, Adobe Flash Bug, UK Government’s Possible Encryption Ban

Hello everyone! Welcome to Week 41! Hope everyone enjoyed the holiday last week. Let’s get right to it:

First off, we talked about HackingTeam which is an Italian survaillence firm which sells its tools to governments to spy on citizens. We don’t know much about the breach itself in terms of technical details but the fact that this is a security company who builds malware makes it super interesting. One of the things revealed in their malware source code that was breached was weaponized child pornography which would plant this nasty stuff on victim’s computers. Also in the mix was some 0-days, most notably a previously unknown flash bug.

We covered a bit about the Flash bug which Adobe has already released a patch for and which is now available in exploit kits and Metasploit. HD Moore’s law in full effect here as we are seeing how fast these things get picked up and weaponized. We quickly rehashed some advice from the past of enabling click-to-play or uninstall this stuff completely as these things pop up constantly. It is also super telling that the only way we know about this bug is that it was leaked from an already existing exploit kit being hoarded by a private firm. There are likely tons of these floating around. Another behavior of some of these Flash bugs is once you are compromised by them, they patch the hole they used in order to make sure other hackers can’t get in.

Another story that keeps rearing its head is the UK government trying to ban encryption entirely. They’ve been talking about this for a while now but it keeps bubbling up in political news stories. Governments want the ability to spy on their own citizens as a whole and encryption is not allowing them to. We touched on the same conversation going on in the USA where the FBI wants a “golden key” scenario where there would still be encryption but they’d have the backdoor to decrypt everything. This is inherently insecure and an awful idea but lots of people keep bringing it up. This is closest to becoming a reality in the UK which would make even things like iMessage illegal and unusable.

We’re all looking forward to Vegas for BlackHat in a few weeks. Be sure to hunt us down to say hi!

Thanks for listening! Check us out on iTunes if you want an audio only version for your phone. Subscribe Here

Join the conversation over on Twitter at #HackerKast or write us directly @jeremiahg, @rsnake, @mattjay

OpenSSL CVE-2015-1793

OpenSSL released a security advisory regarding CVE-2015-1793, a bug in the implementation of the certificate verification process:

… from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and “issue” an invalid certificate.

This largely impacts clients which verify certificates and servers leveraging client authentication. Additionally, most major browsers, IE, FF and Chrome, do not utilize OpenSSL as the client for TLS connections. Thus while this is a high severity vulnerability it also carries a low impact. Due to the nature of this particular issue implementing a test in Sentinel is unnecessary.

If you have any questions please contact WhiteHat Customer Support at support@whitehatsec.com.

The following OpenSSL versions are affected:

* 1.0.2c, 1.0.2b
* 1.0.1n, 1.0.1o

The recommended solution is to update the affected version of OpenSSL:

* OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
* OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p



Importance of a Security Mindset

Back in 2008, Bruce Schneier wrote an article in Wired about the security mindset. In it he wrote:

This kind of thinking is not natural for most people. It’s not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don’t have to exploit the vulnerabilities you find, but if you don’t see the world that way, you’ll never notice most security problems.

I’ve often speculated about how much of this is innate, and how much is teachable. In general, I think it’s a particular way of looking at the world, and that it’s far easier to teach someone domain expertise — cryptography or software security or safecracking or document forgery — than it is to teach someone a security mindset.

He was very sure that mindset is a good thing:

That part’s obvious, but I think the security mindset is beneficial in many more ways. If people can learn how to think outside their narrow focus and see a bigger picture, whether in technology or politics or their everyday lives, they’ll be more sophisticated consumers, more skeptical citizens, less gullible people….

There’s nothing magical about this particular university class; anyone can exercise a security mindset simply by trying to look at the world from an attacker’s perspective. If I wanted to evade this particular security device, how would I do it? Could I follow the letter of this law but get around the spirit? If the person who wrote this advertisement, essay, article or television documentary were unscrupulous, what could he have done? And then, how can I protect myself from these attacks?

The security mindset is a valuable skill that everyone can benefit from, regardless of career path.

In practice, not everyone seems to agree with that last sentence. One person’s “careful and thorough” is another person’s “inconvenient and unnecessary,” when they don’t share the same picture of reality.

This case is extreme but illustrative. It’s taken from the book Even Paranoids Have Enemies: New Perspectives on Paranoia and Persecution:

Dinora Pines (1995) describes her experience with a patient from Russia who had given his KGB companion the slip when he was brought to London. The patient appeared to her to be obsessed by his fantasies about Baba Yar. He never gave her his home address or telephone number and always seemed to slip into his sessions in a shadowy and haunted manner. Pines’s patient did not arouse any emotional response in her and she felt bored, only subsequently realizing that she was in the presence of a person whose main internal difficulty was a “falseness”, a tendency to disallow emotional engagement and closeness. Her non-existent feelings towards him troubled her, keeping her thinking about his internal world until one day external reality erupted in her consulting room. After the murder of a Bulgarian dissident in Oxford Street, her patient disappeared. She never heard another word about him until she was shocked to read an obituary about him in the local newspaper. Pine writes:

I feel very guilty about my previous indifference towards him, and my irritation with him for what seemed to be illogical precautions as to his safety. Yet it also seemed to me, with hindsight, that he was right and I was totally wrong about his reality.

Her patient’s past life experience differed enormously from hers and matters were further complicated by their cultural differences and his own psychological difficulties in being honest and open with those, such as his analyst, whom he perceived to be in a position of authority.

Thankfully, most of us don’t need to worry about anything like the KGB killing us with ricin pellets shot from an umbrella. But these things do happen.

Those of us who aren’t dealing with Advanced Persistent Threats still have enemies on the internet, but we aren’t defenseless. WhiteHat Security can help with reducing your organization’s attack surface, but there are lots of things everyone can do to make their online lives safer (and a little bit less convenient). You can think of our Web Security for the Tech Impaired series as Security Mindset 101.

Web Security for the Tech Impaired: Connecting to WiFi

We’ve all been at an airport or coffee shop and checked our phone to see that your internet connection is incredibly slow. You curse the heavens in frustration and then you notice that they offer free WiFi. “What fortuitous circumstances!” you think. You look on your phone for what networks are available around you and you see:

Uh……. ok…… which one do you choose? They all seem to be owned by Starbucks so you go ahead and connect to the first one. After a few days you notice your credit card has some weird unauthorized charges. “That’s odd” you think, “maybe it had something to do with that free WiFi I connected to….

While connecting to free WiFi networks seems like a good idea, it can be extremely dangerous. The danger is that it is incredibly easy to setup your own WiFi network at these locations. An attacker buys a relatively inexpensive tool which he can set up at any location and give it any name they like. Victims will think that the network is legitimate and connect to the attackers WiFi network. After connecting, the attacker can now see the traffic going between the victim and the internet, effectively spying on all the traffic going back and forth between the victim and any site they are browsing. This is what is known as a ‘man in the middle’ attack.

So how do you protect yourself from being a victim?
1) I always like to turn off WiFi if it’s not being used. This serves two purposes. It saves your battery which is always nice and it protects you from having your device connect to an undesirable WiFi network without you knowing it.

2) If you need to connect to a WiFi network confirm the name of the network with someone at the business. Often in airports there will be official signs with the networks name on them hung throughout. Smaller locations are tougher because attackers can make very convincing fake signs and sprinkle them throughout the business. In these cases I like to ask someone working there what the network name should be.

3) Never trust a WiFi network. I never do any banking, purchasing or sensitive transaction while connected to a public WiFi network. Save that for home or a WiFi network you know and trust. It’s just not worth it. If you absolutely have to, make sure the site is using “https” in front of the URL.

4) If you do connect to a public network, use your phone or computer’s ‘forget network’ feature after you’re done. Your phone will have a list of all networks it’s connected to in the past somewhere within your WiFi settings panel. If WiFi is enabled your phone will automatically connect to these networks. To prevent it from doing that, always go into this settings and either long hold them or select the options menu and select ‘forget network’. This will prevent your phone from automatically connecting.

#HackerKast 40: OPM Breach, Sourcepoint, AdBlock Plus, NSA and AV software, Adobe Flash, Chrome Listens In via Computer Mic

Hey Everybody! Welcome to our 40th HackerKast! Thanks for listening as always and lets get to the news!

Our first story to chat about this week was news bubbling up still about the recent OPM breach. This time, the news outlets are latching on to the fact that data encryption wouldn’t have helped them in this case. Jeremiah poses the question “Is this true? And if so, when does it protect you?” Robert and I go back and forth a bit about layers of protection and how encryption in this regard will only help with host layer issues. Some other ideas come up about data restrictions being put upon the database queries as they are taking place so that the crown jewels can’t be stolen via one simple hole.

Next, we moved on to a story Robert was drooling over about Google’s new pet project company, Sourcepoint, which exists to stop ad blocking. Apparently they originally launched to detect when ads are being modified, which was apparently an issue in the SEO world. However, the way the tech worked, monitoring the DOM allowed them to pivot a bit to detect ad blocking by users. This could be leveraged to stop the user from blocking, or could alert the user and ask really nicely for them not to block ads which could be harming some sites’ revenue. We then all made the comparison here that the modern age of ads looks a lot like the age of Anti-Virus with the whole cat and mouse game of writing signatures to catch which domains are serving ads.

On the topic of ad blockers, AdBlock Plus added a feature which would allow enterprise level IT admins to roll out the browser plugin to an entire company. We need to remind people that AdBlock Plus also is the ad blocker on the market that will allow ads that pay them to be whitelisted. This means the more computers their software is on, the more they can ask to be whitelisted.

Jer couldn’t wait to talk about this next story about the NSA reverse engineering AV software. He starts by giving us all a quick history lesson of his interest in AV being the ironic attack vector for hackers to get into systems. The current story is about a recently leaked Snowden document that outlined an NSA program which reversed AV software — including Kaspersky — to utilize it to track and monitor users. Not a good week for Kaspersky coming off the heels of Duqu 2.0 recently.

Our transition from one virus propagator to another here brings us to our next story: Adobe Flash. The initial story that made our list was Brian Krebs talking about detoxing from Flash for 30 days with it completely removed from his system. He gives some good advice about disabling flash, removing it altogether, or enabling click to play. While editing this story though, he had to add a note at the top which proved his point that the day it was published there was an out-of-band Zero-Day patch Adobe released this week. The Zero-Day was identified by some ridiculously named FireEye report of an attack being used in Singapore from a Chinese hacking group they call APT3. We have a good conversation about Flash and what a huge target it’s been and what a nightmare it is to get users to update.

The icing on our cake to go back to ragging on Google is a story that hit the privacy community this week of Chrome listening to you via your computer microphone. For some reason, the initial group they decided to test this with was Chromium users on Debian who noticed the silent update start to log this audio information. Apparently there is some legitimate purpose behind this, like saying “Hi Google” to your computer and giving it voice commands. They then send this audio to their servers to do analysis to improve their service. They double, triple, super duper promise they aren’t logging it or sharing the audio. We went off on a tangent here on how awful of an idea this is. I brought up how we’ve got a nice diagram from the NSA showing how they strip HTTPS at the Google layer to monitor users so it really doesn’t matter if they log or store it if the NSA can just snoop on the wire there. Who knows where this is going to go, but now you might have an always on microphone in your house.

Thanks for listening! Check us out on iTunes if you want an audio only version to your phone. Subscribe Here
Join the conversation over on Twitter at #HackerKast
or write us directly @jeremiahg, @rsnake, @mattjay


Encryption Would Not Have Helped at OPM Says DHS Official
Former Google Exec Launches Sourcepoint To Stop Ad Blockers
Adblock Plus Rolls Out Mass Deployment For IT Administrators
NSA Has Reverse-Engineered Popular Consumer Anti-Virus Software In Order To Track Users
Operation Clandestine Wolf: Adobe Flash Zero-Day
Krebs month without Adobe Flash Player
Google Chrome Listening In To Your Room Shows The Importance of Privacy Defense In Depth
Just another source on the Chrome listening to you

Notable stories this week that didn’t make the cut:

Heinz QR porn code too saucy for ketchup customer/
Critical Bug Found in Drupal OpenId
The Myth of the Dark Web
How DOJ Gagged Google over Surveillance of Wikileak’s Appelbaum
1,400 Passengers Grounded in Warsaw Due to Airport Hack
DuckDuckGo on CNBC: We’ve grown 600% since NSA surveillance news broke