Perpetual IT

Right at the start of June 2023, well-known Russian cybersecurity outfit Kaspersky reported on a previously unknown strain of iPhone malware.

Most notable about the original story was its strapline: Targeted attack on [Kaspersky] management with the Triangulation Trojan.

Although the company ultimately said, “We’re confident that Kaspersky was not the main target of this cyberattack”, the threat hunting it was called upon to do wasn’t on customer devices, but on its own.

No user assistance required

Because the malware was apparently injected quietly and automatically onto infected devices, without needing users to make a security blunder or to “click the wrong button” to to give the malware its chance to activate, it was reasonable to assume that the attackers knew about one or more closely-guarded zero-day exploits that could be triggered remotely over the internet.

Typically, iPhone malware that can compromise an entire device not only violates Apple’s strictures about software downloads being restricted to the “walled garden” of Apple’s own App Store, but also bypasses Apple’s much vaunted app separation, which is supposed to limit the reach (and thus the risk) of each app to a “walled garden” of its own, containing only the data collected by that app itself.

Usually, bypassing both App Store restrictions and app separation rules means finding some sort of kernel-level zero-day bug.

That’s because the kernel is responsible for all the “walled gardening” protection applied to the device.

Therefore pwning the kernel generally means that attackers get to sidestep many or most of the security controls on the device, resulting in the broadest and most dangerous sort of compromise.

Emergency update is out

Well, three weeks after Kasperky’s original article, as a sort-of solstice present on 2023-06-21, Apple has pushed out patches for all of its supported devices (except for Apple TVs running tvOS), fixing exactly two critical security holes:

• CVE-2023-32439: Type confusion in WebKit. Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. [Credit given to “an anonymous researcher”.]
• CVE-2023-32434: Integer overflow in kernel. An app may be able to execute arbitrary code with kernel privileges. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.7. [Credit given to Georgy Kucherin (@kucher1n), Leonid Bezvershenko (@bzvr_), and Boris Larin (@oct0xor) of Kaspersky.]

Intriguingly, although Apple states no more than that the kernel zero-day (which we are assuming is directly connected with Kaspersky’s Triangulation Trojan attack) “may have been exploited on iOS before version 15.7”…

…every updated system, including watchOS and all three supported flavours of macOS, has been patched against this very kernel hole.

In other words, all systems (with the possible exception of tvOS, though that may simply not have received an update yet) are vulnerable, and it’s wise to assume that because attackers figured out how to exploit the bug on iOS, they might already have a very good idea of how to extend their attack to other Apple platforms.

What to do?

Patch early, patch often.

Or, if you prefer rhyme: Do not delay/Just do it today.

Head to Settings > General > Software Update right now to check that you’ve already got the needed patches, or to download them if you haven’t, and to push your device through the update installation process.

We force-updated our iPhone 16 and our (Intel) macOS 13 Ventura systems as soon as the updates showed up; the installation process took our devices out of action to complete the patches for approximately 10 and 15 minutes respectively.

Note that on macOS 11 Big Sur and macOS 12 Monterey, you’ll actually receive two updates, because the patches for the abovementioned WebKit bug are packaged up in a special update named Safari 16.5.1.

After you’ve updated, here are the version numbers to look for, along with the Apple Bulletins where they’re officially described:

---

Ransomware – as readers here know only too well – is one of the biggest cybercrime challenges we collectively face today.

That’s why Sophos has recently visited cities around the globe to dive deep into the real story behind ransomware.

We captured more than 100 hours of interviews with cybercriminals, cybersecurity experts, industry analysts, and policy makers to provide a full 360-degree perspective.

The result is Think You Know Ransomware?, a three-part documentary series that delves into the realities of ransomware, revealing the far-reaching consequences for both businesses and society at large.

Episode 1, Origins of Cybercrime, is now available to watch. It explores the history of ransomware as told by cybersecurity professionals, ransomware victims, and law enforcement officials.

