Category Archives: News

“Back to basics” as courier scammers skip fake fees and missed deliveries

We’ve been warning about fake courier scams on Naked Security for many years, even before the coronavirus pandemic increased our collective reliance on home deliveries.

These scams can take many different forms, including:

  • A fake gift sent by an online “friend” is delayed by customs charges. This is a common ruse used by romance scammers, who sucker you into an online friendship, for example by stealing other people’s profile data from online data sites, courting you online, and then “sending” you a “gift”, often jewellery or something they know you would appreciate if it were real. The scammer then pretends to be the courier company handling the “delivery”, correctly identifying the item, its value and its made-up shipping code. Finally, there’s a customs or tax payment to make before the item can be released in your country (something that often happens with genuine deliveries via geniune courier companies). Some unfortunate victims pay out this fee, in cash, in good faith. In this sort of scam, the crooks are directly after your money.
  • A fake order will be delivered once you have confirmed the purchase. These fake orders range from low-value subscriptions that have auto-renewed, all the way to expensive new mobile phones or gaming consoles that will ship imminently. Given that it’s easier to guess what you haven’t just bought than what you have, these crooks are banking that you will click the link or phone the “customer support” number they’ve helpfully provided in order to cancel or dispute the charge. Once they have you on the hook, skilled social scammers in a call centre operated by the crooks offer to “help” you to cancel the bogus order or subscription (something that can be annoyingly hard for legitimate goods and services). In this sort of scam, the crooks are after as much personal information as they can persuade you to hand over, notably including full credit card data, phone number and home address.
  • A fake delivery failed and the item was returned to the depot. These fake delivery notices typically offer to help you reschedule the missed delivery (something that is occasionally necessary for legitimate deliveries of geniune online orders), but before you can choose a new date you usually need to login to a fake “courier company” website, hand over credit card data, or both. The credit card transactions are almost always for very small amounts, such as $1 or $2.99, and some crooks helpfully advise that your card “won’t be charged until the delivery is complete”, as a way of making you feel more comfortable about committing to the payment. In this sort of scam, the crooks won’t bill you $2.99 now, but they will almost certainly sell your credit card details on to someone else to rack up charges later on.

KISS – Keep It Simple and Straightforward

But some courier scams keep things way simpler than this, like this one we received ourselves over the weekend.

The email simply offers you a waybill for a delivery that’s headed your way:

This message was aimed at our business email address, and the company’s physical address is a matter of public record, so just confirming delivery details doesn’t sound as though it’s a major privacy risk…

…until the next stage of the process demands a password for the associated email account:

Note that the email address and the company name shown in the password phishing page are extracted directly from the URL specified in the original email.

In the example above, the URL was: https://[REDACTED]/index.php?​email=​yourname@​naksec.test, making it easy for the [REDACTED] website to present a login page with a company name in it, without needing a database of tracking codes shared between the crooks sending the scam emails and the crooks operating the scam web page page.

After you’ve put in your password and the crooks have harvested it, you’re redirected to the domain name from your email, typically the main page of your own company’s website, as a sort of decoy to distract you:

Interestingly, the fraudulent login site redirects via HTTP, but most web servers these days will then automatically redirect you to their HTTPS version, so you probably won’t end up on an insecure page as shown above.

Note that in this scam, there’s no fake payment demanded, no fraudulent credit card payment form, and no failed delivery to reschedule.

Just a “waybill” you can view and verify.

