Perpetual IT

Researchers at application security company Jscrambler have just published a cautionary tale about supply chain attacks…

…that is also a powerful reminder of just how long attack chains can be.

Sadly, that’s long merely in terms of time, not long in terms of technical complexity or the number of links in the chain itself.

Eight years ago…

The high-level version of the story published by the researchers is simply told, and it goes like this:

• In the early 2010s, a web analytics company called Cockpit offered a free web marketing and analytics service. Numerous e-commerce sites used this service by sourcing JavaScript code from Cockpit’s servers, thus incorporating third-party code into their own web pages as trusted content.
• In December 2014, Cockpit shut down its service. Users were warned that the service would be going offline, and that any JavaScript code they imported from Cockpit would stop working.
• In November 2021, cybercriminals bought up Cockpit’s old domain name. To what we can only assume was a mixture of surprise and delight, the crooks apparently found that at least 40 e-commerce sites still hadn’t updated their web pages to remove any links to Cockpit, and were still calling home and accepting any JavaScript code that was on offer.

You can see where this story is going.

Any hapless former Cockpit users who had apparently not checked their logs properly (or perhaps even at all) since late 2014 failed to notice that they were still trying to load code that wasn’t working.

We’re guessing that those businesses did notice they weren’t getting any more analytics data from Cockpit, but that because they were expecting the data feed to stop working, they assumed that the end of the data was the end of their cybersecurity concerns relating to the service and its domain name.

Injection and surveillance

According to Jscrambler, the crooks who took over the defunct domain, and who thus acquired a direct route to insert malware into any web pages that still trusted and used that now-revived domain…

…started doing exactly that, injecting unauthorised, malicious JavaScript into a wide range of e-commerce sites.

This enabled two major types of attack:

• Insert JavaScript code to monitor the content of input fields on predetermined web pages. Data in input, select and textarea fields (such as you would expect in a typical web form) was extracted, encoded and exfiltrated to a range of “call home” servers operated by the attackers.
• Insert additional fields into web forms on selected web pages. This trick, known as HTML injection, means that crooks can subvert pages that users already trust. Users can believably be lured into entering personal data that those pages wouldn’t normally ask for, such as passwords, birthdays, phone numbers or payment card details.

With this pair of attack vectors at their disposal, the crooks could not only siphon off whatever you typed into a web form on a compromised web page, but also go after additional personally identifiable information (PII) that they wouldn’t normally be able to steal.

By deciding which JavaScript code to serve up based on the identity of the server that requested the code in the first place, the crooks were able to tailor their malware to attack different types of e-commerce site in different ways.

This sort of tailored response, which is easy to implement by looking at the Referer: header sent in the HTTP requests generated by your browser, also makes it hard for cybersecurity rearchers to determine the full range of attack “payloads” that the criminals have up their sleeves.

After all, unless you know in advance the precise list of servers and URLs that the crooks are looking out for on their servers, you won’t be able to generate HTTP requests that shake loose all likely variants of the attack that the criminals have programmed into the system.

In case you’re wondering, the Referer: header, which is a mis-spelling of the English word “referrer”, gets its name from a typographical mistake in the original internet standards document.

What to do?

• Review your web-based supply chain links. Anywhere that you rely on URLs provided by other people for data or code that you serve up as if it were your own, you need to check regularly and frequently that you can still trust them. Don’t wait for your own customers to complain that “something looks broken”. Firstly, that means you’re relying entirely on reactive cybersecurity measures. Secondly, there may not be anything obvious for customers themselves to notice and report.
• Check your logs. If your own website makes use of embedded HTTP links that are no longer working, then something is clearly wrong. Either you shouldn’t have been trusting that link before, because it was the wrong one, or you shouldn’t be trusting it any more, because it’s not behaving as it used to. If you aren’t going to check your logs, why bother collecting them in the first place?
• Perform test transactions regularly. Maintain a regular and frequent test procedure that realistically goes through the same online transaction sequences that you expect your customers to follow, and track all incoming and outgoing requests closely. This will help you to spot unexpected downloads (e.g. your test browser sucking in unknown JavaScript) and unexpected uploads (e.g. data being exfiltrated from the test browser to unusual destinations).

