Perpetual IT

Hi, everyone – for S3 Ep8, we’ve gone live a day early to take into account the US Thanksgiving holiday on Thursday. (Followed, of course, by Black Friday, so if you’re splashing out online, please take care out there!)

This week, we talk to hacker and vulnerability disclosure pioneer, Katie Moussouris.

Join us for a fascinating episode with Katie about her journey, the bugs in bug bounty programs, and the people who inspired her along the way.

Interviewer: Kimberly Truong.
Special guest: Katie Moussouris (@k8em0 on Twitter), Founder and CEO of Luta Security.

Intro and outro music: Edith Mudge.

---

WHERE TO FIND THE PODCAST ONLINE

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher, Overcast and anywhere that good podcasts are found.

Or just drop the URL of our RSS feed into your favourite podcatcher software.

If you have any questions that you’d like us to answer on the podcast, you can contact us at tips@sophos.com, or simply leave us a comment below.

Thanks to Bill Kearney of Sophos Rapid Response for his work on this article.

If you’ve read the recent Sophos 2021 Threat Report, you’ll know that we deliberately included a section about all the malware out there that isn’t ransomware.

Sure, ransomware understandably hogs the media headlines these days, but cybercriminality goes way beyond ransomware attacks.

Indeed, as we’ve noted before, many ransomware incidents happen due to other malware that infiltrated your network first and brought in the ransomware later on.

In fact, many network intrusions don’t involve malware at all, because cybercriminals have plenty of other ways of bleeding money out of your users, your company, or both.

Here’s an example that the Sophos Rapid Response team came across recently – a opportunistic network intrusion that was much less sophisticated than a typical ransomware or data stealing attack, but dangerous and disconcerting nevertheless.

Worse still for the employees of the business, these crooks weren’t specifically after the company as a whole, but seemed to attack the network simply because it represented a convenient way of hacking away at lots of individuals at the same time.

Very simply put, the crooks were after as many accounts as they could access to buy as many gift cards as they could as quickly as possible.

As you probably know, gift cards that you purchase online are typically delivered by email to a recipient of your choosing as a secret code and a registration link.

So, receiving a gift card code is a bit like getting hold of the number, expiry date and security code from a prepaid credit card – loosely speaking, whoever has the code can spend it.

Although gift cards are meant to be used by the intended recipient only – they’re not supposed to be transferable – there’s not much to stop the recipient allowing someone else to use them if they choose, and that means they can be sold on the cybercrime underweb.

And for all that a $200 gift voucher, sold illegally online for, say, half its face value, doesn’t sound like much…

…crooks with access to a whole company’s worth of users – in this story, the company’s VPN supported about 200 people – can try to acquire not just one but potentially hundreds of pre-paid gift cards in short order.

The criminals in this case didn’t care whether the victims left out of pocket were the individual employees, the company itself, or both.

Rumbled and repelled

The good news here is that the crooks only got as far as spending $800 of other people’s money before the Rapid Response team were able to kick them out of the network, and as far as we know, the fraudulent purchases were detected and reversed in time so that no one ended up out of pocket.

As you’ll see, the main reason that the crooks were rumbled and repelled early was because a sysadmin at the affected company acted as soon as they spotted that something was wrong.

If you watched last week’s Naked Security Live video, entitled “Beat the Threat“, you’ll know that in our tips at the end of the video, we said:

Any tipoff you can get that suggests a crook might be in your network is a tip worth looking at. [… Just] because you are looking at something that […] you can’t quite justify, but that you saw before and it was OK last time – don’t assume it’s OK this time. […] That’s a bit like hearing your smoke alarm going off in the kitchen and thinking, ‘You know what, last time it was steam from the kettle that triggered it by mistake, so I’m just going to assume that’s what’s happening [again].’ This time, it could be something on the stovetop that’s already set on fire.

For all that we’re proud that the Sophos Rapid Response team was able to react quickly and deal with the attack, the vital part was that the victim triggered a proper response quickly in the first place.

How it happened

These crooks didn’t have time to clean up after themselves – or perhaps they weren’t intending to anyway – but as far as we can tell, the attack unfolded simply and quickly.

We can’t be sure exactly how the crooks got in to start with, but what we do know is:

