The CyberWire Daily Podcast 5.28.19
Ep 852 | 5.28.19

Sensitive mortgage documents left exposed online. Someone’s scanning for BlueKeep RDP issues. Huawei updates. The case of Baltimore City’s ransomware.

Transcript

Dave Bittner: [00:00:03] First American Financial suffers a data exposure with hundreds of millions of mortgage-related documents left open to the internet. Someone is scanning Tor for signs of BlueKeep RDP vulnerabilities. China complains about U.S. complaints against Huawei as some major German firms rethink their dealings. And no, NSA did not hold Baltimore for ransom, but Baltimore wants Washington to pick up its remediation and recovery tab.

Dave Bittner: [00:00:36] And now a word from our sponsor, Carbon Black. When it comes to cybersecurity in 2019, traditional antivirus simply doesn't cut it. Carbon Black aims to keep the world, including you, safe from cyberattacks. Protect your endpoints with next-generation antivirus and endpoint detection and response all in one cloud-delivered platform. Simplify your security stack with a lightweight solution. Predict, prevent, analyze and operate at scale. CyberWire listeners can get a 15-day free trial of CB Defense, their EDR cloud-based solution. Don't let attackers scare you into submission. Take the stand with a safe and simplified solution. See the difference by visiting carbonblack.com/cyberwire-podcast. Again, that's carbonblack.com/cyberwire-podcast. And we thank Carbon Black for sponsoring our show.

Dave Bittner: [00:01:35] From the CyberWire studios at DataTribe, I'm Dave Bittner with your CyberWire summary for Tuesday, May 28, 2019. Krebs On Security broke the story late Friday that First American Financial left data pertaining to hundreds of millions of mortgages going back to 2003 exposed on the internet. Insurance Journal says First American attributed the issue to a design defect in an application and that it's working to fix the problem. It's unknown whether the exposed data have been exploited or misused, but they contain a great deal of sensitive personal information of great potential interest to criminals. First American Financial is involved in closing a great many real estate transactions, and in the course of those deals, it serves as a neutral third party. It collects Social Security numbers, account statements, internal business documents, driver's licenses and records of wire transfers. Eight hundred eighty-five million documents were exposed by the design defect.

Dave Bittner: [00:02:37] Security firm GreyNoise tells ZDNet that parties unknown were scanning Tor exit nodes over the weekend for signs of the BlueKeep vulnerability. This activity seems so far to be in the reconnaissance, as opposed to the attack phase, of a cyber operation. At least we've seen no reports of the scans leading to active exploitation yet. BlueKeep, which is CVE-2019-0708, affects the remote desktop protocol in older versions of Windows. 0patch is offering a micropatch for always-on servers and other systems, to which Microsoft's patch may be difficult to apply.

Dave Bittner: [00:03:16] China has denounced U.S. suspicions of Huawei as so much political posturing - a bunch of hoked-up scare stories designed to give team America the advantage in trade wars. But the U.S. concerns continue to have traction. According to Frankfurter Allgemeine, at least three major German firms - Siemens, SAP and Bosch - are reviewing their relationship with Huawei. Microsoft has also taken some steps toward distancing itself from Huawei, and China's People's Liberation Army has announced it's getting rid of Windows from its systems. And why? Because of the risk that the U.S. might be peeking through Windows to spy on China's secrets. Huawei itself received more unusually bad press over the weekend. The Wall Street Journal published a long account alleging that Huawei has long engaged in deliberated systematic theft of intellectual property from its partners and others.