Episodes 2 and 3 will be released over the next two weeks, with all episodes available at https://www.sophos.com/ransomware.

Please share the documentary series with friends, family members, or co-workers who would find it interesting and useful. The more we all know about ransomware, the better we can defend against it.

---

Researchers at Korean anti-malware business AhnLab are warning about an old-school attack that they say they’re seeing a lot of these days, where cybercriminals guess their way into Linux shell servers and use them as jumping-off points for further attacks, often against innocent third parties.

The payloads unleashed by this crew of otherwise unsophisticated crooks could not only cost you money through unexpected electricity bills, but also tarnish your reputation by leaving investigative fingers from downstream victims pointing at you and your network…

…in the same way that, if your car is stolen and then used in committing a offence, you can expect a visit from the cops to invite you to explain your apparent connection with the crime.

(Some jurisdictions actually have road laws making it illegal to leave parked cars unlocked, as a way of discouraging drivers from making things too easy for TWOCers, joyriders and other car-centric criminals.)

Secure in name only

These attackers are using the not-very-secret and not-at-all-complicated trick of finding Linux shell servers that are accepting SSH (Secure Shell) connections over the internet, and then simply guessing at common username/password combinations in the hope that at least one user has a poorly-secured account.

Well-secured SSH servers won’t allow users to login with passwords alone, of course, typically by insisting on some sort of alternative or additional logon security based on cryptographic keypairs or 2FA codes.

But servers set up in a hurry, or launched in preconfigured “ready-to-use” containers, or activated as part of a bigger, more complex setup script for a back-end tool that itself requires SSH, may start up SSH services that work insecurely by default, under the sweeping assumption that you will remember to tighten things up when you move from testing mode to live-on-the-internet mode.

Indeed, Ahn’s researchers noted that even simply password dictionary lists still seem to deliver usable results for these attackers, listing dangerously predictable examples that include:

root/abcdefghi
root/123@abc
weblogic/123 rpcuser/rpcuser test/p@ssw0rd nologin/nologin Hadoop/p@ssw0rd

The combination nologin/nologin is a reminder (like any account with the password changeme) that the best intentions often end in forgotten actions or incorrect outcomes.

After all, an account called nologin is meant to be self-documenting, drawing attention to the fact that it’s not available for interactive logins…

…but that’s no use (and may even lead to a false sense of security) if it is secure in name only.

What’s dropped next?

The attackers monitored in these cases seem to favour one or more of three different after-effects, namely:

• Install a DDoS attack tool known as Tsunami. DDoS stands for distributed denial-of-service attack, which refers to a cybercrime onslaught in which crooks with control over thousands or hundreds of thousands of compromised computers (and sometimes more than that) command them to start ganging up on a victim’s online service. Time-wasting requests are concocted so that they look innocent when considered individually, but that deliberately eat up server and network resources so that legitimate users simply can’t get through.
• Install a cryptomining toolkit called XMRig. Even if rogue cryptocurrency mining typically doesn’t generally make cybercriminals much money, there are typically three outcomes. Firstly, your servers end up with reduced processing capacity for legitimate work, such as handling SSH login requests; secondly, any additional electricity consumption, for example due to extra processing and airconditioning load, comes at your expense; thirdly, cryptomining crooks often open up their own backdoors so they can get in more easily next time to keep track of their activities.
• Install a zombie program called PerlBot or ShellBot. So-called bot or zombie malware is a simple way for today’s intruders to issue further commands to your compromised servers whenever they like, including installing additional malware, often on behalf of other crooks who pay an “access fee” to run unauthorised code of their choice on your computers.

---

---

As mentioned above, attackers who are able to implant new files of their own choice via compromised SSH logins often also tweak your existing SSH configuration to create a brand new “secure” login that they can use as a backdoor in future.

By modifying the so-called authorized public keys in the .ssh directory of an existing (or newly-added) account, criminals can secretly invite themsevles back in later.