What to do?

  • Check all URLs carefully. Learn what server names to expect from the companies you do business with, and stick to those. Bookmark them for yourself in advance, based on trustworthy information such as URLs on printed statements or account signup forms. Learn not only what your own company’s email login page is supposed to look like, but also exactly what URL it uses, and never login from anywhere else. Look before you leap – it only takes a second.
  • Steer clear of links in messages or emails if you can. Legitimate companies often provide quick-to-click links to help you jump directly to useful web pages for online accounts such as utility bills. These links save you a few seconds because you don’t need to find and type in your own tracking code or account number by hand. But you’ll never get caught out by fake links if you never use in-message links at all! (See point 1 above.) Those few seconds are a small price to pay for not paying the large price of handing over your personal data to cybercriminals.
  • Stop. Think. Connect. Those three words are a long-running and easily remembered phrase from Cybersecurity Awareness Month, which starts in two weeks’ time (October 2021). Try repeating those word aloud to yourself, emphasising the pauses denoted by the periods (full stops), before every online transaction. When you’re on a login page or a payment form, you’re more likely to make a mistake if you’re in a hurry. Of course, you don’t need to wait for Cybersecurity Awareness Month to be aware – get in the habit today!

OMIGOD, an exploitable hole in Microsoft open source code!

The September 2021 Patch Tuesday updates from Microsoft came out this week.

The fix that everyone was waiting for with bated breath was the patch for CVE-2021-40444, a zero-day remote code execution bug in MSHTML that was announced by Microsoft just days before Patch Tuesday came around:

Remotable bugs in MSHTML, which is the web renderer used by Internet Explorer (IE), are always a big deal, especially if the crooks find them before the Good Guys do.

With so little time left before Patch Tuesday, the big ask of Microsoft was, “Will they make it?”… and, fortunately, the answer was “Yes”:

Of course, most Patch Tuesday updates close off more than just one security hole, and some of the others often don’t get much publicity, either because they were found by the Good Guys first, making the patch proactive, or they don’t affect every computer on your network.

OMIGOD, there’s a Linux-based bug as well

This month, CVE-2021-38647 turns out to be a security hole of that sort – interesting and important, but apparently not very exciting.

This flaw doesn’t directly affect Windows at all, because it’s a bug in Microsoft’s open source Open Management Infrastruture (OMI) tool that is designed for Linux in general, and for Azure-hosted Linux servers in particular.

You read that correctly: one of this month’s Patch Tuesday bug notifications was a flaw in a product, aimed at Linux sysadmins, that Microsoft ships in source code form via its GitHub service.

Indeed, the relevant bug fixes were officially available in the OMI source code back on 12 August 2021, more than a month ago.

So, this vulnerability seemed, on the surface, to be one of those that wasn’t really worth jumping up and down about, and that was probably already patched on many or most servers, given that its public source code had long been updated.

Well, Wiz, the curiously named startup that discovered and reported this bug, and was therefore responsible for putting in motion the process of getting it fixed, thinks it’s very much worth getting excited about.

In fact, they’re excited about it to the point that they’ve dubbed it OMIGOD, and written it up on their company blog.

They even gave it a logo, which we’ve used in the image at the top of the article.

It’s easy to be cynical when you hear a new BWAIN announced – our lighthearted acronym for Bug With An Impressive Name – but if you have any Linux servers out there, it’s worth taking note of what Wiz has to say.

The bug in brief

Greatly simplified, OMI is Microsoft’s Linux-based answer to WMI, the Windows Management Interface that sysadmins use to keep tabs on their Windows networks.

Like WMI, the OMI code runs as a priviliged process on your servers so that sysadmins, and system administration software, can query and control what’s going on, such as enumerating processes, kicking off utility programs, and checking up on system configuration settings.

Unfortunately, cybercrooks, epecially ransomware criminals, love WMI just as much as sysadmins.

That’s because WMI helps attackers to plan and execute their destructive attacks across a whole organisation, once they’ve got an Administrator-level beachhead somewhere on the network.

Sadly, OMIGOD is an OMI bug that, in theory, offers criminals the same sort of distributed power over your Linux servers…

…except that you don’t need that Administrator-level beachhead first, because CVE-2021-38647 basically provides a beachhead all of its own, letting you break in, get root, and take over, all in one go.

No password required

Astonishingly, the bug seems to boil down to a laughably easy trick.

