Perpetual IT

Six alleged drug criminals will go free thanks to a ransomware attack on a small Florida city, it was revealed this month.

Stuart is a city in Florida with a population of around 16,500. It suffered an attack involving the Ryuk ransomware in April 2019 that took city servers offline. While reports said that city emergency services, including 911 calls, were unaffected, things were a little different behind the scenes. Detective Sergeant Mike Gerwan explained:

Because we didn’t have access to the internet we were sending police officers to calls blind.

The City refused to pay the $300,000 bitcoin ransom, and instead kept servers disconnected while it rebuilt its servers. At the time, city manager David Dyess said that the city’s data backups saved it from having to negotiate.

While Stuart might have saved some of its data, there were some casualties. Among them were case records that the Stuart police department was relying on for several prosecutions. It was unable to recover crucial evidence for narcotics cases involving 6 defendants facing a total of 28 charges.

The crimes included methamphetamine and cocaine possession, along with selling, manufacturing, and delivering narcotics. Another charge involved illegally using a two-way communication device, according to local station WPTV. Gerwan told reporters:

We lost approximately a year and a half of digital evidence. Photos, videos. Some of the cases have been dropped.

The attackers got into city systems via a spearphishing email, and lurked undetected in the network for two months before launching the Ryuk attack, Gerwan said:

We were totally crippled for the first month and a half. We all went home one day and the next day we came back to work and we were back in the year 1984. Back in 1984 if you wanted to look somebody up you had to find them in the phone book.

Electronic evidence destruction like this seems like a storyline straight out of a Breaking Bad script, but in this case, the ransomware criminals inadvertently did the defendants a favour. It’s a surprisingly common problem, according to Gerwan. He said:

I can’t recall when speaking to my federal partners, that there has been a case where data had not been lost.

Latest Naked Security podcast

Mozilla has said it plans to make a privacy technology called DNS-over-HTTPS (DoH) the default setting for US users of Firefox within weeks.

As our previous coverage explains, DoH encrypts Domain Name System (DNS) queries, which browsers use to resolve website addresses to their underlying numeric IP addresses.

Normally, these requests are sent in the clear, which means that ISPs and governments can see which web domains someone is visiting, which is where the privacy concerns begin.

In the US, ISPs have been accused of selling this data to advertisers. Although not a perfect shield against DNS snooping, DoH makes that a lot harder.

The technology’s been inside Firefox since mid-2018 although until now users had to enable it manually. In September 2019, Mozilla started testing DoH-by-default in the US – with that completed, from next month DoH will become a setting that users have to consciously opt to turn off.

Users can do this via Options > General > scroll down to Network Settings at the bottom of the page and then click Settings. The ‘Enable DNS over HTTPS’ tick box is the last one on the page.

Notice how buried this setting is? Having backed DoH development since its earliest days in 2017, Mozilla doesn’t want to make it easy to turn off something it thinks is against the user’s interests.

Just below the tick box, there’s a second setting that allows users to choose which trusted DNS resolver to use. Cloudflare, Mozilla’s long-time DoH collaborator, is the default but recently users gained the ability to choose a second, NextDNS.

Trusting DoH providers

This aspect has bothered some critics – using companies such as Cloudflare effectively centralises DNS resolution for the tens of millions of people who use Firefox.

It’s a weak argument. People already set alternative DNS resolvers for performance reasons (Google’s 8.8.8.8, for instance) so the idea of using one service provider is hardly new. And is the alternative of routing DNS queries through an ISP’s servers any less centralised?

From an internet topology perspective, perhaps. But browser users don’t care about that. What bothers them more is: Who is recording the websites they go to?

As Mozilla reminds us, currently in the US, 80% of traffic travels through the DNS servers of only five broadband providers. All that using Cloudflare or NextDNS requires is that users trust these companies’ promises to protect privacy in the same way they do for any service provider. It’s a personal choice.

What to do

There are currently no plans to turn on DoH by default outside the US, most likely to defuse criticism by government agencies that it will, in the short term, make it harder to keep tabs on illegal activity by citizens. Google, which also backs DoH, is experimenting more cautiously than Mozilla.