Ironically, public-key-based SSH login is generally considered much more secure than old-school password-based login.

In key-based logins, the server stores your public key (which is safe to share), and then challenges you to sign a one-time random challenge with the corresponding private key every time you want to login.

No passwords are ever exchanged between the client and the server, so there’s nothing in memory (or sent across on the network) that could leak any password information that would be useful next time.

Of course, this means that the server needs to be cautious about the public keys it accepts as online identifiers, because sneakily implanting a rogue public key is a sneaky way of granting yourself access in future.

What to do?

• Don’t allow password-only SSH logins. You can switch to public-private key authentication instead of passwords (good for automated logons, because there’s no need for a fixed password), or as well as regular same-every-time passwords (a simple but effective form of 2FA).
• Frequently review the public keys that your SSH server relies on for automated logins. Review your SSH server configuration, too, in case earlier attackers have sneakily weakened your security by changing secure defaults to weaker alternatives. Common tricks include enabling root logins directly to your server, listening on additional TCP ports, or activating password-only logins that you wouldn’t normally allow.
• Use XDR tools to keep an eye out for activity you wouldn’t expect. Even if you don’t directly spot implanted malware files such as Tsunami or XMRig, the typical behaviour of these cyberthreats is often easy to spot if you know what to look for. Unexpectedly high bursts of network traffic to destinations you wouldn’t normally see, for example, could indicate data exfiltration (information stealing) or a deliberate attempt to perform a DDoS attack. Consistently high CPU load could indicate rogue cryptomining or cryptocracking efforts that are leeching your CPU power and thus eating up your electricity.

---

Note. Sophos products detect the malware mentioned above, and listed as IoCs (indicators of compromise) by the AhnLab researchers, as Linux/Tsunami-A, Mal/PerlBot-A, and Linux/Miner-EQ, if you want to check your logs.

---

ASUS is a well-known maker of popular electronics products, ranging from laptops and phones to home routers and graphics cards.

This week, the company published firmware updates for a wide range of its home routers, along with a strong warning that if you aren’t willing or able to update your firmware right now, then you need to:

[Disable] services accessible from the WAN side to avoid potential unwanted intrusions. These services include remote access from WAN, port forwarding, DDNS, VPN server, DMZ, port trigger.

We’re guessing that ASUS expects potential attackers to busy themselves probing exposed devices now that a lengthy list of bug-fixes has been published.

(Of course, well-informed attackers might have known about some, many, or all of these holes already, but we’re not aware of any zero-day exploits in the wild.)

As we’ve pointed out before on Naked Security, exploits are often much easier to figure out if you have signposts telling you where to look…

…in the same way that it’s much quicker and easier to find a needle in a haystack if someone tells you which bale it’s in before you start.

Do as we say, not as we do.

Annoyingly for ASUS customers, perhaps, two of the now-patched vulnerabilities have been around waiting to be patched for a long time.

Both of these have a 9.8/10 “danger score” and a CRITICAL rating in the US NVD, or National Vulnerability Database (reports paraphrased by us):

• CVE-2022-26376. Memory corruption in the httpd unescape functionality. A specially-crafted HTTP request can lead to memory corruption. An attacker can send a network request to trigger this vulnerability. (Base score: 9.8 CRITICAL.)
• CVE-2018-1160. Netatalk before 3.1.12 [released 2018-12-20] vulnerable to an out-of-bounds write. This is due to lack of bounds checking on attacker controlled data. A remote unauthenticated attacker can leverage this vulnerability to achieve arbitrary code execution. (Base score: 9.8 CRITICAL.)

To explain.

Netatalk is a software component that provides support for Apple-style networking, but this doesn’t mean an attacker would need to use a Macintosh computer or Apple software to trigger the bug.

In fact, given that a successful exploit would require deliberately malformed network data, legitimate Netatalk client software probably wouldn’t do the job anyway, so an attacker would use custom-created code and could theoretically mount an attack from any operating system on any computer with a network connection.

