The CyberWire Daily Podcast 6.28.22
Ep 1608 | 6.28.22

DDoS threat to Lithuania continues. Hacktivists hit Iranian steel mill. Bumblebee loader takes C2C markteshare. CISA adds Known Exploited Vulnerabilities. Music piracy. Where do spies go?

Transcript

Dave Bittner: Distributed denial-of-service attacks against Lithuania. The Dark Crystal RAT is described. Iranian steel mill suspends production due to cyberattack. Bumblebee rising. CISA adds to its Known Exploited Vulnerabilities Catalog. Music pirate sites are brought down by U.S. and Brazilian authorities. Joe Carrigan looks at Apple's private access tokens. Mr. Security Answer Person John Pescatore drops some SBOMs. And where do Russian intelligence officers go after they've been PNGed?

Dave Bittner: From the CyberWire studios at DataTribe, I'm Dave Bittner with your CyberWire summary for Tuesday, June 28, 2022. 

Distributed denial-of-service attacks against Lithuania.

Dave Bittner: Lithuania has said that the distributed denial-of-service attacks it's sustaining probably originate with Russia, SecurityWeek reportsAccording to CNN, the nominally hacktivist outfit Killnet has now claimed responsibility. Lithuania's National Cyber Security Centre said it is highly probable that such or even more intense attacks will continue into the coming days, especially against the communications, energy and financial sectors. Lithuania is attracting Russian attention because of its refusal to allow prohibited goods to be shipped over its rail lines to Russia's non-contiguous region of Kaliningrad, an enclave surrounded by Lithuanian and Polish territory. 

Dave Bittner: Flashpoint, which has been following Killnet and related pro-Russian chatter, finds that chatter to be notably aggressive. They say Flashpoint has identified chatter on various pro-Russian telegram channels, claiming that the current standoff between Russia and Lithuania could escalate to a full-fledged military confrontation, although no evidence of physical violence is yet to take place between Russia and Lithuania as of this publishing. 

Dark Crystal RAT described.

Dave Bittner: CERT-UA earlier this month warned that Windows systems in Ukraine were under attack by Russian operators deploying the Dark Crystal RAT. Fortinet's Fortiguard Labs yesterday issued a description of how DCRat is being used. While the precise infection vector is unknown, it's believed to be a form of phishing. The payload is carried in malicious macros the victim is induced to run. The typical use to which DCRat is put has been data theft, but it also establishes persistence in victims' systems and can be used to stage a broad range of other attacks. The report concludes the RAT can be customized to the attacker's needs by adding plugins. As the RAT primarily focuses on data exfiltration, stolen data will likely be used as a stepping stone for further activities against affected organizations. It can also lead to further damage, such as a threat actor maintaining persistence in the long term, stealing personally identifiable information and confidential data. Targets of this attack are likely in Ukraine. Having a foothold in the compromised Ukrainian organization goes a long way toward inflicting long-term and unthinkable damage due to the nature of this malware. 

Iranian steel mill suspends production due to cyberattack. 

Dave Bittner: A cyberattack has struck one of Iran's major steel companies on Monday, forcing it to halt production, SecurityWeek reports. The attack struck the state-owned Khuzestan Steel Company and two other major steel producers. An anonymous hacking group, “Gonjeshke Darande” - which is predatory sparrow in the Jerusalem Post's translation - has claimed responsibility for the attack, saying that it was done to target the aggression of the Islamic Republic. The group shared alleged closed-circuit footage from the Khuzestan Steel Company in which a piece of heavy machinery on a steel billet production line malfunctioned and caused a fire. CEO of Khuzestan Steel Amin Ebrahimi said nothing of the footage and claimed the attack was thwarted, saying, fortunately, with time and awareness, the attack was unsuccessful, and noting that everything should return to normal by the end of Monday. Neither of the other steel producers targeted in the attack noted damage or production issues. 

Dave Bittner: Predatory Sparrow has been heard from before, CyberScoop observes, notably in 2021's wiper attacks against Iran's rail system, and Check Point has obtained samples from the most recent incident that link it to the earlier attack. Relatively little is known about the group beyond, that is, their self-presentation as hacktivists opposed to the Islamic Republic. 

Bumblebee rising. 

