Perpetual IT

Facebook denies that it’s cringing away from its virtual currency plans due to the fact that regulators loathe it, saying that it “remains fully committed to the project.”

On Tuesday, multiple reports suggested that Facebook has decided not to support its Libra virtual currency in its own products and will instead offer users the ability to make payments with government-issued currencies, or that the platform and its partners are weighing whether they should recast it as mostly a payments network that could operate with multiple coins.

According to a report from The Information that cited three sources, Facebook has been mulling offering digital versions of currencies such as the US dollar and the euro, in addition to its proposed Libra token. The Information also reported that Facebook will still launch a digital wallet to enable users to make purchases and send and receive money, but that the rollout would be delayed by several months.

On Tuesday, Facebook moved to quash both The Information’s claims and another report from Bloomberg about Libra turning into a payments network that could operate with multiple coins.

A Facebook spokesperson sent this statement:

Reporting that Facebook does not intend to offer the Libra currency in its Calibra wallet is entirely incorrect. Facebook remains fully committed to the project.

Facebook didn’t address many of the two media outlets’ claims, including the reported delay in Calibra’s rollout, whether or not it plans to create new digital government currencies, nor whether Libra might be reimagined as mostly a payments network that deals in multiple coins.

Dante Disparte, head of policy and communications for the Libra Association, sent out this statement:

The Libra Association has not altered its goal of building a regulatory compliant global payment network, and the basic design principles that support that goal have not been changed.

What happened?

Things have been rocky since June 2019, when Facebook announced, along with 27 other companies, that it would launch Libra in 2020. The virtual currency was supposed to be a way to connect the globe, circumvent the financial system, and shrink the cost of sending money, particularly for those populations without ready access to banks. The Libra project’s members included the financial heavyweights: Visa, Mastercard, and other large companies that would partner with Facebook to govern the system.

Within months came a chorus of “Hell, no” responses from multiple governments, followed by the cryptocurrency project being pelted by rapid-fire, major body blows from founding members of the Libra Association.

First came PayPal’s terse “On second thoughts, how about ‘No’?” …followed by Mastercard, Visa, eBay, and the payments firms Stripe and Mercado Pago all jumping ship. Then, in October, it was hit again with news of a not particularly optimistic report about the virtual currency from the G7 group.

At that point, Libra had lost all but one payment company.

The G7 report outlined nine major risks posed by digital currencies like Libra. Even if Libra’s backers were to address concerns, it said, the project still might not be approved by regulators. The report came from a G7 taskforce made up of senior officials from central banks, the International Monetary Fund (IMF) and the Financial Stability Board (FSB), which coordinates rules for the G20 economies.

Also in October, the FSB published a separate report addressing the regulatory dangers of “global stablecoins” in general. Stablecoins are a type of cryptocurrency that, unlike a currency such as Bitcoin, are pegged to established currencies such as the dollar and euro.

The G7 report echoed concerns already put out by the US Congress in July 2019, when it asked Facebook to halt the cryptocurrency for the time being, and of France, which in September rejected Libra as being too dangerous.

That’s the bureaucratic version of what’s happened to Libra in these months of planning. Bloomberg gave this more colorful rendition of its history:

What happened to Libra since its June 2019 unveiling is a story of hubris, wary lawmakers, protective regulators and partners fearful of the risks involved.

According to Bloomberg’s sources, representatives of Facebook and the Libra Association have continued to meet with US regulators to work on their concerns. One of the media outlet’s sources said that treasury officials, in particular, are still interested in determining how Libra will ensure that the payments network isn’t used for money laundering – one of the concerns raised by multiple regulators.

Jennifer Campbell, the founder of Tagomi, one of the new members of the consortium, told Bloomberg that the cryptocurrency is already being tested. It’s regulatory approval that’s the biggest hurdle, given that Facebook has said that it won’t launch Libra without the US government’s OK.

---

Latest Naked Security podcast

Hackers are crawling all over the US Department of Defense’s websites. Don’t worry, though: they’re white hats, and DoD officials are quite happy about the whole thing.

Four years after it first invited white hat hackers to start hacking its systems, the Pentagon continues asking them to do their worst – and a report released this week says that they’re submitting more vulnerability reports than ever.