HTTP escaping and unescaping is needed whenever a URL includes a data character that can’t be directly represented in the text of the URL.

For example, URLs can’t include spaces (to ensure that they always form a single, contiguous chunk of printable text), so if you want to reference a username or a file that contains a space, you need to escape the space character by converting it to a percent sign followed by its ASCII code in hexadecimal (0x20, or 32 in decimal).

Similarly, because this gives a special meaning to the percent character itself, it too must be written as a percent sign (%) followed by its ASCII code (0x25 in hex, or 37 in decimal), as must other characters used distinctively in URLs, such as colon (:), slash (/), question mark (?) and ampersand (&).

Once received by a web server (the program referred to as httpd in the CVE information above), any escaped characters are unescaped by converting them back from their percent-encoded forms to the original text characters.

Why ASUS took so long to patch these particular bugs is not mentioned in the company’s official advisory, but handling HTTP “escape codes” is a fundamental part of any software that listens to and uses web URLs.

Other CVE-listed bugs patched

• CVE-2022-35401. Authentication bypass. A specially-crafted HTTP request can lead to full administrative access to the device. An attacker would need to send a series of HTTP requests to exploit this vulnerability. (Base score: 8.1 HIGH.)
• CVE-2022-38105. Information disclosure. Specially-crafted network packets can lead to a disclosure of sensitive information. An attacker can send a network request to trigger this vulnerability. (Base score: 7.5 HIGH.)
• CVE-2022-38393. Denial-of-service (DoS). A specially-crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability. (Base score: 7.5 HIGH.)
• CVE-2022-46871. Potentially exploitable bugs in the open-source libusrsctp library. SCTP stands for Stream Control Transmission Protocol. (Base score: 8.8 HIGH.)
• CVE-2023-28702. Unfiltered special characters in URLs. A remote attacker with normal user privileges can exploit this vulnerability to perform command injection attacks to execute arbitrary system commands, disrupt the system or terminate service. (Base score: 8.8 HIGH.)
• CVE-2023-28703. Buffer overflow. A remote attacker with administrator privileges can exploit this vulnerability to execute arbitrary system commands, disrupt the system or terminate service. (Base score: 7.2 HIGH.)
• CVE-2023-31195. Session hijack. Sensitive cookies used without the Secure attribute set. An attacker could use a bogus HTTP (unencrypted) web link to hijack authentication tokens that shouldn’t be transmitted unencrypted. (NO SCORE.)

Perhaps the most notable bug in this list is CVE-2023-28702, a command injection attack that sounds similar to the MOVEit bugs that have been all over the news lately.

---

---

As we explained in the wake of the MOVEit bug,s a command parameter that’s sent in a web URL, for example a request asking the server to start logging you on as the user DUCK, can’t be handed off directly to a system-level command by blindly and trustingly copying raw text from the URL.

In other words, the request:

https://example.com/?user=DUCK

…can’t simply be converted via a direct “copy-and-paste” process into a system command such as:

checkuser --name=DUCK

Otherwise, an attacker could try to logon as:

https://example.com/?user=DUCK;halt

…and trick the system into running the command:

checkuser --name=DUCK;halt

…which is the same as issuing the two separate commands below, in sequence:

checkuser --name=DUCK
halt

…where the command on the second line shuts down the whole server.

(The semicolon acts as a command separator, not as part of the command-line arguments.)

Session hijacking

Another worrying bug is the session hijack issue caused by CVE-2023-31195.

As you probably know, servers often handle web-based logins by sending a so-called session cookie to your browser to denote that “whoever knows this cookie is assumed to be the same person who just logged in”.

As long as the server doesn’t give you one of these magic cookies until after you’ve identified yourself, for example by presenting a username, a matching password and a valid 2FA code, then an attacker would need to know your login credentials to get authenticated as you in the first place.