If you’re still sourcing JavaScript from a server that was retired eight years ago, especially if you’re using it in a service that handles PII or payment data, you’re not part of the solution, you’re part of the problem…

…so, please, don’t be that person!

---

Note for Sophos customers. The “revitalised” web domain used here for JavaScript injection (web-cockpit DOT jp, if you want to search your own logs) is blocked by Sophos as PROD_SPYWARE_AND_MALWARE and SEC_MALWARE_REPOSITORY. This denotes that the domain is known not only to be associated with malware-related cybercriminality, but also to be involved in actively serving up malware code.

---

A Florida man who was part of a cybercrime gang who went after cryptocoin wallets has been sentenced for his part in a cyberheist that allegedly netted the participants more than $20,000,000.

The scammers, including one Nicholas Truglia, 25, got control of various online accounts belonging to the victim by using a trick known in the trade as SIM swapping, also known as number porting.

Migrating your phone number

As you’ll know if ever you’ve lost a phone, or damaged a SIM card, mobile phone numbers aren’t burned into the phone itself, but are programmed into the subscriber identity module (SIM) chip that you insert into your phone (or perhaps, these days, that you install electronically in the form of a so-called eSIM).

So, a crook who can sweet-talk, or bribe, or convince using fake ID, or otherwise browbeat your mobile phone provider into issuing “you” (meaning them) a new SIM card…

…can walk out of the mobile phone shop [a] with your number in their phone, and [b] with your SIM card invalidated and thus unable to connect to the network to receive calls or get online.

Simply put, your phone goes dead, and theirs starts receiving your calls and text messages, notably including any two-factor authentication (2FA) codes that might get sent to your phone as part of a secure login or a password reset.

The SIM-swap problem, namely that the right to reissue replacement SIM cards is vested in too many different people at too many different seniority levels in too many mobile phone companies to control reliably), is why the US public service no longer recommends SMS-based 2FA for general use, and has disapproved it for government staff.

Bring on the cryptocoins

In this case, it seems that someone in the cybergang went after login details for the victim’s accounts, shared them with numerous other participants, and then got Truglia to act as a receiver for cryptocurrency funds drained from the victim.

Truglia then apparently disbursed the stolen funds back out to numerous other cryptocoin wallets owned by the other participants, keeping an unknown cut as his share of the deal.

The US Department of Justice (DOJ) notes that “[the] Scheme Participants stole over $20 million worth of the Victim’s cryptocurrency, with the defendant keeping at least approximately $673,000 worth of the stolen funds.”

Truglia received an 18 month prison term plus three years of supervised release to follow it, forfeited $983,010.72 right away, and has been ordered to pay back a whopping $20,379,007.

Quite how he will do that without the co-operation of the others in the scam, who seem to have divided most of that $20 million between themselves, and what happens if he doesn’t manage to convince them to do so, is not mentioned in the DOJ’s report.

What to do?

• Limit the amount of cryptocoinage you keep online and directly accessible. So-called cold wallets that can’t be accessed remotely will protect you from password and 2FA-stealing scams where remote criminals access your accounts directly.
• Consider switching away from SMS-based 2FA if you haven’t already. One-time login codes based on text messages are better than no 2FA at all, but they clearly suffer from the weakness that a scammer who decides to target you can attack your account without attacking you directly, and thus in a way that you yourself can’t reliably defend against.
• Use a password manager if you can. We don’t know how the criminals acquired the victim’s passwords in this case, but a password manager at least makes it unlikely that you will end up with passwords that an attacker could guess, or figure out easily from public informtion about you, such as your dog’s name or your child’s birthday.
• Watch out if your phone goes dead unexpectedly. After a SIM swap, your phone won’t show any connection to your mobile provider. If you have friends on the same network who are still online, this suggests that it’s probably you who is offline and not the whole network. Consider contacting your phone company for advice. If you can, visit a phone shop in person, with ID, to find out if your account has been taken over.

---

One of the first low-level network tools that any computer user learns about is the venerable ping utility.