Rather than guessing a valid authentication token to insert into a fraudulent OMI web request, you simply omit all mention of the authentication token altogether, and you’re in!

Of course, with the relevant code patches published more than a month ago, in source code form no less, you might assume that Linux sysadmins who are users of OMI have had plenty of time to patch already.

You might also assume that anyone relying on their Linux distro to provided updated binary packages (thus sidestepping the need to rebuild the code manually from source) would be ahead of the game, too.

However, as Wiz remarks out rather pointedly in its blog post, many Linux-on-Azure users may be unaware that they have OMI, and therefore not even know to look out for security problems with it.

That’s because the OMI software may have been installed automatically, along with various Azure service they chose to use.

Wiz claims that:

Azure customers on Linux machines – which account for over half of all Azure instances according to Microsoft – are at risk if they use any of the following services / tools: Azure Automation, Azure Automatic Update, Azure Operations Management Suite (OMS), Azure Log Analytics, Azure Configuration Management, Azure Diagnostics [and] Azure Container Insights,

As the company is forced to admit, “this is only a partial list,” being limited to the ones they happen to know about, so there may well be others.

If you look after Linux servers, and in partcicular if they’re hosted on Azure, we suggest that you check whether you have OMI, and if so, that you ensure you have the latest version.

What to do?

  • 1. If you know you have OMI on your servers, ensure that it’s up to date. According to Microsoft, you can use the omicli ei (enumerate instance) command to check what version is installed on each server. Look for version 1.6.8-1 or later.
  • 2. If you aren’t sure whether you have OMI installed, search for it. You can search your filesystem for files called omilci.conf, omigen.conf and omiserver.conf, as well as files called .omiclirc and .omigenrc in any account’s home directory, or use your Linux distro’s package manager to search for packages with names starting omi*. If you find OMI where you weren’t expecting it, GOTO 1.
  • 3. Check for listening network services that could expose OMI remotely. According to Wiz, the default port number is 5986, and remote access is not enabled by default. You can check for listening sockets on a server using the netstat command. (See below.) Turn off remote access unless you geniunely want or need it.
  • 4. Read Microsoft’s security advice for CVE-2021-38647. Note that there are three other somewhat less serious vulnerabiities in OMI that Wiz found at the same time, so you may want to read up in those as well: CVE-2021-38645, CVE-2021-38648 and CVE-2021-38649.

How to use the netstat command

To view all listening sockets (root needed):

# netstat -l
[...]

To show all listening sockets with process IDs and names:

# netstat -lp [...]

Restrict output to listening TCP sockets, igven that OMI uses HTTPS over TCP:

# netstat -lp | grep tcp
[...]

To practise using this command, start a listening TCP socket in one terminal window, like this…

$ nc -n -l -v -p 8888 listening on [any] 8888 ...

…and then, in another terminal window, use netstat to search for the listening socket on port 8888:

# netstat -lp | grep tcp
tcp 0 0 [0.0.0.0]:8888 0.0.0.0:* LISTEN {PROCESSNO]/nc

Note that in the example aove, [0.0.0.0]:8888 denotes that the nc process is listening on port 8888 on all network interfaces, which means that the port can be accessed locally or remotely.


S3 Ep50: Two 0-days plus another 0-day plus a fast food bug [Podcast]

[01’28”] Apple patches two zero-day bugs.
[09’25”] Microsoft patches one zero-day bug.
[15’49”] A security researcher finds a fast-food bug (non-insect sort).
[23’04”] Oh! No! A touchpad user turns right into left, and vice versa.

(See also: Big Office bug squashed for September 2021 Patch Tuesday.)

With Paul Ducklin and Doug Aamoth. Intro and outro music by Edith Mudge.

LISTEN NOW

Click-and-drag on the soundwaves below to skip to any point in the podcast. You can also listen directly on Soundcloud.


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.


Apple products vulnerable to FORCEDENTRY zero-day attack – patch now!