• The victim’s VPN server hadn’t been patched for several months. This alone might have been enough to let the crooks break in – a exploit existed for the old version that could, in theory, have allowed the crooks to sneak into network.
• The VPN server had not been set up to require 2FA. This means that a successful password phished from a single user might have been enough to give them their beachhead. (Despite the unpatched vulnerability, we suspect this is how the attackers broke in this time.)
• Once “inside” the VPN, the crooks were able to use RDP internally to jump from computer to computer. This meant they could open up web browsers on user’s computers and see which online accounts they’d not logged out of, including their personal email accounts (e.g. Gmail and Outlook.com). Make sure you secure RDP as sturdily from inside your network as from outside.
• The crooks used individual email accounts to do a raft of password resets. On computers where the crooks could access email accounts due to cached credentials, but couldn’t get into other interesting accounts because the user was logged out of those, they did password resets via the email account. The accounts that the crooks went after included Best Buy, Facebook, Google Pay, PayPal, Venmo and Walmart.

Fortunately, it seems that only a few of the users attacked in this way had saved their credit card details for automatic re-use when making purchases, which is probably why the crooks only managed a few hundred dollars of gift card purchases before being spotted.

Apparently, numerous users who needed to re-reset their altered passwords to get back into their accounts noticed that there were gift cards queued up for purchase in their online shopping carts, but that the crooks had not been able to finalise those purchases.

(We can’t tell whether the crooks left the unsuccessful purchases behind because they were caught before they could clean up, because they hoped that they’d be overlooked and purchased by mistake by the legitimate account holder later on, or because they were focused on speed and didn’t care what happened afterwards.)

But there’s more

As with many attacks, this one didn’t have just a single purpose, although getting hold of “money for sale” seems to have been the primary motivator here.

The crooks also downloaded and installed a popular free file search tool to help them look for interesting files across the network.

This tool left behind a logfile that reveals that the criminals were actively hunting for personal and confidential data relating to both the company and to its staff.

We don’t know how much the criminals were able to acquire from the files they were hunting for, if anything, but we do know what they were interested in, which included:

• Bank statements relating to individuals and the business.
• Merchant agreements for accepting credit card payments.
• Credit card applications.
• Roster details for company drivers.

As far as we can tell, the file searching seems to have been a secondary interest to these criminals, who were but determined and persistent in their attempts to make fraudulent purchases against as many users of the network as they could.

Nevertheless, secondary interest or not, the crooks weren’t after gift cards only.

After all, personal and corporate data that’s supposed to be private also has value on the cybercrime underground – not just for resale to other criminals, but as a vehicle for helping further criminal activity.

Rapid reaction pays off

Fortunately, these crooks seem to have got bogged down early on in their attack.

Presumably frustrated because they couldn’t get into as many user’s email accounts as they wanted, they reset passwords on various company-related accounts to extend their access.

That had the side-effect of locking users, including one of the sysadmins, out of various company systems…

…and the sysadmin didn’t just remedy the immediate problem in order to fix the what , but also triggered a response to find out the why.

That reaction very quickly led to the crooks getting kicked out of the network.

As we said above, any tipoff is a good tipoff!

What to do?

The speed and determination of these crooks, speculatively logging into email account after email account, is an excellent reminder of why defence in depth is important.

All of these tips would have helped here:

• Patch early, patch often. The vulnerable VPN mentioned in this article probably wasn’t the way the crooks got access in this case, but it was a possible inward path anyway. Why be behind the crooks when you could be ahead instead?
• Use 2FA wherever you can. A second factor of authentication for both the external VPN and the internal RDP servers might have been enough on its own to keep these crooks out.
• Log out from accounts when you aren’t using them. Yes, it’s a hassle to log back into accounts every time you need to use them, but combined with 2FA it makes it much harder for crooks to take advantage of you if they get access to your browser.
• Rethink which websites you allow to keep payment card data online for next time. Companies that hold payment card details only for specific purchases, such as paying a utility bill, are a much lower risk than online services via which your card can be used to pay for almost anything, especially for items than are “delivered” immediately via email.
• Don’t block malware alone with your threat protection product. Block potentially unwanted applications (PUAs) and hacking tools too. Cybercriminals are increasingly turning to legitimate cybersecurity and network management software that you already have on your system, instead of using malware – a technique that’s called “living off the land” – in the hope of looking like sysadmins themselves. Catch them out if you can.
• Have somewhere for users to report security problems. If you’re locked out of your own account unexpectedly, make sure your reaction is not simply “I need to get back online” but also “I need to find the underlying cause.” An easily remembered email address or company phone number for cybersecurity reports can help you make your whole company into eyes and ears for the IT security team.
• Keep your users alert to the latest trends in phishing. Consider an anti-phish training product such as Sophos Phish Threat. We can’t yet be sure, but it looks as though a single phished password might have been how the crooks got started in this attacks.
• Don’t get sidetracked by specific threats such as ransomware. Ransomware-specific tools are useful as part of a defence in depth approach, but wouldn’t have stopped this attack on their own. However, a holistic approach that would have blocked these crooks would very likely have stopped the majority of ransomware attacks, too.
  

  ---