The DoD’s Department of Defense Cyber Crime Center (DC3) handles cybersecurity for the DoD, and is responsible for tasks including cyber technical training and vulnerability sharing. It also runs the DoD’s Vulnerability Disclosure Program (VDP).

The VDP emerged from the Hack the Pentagon bug bounty program that the military ran in 2016. That initiative was so successful that it continues to invite hackers to play with its systems. Last year, the Air Force even bought an F-15 to Defcon for hackers to tinker with. Next year, it plans a satellite.

These high-profile events punctuate a more modest but ongoing program that invites hackers to submit security vulnerability reports focusing on DoD websites and web applications. The DoD engaged its DC3 unit to run the continuous program and keep the ethical hacks rolling in.

DC3 just published its first annual report on the program, revealing that it processed 4,013 vulnerability reports from 1,460 white hat researchers. It validated 2,836 of them for mitigation, it said, adding:

These vulnerabilities were previously unknown to the DoD and not found by automated network scanning software, red teams, manual configuration checks, or cyber inspections. Without DoD VDP there is a good chance those vulnerabilities would persist to this date, or worse, be active conduits for exploitation by our adversaries.

2019 was the busiest year for bug reports, the report said, representing a 21.7% increase over 2017 and bringing the total number of bug reports to 12,489.

Information exposure bugs were the most common type reported during the year, followed by violation of secure design principles, cross-site scripting flaws, business logic errors, and open redirects (which are a way to mount phishing attacks).

In the future, DC3 wants to expand the scope of the program beyond DoD websites to cover any DoD information system. It also wants to partner with the Defense Counterintelligence and Security Agency (DCSA) to create what it calls a defense industrial base (DIB) VDP program to secure the DoD’s supply chain. That’s notable, given the past controversy over potential vulnerabilities in third-party drones and cameras sourced by the DoD.

---

Latest Naked Security podcast

Let’s Encrypt was all over the news recently – the cybersecurity news, at any rate – for the laudable reason that it just issued its 1,000,000,000th TLS certificate.

TLS certificates are the cryptographic sauce that puts the S in HTTPS, and the padlock in your browser’s address bar.

The padlock doesn’t vouch for the actual content of the website you visit, of course – it doesn’t prove that the content it presents is correct, or that its downloads are malware free – but it nevertheless provides several benefits that you don’t get with an unencrypted, no-padlock connection:

• The traffic between you and the website is encrypted. This makes it difficult for other people on the internet to sniff out and snoop on exactly what content you are looking at. Even if what you are reading is not personal or private, crooks can learn a lot about you by keeping an eye on what interests you.
• The traffic between you and the website is integrity-protected. This makes it difficult for other people to tamper with the content on its way back to you – if they try to sneak malware into a file download after it leaves the site and before it reaches you, the modified data will be rejected.
• The padlock offers evidence that the person who acquired the certificate really does have access to the website you are visiting. That may sound like a weak guarantee – it doesn’t prove that they actually own the website and it doesn’t identify them in case of any future legal dispute – but it makes it harder for random crooks to get certificates with your website’s name in them.

With this in mind, you may wonder why we have HTTP (unencrypted web traffic) at all.

In the same way that modern train doors lock automatically as you leave the station so you can’t fling them open by mistake at 225 km/hr, why not simply “define” the World Wide Web to be encrypted-only, and be done with it?

Why not force HTTPS?

In the past, there were two main reasons: TLS certificates were complicated and time-consuming to acquire and use; and they cost money that sites such as charities, hobbyists and small businesses resented having to pay, especially given that certificates need renewing regularly.

Let’s Encrypt changed that not only by offering certificates for free, but also by automating and therefore greatly simplifying the process of acquiring and renewing them.

(Let’s Encrypt wasn’t the first project to do free certificates, but it has been by far the most successful at making its free certificates widely-accepted and easy to use.)

As you can imagine, automating the certificate issuing process that much is a bit of a double-edged sword.

A flaw in the issuing protocol, or a bug in the software that implements the protocol, could have serious side-effects.

Unfortunately, something along those lines – a bug in Let’s Encrypt’s auto-validation system – has just been discovered…

…with the outcome that Let’s Encrypt will abruptly be revoking (today, in fact!) more than 3,000,000 web certificates, covering more than 12 million server names, that were still supposed to be valid for weeks or months more.

