SERIES: Security Now!
DATE: March 7, 2017
TITLE: Let's Spoof!
HOSTS: Steve Gibson & Leo Laporte
DESCRIPTION: This week, Leo and I discuss the countdown to March's Patch Tuesday. What was behind Amazon's S3 outage? Why don't I have a cellular connectivity backup? We share some additional Cloudflare perspective. Amazon will fight another day over their Voice Assistant's privacy. An examination of the top nine Android password managers uncovers problems. We'll cover another fileless malware campaign found in the wild; security improvements in Chrome and Firefox; a proof of concept for BIOS ransomware; a how-to walk-through for return-oriented programming; a nifty new site-scanning service.
Matthew Green compares desktop and mobile security. We've got a bunch of feedback quickies, an incredibly wonderful waste-of-time accomplishment, the future threat of deliberately fooling AI, and the dark side of automated domain validation certificate issuance.
SHOW TEASE: It's time for Security Now!. Steve Gibson is here. He's got all the security news. He's got a lot of other stuff, too, including the weirdest scientific diversion ever, and a look at some new certs from Let's Encrypt that could be problematic. It's all coming up next on Security Now!.
LEO LAPORTE: This is Security Now! with Steve Gibson, Episode 602, recorded Tuesday, March 7, 2017: Let's Spoof!
It's time for Security Now!, the show where we get together and talk about security with the one who knows, Mr. Steven “Tiberius” Gibson of GRC. Hi, Steve.
STEVE GIBSON: Yo, Leo. Great to be with you. This is the first Tuesday of March because March 1st was last Wednesday. So this is, once again, this is the lead-up to the probably big March second Tuesday, which of course - so I guess this would be the, what, the penultimate Tuesday…
LEO: Use your words.
STEVE: …before the March Patch Tuesday, which we expect to be huge, well, huge in the sense of it fixing a lot of things. But as we know, now that Windows has just a single blob that is a rollup of everything that they fixed, it's just going to be one thing, but it ought to be a big relief for people who are concerned. I've even seen some independent companies releasing short-term fixes, their own Windows patches for some of these things that Microsoft just didn't get around to fixing in time.
And we've got a ton of news. This is Episode 602. We now know what was behind Amazon's S3 outage. I wanted to just quickly respond to why I don't have cellular connectivity backups, backup connectivity, which a number of our listeners commented on due to last week's delayed recording. I wanted also to share some additional Cloudflare perspective, following up also on last week. Amazon turns out is going to be fighting another day over their Voice Assistant system's privacy questions, so we'll touch on that briefly. An examination of the top nine Android password managers, which uncovered problems in them all, including LastPass, the one that I use and you use and is sort of the show favorite.
There's another wireless malware campaign which has been found in the wild using a disturbing new technology - well, actually a disturbing old technology in a new way. We've got security improvements in both Chrome and Firefox that are both interesting in different ways. A proof-of-concept BIOS ransomware, which was demoed at the RSA conference and will be fully disclosed at this upcoming Black Hat Asia conference at the end of the month. A brief how-to walkthrough for return-oriented programming. I'm not going to go into it in depth, but it's interesting, and I know that some of our listeners will want the details. I found a nifty new site-scanning service. Matthew Green in his most recent blog compares the fundamental security of desktop versus mobile in a very interesting way that I wanted to share because I knew that would be of interest.
We've got a bunch of feedback quickies from our listeners. The most wonderful, amazing waste-of-time accomplishment I've ever seen. I mean, like, okay, I mean, it's just a feat that I think you and our listeners and I also really got a big kick out of. Then the title of this podcast is how we'll wrap up, after we talk about something that just hit me between the eyes, and that is the future threat of deliberately fooling AI. Then we'll wrap up with the reason I titled this “Let's Spoof!” - the dark side of automated domain validation certification issuance.
STEVE: That is, we know about Let's Encrypt.
LEO: Let's Encrypt, now Let's Spoof.
STEVE: And what's happened, Let's Spoof!. Turns out it's being horribly abused.
LEO: Of course it is.
STEVE: And, you know, of course it is.
LEO: This is why we can't have nice things.
LEO: You're not going to talk about the Vault 7 - it's probably too early to talk about the WikiLeaks Vault 7 release of CIA tools.
STEVE: I just didn't have any time to come up to speed.
LEO: Yeah. And we'll talk, I'm sure, next week about it. And it's one of those things where it's 7,000 pages. It's a lot to look at, millions of lines of code. I do think it's interesting the names. You remember we were always fascinated by the naming scheme that the NSA had used in the Snowden dump.
LEO: But that was, I guess, a randomized two-word generator.
LEO: Apparently the CIA doesn't have such an interest - or the GCHQ because I think of these came from Britain - in obfuscating the purposes and the functions of its tools, though they have a lot of clever names that do in fact give you a hint as to what the thing does. I'm sure we'll be talking about that a lot over the next few weeks. All right.
STEVE: I forgot to ask you how many breaks we had in this podcast.
LEO: One more after this.
STEVE: Okay. So our Picture of the Week is xkcd having some fun with a topic we've been covering a lot. This is xkcd.com/1807. And the cartoon shows his little stick figure people that he typically uses, with a couple entering the house. The people who live there say, “Hello, welcome to our house.” And then the couple entering say, “Thanks for inviting us,” and then the A-word.
LEO: Echo, we'll say Echo.
STEVE: So they say, “Thanks for inviting us. Echo, order two tons of creamed corn. Echo, confirm purchase.” And then the caption says: “When visiting a new house, it's good to check whether they have an always-on device transmitting your conversation somewhere.”
LEO: Wow. Come on, Randall. Really? Aw.
STEVE: And of course we know that's not the way it works.
LEO: Somebody made a point, though, the other day that you could, Amazon could program it to listen for other keywords. Right? I mean, sure, there's not a lot of processing or memory in that, but maybe a handful of other keywords that it would silently transmit up to the cloud.
STEVE: Well, Leo, they could change…
LEO: They could just turn it on.
STEVE: Yes. The problem is they can't have all of the devices in the world simultaneously streaming audio to them. That would probably even tax them.
LEO: Yeah. And nobody's got time for that.
STEVE: But they could certainly turn on a microphone here and there, if they had some cause to.
LEO: I suspect that's why they fought the law enforcement subpoena, because they don't want the next step to be law enforcement saying we want a FISA letter, a national security letter that says “Turn on the mic for Leo. Don't tell anybody.”
STEVE: Right, right, right. Okay. So as we said at the top of the show, holding our breath. Seven days from now, March Patch Tuesday. And so we'll probably give that a little more attention than we have because there are a number of zero-days that are being fixed, and who knows what else? And I don't know if we'll ever understand how February got missed, but it did.
We did get some clarification from Amazon about what happened last week. As we know, you guys were talking about it on MacBreak Weekly before last week's Security Now! podcast. And Amazon had a problem with S3. The details, I think, are really interesting. Amazon in their formal post-action report said: “We'd like to give you some additional information about the service disruption that occurred in the Northern Virginia Region on the morning of February 28th. The Amazon Simple Storage Service (S3) team was debugging an issue causing the S3 billing system to progress more slowly than expected.” Okay, so they were doing some maintenance.
“At 9:37 a.m. Pacific time, an authorized S3 team member, using an established playbook, executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. Unfortunately, one of the inputs to the command was entered incorrectly…”
LEO: Pseudo rm-rf* - something like that; right?
STEVE: Yeah, well, a typo, “…and a larger set of servers” - and apparently it was very much larger - “…set of servers was removed than intended.” So they have a command-based sort of meta management system that manages this vast infrastructure. And so, like, rather than going over to servers and talking to them individually, they just do something. And, for example, I've seen that when GRC has been under attack, and it's just like, okay, we're being blasted with ridiculous amounts of traffic. I talk to Level 3, and I say, okay, just blackhole the IP. And so someone at a single console types a command, and all of Level 3's routers at all of their borders update their routing tables to remove that IP.
LEO: That's the power of BGP; right? I mean, we've seen people scrub BGP before.
STEVE: Right. But it also typically, and certainly this is the case with Level 3, they have their own, you know, they can't have that happen by mistake. There's got to be an audit trail. You have to have authorization to do that. So there's like a management layer on top.
LEO: They should never have hired that guy from PricewaterhouseCoopers. That was - just because he was out of work, come on.
STEVE: So Amazon says: “The servers that were inadvertently removed supported two other S3 subsystems. One of these subsystems, the index subsystem” - whoops, that sounds important - “manages the metadata and location information of all S3 objects in the region. This subsystem is necessary to serve all GET, LIST, PUT, and DELETE” - which is, you know, pretty much everything, all the critical verbs for getting and putting, listing and deleting stuff. “The second subsystem, the placement subsystem, manages allocation of new storage” - like where should we put stuff - “and requires the index subsystem to be functioning properly to correctly operate. The placement subsystem is used during PUT requests to allocate storage for new objects.
“Removing,” they write, “a significant portion of the capacity caused each of these systems to require a full restart. While these subsystems were being restarted, S3 was unable to service any requests. Other AWS services in the US-EAST Region that rely on S3 for storage - including the S3 console, Amazon Elastic Compute Cloud (EC2) new instance launches, Amazon Elastic Block Store (EBS) volumes when data was needed from a S3 snapshot, and AWS Lambda - were also impacted while the S3 APIs were unavailable.”
So Amazon's been building this system over time, and they've been building it carefully, and it's sort of their new services are aggregated and use the older ones. And it happens that S3 was where this all began. This is like the root core on top of which all these other things are built and depend.
So Amazon says: “S3 subsystems are designed to support the removal or failure of significant capacity with little or no customer impact. We build our systems with the assumption that things will occasionally fail, and we rely on the ability to remove and replace capacity as one of our core operational processes. While this is an operation that we have relied on to maintain our systems since the launch of S3, we have not completely restarted the index subsystem or the placement subsystem in our larger regions for many years. S3 has experienced massive growth over the last several years, and the process of restarting these services and running the necessary safety checks to validate the integrity of the metadata took longer than expected.”
So essentially this is something that they knew worked, but they hadn't done for a long time. And it sounds like they were surprised that it didn't - that this was an area that wasn't scaling linearly; it was scaling more exponentially. So that they went “oops” when they realized that they'd inadvertently shut down much more of this than they expected. And they're not explaining why, but essentially it required a full restart. And then they realized with some chagrin that, oh, is it restarting? It's like, well, yeah, it's trying. I mean, it is. But it turns out it, like, took way longer than they had expected. And it's something they hadn't done for a long time.
So they said: “The index subsystem was the first of the two affected subsystems that needed to be restarted. By 12:26 p.m. Pacific time, the index subsystem had activated enough capacity to begin servicing S3 GET, LIST, and DELETE requests.” But remember not PUT because that's the other thing. “By 1:18 p.m. Pacific Standard Time, the index subsystem was fully recovered, and GET, LIST, and DELETE APIs were functioning normally. The S3 PUT API also required the placement subsystem.” And remember that that relies on the index subsystem, so that had to come later. “The placement subsystem began recovery when the index subsystem,” they write, “was functional and finished recovery at 1:54 p.m. Pacific Standard Time. At this point, S3 was operating normally. Other AWS services that were impacted by this event began their recovery. Some of these services had accumulated a backlog of work during the S3 disruption and required additional time to fully recover.”
Anyway, I just think this is a fascinating look. And it goes on, for anyone who wants more details. I'm not going to bother going into it here, but I have it all in the show notes. Just sort of an interesting look into, like, the scale of this kind of system, where first of all the design is cool, the idea that - and we know how redundant it is because, for example, you pay more for more redundancy, and you pay less for lower redundancy. And even so, you don't pay much.
I use S3. It is my, as I said before, it is my primary cloud-based backup system. And every month I get a bill. I just keep pouring stuff into it. All the podcasts are archived there, lots of images of critical subsystems and systems are archived there. I get a bill for two bucks. It's incredible. I mean, I'm not doing massive bandwidth transit because that's where you start to pay the bills. But $2 a month. And I think about all the huge amount of storage that I use. And it's incredibly robust. As we've seen, not absolutely unable to fail.
But I should just follow up and say that this was a lesson for them. And as this post continues, they assure us that many steps have been taken as a consequence of what they learned. It is no longer possible to enter that typo. There's much more oversight. There's another system that watches what the impact will be and says, whoa, wait a minute, is this what you meant? And so there's, like, much more accident prevention so that the tool, which arguably had become overly powerful - and this is another one of those things where, over time, the very, like the birthing assumptions no longer really held; but no one had revisited them because there were other things to do, forward progress and work. So, anyway, just an interesting case study, I think, for this kind of massive, super-enterprise scale and how it operates, how it's resilient, and how it gets managed.
LEO: I thought it underscores, just as Cloudbleed did last week, the problems with a monoculture.
LEO: It wouldn't have been such a big deal except that everybody uses S3 and Amazon Web Services.
STEVE: Yes, exactly, a very good point. So suddenly, wham, you know. And in fact, I just saw that because we'll be talking about an interesting site viewer tool later. And someone sent me a link to it. Actually it was our friend Simon Zerafa sent me a link that he had run GRC against it, which is kind of a very boring response because GRC is a small site. And I looked at their list of recently run scans and clicked on CNN, and it was just, like, full of AWS stuff. And I thought, ooh, CNN would have been impacted if there wasn't redundancy.
Now, the flip side of that story is us delaying the podcast last week because my Internet connection was down for a couple hours. And I got a lot of people who were like, what? You mean you don't have an alternative emergency Internet connectivity backup of some sort? And I said, okay. My response was a little defensive, I guess. But 601 podcasts. So in 600 previous podcasts we have never had a single problem. So to me, this represents the proper degree of concern, which is almost none because…
LEO: It's just a podcast, folks.
STEVE: Exactly. It's a prerecorded podcast.
LEO: People ask us the same thing. “What would happen if the power went out at TWiT?” We'd be down. “What would happen if the Internet went out at TWiT?” We'd be down. “Well, don't you have backup?” And my answer is always the same. It's just a podcast. This isn't a hospital. It's not even network television. You can wait a few hours, not a big deal.
STEVE: And I do have things I consider mission critical. GRC has never been down. GRC has redundancy like crazy, I mean, where I don't even - I even have separately physical servers, and I've got hardware firewalls isolating because I just don't trust anything. I mean, I have RAID 6 on SSDs with battery backup. I mean, you cannot take it down. So, I mean, a DDoS will. But it's like, okay, again, people were like, “Oh, my god, you're under attack? Move to Cloudflare.” And it's like…
LEO: Agh, my hair's on fire, my hair's on fire.
STEVE: Yeah. So it's like, okay, let's just keep a sense of perspective. So, yeah. And when my bandwidth has a problem I, you know, like I said, hit the beach. It's some nice-looking beach weather right now.
LEO: Incidentally, we had a great conversation yesterday on Triangulation. I encourage everybody who listens to Security Now!, I think you'll enjoy it. Marc Rogers joined us. He's a legendary hacker. But also SecOps, he's in charge of security operations at DEFCON, has been for 15 years.
LEO: That's a pretty good street cred. And he's the security guy at Cloudflare. So he came on. We talked a little bit about Cloudflare, Cloudbleed, and how they handled that. But we also talked about his hacking history. And it was a great conversation. I think you'd enjoy it, too, Steve. One of the things he said, we were talking about NSA surveillance, and I said, “Well, wouldn't the NSA have every outbound call to Russia that anybody made from anywhere during the election?” And he said, “Well, they might have collected it, but they don't have the capacity to store everything.”
He said there's no doubt they collect everything. He used to work at Vodafone, at British Telecom, for 10 years. So he kind of has a knowledge of what is going into the government databases. He said, you've got to understand, there's so much data, even with this new Utah datacenter, he said, they might have a few weeks or a month, but they can't store stuff forever. They have to pick and choose and say, well, we'll save this stuff, and this stuff's going to get overwritten.
STEVE: Right. And in fact we know from the early Snowden revelations, where we were looking at the nature of the equipment installed in those closets in the major Internet interchange nodes, that they are, in the case of text, they are keyword search sorts of things. So you put filters on certain traffic and say, you know, capture streams that contain the following. So I wouldn't be at all surprised if there is speech recognition stuff at some level where it's like, okay, just look for these words in a conversation. And if you see them, then that we want to store. Otherwise, we don't have infinite storage.
LEO: Yeah. He was good. He also is a car hacker and talked about Tesla and hacking the Tesla. This guy is, I think, pretty good at what he does. So recommend that, yesterday's Triangulation episode.
STEVE: Nice. So, okay. And then some other people, responding to our discussion of Cloudflare last week, one in particular, I just found one, I just pulled one tweet out of many from someone who called himself Amateur, who said: ”@SGgrc Did you read the same response I did? Cloudflare,“ he writes, “totally blamed what they called 'ancient software' and acted like this didn't matter.” And I got a number of responses like that, which caused me to think, okay, did I get that wrong? And then I realized that what I was relying upon much more was the clear responsibility-taking discussion that Nick Sullivan had with you, Leo, on The New Screen Savers, where he was completely forthcoming.
And what I saw of Cloudflare's written disclosure, which was written also by our friend John Graham-Cumming, it appeared to be consistent with what Nick had said. But I imagine that someone reading only a more carefully written corporate post might come away with a different feeling than someone, as I did, watching a completely candid, off-the-cuff interview where he was responding to your questions and saying, yeah, you know, this is what happened. So if anyone still has any doubts, let me encourage you to watch Nick at the beginning of The New Screen Savers from Saturday before last, that was February 25th, Episode 93. I put a link to it in the show notes. Your interview with Nick, Leo, is right at the top of the show so people won't have to dig down into it to find it, if that's the only thing they want to watch. He's right there at the beginning.
And anyone, I think, would come away with the feeling I did, which was they responded immediately. They responded responsibly and really did take responsibility for their use of this software which was actually - and where the problem was triggered by their on-the-fly replacement of that so-called “ancient software.” So anyway, many people were like, wait a minute, is that the proper characterization? And the only thing I could think is that I got it directly from Nick from watching his interview with you.
LEO: And I think you'd say the same thing if you saw Marc's conversation yesterday with me. The one question I had, and it's still an open question, is, well, but do we know, was any damage done? How much damage was done? Because that's the thing that's kind of unknowable. We know that data is leaked.
LEO: But we don't know what data, for who, for what sites. And he said, “We would expect certain kinds of traffic based on somebody getting a hold of any information that was useful. We haven't seen any evidence of that.” So while you can't say everything's fine, we're obviously still watching. But so far, so good.
STEVE: Right. And some listeners did point out that there are other spidery things than just the arguably responsible search engines.
LEO: Right. Well, that's true.
STEVE: Which is true. Again, they would have to have known to look or have discovered this and then gone on a mission for trying to find information. And it isn't something where you're attacking a given site. It's opportunistic, completely out of your control what it is you may get. Low probability of getting anything useful. And then you would have to understand what it was.
LEO: Which is why a government is not going to be as interested as you might think because they have targets.
LEO: And so it's useless for that. The chances of you or me having information revealed is infinitesimally small.
STEVE: Right. And in fact we also do know that there's been a lot of dialogue in the last few days after our President tweeted on Saturday morning that Barack Obama was wiretapping Trump Tower. The fact is that, even if there were conversations involving non-U.S. citizens, as soon as any wiretap realizes there is a U.S. citizen on the line, the rules change. So, yeah, I just don't think it's nearly - my point is that, if our government were to find information that they can't have, well, they're not able to look at it, either.
LEO: And you can't really use it in court, either.
STEVE: Well, exactly, exactly. So we've discussed - we revisited last week the pending question of Amazon's response to the police warrant in the suspected murder, well, somebody was at least killed, we don't know who did it, but of this person in the hot tub, remember, from November of 2015. I thought it was 2016. It may have been…
LEO: No, no, it was two years ago, yeah.
STEVE: Okay. So what happened was we're not going to get any judicial opinion about search warrants covering past audio obtained by and queries served by Amazon's Voice Assistant technology. In documents which were filed last Monday, which we didn't know about for last Tuesday's podcast, but they just came to light, the defendant in that case, James Bates, said that he was willing to allow law enforcement officials to review information contained on his Amazon Echo speaker before the company handed the data over on Friday. So he's pleaded non-guilty. He said, “Fine, I have nothing to hide. Amazon has my permission to turn over anything that they have.”
So it would have been interesting because Amazon, of course, is big enough to fight this with enough strength that this might have ended up being decided by a court, maybe ultimately by the Supreme Court. We don't know. But it's not going to be this case that determines that because in this case they just essentially agreed to say, yeah, okay, fine, let them have what they want.
A group of security researchers who are with the Fraunhofer Institute for Secure Information Technology - their handle is TeamSIK, S-I-K, which sounds a little hacker-ish, but it's actually SIK stands for Security Is Key. And these are obviously the real deal. They wrote: “We meet up regularly in our spare time. Our main motivation is to work on interesting security-related projects for fun, with the goal of exposing security issues. Currently,” they write, “our main issues of interest are Android applications.”
Well, this was in the news last week because they examined carefully and closely, in order to obtain the level of detail they did, the top nine password managers on Android. And those were: MyPasswords, Informaticore Password Manager, LastPass Password Manager, Keeper Password Manager, the F-Secure KEY Password Manager, Dashlane, Hide Pictures Keep Safe Vault, Avast Passwords, and 1Password. So, and the way they described this, like what they came away with was interesting.
They said: “There are different policies for the generation of secure passwords.” They give us a little bit of background on password managers. “However, one of the biggest challenges is to memorize all these complex passwords. Password manager applications are a promising way of storing all sensitive passwords cryptographically secure. Accessing these passwords is only possible if the user enters a secret master password.
“At first sight, the requirements for a password manager application seem simple: storing the passwords of a user centralized in a secure and confidential way. However, how is the reality on mobile password manager applications, especially on Android? Applications vendors advertise their password manager applications as 'bank-level' or 'military-grade' secure. However, can users be sure that their secrets are actually stored securely? Despite the vendors' claims, is it nevertheless possible to obtain access to the stored credentials?
“In order to answer these questions, we performed a security analysis on the most popular Android password manager applications from the Google Play Store based on download count. The overall results were extremely worrying and revealed that password manager applications, despite their claims, do not provide enough protection mechanisms for the stored passwords and credentials. Instead, they abuse the users' confidence and expose them to high risks.
“We found several implementation flaws resulting in serious security vulnerabilities. Some applications stored the entered master password in plaintext, or implemented hard-coded crypto keys in the program code. Consequently, attackers can easily” - now, that's a little questionable because I looked at this carefully also. But they say “attackers can easily circumvent the crypto algorithm” - so I would say “can” circumvent the crypto algorithm - “altogether and thereby gain access to all of the user's data. In other cases, we could simply access all 'securely protected passwords and credentials' with the help of an additional app. Once installed on the device, this malicious app extracts all passwords and credentials in plaintext and sends them to the attacker.
“In yet another case, we could use a so-called data residue attack to access the master key of an application. In most of the cases, no root permissions were required for a successful attack that gave us access to sensitive information such as the aforementioned master password. Furthermore, many of the apps completely ignore the problem of clipboard sniffing, meaning that there is no cleanup of the clipboard after credentials have been copied into it.
“While this shows that even the most basic functions of a password manager are often vulnerable, these apps also provide additional features which can, again, affect security. We found that, for example, auto-fill functions for applications could be abused to steal the stored secrets of the password manager” - and we've been talking about form auto-fill hacks and attacks in the last couple podcasts - “using hidden phishing attacks.”
So they end up in nine password managers, finding 26 different vulnerabilities. All of the ones they disclosed have been fixed beforehand. Avast is the only one that had, first of all, many problems, many more than any of the others. And about half of them remained unfixed. And I should mention that this all happened back in August and September of last year. So there's been plenty of time for these to get fixed. All of the other password managers, including Last Pass, have had those problems which - so this was all responsibly disclosed and responsibly handled.
In the case of LastPass, which I was most curious about, they write: “The Android app of LastPass comes with an access control mechanism which prohibits arbitrary usage of its functionality. By default, the user is asked to enter his master password in order to gain access to the application. Due to its enforced complex requirements” - meaning LastPass Android requires a complex master password - “a user can easily get frustrated entering the master password over and over again. Therefore, LastPass offers to substitute the master password with a PIN mechanism.” So here, again, we're trading security for convenience. “Thereby the user can agree to save the master password on the device” - because remember, the master password is what decrypts the store, that is, the storage blob, so you still need the master password somewhere.
So LastPass offers to substitute the master password for a PIN. “Thereby the user can agree to save the master password on the device and shift all access control to a PIN, which can be from 4 to 14 digits long. The master key and the PIN are symmetrically encrypted and stored in a shared preferences file in the local app folder. The key and PIN are stored encrypted. The key for encrypting and decrypting the credentials is hard-coded into the application's source code.” Thus the problem, and that's what LastPass - that's what these guys found. And LastPass said, okay, you're right, we could do better. So the key for encrypting and decrypting the credentials was found to be hard-coded into the application's source code.
However, even so, for stealing the encrypted master key or PIN, we assume, and that is they required, that the attacker gained physical access to the device, which we're now calling the Evil Maid attack, and in which case that approach required reading out the LPAndroid.xml content, which did not require a root exploit. But not on each Android version. So only on some was this possible. The second approach did require a root exploit, which exists for various types of Androids, depending upon version.
So it wasn't, again, so I wouldn't call that easy. That required either physical access or a root exploit that then allowed you to get it. But even so, LastPass could have done better. And before this was made public, actually quite some time ago, this got fixed. And so I only looked at that level of detail at LastPass. But I've got all the links in the show notes for anyone who might be using - for example, I know 1Password was also popular. They had a similar - there were three problems that all sort of circled around this for LastPass, three different discrete vulnerabilities. I think 1Password had the same. And again, they were all fixed.
So I just say props to these guys for taking a careful close look at these. And it really looks like what we're seeing is examples where the manufacturers do what they think is, you know, they're trying to implement the best security they can, while also keeping their devices sufficiently easy to use. And even so, a third party is still super useful to, essentially, to challenge those assumptions and say, okay, this could be better over here; and then for the original developer to say, uh, yeah, you're right.
And of course I have the perspective of being working on SQRL. And so whenever I see any of these things, I challenge myself, too. I go, okay, wait a minute. How have I handled that? And because I have some of the same sorts of tradeoffs that, for example, in my implementation of SQRL, although this is not part of the protocol, this is part of the how you should do it right, I have handled all of this in a way both with entropy, harvesting, and solving the problem of needing something very complex as a get-out-of-jail-free card that we call a “rescue code,” yet needing something interactively simple; yet at the same time not leaving debris around where, if someone got a snapshot of it, they would get any substantial benefit. So, I mean, these are hard problems to solve, and all you can do is the best possible. In some cases, what is being seen is that manufacturers or software developers have not done everything they possible could.
We discussed a few months ago a file-free malware that was - in fact, it was Kaspersky who actually discovered this in their servers, which their scanners weren't finding because they were scanning the hard drive. They were not looking in RAM. And so they discovered a RAM-resident malware, which was the first time that we had seen that. Well, we've now found another one. Cisco's Talos security research group discovered a new and relatively sophisticated attack which launches from an email-phishing malicious Word document and successfully executes a Windows PowerShell backdoor by communicating with command-and-control servers through a series of - get this - DNS requests.
So we know about DNS. You ask for a machine dot domain name, and you receive whatever is in this DNS record. But you're able to ask, for example, you could do a forward lookup, that is, give me the IP address of this machine and domain. Or you could do a reverse-lookup. You can also ask for other kinds of records, rather than just an address record. And in this case the system uses text records, TXT records, which is another type of thing you can store in the database. And they're increasingly used for various things. The SPF, Sender Provider Framework, which is used as an antispam system, uses DNS TXT records. So whereas originally they were rare, they're becoming quite common now.
So Cisco's dump of this work that they did was called “Covert Channels and Poor Decisions: The Tale of [what they're calling] DNSMessenger.” And they go through it in detail. I won't take us all through it. I do have a lot more detail in the show notes. But essentially they're using a VB script that runs from Word, which a user is tricked into opening, in order to use PowerShell, which Microsoft has continued to make more and more powerful and capable. Basically, it's full scripting of Windows admin tasks. Anything you could imagine wanting to do, you can now do in PowerShell. It's multilevel, hierarchical, object-oriented, insanely powerful.
And what's tricky about this is that this avoids antivirus. It gets past currently the majority of AV because they're not looking for this. And it uses DNS, which has generally been regarded as safe. And the malicious content is obtained over the 'Net, through DNS TXT records. So there's nothing malicious in the code that just sort of benignly says, oh, go fetch me a TXT record at this domain. So that's something you can easily do from PowerShell. Unfortunately, what it receives is a blob which, when decrypted, does become malicious. And it turns out that there is a way, then, using PowerShell, to create persistence through the registry because you're able to create a backdoor using Windows Management Instrumentation, the WMI database. So that allows you to create something persistent which can survive across reboots. So no actual files written by the malware; yet, once this thing gets into your system, if you make the mistake of opening the document, your system can be infected just over DNS. Wow. The bad guys are clever.
LEO: But reboot would fix it; right?
STEVE: No, it survives reboot.
LEO: Well, that's not nice.
STEVE: No. No. No, and it's…
LEO: So it must write something out. How does it survive reboot?
STEVE: It's in the registry. It uses the Windows Management Instrumentation.
LEO: Ah. So it doesn't have a file, but it does store itself on the file system.
STEVE: Correct. Ultimately it does, right.
LEO: Well, they're just getting so clever. I've seen - but that's what Mirai was. It was RAM-based only; right? Because if you rebooted the router, Mirai was wiped.
STEVE: Yes. So Chrome has further tightened up its security on macOS, actually bringing it to parity with some features that already existed in Chrome for Windows. Chrome has their safe browsing initiative. In this case it's broadening its protection of macOS devices, enabling safer browsing experiences by removing defenses against unwanted software and malware which targets macOS. So as a result, now and in future, macOS users using Chrome will start to see more warnings as they navigate to dangerous sites or download dangerous files.
As part of this next step towards reducing macOS-specific malware and unwanted software, which we've begun to see a little bit of, safe browsing is focusing on two common abuses of browsing experiences: unwanted ad injection, and manipulation of Chrome's user settings, specifically the start page, the home page, and the default search engine. Of course, Windows users have fought with changes to their browser for a long time. Google feels and believes users deserve full control of their browsing experience, and unwanted software policy violations hurt that experience.
So what they've done is they've created an API to give extensions control of the Chrome settings, yet to not allow this to happen behind the scenes. So confirmation boxes have been added that users will start seeing to essentially confirm and prompt to allow changes to be made where those things previously could just be made behind the scenes. And that will - actually, it's not already. I misspoke. It's starting with March 31st. So the end of this month, Chrome and safe browsing will warn users about software that attempts to modify Chrome settings without permission of the user. So that's, again, sort of marching forward a little bit to make sure that not too much changes at once, and people are not inconvenienced.
And similarly, from Mozilla on the Firefox front, they have moved their Containers from their very early testing over to the Test Pilot versions. About a year ago, last summer, Tanvi Vyas, who is a security engineer, posted about contextual identities on the web. And what she wrote was perfect as sort of to give us an understanding of what they're talking about, what these Containers are.
She wrote: “The Containers feature in Firefox Nightly enables users to log into multiple accounts” - okay. So users log in to multiple, like, Internet web accounts - “on the same site simultaneously and gives users the ability to segregate site data for improved privacy and security.”
She writes: “We all portray different characteristics of ourselves in different situations. The way I speak with my son is much different than the way I communicate with my coworkers. The things I tell my friends are different from what I tell my parents. I'm much more guarded when withdrawing money from the bank than I am when shopping at the grocery store. I have the ability to use multiple identities in multiple contexts. But when I use the web, I can't do that very well. There is no easy way to segregate my identities such that my browsing behavior while shopping for toddler clothes doesn't cross over to my browser behavior while working. The Containers feature I'm about to describe attempts to solve this problem: empowering Firefox to help segregate online identities in the same way I can segregate my real life identities.
“With Containers, users can open tabs in multiple different contexts: the personal context, the work context, the banking context, and the shopping context. Each context has a fully segregated cookie jar, meaning that the cookies, indexedDB, localStorage, and cache that sites have access to in the Work Container are completely different” - disjoint, separate - “than they are in the Personal Container. That means that the user can log into their work Twitter account on Twitter.com in their Work Container, and also log into their personal Twitter on Twitter.com in their Personal Container. The user can use both accounts side-by-side in tabs, simultaneously. The user won't need to use multiple browsers, an account switcher, or constantly log in and out to switch between accounts on the same domain.
“Note that the inability to efficiently use contextual identities on the web has been discussed for many years. The hard part about this problem is figuring out the right user experience and answering questions like: How will users know what context they are operating in? What if the user makes a mistake and uses the wrong context? Can the user recover? Can the browser assist by automatically assigning websites to Containers so that users don't have to manually manage their identities by themselves? What heuristics should the browser use for such assignments?
“We don't have answers to all of these questions yet, but hope to start uncovering some of them with user research and feedback. The Containers implementation in Nightly Firefox is a basic implementation that allows the user to manage identities with a minimal user interface.”
So, and here is where I loved what they did. “What is the security model provided by Containers?” And this is actually in a recent post, in the last couple days, where this was part of the Test Pilot. They wrote: “The security enhancements of Containers in Nightly and Test Pilot is common across both versions and are based on a modification to the browser's Same-Origin Policy (SOP).” Okay, now, as we know on the podcast, the Same-Origin Policy, which we talk about often because it's such, I mean, you could argue it's the most crucial security operational guarantee that browsers enforce. Which ensures that documents and data, and that includes queries made by script running on a page from distinct origins, meaning like domains, are isolated from each other. It is a critical browser security mechanism, as we know, that prevents content from one site from being read or altered by another, potentially malicious, site.