SERIES: Security Now! EPISODE: #506 DATE: May 5, 2015 TITLE: Law Enforcement Backdoors HOSTS: Steve Gibson & Leo Laporte SOURCE: http://media.GRC.com/sn/SN-506.mp3 ARCHIVE: http://www.GRC.com/securitynow.htm DESCRIPTION: Leo and I catch up with the past week's most interesting security events and cover some miscellaneous tidbits. We then examine the carefully written testimony of two leading computer scientists who argue against the feasibility of incorporating encryption backdoors into commercial mobile and other device technologies. SHOW TEASE: It's time for Security Now!. Steve Gibson's here. We've got lots of security news. And then Steve's going to comment on testimony in Congress about backdoors for law enforcement. We know it's a bad idea. Did Congress get the message? Stay tuned. Security Now! is next. LEO LAPORTE: This is Security Now! with Steve Gibson, Episode 506, recorded Tuesday, May 5th, 2015: Law Enforcement Backdoors. It's time for Security Now!, the show wherein which we cover your security and your privacy, and we get tortured grammar and all of that. Here he is, Security Now!'s professor at large, Mr. Steven "Tiberius" Gibson. STEVE GIBSON: Yo. LEO: Oh, that's the wrong button. STEVE: Great to be with you again, as always. LEO: Thank you, Steve. Good to see you. STEVE: Yeah. Well, and I did want to mention, I tweeted out to the people who follow me and got a lot of positive response. But there are certainly those who listen to this podcast who don't. And so I wanted to give everyone a pointer to last Sunday's TWiT, which I thought was exceptional. You just had - it was a magical combination of personalities that worked well together, knew each other, and also brought a lot of information. I mean, Jason is, like, really wired into what's going on in Silicon Valley. LEO: Yeah. You know, Jason hadn't been on for three years. We had a little falling out. And I decided, oh, life's too short, and I invited him. And it turned out the best possible week ever to bring back Jason Calacanis because he has Tesla No. 1. He knows Elon Musk. So he had a lot of insight on the Powerwall. It was just - I agree. STEVE: And the Hyperloop. He's, like, he's involved in... LEO: Yeah, he's building the Hyperloop. STEVE: ...the two-mile test track. He won't say where. But, yeah, I mean, he was just - it was a great episode. So... LEO: Thank you. Thank you. STEVE: ...I wanted to, for those listeners of this podcast who don't normally listen to TWiT, the last Sunday's TWiT, I think it was 508, was just - it was spectacular. And I noticed, after the formal podcast ended, it kept going on. And that was really good, too. And I think your producer mentioned, like, capturing that also. So is that around somewhere? LEO: Yeah. Jason - it should be in the recording. Is it not? STEVE: I don't know. I didn't... LEO: Oh, you watched live. STEVE: I didn't watch the recording because I watched live. LEO: Yeah. So, and this, I don't know, in the early days of TWiT we did this all the time. I would record a lot more than we would use, and then we'd have some bits in at the end. After the theme song and the credits rolled, we'd kind of "Smokey and the Bandit" style come back and have a little, you know, stuff, not bloopers, necessarily. But in this case Jason Howell, our producer, suggested, and I think he was right - because we had a very kind of philosophical conversation. We had closed the show, of course, eulogizing a dear friend of Jason's, as it turned out... STEVE: Dave Goldberg. LEO: Who was CEO of Survey Monkey and died, we've learned now, died in just a freak accident. He was... STEVE: He said like some sort of a concussion during exercise, or health-related. LEO: He was on a treadmill. STEVE: Ah. LEO: He was on a treadmill. And in fact the Washington Post used this as an occasion to do a long article on the dangers of treadmill because those are very powerful motors in there. STEVE: Yeah. LEO: And people don't take it too seriously. And when treadmills started coming into the home, the accident rate during exercise went through the roof. So I think there was no one in the exercise area, so nobody knew exactly what happened. But he'd apparently fallen off the treadmill, injured his head, and bled out before anybody discovered him. So just a freak accident, a tragedy. Two young kids, I think 13 and 11. STEVE: And he was 47. LEO: He was just 47. And that's one of the reasons I was so glad to have Calacanis there because Jason was his poker buddy, knew him well. And so he was really well equipped to talk about his - he called him Goldie - Goldie's contributions, what a great guy he was, and what a tragedy it was that this father and successful businessman - his wife, Sheryl Sandberg, runs Facebook. STEVE: Right. LEO: Just a loss to the community. I did not know him. But I felt as if I did after Jason spoke about him. So that was also very timely. I was really glad to... STEVE: Well, and as you were saying, the dialogue after the formal podcast ended was just - it continued to be just worth, I mean, just good broadcasting. LEO: Well, we were talking about, you know, life and death and why the good die young and, yeah, it was great. So we kept it. I think it's - I'm pretty sure it's at the end of the recorded episode as kind of outtakes, yeah. STEVE: Okay, good, good. So we don't have a huge news week. The main topic today is what I predicted or promised last week, which was the issue of law enforcement backdoors. This congressional testimony did occur the following day, that is, last Wednesday, following last week's podcast. And so I want to share the written testimony of Matt Blaze, who is a well respected doctor of computer science. He's the guy that found the problems with the Clipper Chip when the government originally tried to do this. His oral testimony is not the same as the written. And I think the written is - because you can sit down and take the time to put it together carefully, and maybe you're in a little bit of less hurry. Whenever they're delivering testimony, it's like they leave out the punctuation. They just sort of rush through it, you know, during the actual committee meeting. But I want to share it because it brings up some really good points. And then I found someone else who we've talked about before, who has come into the podcast, and that's Jonathan Mayer at Stanford, who's a computer scientist and lawyer. And he takes a very different heavy computer science approach, which is looking at Google and Android as an example, what are the actual practical problems with doing this? And he demonstrates that you can't, that it's just impossible. So I think that's going to be really interesting. So I want to share that, and then we'll discuss it. And of course at the top of the show we've got some interesting news to catch up on. So another great podcast. LEO: As they say, busy busy busy. STEVE: So, okay. Our first story, news of the week, is - I don't know why it's called the "Pixie Dust" attack. But it's a new, well, it's a revelation about how to attack the WPS protocol on a number of WiFi routers. And we've covered the problems with WPS in years past. In fact, I'm not going to go back into excruciating detail of the protocol, only because we did that on Episode 337 of this podcast, Security Now!, which was January 25th of 2012, so a little more than three years ago. The title of that podcast was "WPS: A Troubled Protocol." And there we broke down in detail how it works and why it just was never really very solid. You may remember the name "Reaver." I remember when I saw that again, I thought, oh, yeah, I remember Reaver. Reaver was one of the tools that surfaced back then for cracking WPS. Some changes were made. Basically it turned out not to be nearly as strong as it was believed. WPS essentially uses an eight-digit PIN, which is normally printed on the label, along with the serial number and the MAC address for the router. Right next to that it'll say "WPS PIN." And the idea is that, for example, if you have a WPS-aware client, like Windows, you can pair your Windows system to the WiFi router just by typing in this eight-digit PIN from the label of the router into a dialogue on the client, and you're sort of magically done. You don't have to worry about what the router's password has been configured to. So it makes that easier. And there's also a button you can also press. And it's actually one or the other. So some routers just have a button where it's like, okay, within a short window you can do pairing. Otherwise, type in this eight-digit PIN. Well, eight digits seems like a lot to brute force because we know just eight digits of decimal is, what is that? I didn't think of it ahead. A billion? A million? Anyway, it's a lot. And it turns out, though, that there was a weakness in the protocol where, if you divided it up into two four-digit pieces, you could, like, do half of the protocol with only four digits, which dramatically reduced the total number you had to try because essentially you could do four digits at a time. You could do just half. And in fact the eighth digit is actually a checksum digit, so it doesn't really even count for the second four. It's only really three. So there's only a thousand of those, and 10,000 of the first. So some adjustments were made to try to fix it. And, you know, it's sort of - it's limped along. Some routers have it. Higher end routers have removed it because it just sort of has made people feel uncomfortable. Well, so the news of this week, three years after all of this, is that a security researcher, Dominique Bongard, discovered, he looked closely at some actual implementations of the detailed protocol on some popular routers. And what he discovered was that it was much worse, of course, than we thought. Any of these sorts of protocols requires - and how many times have you heard me say this - a good source of random numbers. Cryptography, almost without fail, I'm not sure I can think of an area where there isn't at some point in a protocol the need for entropy because, even though we're protecting the protocol with crypto stuff, normally it's a secret that we're protecting. And it's not the same secret. Typically protocols grab a random number. And then, for example, we were talking about it last week, where if you wanted to communicate privately you'd pick a random number, use that as your key for bulk encryption. Then you'd use public key cryptography to encrypt the random number. Well, obviously, if that random number wasn't random, you have absolutely no protection. None. So despite all the other mechanisms in place, if you don't actually have really unpredictable random numbers, you have no protection. And it turns out that, as a consequence of - in some cases it's got to be a bug, or just them not caring, apparently the implementers not caring very much. At least several routers that have been looked at are beyond bad. And the examples of them being bad are what hooked me on this because, for example, Ralink access points end up using two nonces. Remember that "nonce" is the cryptographic term for a one-term random value. A number once, technically, is what nonce stands for. But the idea is that it can't be known, can't be predictable. It's got to be - oftentimes doesn't actually have to be random, but there has to be no way for an attacker to have an idea of what it could be, however that ends up being arranged. And sometimes just having a good source of true entropy is the way to do that. But in the protocol there are two 128-bit nonces called E-S1 and E-S2. And again, back in that podcast 337, I go over this in detail. So anyone who wants more can get it there. They must be unpredictable for this handshake to work. There is also a publicly chosen and, like, visible random number which the two endpoints share. And that's called the "enrollee nonce." Okay. So this Ralink access point uses for E-S1 and E-S2, which have to be unpredictable, uses for both of them the value zero. Which is, you know, meets no criteria. It turns out that these nonces are mixed in with some other known values and hashed in order to produce intermediate results. And so no Ralink access point is secure if it has WPS enabled. So now what we have is a known offline attack which can listen to any negotiation with WPS - even an attacker can initiate one - generate some protocol, and then just cut through it like butter, immediately determine what the access point's PIN is, and then associate with it, and you're on the network. So Ralink router owners, you absolutely disable, turn off WPS if you haven't already. And that was our recommendation three years ago because it just wasn't safe. Okay, but there's two more examples that are better - well, it can't be worse than zero - but still demonstrate a failure to appreciate the cryptographic importance of entropy. And unfortunately, this one is Broadcom routers with eCos devices. Those two secrets, the E-S1 and E-S2 secrets, they're generated immediately after the enrollee nonce. And the function that is used is a simple, linear, congruential, pseudorandom number generator with no external entropy. So we've talked about that before. A linear congruential pseudorandom number generator basically takes a value and multiplies it by - it takes the current value, multiplies it by some unknown constant, adds another constant, and that's the next value. So what it is, is entirely deterministic. If you know one value, and you know those constants, you know the next value and the next value and the next value and so forth. So here, in the Broadcom router, remember I said that the supposedly random nonces E-S1 and E-S2, are generated immediately after the enrollee nonce. Well, the enrollee nonce is public. It's published. It's in the air. So once again, this can be cut through instantly. Someone initiates a WPS handshake, gets the enrollee nonce, can immediately, from knowing what the PRNG in the Broadcom router is, determine what E-S1 and E-S2 are, and crack the PIN and acquire access to your network. So again, disable WPS. And the last example is Realtek routers. And we don't have model numbers, so I don't want to over panic people who, like, have a Realtek access point. The chipsets may vary. The firmware versions may vary. But these three, instances of these three routers were used in the security presentation. The Realtek access point uses the time in seconds from January 30th, 1970. That is, so however, whatever duration it's been from January 30th, 1970, in seconds, until this protocol is exercised, it uses those to generate these three values. It uses the same generator to make the enrollee nonce, which thereby publishes the value of time that it thinks it now is, and uses this same time value, or the value from current time, for E-S1 and E-S2. So if the entire exchange occurs within the same second, then E-S1 and E-S2, which are the - well, I'm sorry. E-S1 and E-S2 will be the same as the enrollee nonce, which is published in the air at the initial start of this negotiation. So again, no mystery there. And if it doesn't, if the second counter rolls over, then they are literally one greater in value than the enrollee nonce. So, again, no protection. The bad news is it's not like all routers have had this checked. These three routers were found to be ridiculously poor in their actual implementation of a protocol that was already very troublesome. So the lesson here is this is not something - WPS is really not something you want to leave enabled all the time. Yes, it's convenient. But we know what a problem convenience so often is. And this is another example of that. So classic security implementation problems in low-end consumer routers. I did want to update everyone on some tweets that I received after last week or the week before, noting that RC4, this technically still secure, but people just aren't comfortable with it protocol, was disabled in Firefox v36. Apparently there's a whitelist in Firefox where Mozilla found some sites where they didn't want to cripple those sites because, for whatever reason, they only support RC4. So Firefox has a whitelist that still lets RC4 happen, if that's where you're going. But otherwise, by default, it is disabled. So it's no longer offered in the initial handshake of TLS, offering it to the server as an opportunity. And I also wanted to mention that a number of people have tweeted, while we've been talking about this, that they've managed to turn it off in all their browsers. And there's ways to do it in Chrome, and ways to do it in IE. It's like, okay, good. It's not something I'm worried about. It's in the process of being phased out by the industry. There aren't actually any known vulnerabilities with it; whereas, for example, there are with the cipher block chaining ciphers, although there are clients, the browsers have mitigations in place now to solve those problems because those were sort of more theoretical, too. But we know that theoretical vulnerabilities become real very quickly. And Mozilla has stepped into the game with Google of deciding they're going to put pressure for deprecating nonsecure HTTP connections. I guess really Google has been more in the we're going to make the HTTPS connections more secure by putting pressure on the security certificate side. But last Thursday, in the Mozilla security blog, the Firefox security lead Richard Barnes did a blog posting titled "Deprecating Non-Secure HTTP." And he said, just the beginning of his posting, he said: "Today we are announcing our intent to phase out nonsecure HTTP." Okay, now, understand what that means. He says we're phasing out the use of non-HTTPS, meaning we're, like, formally saying we're trying, we're going to do what we can to encourage people to no longer use non-secure web connections. So he said: "After a robust discussion on our community mailing list, Mozilla is committing to focus new development efforts on the secure web" - their phrase - "and start removing capabilities from the non-secure web. There are two broad elements of this plan: setting a date after which all new features will be available only to secure websites, and gradually phasing out access to browser features for nonsecure websites, especially features that pose risks to users' security and privacy." Now, what I thought was really interesting about this is they're putting pressure on a different aspect of the community. They're essentially putting pressure on the site developers, that is, they're saying - and his blog goes into more detail, and there is more detail in the discussion that he talks about being robust. I mean, it was a food fight because it's considered controversial. But what they're saying is they're going to, like in the future, only just by decision, for no security reason except they want to create a way of making it difficult not to use HTTPS, Firefox's forthcoming features simply won't be present. They won't work under HTTP. So a site and webmaster or site builder, the people who are responsible for content, if they insist on continuing to not offer HTTPS, that is, if they're serving content unsecured, Firefox will withhold features, like useful features... LEO: Like what, though? Have they said? STEVE: Well, like HTML5 new features, like CSS new features. Actual, like, standards features that are continually being developed and being added to the browser, they're just going to say, no. If you're not secure, we're not going to let you use those. And so the notion is that content providers would be forced to work around that lack of features at some discomfiture such that is would be easier just to give up and switch to HTTPS. So... LEO: Jesus. STEVE: I know. I know. It's like, wow. Okay. LEO: We could be more bully-ish than Google if we try. STEVE: Yeah, and I have to say, anyone who's interested, it's blog.mozilla.org. The link is "Deprecating Non-Secure HTTP." Last time I looked, there were, like, 208 comments on the blog. And, oh, boy, I mean, it's crazy. I mean, because this is just regarded, you know, I mean, everybody's got their conspiracy theory. They're saying, oh, Firefox has thrown in with the certificate authorities, or they're in league with the HTTPS people or the LetsEncrypt.org. And it's like, what do you mean? That's a free certificate. I mean, it makes sense to be using it. And but I think what this speaks to is what we really see, which is look at IPv4 and IPv6. Rather than switching to 6, people are spending tens of millions of dollars on the vanishing number of IPv4 addresses. I mean, it really does take people, I mean, it'll take a lot of pressure to get people to move away from something that is working, if they really don't have to change. LEO: Well, they're being economically rational. And I just feel like - I don't know. STEVE: I know. I'm with you. It's like, wow. LEO: It seems a little totalitarian to say, well, no, you can't be economically rational. You have to do it this way. Fortunately, there's competition amongst browsers, and you have a choice. STEVE: Yeah. And that's what I found myself thinking was, wow, you know, I hope - I like Firefox. And but there's Chrome, and so far Google's not doing that. And so if that becomes a problem, I mean, although... LEO: Well, Google's going to do it, don't you think? I mean, they're moving in that direction, too. STEVE: Yeah. And actually, this doesn't put pressure on the users, though. This really puts pressure... LEO: Just websites. STEVE: ...on the websites. So users wouldn't see any difference unless the website started saying, please switch to Chrome. LEO: Well, guess what. STEVE: Where we'll offer all, yeah, we'll offer more features. LEO: Yeah, you want a good experience, use Chrome. That's not - people do that anyway. STEVE: Yeah, yeah. LEO: I mean, I guess if the only possible reason that a site is not secure is out of stupidity or laziness, I guess you could make that argument. But I also feel like there might be legitimate reasons why a site is not using SSL. I don't know what they would be. I mean, we've had - it's going to cost me money. STEVE: Yes, yes. LEO: I mean, I have to pay thousands of dollars to make sure that this works, and it's going to make it a less robust site. STEVE: I think there is a - say that you have a site that just wants to provide information. LEO: Yeah. STEVE: It's just there to have people come and read. And, like, nothing else. I mean, and there's certainly a vast, a huge number of sites that fall into that category. It's like, okay. This just, I mean, there's no rationale, no - you can't see a reason for forcing it. Yeah. LEO: Oh, yeah. I mean, I don't know enough about it, I guess. I just know that we are - we feel compelled to do it. And really you don't get the content from us. All you get is web pages from us. Our CDN, Cachefly, which does offer HTTPS, does it. But then I would have a mixed-mode message, though. You're going to get a warning that part of this page is encrypted, part of it's not encrypted. And you're going to get a warning. And that's not a good experience for users. So I've got to bite the bullet and just do it. STEVE: Yeah. And I really do think that, downstream, that's the future. At some point it'll be like, wait a minute, why isn't this site secure? And actually, two more stories, I've got a piece that's a little bit interesting because CloudFlare did a blog posting about sort of this new era of DDoS attacks. And it is the case that man-in-the-middle attacks are trivial to implement on nonsecure HTTP connections. And I don't know if that's justification. But it is the case that it really lowers the bar for attacks not to be served over secure connections. LEO: And that would be a good argument for it. I mean, somebody'd come to TWiT, there'd be a man-in-the-middle, and then they could put malware on their computer, right, because they would think that it is a trusted connection to TWiT, when it's not. STEVE: Correct. And actually we can talk about it right now. I mean, the man-in-the-middle attack is almost impossible with HTTPS because you have to - the man in the middle... LEO: Unless you're Superfish. STEVE: Well, yeah, has to present a certificate that the browser trusts. And now, so a state-sponsored man in the middle can be done because I don't think anybody believes now that a nation-state can't synthesize any certificates they want to on the fly. Just, you know, the NSA has to be able to make a certificate, if they want to. And we know that China can because they own CNNIC and can tell them exactly what they want. So, but still, that raises the bar from hackers to somebody who has the ability to generate certificates on the fly. And that's a heavy burden because the second you generate, as we've seen, a fake Google cert, and a Chrome browser touches it, all hell breaks loose, and the jig is up. So we have enough canaries around now that it's difficult to get away with that. An unsecured page, though, is just - it's literally just plaintext moving by. And on the way to the browser, that is, as the page is being returned to the browser, simply inserting a JavaScript tag with a URL of some foreign server, when that gets to the browser, in parsing the page the browser will fetch and execute that JavaScript. It is that simple. And that, I mean, this is a variation on the Great Cannon that we talked about a couple episodes ago. That's what essentially China's Great Cannon was doing to DDoS GitHub. In that case it was substituting some JavaScript that was already being requested. But nothing prevents anyone from being anywhere in a connection and just adding a JavaScript tag. Browsers run JavaScript. They'll fetch the script, and they'll execute it and can get themselves in trouble. So I can see the logic, if we take that sort of, wow, you know, all is lost, the web is really under attack, then going to secure connections everywhere really does raise the bar. And speaking of raising the bar, there is a crazy new anti-analysis malware which has been found. Craig Williams of Cisco, who's one of their security guys, has been looking at a new strain of spyware that they detected earlier this year, just a few instances. So it's believed to be only in use in targeted attacks. It logs keystrokes and steals data, but also has a destructive side which unleashes wiper capabilities if it detects it's being analyzed and audited. So it's not worried about end users because end users just run it. It's now gone to tremendous lengths to protect itself from being reverse engineered. Quoting Craig, he said: "It sounds clich, but this really is a digital arms race, and we're seeing the next evolution of it here. Malware authors are no longer content with detect and shut down. Now, if malware realizes it's being audited, the binary will destroy the system." LEO: Wow. That's the nuclear option. STEVE: Yes. "It's a simple case of attackers trying to dissuade researchers from going after a sample." And so just to give you a taste of this crazy thing, this thing contains 8,000 executable functions which are never used. It just piles them in there to water down the actual content hiding among 8,000 other functions that never get used. At one point, it writes a byte of data into memory 960 million times in order to break sandbox logging because one of the techniques that's used by sandboxes that are used to watch these things run is they log the activity of the malware. So this thing thumbs its nose at that and writes a byte 960 times. And it turns out that would produce a hundred-gig log file and take half an hour to write to the hard drive. So again, it's like, okay, this thing is really flailing around, refusing to be analyzed. And the unpacking code that unpacks this into the system Cisco describes as "monstrous and has many times the complexity of the anti-analysis code." It contains dozens of functions overlapping each other and embedded with unnecessary jumps added only to increase the complexity of what's called the "call graph." He said: "The result is a nightmare of control flow graph with hundreds of nodes." Oh, and it continually hashes itself in order to detect if any change has been made. And if it finds any, it first tries to overwrite the user's master boot record. And if it can't verify that it did that successfully, it then randomly chooses RC4 keys and overwrites every file of the home folder with a different random key which it doesn't bother keeping track of. LEO: Why should it, no. STEVE: So it's just... LEO: Wow. STEVE: It's like, I can't think of the analogy of, like, some sci-fi where something, some alien has been trapped in a box, and it's just flailing itself around, like, wildly, and finally ends up destroying maybe its host or its container, at least. LEO: Do you think this is written by bad guys? It sounds pretty sophisticated. STEVE: Wow. Well, that's a good question. I mean, unfortunately, we have to ask that question. And there was a lot of interesting, in this congressional testimony that occurred last Wednesday, I have to say I was more impressed than I expected to be with the government's, with Congress's position. There are, I think I read elsewhere, four people in Congress who have computer science degrees, which was four more than I expected. LEO: Yes, really. STEVE: So, yeah. There seemed to be some hope there. LEO: They know COBOL, boy. They know their COBOL. STEVE: So CloudFlare, they did a blog - basically they didn't name China. They didn't say "Great Cannon." But this was pointed straight at them because this was - CloudFlare's blog was titled, "An Introduction to JavaScript-based DDoS." And of course everyone who's been following this podcast knows that the way the Great Cannon works is it was intercepting unsecured connections to a Chinese search engine and replacing a bit of JavaScript which users' browsers all over the world retrieved and then executed. And so that is a JavaScript-based distributed denial of service. And in the blog posting they sort of harkened back to the nice days, where it was just an NTP or a DNS amplification or reflection, you know, those simple days where you would be bouncing stuff off of some server, spoofing your source IP, and so it would reflect onto your target. Now, unfortunately, the DDoS guys have a new trick, which is JavaScript. Now, the question is, how do you get JavaScript into browsers, which is what we were just talking about a minute ago. Now, of course, one way to do that is you infect a website so that the website itself is actually delivering malicious JavaScript. And unfortunately we have seen a variation of that where ad servers get malicious ads until they're discovered and taken down. And so a benign website has links to an ad service that's servicing ads, and that can also contain Flash, for example, and JavaScript and so forth. So, and obviously the ad suppliers are doing everything they can to prevent that from happening. But sometimes something squeaks through that's unseen before, or extra clever. So one possibility is that a malicious page hosts JavaScript. The problem is that a malicious page will get known pretty quickly. And malicious pages, I mean, where the actual site has a page that is deliberately malicious, they don't have many visitors. So the strength of your denial of service attack is purely a function of how many people's browsers are running the malicious script you're offering. So you want to infect very popular, high-traffic sites, one way or the other. Get an ad onto them. Maybe do some SQL injection. If you can modify a page, somehow get a page to produce the script that you're trying to get the browsers to run. Another possibility of attack is the JavaScript libraries themselves because what many web pages do, rather than hosting their own core library, like jQuery is a perfect example, 30 percent of websites in 2014 had pages that referred to jQuery. So they didn't grab a copy of it and then host it themselves. They just pointed to the jQuery library. And they like that because, as the jQuery library gets updated, their pages get the benefits of any bugs that are found and so forth. The flipside of that is, I mean, that represents a huge target for malicious exploitation, if somebody can get into one of these sites. And, for example, last year jQuery.com's website was compromised. So if they could get, like, turn the jQuery library malicious, that's a win. And Leo, didn't you have a problem a couple years ago with one of the libraries you were using? LEO: Yeah. It wasn't jQuery. We use Drupal. STEVE: Yeah. So again, I mean, another... LEO: And it was a Drupal library. It wasn't even a - so Drupal, and this is true of WordPress and a lot of content management systems, has publicly contributed libraries, or little code widgets. And so our developers had used one. And a vulnerability was found in it. Either we didn't patch it, or it hadn't been patched. Bad guy, you know... STEVE: Found it. LEO: All you do is you google. STEVE: Yeah. Yup, yup. LEO: And they're usually easy to find. And then you can use it. He used it to, I think it in effect gave him an open FTP folder that he could put stuff into. So he put some malicious script in there. STEVE: Like storing stuff on your server. LEO: Yeah, and it was a malicious script that would get activated. But it took advantage of a flaw that had been patched in most operating systems. So to my knowledge nobody used - I don't know if our users got bit. And of course very quickly Google puts up that warning, and then everybody follows suit. STEVE: Right. Oh, in fact... STEVE: That's what happened. STEVE: Right, right, right. LEO: Which we welcome, because that means people aren't going to go into our site and get infected. I don't want anybody to get infected. STEVE: Right, right. LEO: We will be using Node.js in our site in future. So this jQuery thing is of interest because that uses - yeah. STEVE: Yeah, exactly. Same sort of solution. Now, there's an interesting proposal we've never talked about coming from the W3C, the World Wide Web Consortium. And this is a new option for - and it's called "Sub Resource Integrity." And this was mentioned in the CloudFlare blog. The idea is that normally your tag would be - it would say "script src=" and then in quotes would be a URL. And the browser would just go and fetch that. And, for example, it might be, and I have in the show notes an example, "jquery-1.10.2.min.js," "min" meaning it's been minified, JavaScript. And so your browser is saying this is the version of jQuery I want to pull. Well, with the addition of Sub Resource Integrity, the script source tag, that tag can also have the optional word "integrity=" and then a hash specifier, like SHA-256 hyphen, and then the hash, the SHA-256 hash, the proper hash of that version of the library. So if a browser is aware of this, and the site has protected itself/its users by providing this, then the browser will see the script tag with this extra integrity value, fetch the resource, do an SHA-256 before executing it, verify the hash matches, and then, and only then, implement, you know, drop that script into the page at that point. So this is very cool. This does not protect us from injection, interception injection. But it would protect from anyone maliciously modifying the library or the resource that is being fetched. So, again, it's not perfect, but it forecloses one of, well, actually, one of the more worrisome avenues would be that the original jQuery library would be infected, the version number not changed, the browser fetches it and runs it, and then every browser on the planet which is at that time fetching pages that are invoking jQuery, would all get this script. So that's breathtakingly awful. So it's neat that we'll have the ability - oh, and so what happened is, or the way it would work is that the webmaster would pull the script, generate the SHA-256 hash, and then put that in their page. The reason this is useful is that this still protects us after we have HTTPS. Remember that the interception injection sort of relies on the man in the middle being able to inject a script tag into the page as it's going back to the browser. The bar for that is very low. It's trivial to do. But once we have SSL/TLS, HTTPS, then that becomes much more difficult to do. So random malicious weenies aren't going to be able to do that. But even with HTTPS, we could still be victim to the source of the library being compromised. So what I like about this Sub Resource Integrity is it blocks that one. If you get, as far as you know, a known good copy, make the hash, put the hash in your page, and then browsers that are aware of this won't act on it. And right now this is not well supported. But Chrome and Firefox both have it in the works. So there will be support for that coming soon. And lastly, the last thing I had in my notes we sort of already covered, which is that I wanted to make sure people understood how trivial man-in-the-middle attacks to inject JavaScript is if we don't have secure pages because it's just plaintext going by. And you drop that little