You know what we’re going to say, so we’ll say it right away.

Patch early, patch often.

Canadian privacy and cybersecurity activist group The Citizen Lab just announced a zero-day security hole in Apple’s iPhone, iPad and Macintosh operating systems.

They’ve given the attack the nickname FORCEDENTRY, for rather obvious reasons, though its official designation is CVE-2021-30860.

Citizen Lab has attributed the vulnerability, and the code that exploits it, to controversial device surveillance company NSO Group, already well-known for its so-called Pegasus line of spyware-like products.

According to Citizen Lab, this exploit relies on booby-trapped PDF files, and was spotted in the wild when a Saudi Arabian activist handed over their phone for analysis after suspecting that spyware had somehow been implanted on the device.

The Citizen Lab report coincides with Apple’s own security bulletin HT21807, which credits Citizen Lab for reporting the hole, and says simply:

Processing a maliciously crafted PDF may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. […] An integer overflow was addressed with improved input validation.

The problem with integers

Integer overflows happen when an arithmetic calculation doesn’t fit into the numeric precision available, often leading to some sort of memory buffer overflow later on.

Computers typically use a fixed number of bits, typically 16, 32 or 64, to do arithmetic on integers (whole numbers, such as 1, 42 and 2021), so some combinations of inputs will produce outputs that won’t fit into the available space.

This is the same class of flaw as the infamous Y2K bug, where programs that used two digits to store the year would compute the year that followed 1999 as 99+1 = 100, using this as “shortcut” instead of calculating 1999+1 = 2000 in full.

Of course, with only two digits to store the answer, the result would “lose” the leading 1-digit denotoing “one hundred years”, and wrap back round to 00, causing the time and date at the stroke of midnight to shoot backwards by a century instead of advancing by just one second.

In memory management code, numeric wraparounds of this sort can easily lead to chunks of data being written to memory blocks into which they simply won’t fit.

For example, a program that relies on 16-bit numbers to store the width and height of an image would happily allow you to specify images up to 65535 pixels wide by 65535 pixels high (0xFFFF in hexadecimal, or 16 bits’ worth of 111...111 in binary).

At first thought, that sounds like a bigger image than you’d ever need.

But if the programmer forgot to specify a 32-bit number for the number of pixels needed (width × height), and out of habit allocated another 16-bit integer for the result, then even an image of, say, 1000×1000 pixels would cause serious trouble.

The product of 1000×1000 should come out at 1,000,000 pixels, or 0xF4240 in hexadecimal, but that number requires 20 bits to store in full, or 5 hexadecimal digits, because of integer overflow. (When you multiply two N-digit numbers together, the result can be up to 2N digits long.)

If that answer gets shoehorned into a 16-bit integer, the 0xF at the start of the number gets discarded, leaving just four hex digits (16 bits), so the computed “image size” wraps around to 0x4240 in hex, like a old-school car speedo that’s gone past 99,999 kilometres and started again from zero.

That produces an incorrect answer of 16,960 instead of 1,000,000.

If the software then blindly allocates just 16,960 bytes of storage space, having miscalculated that as the “correct” size of a 1000×1000 pixel image, a huge and catastrophic buffer overflow would happen as soon as the image was copied into the undersized buffer.

Two bugs fixed

Intriguingly, Apple also fixed another in-the-wild bug at the same time, dubbed CVE-2021-30858.

This second zero-day hole was found in Apple’s web rendering software, WebKit, which forms the heart of the built-in Safari browser on all Apple operating systems.

In fact, all App Store programs (right from the most basic games and utilities to the most powerful web browsers) that can render and display HTML content are compelled by Apple to use WebKit.

Even browsers such as Edge and Firefox, which usually use the Chromium and Gecko web rendering software respectively, have to use via WebKit instead, so WebKit security bugs can have widespread consequences on iPhones and iPads.

The CVE-2021-30858 bug is a use-after-free vulnerability, where a program hands back to the operating system memory that it no longer needs, so it can be used elsewhere…