Did you know you can join us for a live cybersecurity lecture every Friday?

Just keep an eye on the @NakedSecurity Twitter feed or check our Facebook page on Fridays to find out the time we’ll be on air – it’s usually somewhere between 18:00 and 19:00 UK time, which is late morning/early afternoon on the West/East coast of North America.

(Note that you don’t need a Facebook account to watch our live streams, but you will need to login if you want to ask questions or post comments.)

We also upload the videos to our YouTube channel – here’s our latest video on mobile privacy:

[embedded content]

(Watch directly on YouTube if the video won’t play here.)

Thanks for watching… hope to see you online later this week!

---

Modern telephony is full of anachronisms.

For example, we still “dial” calls, and many phone apps still display the word “dialling” while they’re waiting for the person at the other end to pick up.

But when was the last time you saw, let alone used, a phone that actually had a dial?

And we still use idioms such as “ringing off the hook” to describe a day where we never seem to stop receiving calls, even though household phones haven’t actually had hooks since about 1912 and you’d probably have to go to a museum to see one.

Hooks weren’t a necessary part of the early telephone system, of course – in the exchange, calls were switched using jack plugs – but a gravity-operated switch that activated when the receiver was replaced or removed was a clever user interface choice.

You needed somewhere to store the receiver when you were no longer using it at the end of a call, so providing a place to hang it up that simultaneously disconnected the receiver from the circuit was a smart design decision – on the hook automatically meant out of circuit.

Actually disconnecting the receiver electrically from the circuit when not in use was important. On a single line connection, leaving the receiver off-hook prevented the circuit being used by anyone else, and therefore tied up a line in the exchange. On a party line, where several homes were wired to a single connection, if too many households had their phones off the hook (i.e. in the circuit) at the same time, the additional electrical load on the shared circuit would prevent everyone’s ringers working and the exchange would not be able to put calls through to anyone.

Who’s listening?

As you probably know, mobile voice messaging doesn’t rely on this “circuit switched” approach any more.

When you make a Messenger call, for example, the app on your device – which could be a mobile phone, a laptop or even something like a smart TV – asks the Messenger cloud to locate the recipient’s device, and the apps at each end start negotiating to set up a call.

Once the call is accepted by the recipient – typically after the app has played a ringtone, popped up a message or both, and the recipient has opted in to the call – then the apps start exchanging network packets of audio data.

The app at each end samples audio data from its own microphone and sends it off in chunks to the other end; at the same time it takes the audio chunks received from the other end, stitches them back together and plays them out of its own headset or speaker.

If the network is slow or unreliable, the app typically won’t drop the call, but will do its best to carry on anyway, either by leaving silent gaps in the audio, or by guessing in the case of short outages (that’s typically what is happening on an internet voice call when you hear a sound rrrrrrrepee-ee-ee-eated unnaturally), or by falling back to lower, scratchier quality.

In other words, there is no actual circuit that gets switched on or off between two internet phones, like there is between two old-school landlines connected to the same exchange.

Likewise, if the app has a mute button, it doesn’t work by disconnecting the microphone in your device electrically.

The apps at each end decide, based on data sent and received in chunks over the network, when to initiate a connection with a view to establishing a call; when to ring to signal an incoming call; when it’s OK to start recording and relaying sound; when to mute the call; and when to stop exchanging data and therefore “hang up” the call and to disconnect the virtual voice circuit.