At first glance, 3,000,000 out of hundreds of millions of currently-active certificates (Let’s Encrypt claims to secure 190 million websites) doesn’t sound like an enormous proportion.

But companies with affected certificates need to renew them right now, instead of waiting until their server renews them automatically.

That’s because carrying on using a revoked certificate will cause visitors to your website to see security warnings, and may ultimately prevent them doing business with you online at all.

What happened?

A really tiny bug – tiny in code size, not in impact – seems to have caused the problem.

Let’s Encrypt certificates are valid for 90 days, and autorenew for most users when there are 30 days or fewer left on their current certificates.

Many Let’s Encrypt users have multiple certificates covering multiple websites and domains – for example, you might want a separate site for each of: billing DOT example, community DOT example and downloads DOT example.

For reasons of efficiency and reliability, you can renew a whole batch of domains at the same time, and that’s what most multi-certificate users will do – or, at least, it’s what their auto-renewal software will do for them.

Now, as a security precaution during renewal, in addition to any other checks that are carried out, Let’s Encrypt is required to look up what’s called a CAA, or Certificate Authority Authorization, for every domain you’re renewing.

A CAA check involves doing a DNS (domain name system) database lookup on the relevant domain to see if the owner of the domain – who might not be the person requesting the website certificate – has placed any restrictions on certificate renewal.

For example, the domain owner might not use Let’s Encrypt themselves, and might therefore publish a DNS entry saying, “Only accept XYZ Corporation to issue certificates for this domain,” as a way of making it harder for unauthorised third parties to get bogus certificates to impersonate their site.

This is a simple precaution that’s supposed to make it harder for crooks to take over your online identity – if you insist that they stick to one certificate issuing company, then you force the crooks to follow a certificate renewal path that makes it more likely you will catch them at their deception.

In fact, the rules of certificate signing say that an issuer must check a server’s CAA record no more than eight hours before issuing a certificate – to make the checks as current as possible.

And here comes the bug: when Let’s Encrypt went to check the CAA records for a list of, say, 10 certificate renewals, it didn’t check each domain in the list once.

Instead, it inadvertently picked one of the domains and then redundantly checked it 10 times over, leaving the other nine domains unchecked.

In pseudo-code, the checking was supposed to work like this:

for name in {'one.example', 'two.example', 'three.example'} do check_caa_of(name)
end
// all domains checked at this point

But it ended up working something like this:

for name in {'one.example', 'two.example', 'three.example'} do oops = 'two.example' // list is "traversed" but name never updates, // so one domain gets checked N times check_caa_of(oops) // instead of N domains checked once each
end
// two domains unchecked here

In truth, the number of domains that would have been rejected if they’d been checked properly is almost certainly very tiny, so the overall risk of crooks using this bug to hijack domains on purpose is quite small.

But in real life, the Rules Of The Game say that certificate issuing organisations – known as CAs, short for Certificate Authorities – can’t make that sort of assumption.

So Let’s Encrypt has to make a disclosure of what happened, and how, and what it has done to prevent the problem happening again. (It has already started that process.)

And it has to revoke any certificates that weren’t renewed in strict accordance with the rules, which require that the server name for any certificate must be CAA-checked.

It doesn’t matter if you are 99% certain than the CAA check would have passed – what matters is that the check has to be carried out, as a way of keeping the process objective and honest.

So: three million suddenly-revoked certificates.

What to do?

If you have certificates that are being revoked, Let’s Encrypt will try to email you. Affected customers ought to have received warning emails by now – Let’s Encrypt has a web page showing what the emails look like, and how get further advice – that page also has links showing you how to download a full list of serial numbers of affected certificates (0.3GByte download) and how to check those serials against your own certificates.

If you have an affected Let’s Encrypt certificate and you don’t renew it, it will suddenly stop working because it will be revoked today at 2020-02-04T20:00Z. (That’s 8pm in the UK, 3pm on the US East Coast, noon on the West Coast.)

So you need to run your certificate renewal process manually – this is typically as easy as running a command-line script – instead of waiting for the next automatic renewal.

You can check Let’s Encrypt’s website for more advice – the fix isn’t difficult, but if you don’t do it you will find visitors unable to access your site.

(As far as we can see, if you have one and only one Let’s Encrypt certificate, this bug doesn’t apply to you – because you wont ever have tried to renew more than one certificate at a time.)