Named after the eponymous sound effect from any and every old-school war movie scene involving submarines, the command is a metaphorical echo (see what we did there?) of the underwater version of RADAR known as SONAR.

You send out a p-i-n-g (more like a d-o-i-n-n-n-n-g noise, in reality) into the briny depths, and by measuring how long it takes for its eerie echo to come back to you, and by estimating the speed of sound in the surrounding ocean, you can compute the distance to the object that produced the echo.

Intriguingly, given that you’ve probably heard the abbreviation TCP/IP used as a generic description of the protocol glue that powers the internet, ping doesn’t technically use TCP/IP at all.

In fact, TCP/IP is short for transmission control protocol over the internet protocol, and refers to a fairly high-level mechanism for sending data over the internet in such a way that the network itself puts in a lot of the “did that actually work properly?” effort for you.

For example, in TCP connections, any chunks of data you send are guaranteed either to arrive intact at the other end or to cause an error so you know they didn’t make it.

Furthermore, even if different data chunks end up taking different routes across the internet (for example due to load balancing, temporary outages, or other recoverable errors), and even if some chunks take longer to arrive than others, TCP data will be correctly buffered up and presented in the right order at the other end.

Ping is different

The ping command, however, is typically used to verify if a computer you’re interested in is online at all, especially if it’s not accepting the sort of high-level TCP connections you’d expect, such as receiving email or allowing SSH logins.

This quickly helps you determine whether an outage is likely to be due to the network or the server itself going down, or due to individual services running on that server failing to start correctly.

As a result, ping uses a much lower-level protocol than TCP.

Indeed, ping doesn’t even use TCP’s more casual cousin UDP, short for user datagram protocol, which is a way of transmitting data chunks that is fast and easy, but is popularly referred to as send-and-hope (or, if you are a cynical sort, as spray-and-pray).

UDP itself doesn’t inform you whether your data got to the other end or not, and even if it arrives intact, UDP doesn’t keep track of the order in which your packets were originally sent, so it can’t rearrange them at the other end if they get there out of sequence.

Ping, for what it’s worth, uses a very-low-level-indeed protocol, specially designed for troubleshooting and network reconfiguration purposes, known as ICMP, or internet control message protocol.

Typically handled right in the operating system kernel, so that ICMP/IP packets are almost certain to get through even if no higher-level networking software has come up correctly, ICMP notably includes two special message types:

• Type 0x08. Officially called ICMP Echo, this sort of packet is usually called an Echo Request. It’s what the ping program sends out in order to probe for active computers on the network.
• Type 0x00. Officially called ICMP Echo Reply, this packet type is exactly what it says. A computer that is alive, online, and not configured to block ICMP Echo traffic is supposed to send this sort of packet straight back to the computer that requested it.

Like this:

$ ping -c 3 -p 4E414B45445345435552495459 nakedsecurity.sophos.com
PATTERN: 0x4e414b45445345435552495459
PING news-sophos.go-vip.net (192.0.66.227) 56(84) bytes of data.
64 bytes from 192.0.66.227 (192.0.66.227): icmp_seq=1 ttl=53 time=84.0 ms
64 bytes from 192.0.66.227 (192.0.66.227): icmp_seq=2 ttl=53 time=85.1 ms
64 bytes from 192.0.66.227 (192.0.66.227): icmp_seq=3 ttl=53 time=84.8 ms --- news-sophos.go-vip.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 84.025/84.644/85.062/0.446 ms

To see a ping in action at a slightly lower level, we’ll use the Lua code that you can find at the end of the article to construct an ICMP Echo packet of our own, and to read the reply that comes back, if any:

$ sudo luax ping.lua nakedsecurity.sophos.com
Sending ICMP ECHO request to 192.0.66.227 -->
00000000 08 00 03 02 bb 5a 6f 1d 50 69 6e 67 52 65 71 75 |.....Zo.PingRequ|
00000010 65 73 74 4d 65 73 73 61 67 65 20 42 42 35 41 36 |estMessage BB5A6|
00000020 46 31 44 |F1D |
Got back-->
00000000 45 00 00 37 f6 af 00 00 35 01 94 7f c0 00 42 e3 |E..7....5.....B.|
00000010 XX XX XX XX 00 00 0b 02 bb 5a 6f 1d 50 69 6e 67 |.........Zo.Ping|
00000020 52 65 71 75 65 73 74 4d 65 73 73 61 67 65 20 42 |RequestMessage B|
00000030 42 35 41 36 46 31 44 |B5A6F1D |