Dave Bittner: The Symantec Threat Hunter team, part of Broadcom Software, this morning released a report on the Bumblebee loader. The researchers characterize it as a recently developed malware loader and say that it has quickly become a key component in a wide range of cybercrime attacks and appears to have replaced a number of older loaders, which suggest that it is the work of established actors and that the transition to Bumblebee was preplanned. The rapidity with which Bumblebee has achieved a central position in criminal-to-criminal markets indicates not only the C2C market's relative efficiency but the extent to which it's come to resemble the functioning of legitimate markets. The Symantec Threat Hunter team concludes, Bumblebee's links to a number of high-profile ransomware operations suggest that it is now at the epicenter of the cybercrime ecosystem. Any organization that discovers a Bumblebee infection on its network should treat this incident with high priority since it could be the pathway to several dangerous ransomware threats. Their study includes a long set of indicators of compromise. 

CISA adds to its Known Exploited Vulnerabilities Catalog.

Dave Bittner: CISA yesterday added eight vulnerabilities to its Known Exploited Vulnerabilities Catalog. Five of the issues are with Apple products. The other three affect Google Chromium, Red Hat and Mitel. federal civilian executive branch agencies falling under Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities must address the eight issues by July 18, 2022. In each case, CISA tells its charges to apply updates per vendor instructions. While the private sector in the U.S. and elsewhere, of course, isn't bound by BOD 22-01, it's prudent for all organizations to take a close look and consider remediating these vulnerabilities. Full details are available in the catalog. 

Music pirate sites brought down by US and Brazilian authorities.

Dave Bittner: U.S. and Brazilian authorities have seized some 272 websites that had been used to illegally download copyrighted music. The domains of six of the pirate sites were in the U.S., but the vast majority - 266 of them - were Brazilian domains. Brazilian police collared six suspects in 30 search-and-seizure raids. 

Where do Russian intelligence officers go after they’ve been PNGed?

Dave Bittner: And finally, if you're a Russian spy - and to speak more precisely, an intelligence officer - where'd you rather work - in the GRU's Aquarium back home, for example, or maybe someplace nice like Geneva? We're just spitballing here, but we're guessing that Geneva wins, hands down. Anyhoo, the AP reports that the Swiss Federal Intelligence Service in the annual report it issued yesterday has reached a similar conclusion. Russia's war against Ukraine has resulted in a number of Russian intelligence officers - officers operating under diplomatic cover - finding themselves expelled from their stations in Western countries. The Federal Intelligence Service urges those countries, and especially its own government, to take seriously the possibility that Russia would try to redeploy such operators against other Western targets. Not only is it sound counterintelligence practice to keep the bad guys out, but, the report observes, doing so could help ensure that Russian intelligence capabilities will be weakened with lasting effect. So read and heed, Western counterintelligence operators, and good hunting. 

Automated Voice #1: Mister. 

Automated Voice #2: Security. 

Automated Voice #3: Answer. 

Automated Voice #4: Person. 

Automated Voice #1: Mister. 

Automated Voice #2: Security. 

Automated Voice #3: Answer. 

 Automated Voice #4: Person. 

John Pescatore: This is John Pescatore, and welcome to ask Mr. Security Answer Person - short drilldowns at the timely security issues with a lot of hype busting. 

John Pescatore: Here's the question that came in for today. Hey, Mr. Security Answer Person, in one of your earlier segments, when asked about zero trust, you pointed out it was overhyped, saying it was mentioned 11 times in President Biden's 2021 cybersecurity executive order. Well, there was another term mentioned 11 times in that executive order - software bill of materials, or SBOM. My security team recently raised that as a critical initiative for us in software supply chain security, but our procurement of software folks say, no way, not feasible. What's the bottom line here? 

John Pescatore: OK. Here's the deal. Your security team is definitely right because events from Heartbleed to Log4j have hammered home the need for something like SBOM to solve a serious security problem. The procurement and app dev folks are looking at SBOM as something they don't need and something that would just cause them more work. These segments are too short to fully explain SBOM, but here's a quick background. You can do an internet search on SBOM-a-rama - I'm not kidding - if you want to dig in in detail. 

John Pescatore: In the old days, software applications were monolithic. Your dev team or a software vendor wrote and compiled every line of code into one big old executable. It was kind of like a restaurant that only served steaks. You knew you were getting beef and maybe a mysterious sprig of parsley. But with the rise of open-source code and modern modular software development methodologies, developers learned that they could find pieces of code or even entire libraries that they could reuse for boring, common functions, and they could focus on the fun parts of the application. It was kind of like the steak restaurant changed to being a salad bar. Your meal now had dozens of ingredients from many suppliers, just as modern applications often contain dozens of external code segments or libraries. 