…but then inadvertently keeps on using it anyway, trampling over any new data that’s been stored there for some other purpose.

This sort of bug almost always leads to application crashes, and occasionally gives attackers the chance to come up with ull-on remote code execution (RCE) exploits, which seems to be what happened here.

We have no idea whether the two bugs in this story are related – the Citizen Labs report mentions only CVE-2021-30860, and the WebKit CVE-2021-30858 flaw is credited simply to “an anonymous researcher”.

What to do?

With two apparently independent bugs in the wild at the same time, and with little indication so far of what to watch out for in booby trapped PDF files or web pages, there’s not much you can do…

…other than patch early, patch often.

Current patches [2021-09-14T00:01Z] are documented in Apple’s latest security bulletins as follows:

  • HT212804: macOS Big Sur 11.6, fixing both bugs.
  • HT212805: 2021-005 Catalina, fixing PDF bug only.
  • HT212806: watchOS 7.6.2, fixing PDF bug only.
  • HT212807: iOS 14.8 and iPadOS 14.8, fixing both bugs.
  • HT212808: Safari 14.1.2 for Catalina and Mojave, fixing WebKit bug only.

This means that on macOS Catalina, there are presently two patches you’ll need, one for the operating system itself, and the other for WebKit/Safari.

To check for updates (and automatically fetch them if they haven’t been downloaded automatically yet), do this:

  • On an iPad or iPhone. Go to Settings > General > Software Update. If you are using iOS 14, you want 14.8.
  • On a MacBook laptop or a desktop Mac. Go to Apple menu > System Preferences > Software Update. If you are using macOS Big Sur 11, you want 11.6.

As far as we can tell, the Citizen Lab bug affects “all iPhones with iOS versions prior to 14.8”, which we assume includes iOS 12, still officially supported by Apple.

But we can’t find any current security bulletins that mention iOS 12, which means that older phones might be vulnerable but not yet patched.

Bulletin HT212803, which immediately precedes this batch of zero-day patches, covers the recent and perhaps unsurprising news that attaching an iPhone directly to a high-powered motorcycle, or to a mountain bike used on hard-core offroad rides, might cause premature vibration damage to the precision engineering components in the lens of your phone. Bulletin HT212809, the next in sequence after this batch, doesn’t yet exist [2021-09-14T00:01Z].

For users of older iPhones, all we can suggest at the moment is for you to be more cautious than usual about whom you accept PDF files from, and the sites from which you download them.

In particular, don’t be swayed just because the document you’re being tempted with apparently relates to your own job or hobbies.

Cybercriminals can easily figure out your interests, in both your professional life and your home life, simply by reading your job description or peeking at your social media pages.

If in doubt, leave it out!


Serious Security: How to make sure you don’t miss bug reports!

Articles in our Serious Security series are often fairly technical, although we nevertheless aim to keep them free from jargon.

In the past, we’ve dug into into topics that include: website hacking (and how to avoid it), numeric computation (and how to get it right), and post-quantum cryptography (and why we’re getting it).

Helping others to help you

This time, however, the Serious Security aspect of the article isn’t really technical at all.

Instead, this article is a reminder of how you can make it easy for people to to help you with cybersecurity, and why you want to help them to do just that.

After all, lots of companies these days either run bug bounties, or hire an outside company to look after bug submissions, which shows that they are genuinely interested in knowing about security vulnerabilities in their products or services.

But that still doesn’t answer the questions, “Where to report? Whom to tell? How to do it?”

Relying on bug-finders to work it out for themselves, especially when a third-party bug bounty company is involved, is prone to failure.

Firstly, some bug-hunters aren’t interested in communicating via an external service in order to tell you about a problem they’ve discovered, and would prefer simply to tell you directly.

Some aren’t interested in receiving a bounty; some don’t don’t want the hassle of creating what might be yet another account with a third-party provider; and others simply want the option of communicating with you easily and privately.