And as long as neither the server nor your browser ever accidentally sends the magic cookie over a non-TLS, unencrypted, plain old HTTP connection, then an attacker won’t easily be able to lure your browser to an imposter server that’s using HTTP instead of HTTPS, and thus to read out the cookie from the intercepted web request.

Remember that luring your browser to an imposter domain such as http://example.com/ is comparatively easy if a crook can temporarily trick your browser into using the wrong IP number for the example.com domain.

But luring you to https:/example.com/ means that the attacker also needs to come up with a convincingly forged web certificate, to provide fraudulent server validation, which is much harder to do.

To prevent this sort of attack, cookies that are non-public (either for privacy or access control reasons) should be labelled Secure in the HTTP header that’s transmitted when they’re set, like this:

Set-Cookie: AccessToken=ASC4JWLSMGUMV6TGMUCQQJYL; Secure

…instead of simply:

Set-Cookie: AccessToken=ASC4JWLSMGUMV6TGMUCQQJYL

What to do?

• If you have an affected ASUS router (the list is here), patch as soon as you can. Just because ASUS left it for ages to get the patches to you doesn’t mean that you can take as long as you like to apply them, especially now that the bugs involved are a matter of public record.
• If you can’t patch at once, block all inbound access to your router until you can apply the update. Note that just preventing HTTP or HTTPS connections (web-based traffic) is not enough. ASUS explicitly warns that any incoming network requests could be abused, so even port forwarding (e.g. for games) and VPN access need to be blocked outright.
• If you’re a programmer, sanitise thine inputs (to avoid command injection bugs and memory overflows), don’t wait months or years to ship patches for high-scoring bugs to your customers, and review your HTTP headers to ensure that you’re using the most secure options possible when exchanging critical data such as authentication tokens.

---

For the third time in about a week, cybersecurity law-and-order news includes a criminal case that’s been brewing for more than a decade.

This time, the news is prison sentences for two of the main four original defendants in the infamous Megaupload saga.

If you weren’t following cybersecurity a decade ago, we’ll recap directly from the article we published at the time of the site’s takedown by the FBI in early 2012:

Megaupload’s larger-than-life founder, who these days answers to the name Kim Dotcom, certainly likes to show off.

He and his crew ran a bunch of swanky, top-of-the-range cars with in-your-face number plates such as GOOD, EVIL, MAFIA, HACKER, STONED, GOD and GUILTY.

But whether Dotcom turns out to be GUILTY or GOOD, he’s certainly in a lot of trouble right now. He was arrested at his sprawling mansion home in New Zealand last week [January 2012]. If the FBI gets its way, he’ll be extradited to the USA to be charged with a whole raft of offences.

Mr Dotcom, apparently born Kim Schmitz, isn’t just facing copyright offences, but is also charged with conspiracy to commit racketeering and money laundering.

The short version of FBI’s beef with Megaupload, or the Mega Conspiracy as the FBI describes it, is that the organisation generated revenue primarily as a side-effect of encouraging and rewarding the large-scale uploading and downloading of stolen content such as movies, music and complete TV shows.

Megaupload fans would say, “So what?”

Google’s search engine, they say, often links to infringing material, which lets it make money out of adverts surrounding dodgy online content.

Google’s YouTube video site, say file-sharing enthusiasts, offers bucketloads of unlawfully ripped videos and audio tracks, and unashamedly makes money from links to legitimate sites served up whilst doubtful videos are playing.

And as for Kim Dotcom’s eye-watering spending on fancy cars, didn’t Google’s founders do a deal with NASA to park their private Boeing 767 at Moffett Field?

Therefore, an inveterate sharer might argue, Megaupload and Google are just two sides of the same coin.

The FBI and the US courts disagree.

The affidavit lodged against the so-called Mega Conspirators paints a different picture: “In contrast to legitimate internet distributors of copyrighted content, Megaupload.com does not make any significant payments to the copyright owners of the many thousands of works that are willfully reproduced and distributed on the Mega Sites each and every day.”

The Mega Conspirators