By the way, we needed to use sudo above to run our script with superuser privileges, because we created what’s known as a raw IP socket – one that can be crafted into any underlying format we like, including TCP, UDP and, as needed here, ICMP.

On many Linux/Unix systems, the ping command supplied by your distro works without explicitly being given root privileges, usually because it’s installed with special security capabilities, or with its setuid flag set, meaning it starts off with running under a different user account than the user who ran it.

Well-designed ping programs, of course, will automatically discard their extra privileges once they’ve opened up the raw socket they need.

We omitted this privilege-dropping code from our sample script for the sake of brevity. You can use the posix.unistd.setpid() function to switch to an unprivileged account after creating the socket, but before sending or receiving any data.

Examining the reply

As you might recognise in the data dump from our script above, the network socket function we’re using to read back data from the responding server includes not only the ICMP Echo Reply data, but also the low-level IP (internet protocol headers) in the underlying packet.

We haven’t tried to parse or otherwise process this data, but the FreeBSD ping program needs to do so in order to make sense of the reply, including making sense of any error messages that come back.

If the ping gets rejected in some way, the Echo Reply will typically include not only its own IP headers (as seen above) but also a reference copy of the IP headers and the ICMP data that appeared in the original outbound request.

IPv4 packet headers usually look much like you see above, where the IP headers start with 45 00 00 37... and continue for 20 bytes in total, up to and including the bytes shown as ...XX XX XX XX, which is the IP address of my laptop.

Like this:

00000000 45 00 00 37 f6 af 00 00 35 01 94 7f c0 00 42 e3 |E..7....5.....B.|
00000010 XX XX XX XX |.... | IP version and header length: 0x45 (4 = IPv4, 5 = five 32-bit words, i.e. 20 bytes Service type and congestion data: 0x00
Total length of packet: 0x0037 (decimal 55)
Sequence information: F6 AF 00 00
Time-to-live (hops left): 0x35 (decimal 53)
Protocol type: 0x01 (ICMP)
Checksum: 0x947F (decimal 38015)
Sending computer's IP number: C0 00 42 E3 (192.0.66.227 = nakedsecurity.sophos.com)
Recipient's IP (my laptop): XX XX XX XX (REDACTED = my own IP number)

FreeBSD’s ping programmers, it seems, assumed that headers of this sort would, indeed, always be exactly 20 bytes long, based on that header-length value in the first byte of 0x45, denoting IPv4 (0x4?) with a 5-DWORD (0x?5), or 20-byte, header.

With just 20 bytes to worry about, the programmers allocated fixed-size buffers on the stack where they could keep a copy of the IP headers in the reply, plus any embedded IP headers from the original request, if there was an error condition to handle.

You can guess where this is going.

That first byte in the IPv4 header can legally have any value from 0x45 (the minimum header size of 5 DWORDs, or 20 bytes, as shown) up to 0x4F (denoting 15 DWORDs, because 0xF is decimal 15, or 60 bytes of header data in total), thus neatly allowing for an optional extra 40 bytes of header data.

Those rare, but legal, extra header bytes can be used for various funky and unusual “features” with curious names such as Selective Directed Broadcast, Experimental Flow Control and Upstream Multicast Packet – things that we’ve heard of but never knowingly used, or even seen.

Beware cybercriminals who put you to the test

As you can imagine, given that those extra fields are almost never used, you might never see an IPv4 packet with anything other than 0x45 at the start, and with 20 bytes of header data in total, unless you’ve run into a bunch of cybercriminals who are ready to put you to the test.

Sadly, there’s not much to stop an attacker from rigging up a server that guesses whether you’re using FreeBSD, and deliberately generates oversized ICMP/IP Echo Reply packets in order to provoke a stack buffer overflow inside your ping program.

If ever you check to see if their server is active (which you might do even, or perhaps especially, if you think it’s suspicious!), you could be targeted with a booby-trapped reply.

At best, your ping program will crash; at worst, however, as the FreeBSD security advisory generously admits, “it may be possible for a malicious host to trigger remote code execution in ping.”

Fortunately, as the FreeBSD authors also point out, “[t]he ping process runs in a capability mode sandbox on all affected versions of FreeBSD and is thus very constrained in how it can interact with the rest of the system at the point where the bug can occur.”

In other words, you definitely need to patch, but the risks can be considered modest.

Notably, the ping program is not only locked in a sandbox, but isn’t running as root when the buggy code gets reached, as confirmed in the security advisory: “When ping runs, it creates the raw socket needed to do its work, and then revokes its elevated privileges.”

As described above, superuser powers are required only to acquire a raw IP socket from the operating system, not to use the sendto() and recvfrom() functions on that socket afterwards.

This bug has been given the official identifier CVE-2022-23093; it is documented in the security advisory FreeBSD-SA-22:15.ping.

What to do?

• If you’re a FreeBSD user, simply update the affected releases (FreeBSD 12 and FreeBSD 13) to their latest versions, where this bug is fixed.
• If you’re a network programmer, always ensure that you have accounted for packet headers that could indicate unusual size variations. The fact that you’ve never seen any variation yourself doesn’t stop you facing a packet tomorrow that is out-of-the-ordinary yet perfectly legal.
• If you’re a network manager, consider blocking IPv4 packets with IP headers that aren’t 20 bytes in size. If you genuinely seem to need to allow some software products to use unusual IPv4 header options, consider logging those unusual packets to learn why.

Take care out there!

---

EXAMPLE CODE TO DEMONSTRATE PING TRAFFIC

---

It’s just under two weeks since Google rushed out a Chrome patch for the then-current version 107 to seal off a bug that was already being used in real-life attacks.

The company said nothing more about that bug than to describe it as a “heap buffer overflow in GPU” [sic], and to report that it was already being used in real-world attacks.

Google left all of the following questions unanswered:

• How might the bug might be triggered? Was merely viewing a booby-trapped web page enough?
• Could it be abused for remote code execution? Could the crooks end up installing malware without any visible warning?
• Who was using it? Were they state-sponsored attackers, or some other sort of cybercriminals?
• What they were after? Were they into data stealing, ransomware attacks, unlawful surveillance, or all of those things?

To be clear, many, if not most, memory bugs never quite end up getting turned into remote code execution (RCE) attacks.

Altough a buffer overflow often makes it easy to crash a program, thus causing it to stop responding, it isn’t always easy to figure out how trigger the bug with sufficient precision to grab control over the app itself.

(Often, the misbehaviour provoked by the bug will be detected as some sort of access violation by the operating system, which will kill off the program before it can be tricked into going rogue.)

In this case, of course, the bug was already actively being exploited, which implied that an RCE exploit had indeed been found, and that the attackers knew how to do much worse than merely to crash your browser.

More Chrome updates

Shortly after the GPU heap overflow patch, a new Chrome version, numbered 108, came out with no fewer than 28 security fixes, including patches for numerous of memory mismanagement flaws, at least some of which we assume could ultimately have been wrangled into RCE exploits.

Fortunately, none of those 28 bugs were known to be “in the wild”, meaning that they seem to have been found and reported by responsible cybersecurity researchers before any cybercriminals or state-sponsored hacking teams figured them out.

Unfortunately, Google has already needed to publish a follow-up security update for its ninth zero-day of the year 2022, bringing Chrome to version 108.0.5359.94 for Mac and Linux, and to 108.0.5359.94 or 108.0.5359.95 for Windows.

Once again, the security report is ultra-terse, this time noting only that:

• CVE-2022-4262 is the official bug designation.
• Type confusion in V8 is the basis of the bug.
• An exploit already exists and is being abused in the wild.

As we’ve explained before, V8 is Google’s JavaScript subsystem, responsible for compiling and running any JavaScript programs embedded in any web pages you visit.

Type confusion in JavaScript is where a block of memory that’s supposed be used in one sort of calculation inadvertently gets consumed and trusted by a different algorithm.

For example, mixing up a 64-bit unsigned integer and a 64-bit floating point number will typically throw your calculation off horrendously, because the internal layouts of the two number formats are incompatible.

But treating, say, a 64-bit unsigned integer that can safely contain any numerical value you like, such as an encoded date and time, as a memory pointer that specifies a program subroutine to be called next…

… could lead to deliberate deviation of the code flow in the program.

You won’t just get incorrect results; you’ll end up with RCE: a local program under malicious remote control because it was tricked into running untrusted code that was sent in from outside.

What to do?

Even if you’ve checked your Chrome version in the past few days, we recommend checking again by opening Chrome’s Three-dot menu (⋮) and then choosing Help > About Chrome.

As mentioned above, you are looking for version 108.0.5359.94 for Mac and Linux, and for version 108.0.5359.94 or 108.0.5359.95 for Windows.

(By the time you read this, there may have been further updates, so consider the above version numbers to be the minimum you want.)

Edge, as you almost certainly know, is based on Chromium, the open source core of Google’s Chrome project, and Chromium also uses V8 for handling JavaScript.

This makes it almost certain that Edge has this bug, too, but at the time of writing [2022-12–4T23:30Z] Microsoft hadn’t announced an update to patch against it.

We therefore recommend keeping an eye on Microsoft’s official release notes so you know when the Edge update arrives.

---

It’s just under a month since iOS 16.1.1 came out for Apple iPhone users, fixing a pair of bugs that were listed with the worrying words “a remote user may be able to cause unexpected app termination or arbitrary code execution”.

Both macOS 13 Ventura and iPadOS got updated at the same time, with a pair of security bulletins published on Apple’s web site.

Now, there’s another security update, apparently moving iPhone users only up to version iOS 16.1.2.

We did it so we could report back to you

We have installed it, and after a comparatively modest download (by Apple standards, at least) of about 250MBytes, the reboot-and-update process completed reassuringly quickly, and our phone still seems to be working just fine.

But this update is mysterious even by Apple’s usually tight-lipped standards, with the company living up to, and perhaps even beyond, its official statement that the it “doesn’t disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are generally available.”

Apple insists that this veil of secrecy exists “[f]or the protection of our customers”, and if silence really is golden when it comes to cybersecurity updates, then we can only assume there’s an awfully serious bug getting fixed this time round.

Indeed, we haven’t yet received an Apple Security Advisory email, which is the usual way we hear about the latest patches, and Apple’s official security update portal HT201222 says nothing more than this:

iOS 16.1.2 (details available soon) – iPhone 8 and later – 30 Nov 2022

It’s now 2022-12-02, two days after than the official release date shown above, and we can’t tell you anything more than what we learned from the popup that appeared when we went to Settings > General > Software Update.

This assured us that “this update provides important security updates”, and sent us back on a fruitless loop back to the uninformative HT201222 page for “information about the security content”:

As you can see from the HT20122 screenshot above, this is, for now at least [2022-12-02T21:00Z], an iPhone-only patch, with no updates listed for any versions of iPadOS, macOS or Apple’s Watch and TV platforms.

What to do?

As mentioned above, we updated right away, on the grounds that the mystery only served to convince us that something serious was probably afoot…

…and because we are in the fortunate position of having an Android phone to fall back on if something goes wrong.

We therefore figured we’d take one for the team (by which we mean for the Naked Security community!) and see if there were any compelling reasons to advise you against the update.

Fortunately, we didn’t encounter any trouble that made us think you shouldn’t update, and many iPhone users probably either already have or will soon receive the update automatically.

But if, like us, you prefer to have at least some technical information to go on first, then, as we pointed out right in the headline itself, you’ll find Apple less communicative than ever this time.

Keep your eyes on that HT20122 portal page to keep up with the full story, and to watch out in case other Apple platforms (e.g. iPadOS, macOS) or earlier supported versions (e.g. iOS 15) get belated-but-related updates for the same security holes.

You’re welcome.

---