Category Archives: Technical Insight

Why is Passive Mixed Content so serious?

One of the most important tools in web security is Transport Layer Security (TLS). It not only protects sensitive information during transit, but also verifies that the content has not been modified. The user can be confident that content delivered via HTTPS is exactly what the website sent. The user can exchange sensitive information with the website, secure in the knowledge that it won’t be altered or intercepted. However, this increase in security comes with an increased overhead cost. It is tempting to be concerned only about encryption and ignore the necessity to validate on both ends, but any resources that are called on a secure page should be similarly protected, not just the ones containing secret content.

Most web security professionals agree that active content — JavaScript, Flash, etc. — should only be sourced in via HTTPS. After all, an attacker can use a Man-in-the-Middle attack to replace non-secure content on the fly. This is clearly a security risk. Active content has access to the content of the Document Object Model (DOM), and the means to exfiltrate that data. Any attack that is possible with Cross-Site Scripting is also achievable using active mixed content.

The controversy begins when the discussion turns to passive content — images, videos, etc. It may be difficult to imagine how an attacker could inflict anything worse than mild annoyance by replacing such content. There are two attack scenarios which are commonly cited.

An unsophisticated attacker could, perhaps, damage the reputation of a company by including offensive or illegal content. However, the attack would only be effective while the attacker maintains a privileged position on the network. If the user moves to a different Wi-Fi network, the attacker is out of the loop. It would be easy to demonstrate to the press or law enforcement that the company is not responsible, so the impact would be negligible.
If a particular browser’s image parsing process is vulnerable, a highly sophisticated attacker can deliver a specially crafted, malformed file using a passive mixed content vulnerability. In this case, the delivery method is incidental, and the vulnerability lies with the client, rather than the server. This attack requires advanced intelligence about the specific target’s browser, and an un-patched or unreported vulnerability in that specific browser, so the threat is negligible.
However, there is an attack scenario that requires little technical sophistication, yet may result in a complete account takeover. First, assume the attacker has established a privileged position in the network by spoofing a public Wi-Fi access point. The attacker can now return any response to non-encrypted requests coming over the air. From this position, the attacker can return a 302 “Found” temporary redirect to a non-encrypted request for the passive content on the target site. The location header for this request is a resource under their control, configured to respond with a 401 “Unauthorized” response containing a WWW-Authenticate header with a value of Basic realm=”Please confirm your credentials.” The user’s browser will halt loading the page and display an authentication prompt. Some percentage of users will inevitably enter their credentials, which will be submitted directly to the attacker. Even worse, this attack can be automated and generalized to such a degree that an attacker could use commodity hardware to set up a fake Wi-Fi hotspot in a public place and harvest passwords from any number of sites.

Protecting against this attack is relatively simple. For users, be very suspicious of any unexpected login prompts, especially if it doesn’t look like part of the website. For developers, source in all resources using HTTPS on every secure page.

#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

Resources:

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

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.

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.

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:

http://example.com/search?q=<script>alert(1)</script>

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

References:

*https://www.openssl.org/news/secadv_20150709.txt
*https://access.redhat.com/solutions/1523323
*http://lists.opensuse.org/opensuse-security-announce/2015-07/msg00019.html

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:
Starbucks
FREE_Starbucks
Public-Starbucks

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

Resources:

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

#HackerKast 39: MLB Astros Hacked By Cardinals, Duqu 2.0, More Ad Blocking News and RIP Microsoft Ask Toolbar

Hey everybody and welcome to another week in Internet Security. Robert and I were trying our best to stay above water with Tropical Storm Bill hitting Southern Texas while Jeremiah was making us jealous with his palm trees and blue skies in Hawaii. I’ll remember that one Jer…

Back on topic, our first story was some shameless self promotion of Jeremiah talking about eSecurityPlanet doing a story on the Top 20 Influencers in the security industry. He happened to make the list himself but there are a lot of other notable names on there with links to lots of good research going on. Notably for me was our friend Dan Goodin who is a journalist that we link to a lot in HackerKast and is the first to cover many security news stories. Kudos to all.

Next, some news broke right before we started recording that was super interesting about some MLB teams getting into the hacking space. Turns out a former employee of the Houston Astros who left and now works for the St. Louis Cardinals never had his access turned off and was leveraging his old credentials. The Astros have some high-end scouting data that was put together with some cutting edge “Moneyball” style metrics that the Cardinals wanted their hands on. The FBI has been brought in to investigate this, how far this incident went and to prosecute those at fault.

We moved on from the baseball hack and into a security company admitting getting hacked with Kaspersky coming out and talking about Duqu 2.0. Robert touched on this and what made it interesting was that Duqu is almost certainly developed by a nation state due to some evidence reported on about it. The other major interesting tidbit about this is Duqu at some point, stole a valid Foxconn SSL certificate which allowed the malware to bypass a lot of first lines of defense. By using a valid cert, Duqu wouldn’t trip many of the alarms that normal malware would have upon entering a network. Robert also mentioned that in light of this, Foxconn should probably be doing some forensics and incident response into figuring out how their certificate was stolen.

Couldn’t make it out of another HackerKast without talking about one of our favorite topics, ad blocking. There was an article this week in Wired which discusses the differences in ad blocking on desktop platforms and mobile devices. Since browser extensions have become so prevalent and are cutting into the wallets of certain advertisers, *cough*Google*cough, there is a movement towards pushing users to use specific apps for content that they’d like to digest. Robert’s discusses an example with CNN where it would push users to use the CNN mobile app where they control the content fully and there would be no such thing as ad blocking.

Staying on the ad topic, Microsoft put out a research paper about serving web ads locally from your own computer. Think of this as a super cache which would have some implications on bandwidth, load time, ad blocking, and some malware related consequences. The major motivation here is almost certainly avoiding ad blocking since the ads are not loading dynamically from the web. Jer made the joke of hoping that chmod 000 being a thing for that folder.

Lastly we finish off with a Dan Goodin story with a witty title of “Ding Dong, the witch is dead” referring to Microsoft finally bringing the hammer down on the Ask toolbar. Microsoft’s malware team and suite of software including Microsoft Security Essentials will now flag the Ask Toolbar, most notably bundled with Oracle products by default such as Java, as unwanted software. The criteria of this flagging is software that includes “unwanted behavior, delivery of unwanted advertising, and a loss of user’s privacy”. The other speculation we made was that this would save Microsoft millions of dollars in customer service calls of how to remove it from Internet Explorer from unsavvy users who accidentally installed it. We all smell lawsuits on the horizon and will be an interesting one to watch.

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

Resources:

20 Top Security Influencers
Cardinals Face F.B.I. Inquiry in Hacking of Astros’ Network
The Duqu 2.0 hackers used a Legitimate digital certificate from Foxconn in the Kaspersky attack.
Apple’s Support for Ad Blocking will Upend How the Web Works
A Microsoft Research paper considers serving web-ads from your own computer
Ding dong, the witch is dead: Microsoft AV gets tough on Ask Toolbar

Notable stories this week that didn’t make the cut:
FBI seizes Computers Involved in Massive Celeb Nude Leak
Report: Hack of government employee records discovered by product demo
Catching Up on the OPM Breach
Bing to Start Encrypting Search Traffic
LastPass Hacked – Email Addresses and Password Reminders and More Compromised
Stealing Money from the Internet’s ATMs or Paying for a Bottle of Macallan
Using the Redis Vulnerability to Patch Itself