Four men were identified as the chief movers-and-shakers in the Mega Conspiracy all those years ago.

There was the abovementioned larger-than-life Kim Dotcom, along with Mathias Ortmann, Bram van der Kolk, and Finn Batato, depicted here in silhouette at the founding of their followup company Mega, which cheekily launched on the anniversary of kim Dotcom’s larger-than-life arrest:

Batato, sadly, died of cancer in 2022.

Ortmann and van der Kolk challenged extradition for many years, but finally agreed to a deal where they’d be spared extradition in return for being charged, convicted and sentenced in Aotearoa.

(Aotearoa, in case you’re wondering, is the other official name for New Zealand, which is commonly abbreviated to NZ, and pronounced En Zed, in case you ever need to say it out loud.)

Dotcom continues to to insist that he’s a scapegoat and is challenging being sent to the US for trial, despite Aotearoa ruling that his extradition would be legal.

Megaupload, like its also-defunct contemporary RapidShare, was what became known as a file locker service.

That’s a file locker in the upbeat metaphorical sense of a sense of a gym locker, namely a cloud service where you can stash files for later download, not a file locker in the downbeat sense of file-locking ransomware that scrambles your files until you pay a blackmail demand to decrypt them.

The FBI claimed that Megaupload’s business model was really all about a few people uploading lots and lots of files, including ripped-off content, so that lots and lots of other people could download them for free…

…rather than simply being a file storage service where you could backup your own files indefinitely.

Simply put, the FBI considered it to be much, much more of an unlicensed megadownload service than the name Megaupload would suggest.

Sentenced at last

Ortmann and van der Kolk have now been sentenced, eleven years on, and the judge’s official report, though long at 38 pages, makes very interesting reading.

Early on, the court explicitly reminds us all that the concept of a cloud storage and file-sharing service is not intrinsically illegal, and reminds the defendants that they weren’t charged on that basis:

It is not suggested that any of the process of uploading files, being allocated a URL or sharing those URLs, itself breached any law.

However, the agreed summary of facts records that the overwhelming majority of Megaupload’s traffic consisted of content which was first, protected by copyright, and second, made available to users in breach of the rights of copyright owners.

You accept in the summary of facts that by operating Megaupload, you intended to obtain significant financial benefits from copyright infringement, to the detriment of copyright owners.

At the same time, the court argued that evidence in the case showed that the defendants knew full well that what they were doing would get them into trouble:

You also anticipated that, sooner or later, you would be the subject of legal action.

You discussed amongst yourselves the possibility of facing legal problems and the fact that this risk was increasing over time.

More importantly, the court noted that the two didn’t just anticipate legal challenges, but planned how they could pretend to react to takedown requests without actually doing so:

For example, in 2009, Mr Ortmann, you and Mr Dotcom discussed how to respond when lawsuits were threatened, and you suggested “promise some kind of technical filtering crap and then never implement it”.

The court also described how the defendants actively encouraged illegal uploaders in order to grow their subscription business, while knowingly disguising the publicly visible amount of infringing content:

For example, in January 2008, you, Mr van der Kolk, observed that it was counterproductive to disqualify any users from receiving payment “because growth is mainly based on infringement”. […]

Instead of showing the top 100 most downloaded files, Mr Dotcom and each of you curated 100 non-infringing files for the Megaupload’s “Top 100” page.

But in the event of a takedown request via the company’s Abuse Tool, only individual URLs would be removed, not the actual content they linked to:

Multiple uploads of the same file were “deduplicated”, so that multiple download URLs could ultimately point to the same file. […]

You accept in the summary of facts that this was a deliberate ambiguity, and that Megaupload’s overall concealment of its inner workings gave the impression that infringing content had been removed when it had not.

You accept that this was one of the key mechanisms which enabled Megaupload to disseminate infringing content freely, while falsely maintaining that it operated a robust and effective system to protect the interests of copyright owners.