This week we discuss the latest in the Clearview AI debacle, get more tales from the ransomware swamp and discover how often our smart speakers are listening to us.

Host Anna Brading is joined by Sophos experts Paul Ducklin and Peter Mackenzie, and me!

How much would you ‘pay’ for ‘free’ Wi-Fi?

Would you give away your birthday? Your travel details? Your home address? Your phone number?

Well, a couple of weeks ago, a security researcher in the UK was looking around online, as you do…

…when he came across yet another company that had joined the 100 million club.

That’s the name we jokingly coined – we hoped we were making a joke at the time, though we quickly realised we weren’t – back in 2013 when Adobe infamously suffered a breach that exposed 150,000,000 encrypted password records in one go.

Despite the encryption – which Adobe hadn’t gone about in the right way – a significant minority of the passwords in the list could be figured out. (Adobe had stored the password hints in plaintext, and lots of users had just repeated their passwords in the hint field, as absurd as that sounds.)

Big breach society

Back then, we rather naively assumed that membership of this notional “100 million club” would remain thankfully rare.

But the low cost and ready availablity of cloud storage has, sadly, made it easier than ever for just about anyone to leak just about as many records as they care to share.

And that’s what seemed to have happened in the case that Jeremiah Fowler of Security Discovery stumbled upon in mid-February 2020.

Although the data, 146 million records’ worth of it, didn’t include deeply sensitive details such as as passwords (or even password hashes), payment card details or financial transactions, Fowler could see what looked like travel details in there.

He quickly tracked the source back through domain names in the data to a company that turns out to operate ‘free’ Wi-Fi’ hotspots, including at a number of train stations in England.

The company reacted quickly to Fowler’s report by sealing off the data it had accidentally exposed in the cloud – though it didn’t tell Fowler, leaving him to worry that his report wouldn’t get looked at until the following week).

So, why would anyone want to worry about 146,000,000 database entries relating to free Wi-Fi users connecting to a free Wi-Fi service?

The problem is, of course, that – in the UK at least – ‘free’ Wi-Fi seems to divide into two categories.

There’s ‘free if you come into the coffee shop and buy something, here’s the password, help yourself, no need to register, and why not try the carrot cake while you’re about it, you will like it more than you think‘ (true).

And there’s the ‘free in return for a bunch of personal data that will help us market to you in a way that makes your retail/station/airport experience so much more enjoyable‘ (not-so-true).

The problem with the second sort of ‘free’ Wi-Fi is that the company that’s giving you the ‘free’ service can only really make money out of it – by which we mean that they can only make you pay for it – if they keep track who you are and what you do when you connect.

That’s why Fowler found all sorts of scammer-friendly information logged in the records of the database he came across, including names, email addresses, age ranges and device data of users of the service.

As Fowler remarks:

In this case anyone with an internet connection could see what station the user was at, a time stamp, ads they may have seen, the postcode where they live and much more. Every little piece of information is essentially a puzzle piece that can be used to paint a bigger picture of the user.

So, just how much personal data should you give away in return for a ‘free’ service such as Wi-Fi?

In an era of affordable mobile data – especially in the UK, where pay-as-you-go SIM cards are cheap and can be bought without much fuss at just about any supermarket checkout – do you even need free-as-in-paid-for-indirectly Wi-Fi at all?

What to do?

Here’s an idea: sit down one evening, decide how much your various items of personal data are worth to you, and then stick to your valuation whenever you hit an online sign-up page.

For example, in our opinion, your age in general and your birthday in particular – still treated as a factor of identification by many organisations – is worth too much to hand over in return for free Wi-Fi, even though it’s a data point many Wi-Fi services seem to want.

If a company demands data that you think is worth more to them than you are getting in return, our advice is simple: “Stay away.”

After all, if they don’t value your data as highly as you do, there’s not much incentive for them to look after your data with the zeal you might expect.

Incidentally, it seems that in this case, the Wi-Fi provider did offer a “don’t want to give you that data” option during sign-up, and that would have been the wise choice.

Remember: you don’t have to fill in optional fields in web signup forms, and life is a lot simpler if you routinely leave them blank.

After all, if you don’t hand over data in the first place, there’s no way the company at the other end can ever lose it in a data breach.