Dave Bittner: [00:04:13] The RobbinHood ransomware that's afflicted Baltimore this month appears to have spread via the EternalBlue vulnerability. EternalBlue, distributed to the world by The Shadow Brokers in 2017, is widely believed to have been a zero-day flaw discovered and held for exploitation by NSA, hence the reporting in The New York Times and elsewhere that an NSA tool was used against Baltimore. There have even been some headlines who have suggested - and this is simply wrong and misleading - that NSA itself was attacking American cities, which, of course, NSA is not doing, nor is the ransomware itself an NSA tool, as Baltimore Mayor Jack Young insisted for a time before correcting himself. It isn't. Rather, it's a strain of ransomware that's being installed by exploiting the EternalBlue vulnerability in unpatched systems. And EternalBlue is, as we've said, generally believed to be a zero-day NSA discovered and held back on disclosing. The RobbinHood ransomware is now thought to arrived via a phishing email to a city employee. Whether this was targeted spear phishing or large-scale trawling that just hit it lucky isn't clear. Once the ransomware was in, however, it spread through systems that had not been patched against EternalBlue.

Dave Bittner: [00:05:31] Critics - and a lot of those working in cybersecurity are among the critics - point out that EternalBlue has not only been disclosed for two years, but that it's also been patched for two years. The vulnerability has been exploited to distribute other malware, notably WannaCry, before - neither EternalBlue nor its exploitation in high-profile cyberattacks nor the fact that Microsoft issued patches to fix it, including patches for Windows XP and Windows Vista. XP at the time was beyond the end of its support life, and Vista was fast approaching the same condition, so in some respects, Redmond's patching was a commendable act of supererogation. Should Baltimore have patched over the past two years?

Dave Bittner: [00:06:14] The city is asking for federal emergency relief funds to help mop up its ransomware disaster. The mayor and the city council are arguing, in effect, that this is NSA's mess and that Washington needs to step in and help clean it up. The squabble puts the Maryland congressional delegation in a bit of a bind. To take one example, Representative Dutch Ruppersberger, whose district includes both portions of Baltimore City and Fort Meade - home of NSA - has expressed shock that an NSA-discovered vulnerability should have found its way into the hands of bad actors and has called upon the agency to answer to Congress as to how this came about. It seems worth considering that the time for shock, if any, would probably have been back in 2017, and that Representative Ruppersberger is about as well informed about the U.S. intelligence community in general - and the National Security Agency in particular - as anyone in Congress. And a lot of constituents either work for NSA or in the cybersecurity industry.

Dave Bittner: [00:07:14] It's worth noting that what to do with zero-days, the intelligence community finds, is controlled by the Vulnerability Equities Process, an inter-agency procedure that decides what to disclose and when and to whom. There's always a degree of vagueness with assigning blame for negligence. It may be hard to draw a sharp line between day and night, but only the most obtuse member of a city council would deny the obvious difference at Charm City's latitude between 3 p.m. and midnight. With respect to patching and recovery planning, at city hall, it's probably around 10:30 p.m. Eastern Daylight Time. And yes, it can be tough to patch, but Baltimore's IT issues seem to run fairly deep. Ars Technica has a useful rundown of the high turnover among the city's IT leadership over the past several years. The publication reports, quote, "since 2012, four Baltimore City chief information officers have been fired or have resigned. Two left while under investigation" - end quote. It seems only fair to note that Baltimore did much better when hackers intruded into the city's networks back in March 2018. The city's 911 and 311 systems were out for about 17 hours, but the city reverted quickly to manual backups and had everything back to normal in less than a day. The contrast with the chaos produced in Atlanta by a SamSam ransomware attack at about the same time was striking. Atlanta was clobbered. Baltimore looked pretty good by contrast. Not so this time around.

Dave Bittner: [00:08:48] Now it's time for a few words from our sponsor, BlackBerry Cylance. They're the people who protect our own endpoints here at the CyberWire, and you might consider seeing what BlackBerry Cylance can do for you. You probably know all about legacy antivirus protection. It's very good as far as it goes, but you know what? The bad guys know all about it, too. It will stop the skids, but to keep the savvier hoods' hands off your endpoints, BlackBerry Cylance thinks you need something better. Check out the latest version of CylanceOPTICS. It turns every endpoint into its own security operations center. CylanceOPTICS deploys algorithms formed by machine learning to offer not only immediate protection but security that's quick enough to keep up with the threat by watching, learning and acting on systems' behavior and resources. Whether you're worried about advanced malware, commodity hacking or malicious insiders, CylanceOPTICS can help. Visit cylance.com to learn more. And we thank BlackBerry Cylance for sponsoring our show.