Secondly, even researchers who do this sort of thing for a living need to know the right place to start, and having a standardised storage place for contact details makes bug reporting easier for everyone.

What if you win the keys to the kingdom?

Problems with the issue of “where to report” were illuminated amusingly in the media last week, when a UK developer called Connor Greig received a promotional email from fast-food giant MacDonald’s…

…into which a bunch of Azure database connection text had leaked, apparently including authentication credentials.

At a glance, it looks as though some of the confidential input data from the database query that was used in generating Greig’s email had accidentally been repeated in the output data he was sent, dumped inadvertently into the body of the email.

That’s a bit like entering your password up front in order to login to your chosen webmail service, and then accidentally pasting the password text into the body of all the emails you subsequently sent out.

As it happens, Connor Greig runs a boutique web-based company of his own that aims to improve revenues and analytics for social media creators, so he not only realised that he was looking at data he wasn’t supposed to have, but also recognised the value of reporting the problem so it wouldn’t happen again.

To cut a roundabout journey short, he couldn’t figure out where to start, despite apparently trying the most obvious phone numbers and email addresses he could find.

The problem with sending comments such as bug reports to email addresses that aren’t clearly listed as “the right place to send notifications about cybersecurity issues” is that you can’t be sure that the email reached anyone, or even if it did that the recipient themselves knew what to do with it. After all, if you can’t easily find out where to send this stuff, it’s reasonable to assume, in a large company, that insiders might have exactly the same problem, leaving your report bouncing from pillar to post while the problem persists.

Dance Dance Cybersecurity Revolution

So Greig took an unusual step.

He published a bug report via the medium of TikTok!

@creatorsphereco

I don’t want these. Please answer emails McD. #cybersecurity #mcdonalds #disclosure #help #techtok #monopoly

♬ original sound – CreatorSphere.co

He didn’t dance his report, or sing it, just asked that if “someone can put me in touch that would be great, because currently I have the keys to the kingdom… and I don’t want them!”

According to news site The Register, Greig’s video did get the attention of someone at McDonalds, but the company (perhaps understandably, given the circumstances) was at first inclined to treat the bug report as “suspicious”, leading to yet further delays in dealing with it.

Ultimately, Connor Greig did get to communicate with someone who was in a position to deal with the problem…

..but it would have been a much shorter tale if his first attempt to report the issue had hit the spot.

What to do?

The good news is that there’s a simple and nearly-but-not-quite standardised way to let security experts know where to start.

It’s currently a draft internet standard entitled A File Format to Aid in Security Vulnerability Disclosure, and the proposed system has already been accepted by IANA (the Internet Assigned Numbers Authority) as what’s known as a Well-Known URI.

The filename is the easily-remembered security.txt, and the idea is that it is a simple, text-only download that you can place at the top level of your company’s domain, as we do at Sophos: https://sophos.com/security.txt.

There are numerous information lines that you can put in this file, the most important of which is a group of one or more Contact items, as you will see in the file that we use [2021-09-13T16:00Z]:

Contact: security-alert@sophos.com Contact: https://www.sophos.com/security Contact: https://bugcrowd.com/sophos Acknowledgement: https://www.sophos.com/en-us/legal/sophos-responsible-disclosure-policy/thanks.aspx
Disclosure: https://www.sophos.com/security

We’re offering you three different ways to get in touch with us, from an internal email address for those who prefer direct contact, to a third-party website for those who are interested in submitting security reports to stake a formal bounty claim.

You can also put your security.txt file at a special location reserved for IANA well-known URIs, like our blog hosting company Automattic, (owner of WordPress: https://automattic.com/.well-known/security.txt.

The concept of Well-Known URIs and where to put them is defined in RFC 8615.

If you have a website, why not add a security.txt file today if you haven’t already?

It’s quick and easy to do, and it could save you hours or days in a cybersecurity emergency…


go top