You accept that you knew, and intended, that your response to takedown notifications would have no material effect on preventing access to copyright infringing content on your sites.

Not just the billion-dollar Big Guys

Interestingly, the court accepted that adjudicating the actual harm done to copyright holders in case like this “is a contentious topic”, and that just because international megacorporations insist that they suffer untold losses due to illegal downloading doesn’t make it true.

Notably, the court referenced a judgment in the English Court of Appeal in 2017, which questioned the typically enormous, often multi-billion-dollar, losses claimed by large corporate copyright holders:

[A]n estimate of losses based on royalties due per download was more “notional than real”, given “by no means everybody who downloaded tracks via the appellants’ website would have downloaded those tracks via legitimate means had they not been obtainable through them.”

But the court did stick up for the rights of smaller producers, who may not have suffered multi-million dollar losses, but were directly and personally harmed by piracy of their work:

However, it is not in dispute that the victims of your offending are not limited to large corporate owners of copyright protected material.

They include, for example, the numerous owners of the copied YouTube clips and smaller software developers and video producers.

As an example of the latter, I have been provided with a victim impact statement from a Timaru-based computer software developer.” [Timaru is a town on Aotearoa’s South Island.]

That local coder’s impact statement was described in court as follows:

[The Timaru developer] says that he submitted at least 10 to 20 takedown requests to Megaupload after he had noticed a decline in sales of his software towards the end of 2009, and finding pirated versions were being made available to him on the internet.

The victim notes that infringing copies of his software remained active on Megaupload after takedown requests were made, with the result that what he found to be a very time consuming process of putting in takedown notices was a waste of his time.

He states that piracy reduced his income to such an extent that it was no longer viable for him to work full-time on his software business, and while his product still yields a modest income, he was forced to take other jobs.

The victim responsibly notes that he cannot quantify how much Megaupload in particular contributed to the piracy problems he experienced.

How long should they get?

The court’s discussion on sentencing is interesting, noting that the prosecutors argued that the maiximum possible sentence should be taken as 14 years, while the defence argued for an absolute maximum of seven years for Ortmann and five years for van der Kolk.

After a lengthy review of related cases in New Zealand, England and the US (including the US sentence of one-year-and-one-day handed to another Mega employee who was extradited from the Netherlands to the US), the judge decided that maximums of 10 years 6 months and 10 years respectively were appropriate.

Ultimately, in view of that fact that the defendants ultimately pleaded guilty, will collectively pay back more than US$5,000,000 in reparations (though the judge did describe this as a “drop in the bucket”), and will assist the US authorities to the point of testifying against Kim Dotcom in any American prosecution, the defendants were sentenced to 25% of their potential maximums.

Interestingly, the defendants’ requests for their alleged mental heath issues (autism and ADHD respectively) to be taken into account in reducing their sentences were rejected by the judge, who reasoned as follows:

Given the contents of the summary of facts, I am unable to accept that your conditions somehow masked or prevented you from having the capacity to see “invisible” victims, given you were clearly aware of the harm you were causing to copyright holders and that doing so was unlawful.

Both defendants were convicted of conspiring to obtain documents dishonestly, conspiring to cause loss by deception, and on various charges of participation in an organised criminal group.

Accordingly, with their assorted sentences to be served concurrently, Mathias Ortmann was sentenced to 2 years 7 months in prison, and Bram van der Kolk to 2 years 6 months, those lengths being 25% of the maximum allowable sentences that the judge had settled upon.

What next?

Following their agreement to be charged and plead guilty in Aotearoa, and to assist the US authorities in its ongoing investigations, the Americans will no apparently longer seek their extradition.

The US will accept the Aotearoa court’s sentence as their ultimate criminal punishment in this long-running saga.

Kim Dotcom, of course, wasn’t part of this case, and is still fighting extradition to the US, so the saga is not over for him.

As my learned friend and colleague Doug Aamoth likes to say on the Naked Security podcast, “We will keep an eye on this.”

---