Similar arguments were once made about the risk posed by HTTPS security and, in the 1990s, the spread of encryption more generally. But anyone who is serious about evading web surveillance can already do that in several ways that are more effective than using DoH, for example using Tor or firing up a VPN.

For non-US users, DoH can be turned on using the same settings mentioned above.

The technology can also be configured with slightly more difficulty in rival browsers such as Chrome, Edge, Brave and Opera although not, so far, in Apple’s Safari. The technology is coming to Windows 10 at some point.

Latest Naked Security podcast

Just because YouTube is everywhere doesn’t make it the town square, a Seattle appeals court said on Wednesday. It’s neither a public forum nor a “state actor”, and it can’t be held to First Amendment court oversight as if it were a government body.

Thus did the 9th Circuit Court of Appeals in San Francisco dismiss a top right-wing content creator’s allegation that Google had violated its First Amendment rights by tagging dozens of its videos on abortion, gun rights, Islam and terrorism with its Restricted Mode and demonetizing them so the nonprofit can’t make money from advertising.

The suit was originally brought in 2017 by radio talk show host Dennis Prager, who runs the conservative, nonprofit educational company Prager University (PragerU). PragerU isn’t an actual university, and it doesn’t award certificates or degrees. It’s best known for its many 5-minute videos, some of which, starting in 2016, Google dubbed Restricted, including videos about the 10 Commandments, whether police were racist, and Israel’s legal founding.

The suit claimed that Google, with its outsize power to moderate user content on YouTube, was using that power to censor conservative viewpoints. Google’s content filters apply the Restricted Mode to material seen as unfit for minors, including videos that include alcohol abuse, sexual situations, violence, and other mature matters.

None of that applied to PragerU’s content, but dozens of its videos were still flagged for “objectionable content” by Google’s algorithm. After being flagged, the videos were then reviewed by humans, who often upheld the content restriction and, in addition, demonetized videos, making it tough for PragerU to leverage the platform for moneymaking opportunities by advertising.

Prager’s suit argued that Google’s opposition to conservative political views led to its content being flagged, in violation of First Amendment protection of free speech. That argument doesn’t fly, the appeals court said on Wednesday, given that YouTube isn’t a public forum:

PragerU’s claim that YouTube censored PragerU’s speech faces a formidable threshold hurdle: YouTube is a private entity. The Free Speech Clause of the First Amendment prohibits the government – not a private party – from abridging speech.

The appeals court also rejected PragerU’s claim that Google’s “braggadocio” about free speech constituted false advertising. Nope, that’s just opinion, the court said on Wednesday. Or, to be more precise, it’s marketing puff-speak:

Lofty but vague statements like ‘everyone deserves to have a voice’, and that the world is a better place when we listen, share and build community through our stories or that YouTube believes that ‘people should be able to speak freely, share opinions, foster open dialogue, and that creative freedom leads to new voices, formats and possibilities’ are classic, non-actionable opinions or puffery.

Farshad Shadloo, a Google spokesman, told Reuters that the company’s products “are not politically biased,” and the decision “vindicates important legal principles that allow us to provide different choices and settings to users.”

Donald Verrilli, a US solicitor general under President Barack Obama, wrote on behalf of the Computer & Communications Industry Association in support of Google and YouTube, saying in a legal brief that courts have consistently found private companies such as Google, YouTube and Facebook don’t qualify as state actors for First Amendment purposes.

Interpreting them otherwise would “change the internet” by threatening to make websites “chock-full of sexually explicit content, violent imagery, hate speech, and expression aimed at demeaning, disturbing, and distressing others”, he wrote.

Latest Naked Security podcast

Microsoft has a neat web page that helps you get Outlook set up on your phone.

You can either scan in a QR code off the web page, which takes you to the relevant download link…

…or put in your phone number and get an SMS with the link in it:

Just like Italian security researcher Luca Epifanio, our first thought was, “What if someone decides to put in someone else’s phone number and then spam them over and over and over again?”