Dave Bittner: [00:09:58] And joining me once again is Malek Ben Salem. She's the senior R&D manager for security at Accenture Labs. Malek, it's great to have you back. You wanted to touch today on some stuff coming from NIST about transitioning crypto algorithms. What can you share with us today?

Malek Ben Salem: [00:10:15] Yeah. Last month, NIST published the second revision of this special publication, 800-131A, which looked at transitioning the use of cryptographic algorithms and key lengths. The first revision of this publication, which was published back in November 2015, is now withdrawn, and this publication - NIST provides some guidance on the recommended key management procedures, the recommended algorithms that protect sensitive information and how to plan for possible changes in the use of crypto algorithms, including the migration to new algorithms. This actually addresses possible use of new crypto analysis but also the increasing power of classical computing technology and the potential emergence of quantum computers.

Dave Bittner: [00:11:06] And so what are some of the key updates here with this version versus the one that it replaces?

Malek Ben Salem: [00:11:12] Yeah. The main change with respect to the previous version is the recommended security strength for crypto algorithms. It used to be 80 bits. Now NIST recommends a security strength of at least 112 bits for applying crypto protection to data, whether it's for encrypting data or for signing data. As I mentioned, you know, in previous episodes on CyberWire, we talked about the emergence of quantum computing and the threat that it brings to the way we protect our data today because it jeopardizes the strength of the underlying math that we use to - in crypto algorithms. You know, the way we encrypt data, which relies on public key infrastructure, is based on the intractability of the integer factorization and the discrete log problems, and that intractability may no longer be valid when we have quantum computers. So NIST is prepping for that, as well as for the advancements of classical computing technology, by asking businesses and, you know, federal agencies to increase the key lengths of the algorithms they use today so that a security strength of at least 112 bits is used.

Dave Bittner: [00:12:42] And is there any particular downside to this? Does this mean that there'll have to be more computing power thrown at these algorithms to make them work?

Malek Ben Salem: [00:12:52] That may be the case. There may be more computational power used to encrypt data. Obviously, the data that has been encrypted already will continue to be decrypted with the existing algorithms with the existing keys. That presents some risk that organizations need to be aware of, but, you know, that's part of, you know, going through this transition.

Dave Bittner: [00:13:16] And in terms of organizations plotting out their own use of encryption and deciding what sort of levels they should set it at - I mean, is this the type of thing where you take a risk-based approach, or is there generally a minimum level below which you should not even consider falling?

Malek Ben Salem: [00:13:34] Absolutely. They should take a risk-level approach. I think the current recommendation for 112 bits, in terms of security strength - that applies, obviously, for protecting highly sensitive data. For less sensitive data, you would take a risk-based approach and choose the right algorithm or the right security strength for your algorithm.

Dave Bittner: [00:13:57] All right. Well, it's interesting information. Malek Ben Salem, thanks for joining us.

Malek Ben Salem: [00:14:01] Thank you, Dave.

Dave Bittner: [00:14:06] And that's the CyberWire.

Dave Bittner: [00:14:08] Thanks to all of our sponsors for making the CyberWire possible, especially our supporting sponsor, ObserveIT, the leading insider threat management platform. Learn more at observeit.com.

Dave Bittner: [00:14:19] Don't forget to check out the "Grumpy Old Geeks" podcast, where I contribute to a regular segment called Security Ha. I join Jason and Brian on their show for a lively discussion of the latest security news every week. You can find "Grumpy Old Geeks" where all the fine podcasts are listed. And check out the "Recorded Future" podcast, which I also host. The subject there is threat intelligence, and every week, we talk to interesting people about timely cybersecurity topics. That's at recordedfuture.com/podcast.

Dave Bittner: [00:14:48] The CyberWire podcast is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technology. Our CyberWire editor is John Petrik, social media editor Jennifer Eiben, technical editor Chris Russell. Our staff writer is Tim Nodar, executive editor Peter Kilpe and I'm Dave Bittner. Thanks for listening.