As you can probably imagine, there’s a lot that can go wrong here.

For example, a malicious voice app could deliberately record and transmit sound while purposefully pretending that it wasn’t, such as while waiting for you to start dialling.

Or a legitimate but buggy app might start transmitting sound before you expected it to, innocently but no less leakily.

After all, there’s no receiver to take off any hook, and no physical switch that literally wires you into a dedicated electrical circuit connected to the other end.

Indeed, while the call is ringing, the apps at each end are already communicating with one other, so they are technically capable of exchanging voice data at that point.

You’re just assuming that neither end will start transmitting until both ends have exchanged and acknowledged control messages to confirm that each party has agreed to the call.

Typically, the caller agrees to the call implicitly and proactively by “dialling” it in the first place; and the recipient agrees to the call explicitly and reactively by tapping [Answer] (or by clicking an icon showing an imaginary receiver being lifted from an imaginary hook).

Until that point, both parties have to assume that the apps at each end are in “no mutual call consent yet” mode and are therefore neither collecting nor transmitting any audio data.

What if there’s a bug?

But what if there’s a bug?

What if a voice call app were to assume consent from both ends too soon?

Unfortunately, a bug of that sort was just fixed by Facebook in its Messenger app on Android.

The bug was found about a month ago and responsibly disclosed by Google’s Project Zero.

The flaw was revealed by Google this week after Facebook had fixed and updated the vulnerability.

To be quite clear: there is no suggestion that this was anything other than a software bug; it seems that the bug was known only to Google and Facebook while it was being fixed; and there is no evidence that the flaw has ever been exploited or even known to attackers in real life.

In other words, this isn’t a zero day hole, where the crooks found it first, and so if you make sure you already have the latest version of Messenger on your Android, you should be ahead of any cybercriminals out there who might be scrambling to figure out the bug now.

We don’t know which older versions of the app were vulnerable, but the date on which Google opened up its bug report to the public coincides with the publication of the latest version [at 2020-11-20T15:00Z], which appears to be numbered 291.0.0.20.114, released 2020-11-17.

Google’s original bug report included PoC (proof of concept) code to demonstrate that the bug could be exploited, which Google stated as working on version 284.0.0.16.119 of the app.

How the bug worked

Greatly simplified, the bug involves an attacker sneaking through an unexpected, additional control message to the app on your phone while the call is still ringing at your end.

This control message essentially says “user has consented to the call”, thus tricking the app on your phone into thinking you have answered the call before you do (or even if you don’t).

In other words, the bug effectively allows the caller to pretend that you have clicked to accept the call while your phone’s display is still asking you if you want to accept it.

So, in those fateful few seconds while you are looking at your phone and deciding whether to accept the call – and who hasn’t let slip a few choice words to brace themselves before talking to a fearsome aunt or confronting a former friend? – you might already be coming through loud and clear at the other end.

The good news, as far as we can make out from Google’s report, is that:

• The bug can’t be triggered invisibly or arbitrarily. An attacker has to try to call you, and would only get a “sneak preview” of what you might say while the call is ringing at your end. So we don’t think this trick could easily be used for long-term surveillance or eavesdropping.
• The PoC exploit requires you to be logged into Facebook in your browser at the same time as the app announces the incoming call. If you are in the habit of logging off in your browser when you aren’t using an account, or if you use Facebook only on your phone, it sounds as though this bug would be difficult or impossible to use against you.

Nevertheless…

…patch early, patch often, eh?

(And if in doubt, don’t blurt it out!)

---

In this episode: we say thanks to companies that refuse to pay ransomware hush money, dig into the new Sophos 2021 Threat Report, and take a quick look inside a malicious Linux kernel driver. Also, a sneak preview of our upcoming podcast interview with bug bounty pioneer Katie Moussouris.

With Kimberly Truong, Doug Aamoth and Paul Ducklin.

Intro and outro music: Edith Mudge.

---

WHERE TO FIND THE PODCAST ONLINE

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher, Overcast and anywhere that good podcasts are found.

Or just drop the URL of our RSS feed into your favourite podcatcher software.

If you have any questions that you’d like us to answer on the podcast, you can contact us at tips@sophos.com, or simply leave us a comment below.