John Pescatore: SBOM is kind of like one of those nutrition facts panels on the packaged food put on the side of the salad bar for each item. You could tell who provided those deviled eggs and maybe even how old they were. It would tell you if there'd been any E. coli recalls on any of the lettuces - no help if you don't read them, but for those who care, good information. We need this for supply chain security reasons. But think of all the work it would take for every salad bar to post those salad bar bills of materials and keep them accurate and up to date. That is where much of the pushback on SBOM comes from. This is critical, because for a bill of materials to be useful, it must document the ground truth of a piece of software and always be available for the latest release as well as all past releases, which seems like a lot of work to commercial and open-source developers, who often don't use secure development methodologies, which essentially already require that SBOM-like information be captured. 

John Pescatore: But there's a bigger issue. Most enterprises don't have accurate software inventories of the high-level software and apps they actually have in use. They're essentially lacking a meta SBOM, if you will. It's not uncommon for a vulnerability scan to show the configuration management database is only 80% complete. If the top of the supply chain - your organization - has rogue apps running, it will always have blind spots throughout the entire supply chain. This brings us back to good old, basic security hygiene. Sort of good news is that while there's a lot of forward movement around SBOM standards and implementations, it is unlikely to be ready for prime time before 2024. 

John Pescatore: So take advantage of the hype today, and pull on SBOM now to first raise your level of basic security hygiene around configuration management and software inventory, as well as addressing the issues of in-house development using open-source apps and libraries and production software and internal tools. Then begin your lobbying of the software and procurement organizations to begin requiring SBOM compliance from all software and cloud app vendors to be ready when SBOM is more fully baked. And by the way, practice saying SBOM three times fast before doing any management briefings on it to avoid accidentally using a nearly identically sounding term that may get you some odd looks. 

Automated Voice #1: Mister. 

Automated Voice #2: Security. 

Automated Voice #3: Answer. 

 Automated Voice #4: Person. 

John Pescatore: Thanks for listening. I'm John Pescatore, Mr. Security Answer Person. 

Automated Voice #1: Mister. 

Automated Voice #2: Security. 

Automated Voice #3: Answer. 

 Automated Voice #4: Person. 

Dave Bittner: Mr. Security Answer Person with John Pescatore airs the last Tuesday of each month right here on the CyberWire. Send your questions for Mr. Security Answer Person to questions@thecyberwire.com. 

Dave Bittner: And joining me once again is Joe Carrigan. He's from the Johns Hopkins University Information Security Institute and also my co-host over on the "Hacking Humans" podcast. Hello, Joe. 

Joe Carrigan: Hi, Dave. 

Dave Bittner: You know, over on "Hacking Humans," we talk a lot about authentication. 

Joe Carrigan: Yes. 

Dave Bittner: And one of the ways that we get authenticated online or at least prove our humanity... 

Joe Carrigan: Yes. 

Dave Bittner: ...Is through the use of CAPTCHAs. 

Joe Carrigan: CAPTCHAs. 

Dave Bittner: I'm going to quiz you here. Any idea what CAPTCHA stands for? 

Joe Carrigan: Actually, if you'd asked me this before I read this article, I'd have said nope. 

Dave Bittner: (Laughter). 

Joe Carrigan: But here's what CAPTCHA stands for - completely automated public Turing - and then test to tell - computers and humans apart. OK. So I have a problem with this right off the bat... 

Dave Bittner: OK. 

Joe Carrigan: ...With the idea of a CAPTCHA. First off, they suck. Everybody agrees. CAPTCHAs are awful. 

Dave Bittner: Yeah. 

Joe Carrigan: But a completely automated public Turing test - a Turing test is something that tests an AI to see whether it's a good enough AI. 

Dave Bittner: Yeah. 

Joe Carrigan: And if you can't tell the difference between AI and a human, the AI passes the test. 

Dave Bittner: Right. 

Joe Carrigan: So a CAPTCHA is - it seems to me like it's designed to fail if it's a Turing test. 

Dave Bittner: It's an upside down. 

Joe Carrigan: Right. 

Dave Bittner: Yeah. 

Joe Carrigan: Yeah, it's a backwards implementation of it. And we've seen all kinds of AI coming after these CAPTCHAs. 

Dave Bittner: Sure. 

Joe Carrigan: And there's even the old robot clicking the button that says I'm not a robot. 

Dave Bittner: Yeah. 

Joe Carrigan: You seen that? That's pretty funny. 

Dave Bittner: Well, this article is from AppleInsider. It's written by Andrew Orr. 