That would be pretty darned bad – bad for the recipient, whose phone would be swamped with unwanted text messages, and bad for Microsoft, who would look like shabby and unreconstructed spammers.

(It might also end badly for the person who dishonestly triggered all the spam in the first place, if ever they were found by law enforcement or the regulators, but that is an issue for another day.)

We tested it against our own phone number, using various browsers from various countries (we used the Tor proxy so we emerged onto the internet from semi-random places), and were happy to notice, as did Luca Epifiano, that after three messages, that was that.

Microsoft’s website will accept the number a fourth, fifth, sixth time, and so on, but simply and quietly stops texting it once it’s received three messages. (We don’t know how long it takes for the block to be lifted, but it certainly stopped us spamming ourselves at will.)

Well, Luca wondered just how robust Microsoft’s “same number” detection might be, and whether it could easily be bypassed.

Using a locally-installed web proxy, he snooped on his own web traffic to see what the data looked like on the way from his browser to Microsoft.

To his surprise, he found that by replaying the original web request with a non-alphabetic character at the end, such as a star (*) or a plus (+), he’d get three more goes at texting the number.

Then he could pick another character and get three more goes, and so on, allowing him to bypass the three-message limit at high speed, just by churning out new HTTP requests with a tiny modification each time.

Only the digits matter in the phone number to which the message gets sent, but – as Luca suggested in an email he sent us – it looks as though Microsoft’s “number verification” check was done with the extraneous characters included.

In other words, the number wasn’t being trimmed to its simplest correct form (you’ll see this called canonicalisation in the jargon) before it was logged, tested and used.

As a result, numbers that were the same in practice appeared different in theory, allowing the rate limit to be bypassed.

This is a similar sort of problem to one that Google experienced back in 2017, when an adware app that falsely claimed to be from the vendor WhatsApp, Inc. was able to sneak past the Play Store validation checks simply by adding a space character to the company name.

Visually, you couldn’t tell the difference, so the new app looked legitimate, but programmatically the two company names were of different lengths and contained different characters – so the new app was not recognised as an imposter and was admitted anyway.

What to do?

The good news is that you don’t have to do anything – Luca reported this responsibly to Microsoft, who fixed the problem.

We tried adding redundant characters to our own phone number today, and were unable to send any messages after the third had gone through.

Luca also received a bug bounty payout, with the ultimate result that everyone ended up a winner.

We think that the lessons to learn are:

• Bug hunting isn’t just about machine code hacking and reverse engineering. You don’t need to crack open a debugger and a disassembler to do useful and productive cybersecurity work.
• Bugs can be deceptively simple. In this case, a single character that would typically be ignored was enough to bypass an important rate limit. If you’re a programmer, don’t forget to test for the obvious things as well as all those complex “corner cases” you need to deal with.
• Responsible bug reporting really works. If you find bugs, it’s tempting to make a big splash by disclosing them for shock value in a blaze of glory, but as Luca has shown here, you can do the right thing, help everyone else, and still get recognition – without turning security holes into nightmares.

Slickwraps, a Kansas company that makes vinyl wraps for phones and other electronics, announced last week that it had suffered a data breach.

This was no ordinary data breach. This was a breach that earned the deep scorn of both the hacker – who was twice blocked by Slickwraps for reporting the vulnerability – and observers after some other hacker went ahead and exploited the company’s vulnerable setup.

The Verge, for one, called the breach and the aftermath “comically bad”. One of the commenters on The Verge’s story, trost79muh, had this to say about when a company with garbage security meets a bug reporter with an attitude:

The whole thing on both sides was clownshoes, when an unpiercably large ego meets an unfathomably dense IT staff.

The initial hacker – who calls themselves a white-hat security researcher – isn’t coming out of this smelling like roses either. Slickwraps was given little time to follow up on their vulnerability report and they then proceeded to run amok getting and exploiting root and taunting the company instead of clearly explaining the vulnerability.

@Lynx0x00 @Medium @MediumSupport Read your article. It should remain down. You are not a white hat. You breached th… twitter.com/i/web/status/1…

