Unfortunately, anti-phishing advice often seems to fall on deaf ears, because phishing is an old cybercrime trick, and lots of people seem to think it’s what computer scientists or mathematical analysts call a solved game.
Tic-tac-toe (noughts and crosses outside North America), for example, is a solved game, because it’s easy to create a list of every possible play, and figure out the best possible move from every game position on the list. (If neither player makes a mistake then the game will always be a draw.)
Even games that are enormously more complex have been “solved” in this way too, such as checkers (draughts)…
…and in comparison to playing checkers, spotting phishing scams feels like an easy contest that the recipient of the message should always win.
And if phishing is a “solved game”, surely it’s not worth worrying about any more?
How hard can it be?
Simply put, the phishing “game” only has two moves: the scammers always play first, trying to trick you, and you always get to play second, after they’ve sent out their fake message.
There’s little or no time limit for your move; you can ask for as much help as you like; you’ve probably got years of experience playing this game already; the crooks often make really silly mistakes that are easy to spot…
…and if you aren’t sure, you can simply ignore the message that the crooks just sent, which means you win anyway!
How hard can it be to beat the criminals every time?
Of course, as with many things in life, the moment you take it for granted that you will win every time is often the very same moment that you stop being careful, and that’s when accidents happen.
Don’t forget that phishing scammers get to try over and over again.
The crooks can try threatening you with closing your account, warning you of an invoice you need to pay, flattering you with false praise, offering you a new job, or announcing that you’ve won a fake prize.
They may pretend to be your ISP today, they may masquerade as Apple iTunes tommorrow, and yesterday they might have said they were a courier company trying to delivery your latest online order.
In contrast, you only have to make one mistake for the crooks to win.
You might be tired, or in a hurry, or simply get caught up in an unlucky coincidence where the subject of a phishing message happens to match up with something you just did online.
Phishing isn’t a “solved game” after all, and phishing scams are still the main way that crooks get their first toe over the threshold in online cyberincidents such as ransomware attacks.
Keep yourself informed
To stay ahead of the phishing crooks, both at work and at home, start by reading up on our Top Ten Phishing Treacheries:
We’ve listed the email topics that catch out people the most when you train them using the Sophos Phish Threat toolkit, and it’s often the friendliest messages that trick the most people.
(In case you’re wondering, one of the top phishing lures in our tests was also one of the simplest: “Headlights left on. Is this your car?”)
You should also read our aritcle Phishing tricks that really work, and how to avoid them, which gives you useful insights into the psychological tricks that scammers use:
Learn how to get your anti-phishing act together at work with our explainer Gone phishing: workplace email security in five steps:
And learn about the many different ways that phishing crooks can adapt their game in our technical analysis entitled Serious Security: Phishing without links – when phishers bring along their own web pages:
Remember, when it comes to unexpected messages that want you to hand over information that you think you should keep to yourself: IF IN DOUBT, DON’T GIVE IT OUT!
DEFENDING AGAINST RANSOMWARE: WHAT WORKED (AND WHAT DIDN’T)
Finally, here’s an easy-to-follow video you can share with your friends and family to help them keep ahead of the phishing crooks, too:
You don’t get one for a while, and then three come at once.
For buses on busy urban routes, at least, the explanation of the phenomenon goes something like this.
If three buses start out travelling the same route together in a nicely spaced sequence, then the first one is most likely to be the slowest, because it will be stopping to scoop up most of the waiting passengers, while the ones behind will tend to travel faster because they need to stop less often or for shorter periods.
So buses naturally tend to scrunch up and arrive in bursts.
Burst-mode software patches
When it comes to software patches, however, the problem often works the other way around.
If the first patch arrives too quickly, then it may not have been reviewed or tested quite as much as you might like.
So it’s not so much that the next patch in the queue catches up because the first one is too slow, but that the next one has to be completed in a rush to keep up…
…and, if you aren’t careful, then that second patch might itself beget a third patch, needed to patch the patch that patched the first patch.
Three Apache buses
And thus with Apache: just two days ago, we reported a path validation bug dubbed CVE-2021-41773 that was introduced in Apache 2.4.49:
We advised you to update to 2.4.50, which would indeed have protected you against at least some of the known exploits already circulating on Twitter.
But the 2.4.50 update itself was incomplete, having been put together in something of a hurry, so that although it blocked some ways of exploiting the bug, it didn’t reliably block all of them.
The bottom line is that if you have Apache 2.4.59 (released 2021-09-15) or Apache 2.4.50 (released 2021-10-04) then you now need to update to Apache 2.4.51 (released 2021-10-07).
What went wrong?
We haven’t investigated this in detail, but a quick look at the three versions listed above suggests that the vulnerability progressed like this:
Apache 2.4.49 made it possible to embed the string ../ (dot-dot-slash) in a URL by using a sneaky text encoding that disguised the second dot. Filenames with dot-dot-slash sequences are dangerous because they tell the operating system to go up one directly level, thus “cancelling out” the previous subdirectory specified in the path. Multiple dot-dot-slash sequences could allow an attacker to ascend far enough up the directory tree to “escape” from the web server’s official sub-tree of official files, and from there to descend again into forbidden parts of the operating system, such as /etc on Unix or C:\Windows\System32 in Windows.
Apache 2.4.50 watched out for suspiciously encoded dots in any dot-dot-slash sequence. But the patch wasn’t always able to block suspiciously encoded slashes in the pathname, so that by shifting the trick from disguising a dot to disguising a slash, an attack was still theoretically possible.
Apache 2.4.51 now watches out for a wider range of suspcious encodings. The code now explicitly includes an internal flag named AP_UNESCAPE_URL_FORBID_SLASHES, and is stricter about reporting errors for inappropriate and therefore exceptionable URL encodings, even if they might inadvertently appear in non-malicious URLs.
What next?
Will the sudden arrival of the third bus in this burst of patches mean that we’ll soon have 2.4.52 to follow?
We don’t know.
But at least the patch-for-the-patch came out within two days of the 2.4.50 update, which, though imperfect, would have stopped a range of already-known attacks that were widely circulated in the wild.
So we don’t regret having urged you to update to Apache 2.4.50 earlier this week, even though it now means updating once again.
(Our Linux distro took care of both of these updates for us quickly and automatically, but if you’re using an Apache version you built yourself, don’t forget that you need to recompile it.)
Our earlier article about this CVE-2021-41773 bug includes an explanation of jargon terms path validation and path traversal, and provides some suggestions on how to find Apache servers that you might not realise are in use on your network:
The venerable Apache web server has just been updated to fix a dangerous remote code execution (RCE) bug.
This bug is already both widely-known and trivial to exploit, with examples now circulating freely on Twitter, and a single, innocent-looking web request aimed at your server could be enough for an attacker to take it over completely.
Estimates of Apache’s prevalence vary, but a good guess is that somewhere between a quarter and a third of internet-facing web services will end up getting handled by an instance of Apache.
Remember that even if you don’t run your organisation’s public-facing web servers on Apache (perhaps you use the popular nginx product on Unix, or Microsoft IIS on Windows), you may nevertheless have Apache running somewhere on your network.
Indeed, any software product that has its own HTTP interface, such as a document management system or a support ticketing system, might, for all you know, be using Apache as its built-in web server.
You should therefore review your network not just for traditional web servers made for external visitors, but also for HTTP servers inside your network that cybercriminals such as ransomware gangs could use to extend or expand an attack that is already underway.
Intriguingly, given the nature of the bug, this flaw, dubbed CVE-2021-41773, was introduced less than a month ago, in Apache 2.4.49.
Ironically, this means that Apache users who were sloppy about updating last time, and are still back on 2.4.48 or earlier, will skip over this vulnerability altogether.
To patch against the bug, upgrade immediately to Apache 2.4.50.
Path traversal explained
When we first heard about CVE-2021-41773, documented as a “path traversal and file disclosure vulnerability”, we assumed that the flaw had been lying around unnoticed in the Apache code for years.
That’s because path traversal bugs are very last-century, and many path validation flaws in contemporary code turn out to be programming artefacts left over from a less careful age.
Simply put, a path traversal bug happens when a user tries to access a file on the server that ought to be blocked, but the security check on the filename fails.
This programming mistake is easy to make because there are many different ways of referring to the same file, and you have to take all of them into account.
For example, let’s assume that you are currently sitting in a directory called /home/duck (the equivalent of C:\Users\duck on Windows), where you have placed a file called findme.txt.
Canonically, which is the jargon term for “the one true way to do it”, you’d refer to this file as:
/home/duck/findme.txt
If you wanted to make certain that this file really was located in the /home/duck directory, the obvious programmatic way to do it would simply be to check that the full filename starts with /home/duck/, for example like this:
But this isn’t good enough, because all major filing systems on all major operating systems allow you to have filenames that “jump around” inside the directory tree, for example like this:
In directory names, dot-dot is shorthand for “go up a directory”, so that in the first filename above, subdir1/subdir2/ descends two levels deeper into the directory tree, while the ../../ that follows goes back up again by two levels.
In other words, every instance of ../ in a filename essentially cancels out the directory name that immediately precedes it in the path.
Our simplistic isfilewithinpath() function would conclude that the files findme.txt and passwd above were both safely contained underneath the “root path” of /home/duck/, because both paths start with exactly that text string.
But only the first file is actually under /home/duck/, because those names simplify to…
One of them is our very own findme.txt file, safely stashed in our own directory tree, while the other is the central Unix/Linux password file from the system directory /etc.
(On modern systems, the passwd file is a bit of a misnomer: it does contain usernames, but for security reasons it hasn’t contained passwords or even password hashes for many decades, just in case you were wondering.)
In fact, you can even use dot-dot as a sort of escape-completely-from-anywhere mechanism, because when you reach the root directory of the system itself, typically / on Unix or C:\ on Windows, every subsequent dot-dot gets ignored, like this:
/home/duck/findme.txt --> /home/duck/findme.txt
/home/duck/../findme.txt --> /home/findme.txt
/home/duck/../../findme.txt --> /findme.txt
/home/duck/../../../../findme.txt --> /findme.txt <-- we've hit the ceiling and now we simply stay there (no errors)
/home/duck/../../../../../findme.txt --> /findme.txt
In other words, you don’t have to know your exact place in the directory hierarchy to escape to any other specific subdirectory, as long as you put plenty of dot-dot-slash entries in the filename.
In particular, you won’t cause an error if you accidentally have more dot-dots than are strictly necessary.
Try the command below on a Windows computer from almost anywhere on the C: drive, and you will print out the hosts file (a list of IP number overrides for specific server names, often used by legitimate users to block annoying ad networks, and by malware to block useful cybersecurity websites).
Note that this filename is an innocent-looking relative filename (because it doesn’t explicitly denote a hard-wired path that it wants to use), but thanks to the dot-dot-slash trickery, it effectively acts as an absolute pathname.
The dot-dots launch you upwards until you reach C:\, where you just bounce repeatedly off the ceiling and stay in C:\ until the path starts descending again to to the desired finishing point:
-- I went three levels down in my own home directory: C:\Users\duck\test\subdir1\subdir2> type ..\..\..\..\..\..\..\..\..\..\Windows\System32\drivers\etc\hosts -- But even using a non-absolute path I traversed predictably to the Windows directory: # Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
[. . .]
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host # localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
All security conscious software, especially including web servers, needs to be on the lookout for this sort of dot-dot trickery.
Path traversal treachery can allow attackers to specify filenames that look as though they’re in a harmless location, and that the attackers are therefore able to read in, or perhaps even to write to or execute, when they aren’t supposed to see those files at all.
If we wanted to look out for dot-dot treachery in a URL, we would need to look out for double-dots and react accordingly, for example like this, where we loop through the path string to see if the untrustworthy substring ../ appears at any point:
But this is not a strict enough test for a web server, because URLs that include file and path names can be encoded using what are known as URL escape sequences.
URL escapes represent ASCII characters that would otherwise be illegal in URLs by converting them into a percent sign followed by two hexadecimal digits to represent the ASCII code.
You can’t have spaces in a URL, for example, so if you want to use a filename or directory name that includes a space as part of a URL, you have to transmit each space as %20, short for “replace this with ASCII hex code 0x20 (decimal 32)”, which denotes a space character.
URL escape codes of all 128 ASCII characters. %2E (dot) highlighted in red.
Even if a character in a URL doesn’t need escaping, you can generally escape it anyway in your web request, and the server at the other end will decode it and use it correctly, as you will find if you try either or both of these commands:
The URL path in the second command above is just the word podcast converted into URL escape codes using the table above.
So, to detect the appearance of the dot-dot sequence in a URL path, you really need to look for any or all of the following different ways of encoding it:
. . <-- both dots can be represented literally as themselves %2E . <-- or the first dot alone can be escaped %2e . <-- and note that URL escapes can use upper or lower case hex digits . %2E <-- or the second dot alone can be escaped . %2e %2E %2E <-- or they can both be escaped %2e %2E %2e %2E %2e %2e
The CVE-2021-41733 bug introduced in Apache 2.4.49 was new code added to normalise, or canonicalise, URL paths to remove inconsistent, unnecessary or dangerous parts of the pathname…
..but (as far as we can see) the code only correctly detected the first three cases above, where either both dots were sent unescaped, or only the first dot was escaped.
By encoding the second dot as %2E, you could bypass the dot-dot check and thus exploit this aptly-named path traversal vulnerability.
Initial reports correctly implied that this bug was exploitable for reading files that were off-limits, including accessing files outside the web server’s own directory tree, as well as downloading script and other source code files inside the server tree that were not supposed to be directly accessible to website visitors.
That’s bad enough, but it turns out that by asking for a rogue file, for example by trying to access the system’s shell interpreter, and at the same time supplying a rogue HTTP header in your request, you may be able not only to execute arbitrary programs on the server, but also to pass arbitrary parameters (command line options) to those programs.
When you have remote, unauthenticated access to a command shell like bash, and you can send it any commands you like via a simple HTTP request, you pretty much have a generic server “backdoor”, and you have pwned the system completely.
The bug has been fixed somewhat clumsily by checking explicitly for a dot-dot sequence in which the first character already appears as a dot, either because it was sent literally or has already been converted, while the second character may appear as a literal dot or as a %2E sequence that has not yet been unescaped.
What to do?
If you have Apache 2.4.49, you need to update right away to Apache 2.4.50 if you haven’t already. This bug is widely-known and sample code to abuse it is widely available online.
If you have older version of Apache, you aren’t affected by this bug. Ironically, perhaps, if you were slow to update last time (2.4.49 came out on 15 September 2021) then your sluggishness has protected you this time.
Don’t just patch this hole on internet-facing web servers. Do the publicly exposed ones first, because that’s where your immediate danger lies. But expect cybercrooks to adopt this exploit as a “lateral movement” trick once they already have a beachhead inside a network, because it’s so easy to abuse.
If in doubt whether any of the web-enabled software you use includes Apache, ask your vendor. If you have network scanning tools such as Nmap available, you can probe for HTTP or HTTPS servers on your own network and check their reply headers, which often reveal the server code in use, notably in the Server: header.
EXAMPLE CURL COMMANDS TO LOOK FOR APACHE
If you know the server name (or IP number) and port number of HTTP or HTTPS services on your network, you can look at the headers that come back when you send a basic web request to it, as you see here:
$ curl --http-1.1 --head https://nakedsecurity.sophos.com/
HTTP/1.1 200 OK
Server: nginx <-- We're using Nginx
Date: Wed, 06 Oct 2021 17:19:46 GMT
Content-Type: text/html; charset=UTF-8
[. . . ] $ curl --http1.1 --head https://www.apache.org
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 73991
Server: Apache <-- As you would expect!
[. . .] $ curl --http1.1 --head https://127.0.0.1:8888
HTTP/1.1 501 Not implmemented
Server: Lua-TLS-Generic <-- Local test server I use for articles
Connection: close
Content-Type: text/plain
[. . .]
Some results may be inconclusive because they don’t return a Server: header, like the excellent, free Fossil source code management tool that we use for our sample code.
This product has a web server that doesn’t use Apache, but doesn’t have a server tag of its own:
$ fossil ui
Listening for HTTP requests on TCP port 8080
[. . .] $ curl --http1.1 --head http://127.0.0.1:8080
HTTP/1.0 302 Moved Temporarily
Date: Wed, 6 Oct 2021 17:23:52 +0000
Connection: close
X-Frame-Options: SAMEORIGIN
[. . .]
Likewise, some servers may deliberately choose to identify themselves as something other than they really are, either as a decoy to mislead naive network scanners that routinely hurl unwanted exploit “tests” at them, or for compatibility reasons with client apps that expect a specific vendor’s product at the other end.
Back in June this year, we wrote about a ransomware-related bust in Ukraine, featuring a police video in which a high-security door was dismantled with a BFG (Big Fat Grinder), substantial piles of cash were counted out and packed into evidence bags, and numerous fancy cars were seized.
Well, here’s another bust video from the Кіберполіція України, or Ukranian Cyberpolice:
[embedded content]
The BFG is back, but thankfully it wasn’t needed inside what looks like a rather modern and upmarket apartment block, because the suspects gingerly opened the door of their own accord when they heard the police outside.
This time, we didn’t spot a breadmaker in the kitchen, or any trendy candles on the dining table, as we did in the pervious video, but you will once again notice that Apple Macs seem to be the laptop of choice for these suspects, along with a fearsome-looking illuminated gaming rig that got seized along with a sea of other electronic gear.
In case you’re wondering why cops in cases like this often get warrants to tow away suspects’ vehicles: it’s not just because flash cars are often considered “proceeds of crime”, but also because the average modern car may contain significant amounts of electronic evidence, for example by way of dashcams, anti-theft trackers, satnavs and mobile phones paired over Blueooth.
Cash and cryptocoins
Last time, most of the money we saw being counted out by the cops was Ukrainian cash; this time, the cops came across a small but nevertheless substantial stash of Benjamins (US $100 bills, which feature a drawing of Benjamin Franklin) in what looked very much like the proverbial hiding place: a shoe-box in a clothing cupboard:
Click to view clip from original video.
According to Europol, the banknotes in the box added up to $375,000 altogether, and the police also managed to freeze more than $1.5 million (EUR 1.3m) in cryptocurrency.
The report doesn’t list which cryptocurrencies were frozen, and doesn’t say whether those assets might ever actually be reclaimable if the suspects are ultimately convicted.
That’s because preventing a cryptocoin stash from being spent, or at least from being “cashed out” on an official crypocurrency exchange, isn’t necessarily enough to permit those funds from being accessed and restored to their rightful owners or paid over to a court.
As an analogy, imagine that the police had a warrant to seize the ATM card needed to withdraw stolen money from a suspect’s bank account, but they didn’t have the PIN for the card, and the bank was unable to release the funds any other way, warrant or not. The funds would be off-limits not only to the suspect, but also to everyone else involved.
Two $100,000 cars were towed away, too, and two suspects arrested.
What next?
Somehow, we don’t think this will make much of a dent on the ransomware scene (if we assume, for the time being, that the suspects really were involved in ransomware criminality).
We don’t even know which ransomware gang these suspects were affiliated with, but the mention of ransom demands as high as EUR 70,000,000 in Europol’s press release has led to some reporters inferring that these busts must be connected to the infamous Kaseya breach, where crooks used bugs in Kaseya’s network management tools to break into not one but many networks at the same time.
In the Kaseya attack, the crooks were allegedly part of the REvil ransomware “affiliate network”, and apparently ended up biting off more than they could realistically chew.
This led to a sort of “all-you-can-eat” offer from the core criminals, suggesting that the victims should club together to pay a whopping $70 million one-time fee, in return for a universal decryption tool that would (or so the crooks claimed) work on any and every infected computer.
Nevertheless, if these suspects really are part of the modern big-money raonsomware underground, their arrest will surely do no harm, and may act as a disincentive to anyone currently sitting on the fringes of the cybercrime scene wondering if it’s worth the risk of getting fully involved.