Joe Carrigan: It is. 

Dave Bittner: And it's about some stuff that came out of Apple's recently developer conference. 

Joe Carrigan: Right. There's a lot to cover here. 

Dave Bittner: They're talking about Private Access Tokens hoping to replace CAPTCHAs. What's going on here, Joe? 

Joe Carrigan: The problem with validating that you're dealing with a human is a real problem on the web because there are tons of automated ways to go through a web interface and just stuff credentials or do whatever you want to do. So CAPTCHAs are the best option we have right now until this thing came out from Apple. Here's how it works. First, this is something that's transparent to the user. It's - so it's low friction. 

Dave Bittner: Yeah. 

Joe Carrigan: And second, this is done in addition to existing authentication methods. 

Dave Bittner: OK. 

Joe Carrigan: So you'll still have, like, passwords and usernames and even multifactor authentication, but now you'll also have this Private Access Token, or this PAT. 

Dave Bittner: OK. 

Joe Carrigan: So the protocol relies on a trusted third party. And of course, in this case because it's Apple doing it, they're going to say it's us. 

Dave Bittner: OK. 

Joe Carrigan: So when the web server requests a PAT, the client device will contact an attestation server. 

Dave Bittner: OK. 

Joe Carrigan: Do a test that this is a real person. Right? The Apple implementation uses the trusted enclave - right? - the keys and certificates stored in there... 

Dave Bittner: Yeah. 

Joe Carrigan: ...And some state detection that's used on the hardware to detect if this is a valid request. And then it issues a token that it signs. 

Dave Bittner: OK. 

Joe Carrigan: Right? That token is then sent back to the web server, which validates Apple's signature on the token with one of their public keys. 

Dave Bittner: OK. 

Joe Carrigan: And then the user is granted access. OK? So it's essentially just Apple saying, yep, we think this is a real person. 

Dave Bittner: Right. 

Joe Carrigan: And we've gone through our workflow to do it. 

Dave Bittner: So in other words, I access my mobile device with, say, Face ID or Touch ID. 

Joe Carrigan: Correct. 

Dave Bittner: Apple says, hey, that's good enough for us. We're convinced this is a real human. So when this web thing checks in with Apple's technology, it says, yep, we've checked in on this person. We think it's real. Go for it. 

Joe Carrigan: Right. 

Dave Bittner: OK. 

Joe Carrigan: But the questions that aren't answered are, how did you check into it? 

Dave Bittner: Yeah. 

Joe Carrigan: Nope. Trust us. Right? And that - actually, that's good because the next point here is that there's a good bit of privacy design in this protocol. The web server only gets the signed token, the destination URL and the IP address of the device, which it always needs, right? 

Dave Bittner: Yeah. 

Joe Carrigan: So the only thing you're sending to the web server is the token. Now, the article breaks this down into a little more nuanced explanation where they talk about service providers like Cloudflare getting the token and then passing the URL off. 

Dave Bittner: Yeah. 

Joe Carrigan: But this could all be done by just a single website... 

Dave Bittner: OK. 

Joe Carrigan: ...You know, a web server. There's no reason to have a third party in there. You could have a third party in there. I mean, there may be valid business reasons. But for this protocol, there's no - it's not necessary. The attestation server only gets the data about the device necessary to generate a token, right? So Apple never sees what website you're going to. All they see is that you're requesting one of these tokens. 

Dave Bittner: I see. 

Joe Carrigan: And they don't care where you're going. Right? That's not their business. And they do a good - I would trust Apple. Apple tends to be pretty good with privacy and security. 

Dave Bittner: Yeah. 

Joe Carrigan: So one of the features of the protocol is that each token is unique. And this does two things. First, of course, it prevents a replay attack, right? 

Dave Bittner: Right, right. 

Joe Carrigan: Which is a cryptographic attack where bad guys just send the same information over and over again. And if you're not equipped to deal with a replay attack, your protocol doesn't have that in, you know, that resilience built in there, it's susceptible to that, and it's really easy to defeat your protocol. 

Dave Bittner: OK. 

Joe Carrigan: So each one's unique to prevent that from happening. Then, since every token must be generated by the attestation server - the server that it tests - it provides an opportunity to rate limit the requests, right? So now a malicious actor with a click farm can't send in 100 requests a second, right? 

Dave Bittner: I see. 

Joe Carrigan: The attestation server goes, no, no, no, we're not issuing tokens for you, right? And that's the hope of how this works. 

Dave Bittner: I see. 