—
Ian Rash (@redcodefinal) February 22, 2020

@Lynx0x00 @Medium @MediumSupport Not saying slickwrap is right, but you could have done better in “notifying” them… twitter.com/i/web/status/1…

—
吳禮翔 (@NoctNgu) February 22, 2020

The hacker who initially found Slickwraps’ vulnerability goes by the handle Lynx0x00. They recently posted an article to Medium (here’s the archived version) detailing how they pulled off the hack and how pathetic Slickwraps’ response was.

You can read the Medium post or The Verge’s writeup for all the gory details, but in essence, Hacker 1 –  Lynx0x00 – found a vulnerability on Slickwraps’ phone case customization page that would enable anyone with the right toolkit to upload “any file to any location in the highest directory on their server (i.e. the ‘web root’).”

From there, an attacker could get at current and former employees’ resumes (including their selfies, email addresses, home addresses, phone numbers and more) and backed-up customer photos (including porn), among many other things.

Then, Hacker 2 came along, read the Medium post, exploited the vulnerability, and gang-emailed 377,428 email addresses from the company’s records using the hacked email address hello@slickwraps.com. Some customers shared the hacked email on Twitter:

Well that’s a big old yikes from @SlickWraps https://t.co/28SOEMIBZ9

—
  (@Toneman) February 21, 2020

The responses to this breach are all over the map, but they generally fall into two camps: contempt for Slickwraps, and contempt for the way that Hacker 1 and Hacker 2 handled disclosure by breaching the company – not exactly “white hat” behavior, that. Here’s one such critique from Reddit’s r/hacking forum:

[All typos are sic] Theres just so much glaringly wrong with how this person went about this. This wasnt a “oh i found a vuln” this was an “i compromised their entire company, stole customer data and then failed to properly convey the severity”

tagging someone and telling them they failed a “vibe check” is a joke. no wonder noone at the company took the disclosure seriously. and then posting a complaint email and assuming the social media person would put 2 and 2 together that they have been compromised? also not the way to go about a breach report.

Last i checked a fairly common disclosure cycle is about 90 days, not the 7 this person gave them to figure out by vague twitter posts they had been compromised. If youre going to approach a company about your findings at least tell them you have something to disclose dont just tweet about “vibe checks” and then throw a hissy fit when they dont reply right away.

As far as the breached data goes, Slickwraps CEO Jonathan Endicott said in his announcement that the “Slickwraps Family” need not worry, as passwords and financial data are safe and weren’t involved in this breach.

The information did not contain passwords or personal financial data.

The information did contain names, user emails, addresses If you ever checked out as “GUEST” none of your information was compromised.

However, some commenters said that their information was compromised in spite of having registered only as guests on the site.

In their Medium post, Lynx0x00 said that they used the vulnerability to access an extensive list of sensitive information:

• All SlickWraps admin account details, including password hashes
• All current and historical SlickWraps customer billing addresses
• All current and historical SlickWraps customer shipping addresses
• All current and historical SlickWraps customer email addresses
• All current and historical SlickWraps customer phone numbers
• All current and historical SlickWraps customer transaction history
• Current SlickWraps API credentials for its email marketing service provider
• Current SlickWraps API credentials for a number of of the company’s credit card and payment handlers
• Current SlickWraps API credentials for the company’s warehouse management system
• Current SlickWraps API credentials for the company’s customer service platform
• Current SlickWraps API credentials for the company’s official brand Facebook account
• Current SlickWraps API credentials for the company’s official brand Twitter account
• Current SlickWraps API credentials fo the company’s official brand Instagram account

…all of which the hacker accessed only after exploiting the vulnerability to get remote code execution (RCE), decrypting the local config file, and finding the credentials to get into the company’s database.

Readers, do the actions and disclosure style of this “white-hat” hacker pass your “vibe test?” Is that how responsible disclosure works? I’m a “No” on both counts, but please, do tell us what you think.

Slickwraps says the exploit has been fixed, and it’s working hard to get back customer trust.

Latest Naked Security podcast