Joe Carrigan: All right? So it's a pretty well-designed protocol and pretty good. Web servers' access through Safari and WebKit, which is the Apple web engine... 

Dave Bittner: Right. 

Joe Carrigan: ...Will work automatically with PATs. Other devices may not recognize the token process. So Apple cautions developers to make sure that authentication doesn't block the main webpage. So in other words, if you can't get a PAT, don't shut it down. 

Dave Bittner: Yeah. 

Joe Carrigan: Don't shut down the... 

Dave Bittner: Maybe... 

Joe Carrigan: ...The transaction. 

Dave Bittner: ...Fall back to a capture or... 

Joe Carrigan: Right. 

Dave Bittner: ...Something like that. 

Joe Carrigan: Fall back to a CAPTCHA. 

Dave Bittner: OK. 

Joe Carrigan: So one of my concerns, when I'm reading this, is it - is this something that Apple is going to keep to themselves as intellectual property and try to make privacy more of a differentiator in the marketplace for them, right? It seems no. The company is actually working to make private access tokens a web standard... 

Dave Bittner: Oh. 

Joe Carrigan: ...Which is nice... 

Dave Bittner: Yeah. 

Joe Carrigan: ...According to this article. But there is no mention of tokens working with Android or Windows, probably because they're not out there yet. But if everybody got on board with the standard or if, you know, if enough people got on board with the standard and the Internet Engineering Task Force adopted it as a standard... 

Dave Bittner: Yeah. 

Joe Carrigan: ...Then everybody could do it and there's no reason why Google or Windows or anybody else could do it. 

Dave Bittner: Could other organizations spin up their own attestation servers... 

Joe Carrigan: Sure. 

Dave Bittner: ...Theoretically? 

Joe Carrigan: Sure. 

Dave Bittner: Yeah. 

Joe Carrigan: If it's an open standard, absolutely. 

Dave Bittner: Yeah. 

Joe Carrigan: I have two concerns with this protocol. 

Dave Bittner: OK. 

Joe Carrigan: OK? And the first one is how you exploit it. And you exploit it very similarly to the way you exploit the root certificate authorities. You create a malicious attestation server that lets you go ahead and start issuing these things. Now, that's kind of easy to mitigate, right? Because you just say to - as the developer of a website or of a service like Cloudflare, you say, well, I'm not going - I don't know who that is, so I'm not going to accept attestations from them or tokens from them. 

Dave Bittner: (Laughter) Right. We're only going to... 

Joe Carrigan: Right. 

Dave Bittner: ...Accept attestations from servers that have been attested to (laughter). 

Joe Carrigan: Right. The servers that we trust, right? 

Dave Bittner: It's attestation all the way down, Joe (laughter). 

Joe Carrigan: Right. Exactly. And it comes to the same problem that the root certificate authorities come to, right? 

Dave Bittner: Right (laughter). 

Joe Carrigan: Who do you trust? 

Dave Bittner: Yeah. 

Joe Carrigan: That's the same problem. The other concern I have is that this might lead to a less open web because of that. Couple mitigations for that - one, you can always fall back to still using a CAPTCHA. 

Dave Bittner: Right. 

Joe Carrigan: Right? Or you could have a - an open foundation like the Mozilla Foundation or the Electronic Frontier Foundation become an attestation provider or token provider, right? So if that's who you use - let's say you run Linux, right? 

Dave Bittner: Yeah. 

Joe Carrigan: So you don't have a large company behind you like Apple or Microsoft or Google that develops your operating system. It's an open-source operating system. Well, OK. I'm going to use Mozilla's private access token service if Mozilla has enough money and funding to set one up, or the EFF has one. 

Dave Bittner: Right. 

Joe Carrigan: But it can be done. 

Dave Bittner: Yeah. 

Joe Carrigan: It can be done. I like this protocol. I'm pretty pleased with it. 

Dave Bittner: All right. Well, good to know. Thanks for explaining it to us. Joe Carrigan, thanks for joining us. 

Joe Carrigan: It's my pleasure. 

Dave Bittner: And that's the CyberWire. For links to all of today's stories, check out our daily briefing at thecyberwire.com. 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 technologies. Our amazing CyberWire team is Liz Irvin, Elliott Peltzman, Tre Hester, Brandon Karpf, Eliana White, Puru Prakash, Justin Sabie, Rachel Gelfand, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Gina Johnson, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Rick Howard, Peter Kilpe, and I'm Dave Bittner. Thanks for listening. We'll see you back here tomorrow.