Perpetual IT

Security holes in WordPress plugins that could allow other people to poke around your WordPress site are always bad news.

Even if all you’re running is a basic setup that doesn’t have customer accounts and doesn’t collect or process any personal information such as names and email addresses…

…it’s worrying enough just knowing that someone else might be messing with your content, promoting rogue links, or publishing fake news under your name.

But security holes in plugins that you use to support online payments on your site are another level of worry altogether.

Unfortunately, popular e-payments platform WooCommerce has just notified users as follows:

On 2023-03-22, a vulnerability was discovered within WooCommerce Payments that, if exploited, could permit unauthorized admin access to impacted stores. We immediately deactivated the impacted services and mitigated the issue for all websites hosted on WordPress.com, Pressable, and [WordPress VIP].

Fortunately, it seems that the bug was found as part of an officially-sanctioned penetration test conducted by a Swiss security researcher, and WooCommerce seems confident that no one else had figured out the flaw before they found out about it themselves:

As soon as the vulnerability was reported, we began an investigation to ascertain whether any data had been exposed or if the vulnerability had been exploited. We currently have no evidence of the vulnerability being used outside of our own security testing program. We shipped a fix and worked with the WordPress.org Plugins Team to auto-update sites running WooCommerce Payments 4.8.0 through 5.6.1 to patched versions. The update is currently being automatically rolled out to as many stores as possible.

To change passwords or not to change?

Interestingly, WooCommerce suggests that even if attackers had found and exploited this vulnerability, the only information about your logon passwords they’d have been able to steal would have been so-called salted password hashes, and so the company has written that “it’s unlikely that your password was compromised”.

As a result, it’s offering the curious advice that you can get away without changing your admin password as long as [a] you’re using the standard WordPress password management system and not some alternative way of handling passwords that WooCommerce can’t vouch for, and [b] you’re not in the habit of using the same password on multiple services.

Forgive us for asking, but you don’t share passwords between any sites, let alone sharing the admin account password to your e-commerce system, do you?

However, the company does urge you to “chang[e] any private or secret data stored in your WordPress/WooCommerce database”, notably including data such as authentication tokens, session cookies, or API keys – the jargon names given to what are essentially temporary passwords that your browser (or other software) can add to future web requests to get immediate access.

These “part-time passwords” are there to allow the server to infer that you went through a full-on logon process recently enough for you and your pre-authorised apps to be trusted, without forcing you to share your actual primary password with every app or brower tab that’s going to be making programmatic requests on your behalf.

Because you generally need to copy-and-paste authentication tokens into other apps so that they can use them without requiring you to type them in every time, they’re typically stored in plaintext form, not in salted-and-hashed form like your primary password.

Simply put, even though criminals with admin-level access to your account can’t retrieve the actual text of your primary password, they typically can (and will, if give a chance to do so), get hold of the plaintext of any authentication tokens you’ve created for your account.

The “authentication token” process is a bit like having to show full photo ID in order to get past reception in an office building, after which you’re given an access card that will let you swipe back in and out as much you like, and to move around inside the building, albeit only for a limited time.

If someone steals your photo ID, it won’t do them much good unless they look just like you, because the details will be carefully scrutinised when they present it.

But if they get hold of your access card while you’re inside the building, they can sneak around under cover of being you, because the comparative difficulty of acquiring the access card in the first place means that it’s assumed to be be a reliable way of identifying you, at least temporarily.

What to do?

• Check that you have a patched version of the WooCommerce Payments WordPress plugin. The company claims that sites hosted by WordPress, Pressable and WordPress VIP should already have been updated for you, but we recommend checking anyway. Instructions on how to check (and how to patch if needed) can be found on the WooCommerce developer blog. Each of the company’s nine (!) officially supported product versions, from 4.8.x to 5.6.x, has its own update.
• Get all administrators on your site to change their passwords. WooCommerce suggests that you should be OK even if you don’t change your password, because attackers would need to crack any stolen password hashes first. But your password hashes weren’t supposed to be at risk of exposure in the first place, so changing them now is a sensible precaution. Remember that cybercriminals don’t have to crack stolen hashes right away. They only have to crack one or more of them before you get around to invalidating those hashes by changing the passwords from which they were calculated.
• Cancel all current Payment Gateway and WooCommerce API keys. Generate new keys, as explained in WooCoomerce’s documentation, so that any compromised authentication data is useless to crooks who may have acquired it.

DELETED DATA THAT JUST WON’T GO AWAY

The mobile phone bugs that Google kept quiet, just in case. The mysterious case of ATM video uploads. When redacted data springs back to life.

With Paul Ducklin and Chester Wisniewski. 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

Just yesterday, we wrote about a bug in Google Pixel phones, apparently now patched, with potentially dangerous consequences.

The bug finders, understandably excited (and concerned) by what they’d found, decided to follow the BWAIN principle for maximum, turning it into a Bug With An Impressive Name: aCropalypse.

In case you’re wondering, the word apocalypse literally means any sort of revelation, but it’s usually used to refer to the biblical text known as the Revelation of St. John, which portrays the end of the world.

Thus its metaphorical meaning, in the words of the New Oxford American Dictionary, is “an event involving destruction or damage on an awesome or catastrophic scale.”

We’re not quite convinced that this bug deserves quite such an, ahhhh, apocalyptic name, but we’re willing to concede that in a world where awesome can mean “quite good”, the name is probably acceptable, if not entirely unexceptionable.

The “Crop” in “aCropalypse”

The “crop” part of the name comes from the activity that is most likely to trigger the bug, dubbed CVE-2023-20136 in its Google incarnation: cropping photos or screenshots to remove sensitive or unwanted parts before you share them.

Loosely speaking, you can imagine that if you took, say, a 1080×1980 screenshot of your phone’s entire screen, you probably wouldn’t want to post the entire image online, or to send the whole thing to a friend.

Most people would prefer to crop off at least the top of the screenshot, thus removing details such as the name of their mobile provider, the date and the time.

And if you were snapping, say, an email or a social media posting in the middle of a list, you’d almost certainly want to obscure the emails or postings that appeared just above or just below the portion of interest.

Even after croppping the image, you might also want to redact parts of it (a jargon word meaning to obscure or censor part of a document), for example by dropping a black box over the sender’s name, email address, telephone number, or whatever.

At any rate, you might assume that if you chopped out chunks of the original, obscured some details with blocks of solid colour (which compress much more readily than regular image data), and saved the new image over the old one…

…that the new image would almost certainly be smaller, possibly much smaller, than the original.

Because of all the stuff you left out!

But that isn’t what happened on Google Pixel phones, at least until the March 2023 Android security update.

Overwritten but not truncated

The new, smaller, image file would be written over the start of the old one, but the file size would remain the same, and the now-redundant and unwanted data at the end of the original file would stay where it was.

If you sent that file to someone else and they opened it with a conventional image viewing or editing tool, their software would read the file until it reached a data chunk that said, “That’s it; you can stop now and ignore any trailing data in the file.”

In other words, the coding flaw that caused unwanted data to be left behind at the end of the file wouldn’t generally provoke any obvious errors, which presumably explains why the bug wasn’t spotted until recently.

But if the recipient opened it with a more inquisitive software tool, such as a hex editor or a cunningly modified image editor, anywhere from a few bytes to a vast amount of the original image would still be there, past the official end-of-image marker, waiting to be explored and potentially exposed.

Most screenshots are saved as PNG files, short for portable network graphics, and are internally compressed using a compression algorithm known commonly as deflate.

The left-over data therefore doesn’t look obviously like rows and columns of pixels, and it can’t be directly decompressed by conventional unpacking tools, which will consider the compressed data stream to be corrupt, which it is, and will usually refuse to try unpacking it at all.

But deflate compression typically squeezes its input data as a sequence of blocks, looking back only so far in the input for repeated text (32 Kbytes at most, for matches at most 258 bytes long) in order to reduce the amount of memory needed to run the algorithm.

Those restrictions aren’t just down to the fact that the format dates back to the 1990s, when memory space was much more precious than today.

By “resynchronising” the compressor on a regular basis, you also reduce the risk of losing absolutely everything in a compressed file if even just a few bytes at the start were to get corrupted.

Substantial reconstruction may be possible

This means that image files stored in compressed PNG format can often be substantially reconstructed, even if sizeable chunks of the original are overwritten or otherwise destroyed.

And if you’re talking about image fragments that can be reconstructed from a file that’s been cropped or redacted…

…there’s clearly a chance that the left-over data at the end, that was supposed to be chopped off, will contains recoverable image portions revealing the very parts you intended to remove permanently from the image!

You could get lucky, to be sure: if the image is stored row-by-row (so the data for top of the image is close to the start of the file, and the bottom is at the end), and you crop off the top of the image, you will probably end up with a new image consisting of the bottom half of the old image in the “official” part of the file, and the bottom half repeated in the left-over data that was supposed to be chopped off but wasn’t.

But if you crop off the bottom of the image, the new file will have the old top part “officially” re-encoded and written over the start, and the cropped-off bottom half of the image left behind exactly where it was before, in the unofficial end of the new file, waiting to be extracted by an attacker.

Windows 11 affected too

Well, the deal is that this problem of files not being truncated when they are replaced with new version also applies on Windows 11, where the Snipping Tool, like the Google Pixel Markup app, will let you crop an image without correctly cropping the file it’s saved into.

For example, here’s a PNG file we created with GIMP, and saved with a minimal set of headers and no compression:

The file is 320×200 pixels of 8-bit RGB data (three bytes per pixel), so the file is 320x200x3 bytes long (192,000), plus a few hundred bytes of header and other limited metadata, for a total size of 192,590 bytes.

In the illustrative hex dump below, you can see that the data is 0x20F04E bytes long, which is 192,590 in decimal:

We then cropped it as small as the Snipping Tool will allow (48×48 pixels seems to be the minimum) and saved it back over itself, but the “new” file ended up the same size as the uncompressed 320×200 file!

In the hex dump below, the portion highlighted in pink at the top is the entirety of what the cropped file is supposed to contain, at 0xBD bytes long, or 189 in decimal.

The new data concludes with an IEND data block, which is where the new file should end, but you can see it continues with the left-over data from before, ultimately finishing with a duplicate-but-now-redundant IEND block that has been carried over from the old file, along with almost all of its image data:

When we used the Save button to write it out under a brand new filename, the compressed 48×48 file did indeed come out at just 189 bytes long.

Note how the data in the file matches the 189 bytes highlighted in pink in the previous image:

The bug, therefore, is that saving a file back over an existing filename doesn’t truncate the old file first, and doesn’t create a new file with the expected size.

Simply put, the cropped file is partially overwritten, rather than actually replaced.

As mentioned above, we’re guessing that no one spotted this flaw until now because image viewing and editing programs read up until the first IEND tag (you can see this at the bottom right corner of the screenshot above), and silently ignore all the extra stuff at the end without reporting any anomalies or errors.

What to do?

• If you’re a Windows 11 user. Always save cropped files created with the Snipping Tool under a new filename, so there is no original content in it that can get left behind.
• If you’re a programmer. Review everywhere you create “new” files by overwriting old ones to make sure you really are truncating the original files when you open them for rewriting. Or only ever create new files by saving them to a genuinely new file first (use a securely-generated unique filename), then explicitly deleting the original file and renaming the new one.

By the way, we tested Microsoft Paint, and as far as we can see, that program will create cropped files with no left-over data from before, whether you use Save (to replace an existing file) or Save As (to produce a new one).

LEARN ABOUT FILE OPEN MODES FOR YOURSELF

Compile this code and run it.

On Windows, you can use minimalisti-C, our own curated build of the free Tiny C Compiler, if you don’t have a development system installed.

It’s under 500 KBytes in size (!), including full source code, compared to gigabytes each for Visual Studio or Clang for Windows.

#include <fcntl.h>
#include <stdio.h> int main(void) { char* az = "ABCDEFGHIJLKMNOPQRSTUVWXYZ"; int fd; // Create a file with A-Z in it // Octal 0666 means "read/write for everyone" // O_CREAT means create if needed fd = open("blah1.txt",O_WRONLY+O_CREAT,0666); write(fd,az,26); close(fd); // Create another file with A-Z in it fd = open("blah2.txt",O_WRONLY+O_CREAT,0666); write(fd,az,26); close(fd); // Write 10 bytes without O_TRUNC set // The left-over 16 bytes should remain fd = open("blah1.txt",O_WRONLY); write(fd,"----------",10); close(fd); // Write 10 bytes *with* O_TRUNC set // Left-over old data should be chopped off fd = open("blah2.txt",O_WRONLY+O_TRUNC); write(fd,"==========",10); close(fd); return 0;
}

Note the different between opening an existing file for writing (O_WRONLY) with and without setting the O_TRUNC flag.

Print out the contents of blah1.txt and blah2.txt after running the test program:

C:\Users\duck\CROP> petcc64 -stdinc -stdlib test.c
Tiny C Compiler - Copyright (C) 2001-2023 Fabrice Bellard
Stripped down by Paul Ducklin for use as a learning tool
Version petcc64-0.9.27 [0006] - Generates 64-bit PEs only
-> t1.c
-> c:/users/duck/tcc/petccinc/fcntl.h . . . .
-> C:/Windows/system32/msvcrt.dll
-> C:/Windows/system32/kernel32.dll
------------------------------- virt file size section 1000 200 2a0 .text 2000 600 1cc .data 3000 800 18 .pdata
-------------------------------
<- t1.exe (2560 bytes) C:\Users\duck\CROP> t1.exe C:\Users\duck\CROP>dir blah*.txt
Volume in drive C has no label.
Volume Serial Number is C001-D00D Directory of C:\Users\duck\CROP 22/03/2023 07:20 pm 26 blah1.txt
22/03/2023 07:20 pm 10 blah2.txt 2 File(s) 36 bytes C:\Users\duck\CROP> type blah1.txt
----------KLMNOPQRSTUVWXYZ C:\Users\duck\CROP> type blah2.txt
==========

Even if you’ve never used one, you probably know what a VCR is (or was).

Short for video cassette recorder, it was how we recorded and watched back videos at home in the days when digital video stored on hard disks was the absurdly expensive privilege of huge companies, typically TV stations.

The cassettes were small plastic containers that held two reels and a long strip of magnetic recording tape – kind of like an old-school hard disk, but with the magnetic surface arranged in a long strip of…

…well, of plastic tape, 12.7mm wide (that’s 1/2″ exactly) and about 100m long for every hour of recording.

(Tapes were sold with identifiers such as E-120, meaning PAL or SECAM recording, as used in most of the world, 120 minutes long, or T-180, for three hours of NTSC-format recording, the TV standard used in North America and Japan).

Leftover data revealed at the end

Few TV shows were exactly the length of a tape, so when you recorded a show, you’d usually have at least a bit of tape left at the end of the reel, which would be blank.

When you watched back, say, a 45-minute show recorded on an E-60 tape, you’d get 15 minutes of video fuzz (commonly known as “static”) if you left the tape running when the show had finished, until the VCR detected the end of the reel and obligingly rewound the cassette for next time.

Unless, of course, you (or the friend who’d lent you the tape) had used it before, and recorded something longer than 45 minutes…

…in which case you’d end up watching the last part of whatever was left over from the time before, and when that ended, what was recorded the time before that, or the time before that, and so on.

You get the picture.

The cut-over was never very clean, because the VCR would typically lose track of the video signal when the first recording ended, and play back a mish-mash of slanting lines, partial frames that jumped around on the screen, blurry washes of colour, and a weird, garbled mix of different audio soundtracks.

For a while, anyway.

Typically, however, the VCR would “realign” itself with the leftover data from the previous recording, resynchronise with the old video stream, and the messed-up, unintelligible nonsense on the screen would vanish.

You’d be cast into the tail-end of an unknown TV show, watching a vacation recording, or viewing some other sort of home video, most (but not all!) of which had been lost when it was recorded over.

In truth, unless you erased the entire tape first, before recording over it, you’d almost always leave some unexpected, and perhaps unwanted, previous content at the end.

The “aCropalypse” bug

Well, a UK cybersecurity researcher called David Buchanan has just published an article about a bug of this sort…

…in the image editing tool on Google’s Pixel phones.

The offending software is apparently known as Markup, and it lets you take photos or screenshots that are already on your phone, and crop or otherwise edit them to remove unwanted details before sending them on to your friends or uploading them to online services.

For instance, you might want to crop someone out of the picture to oblige their request not to have their face shared, or to block out a username or account ID in a software screenshot, or to obscure someone’s house number so as not to give away their address.

As you can imagine, especially when you crop a picture to reduce its size, the resulting image file often ends up smaller than the one you’re replacing.

Markup, apparently, would deal with smaller-than-before images by writing the new image over the old one (like your Dad or your Grandfather recording this week’s football match over the game on last week’s VCR tape), and then truncating the image file to its new, shorter size.

The old data – the tail-end of last week’s football game, in our VCR analogy – would remain behind on the storage device, but it would no longer be part of the digital file containing the new image.

In other words, when you opened the new file, you wouldn’t have the VCR problem of leftover image content being included in it, because the operating system knew to stop reading (or copying) the file at the right point.

The leftover data therefore couldn’t accidentally be leaked if you sent the new file to someone else, or uploaded it to a cloud service.

An attacker would typically need physical access to your phone, need to know how to unlock it and get root privileges, and be able to do a low-level forensic image of the unused data to recover any previously-deleted stuff.

Except for the bug.

To truncate or not to truncate?

As Buchanan discovered, the Java programming function that Markup used to “open the existing file in truncate mode” (meaning that unused data left over after you’d finished rewriting it would be chopped off from the end of the file)…

…was changed, apparently about two years ago, to “open in rewrite mode with no truncation when finished”.

In other words, if you opened the old file and wrote just one solitary byte at the start before closing it, the new file would not be one byte long with the rest chopped off, as you might expect, but would be the old file, in its entirety, with only the first byte changed.

The rest would be intact – not at all what was intended!

As Buchanan found, even though the leftover data from the previous version of the image was incomplete, and would be left alone if the file were opened with a regular image viewer (which would read as much as it needed and ignore the extra stuff at the end)…

…you could nevertheless extract that leftover image data and often make some sense out of it, even though you might end up with a stream of compressed data that started part-way through a compressed block.

Like those VCR tapes, where the VCR player might not be able to synch with the leftover recording immediately, a specially-written PNG file decompressing program might not be able to make sense of the first few chunks of the leftover data, but could often reconstruct blocks of the previous image that followed later on.

Like those VCR tapes, where the leftover part might not be worth much all on its own, you could never be quite sure what had been left behind, and anyone digging into your files might sometimes get lucky with the chunks they managed to reconstruct.

That means they might uncover image fragments from the end of the previous version that were exactly what you had intended to remove.

Loosely speaking, the more you’d cropped and shrunk the original file, the more leftover data would remain behind, and the greater the chance that some of it was just what you didn’t want to share.

What to do?

• Patch now. Google has apparently patched the Markup program in the March 2023 security update of Android. You can track this bug-fix with the identifier CVE-2023-20136.
• Revisit images you’ve already shared. Images you’ve cropped and shared already are too late to fix. But you may want to consider removing them anyway, or replacing them with re-edited images created with the patched version of Markup.
• Consider editing security-critical images conservatively on your laptop. File formats such as PNG can also include comments and so-called metadata (e.g. location information or camera details) that you never intended to share, let alone inadvertently retaining leftover pixels from before.

Command-line image manipulation tools such as ImageMagick or GraphicsMagick, and open-source tools such as GNU Image Manipulation Progam, allow you to convert edited images into formats where you control the content precisely.

For example, raw RGB files include only the colour values of each pixel in the image, with no headers, metadata, comment fields. or other extraneous information or pixels.

RGB files can be huge, because there’s no compression to save space, but that means you don’t lose any image quality in the conversion, even though you do lose any and all data that is not directly part of the image you’re interested in.

So, transcoding an image into RGB format and then back, say, to PNG, is one way of ensuring that you create a totally new file that “knows” nothing about where or how the original image was created, or what now-deleted data it might previously have contained.

There are plenty of military puns in operating system history.

Unix famously has a whole raft of personnel known as Major Number, who organise the batallions of devices such as disk drives, keyboards and webcams in your system.

Microsoft once struggled with the apparently incompetent General Failure, who was regularly spotted trying to read your DOS disks and failing.

Linux has intermittently has trouble with Colonel Panic, whose appearance is typically followed by lost data, potentially damaged file systems, and an urgent need to turn off the power and reboot your computer.

And a Czech cryptocurrency company doesn’t seem to be getting the sort of reliability you might reasonably expect from a personality called General Bytes.

Actually, General Bytes is the name of the company itself, a business that sadly is no stranger to unwanted intrusions and unauthorised access to cryptocurrency funds.

Once is misfortune

In August 2022, we wrote how General Bytes had fallen victim to a server-side bug in which remote attackers could trick a customer’s ATM server into giving them access to the “set up a brand new system” configuration pages.

If you’ve ever reflashed an iPhone or an Android device, you’ll know that the person who performs the original setup ends up with control over the device, notably because they get to configure the primary user and to choose a brand new lock code or passphrase during the process.

However, you’ll also know that modern mobile phones forcibly wipe the old contents of the device, including all of the old user’s data, before they reinstall and reconfigure the operating system, apps, and system settings.

In other words, you can start again, but you can’t take over where the last user left off, otherwise you could use a system reflash (or a DFU, short for device firmware upgrade, as Apple calls it) to get at the previous owner’s files.

In the General Bytes ATM server, however, the unauthorised access path that got the attackers into the “start from scratch” setup screens didn’t neutralise any data on the infiltrated device first…

…so the crooks could abuse the server’s “set up a new administrative account” process to create an additional admin user on an existing system.

Twice looks like carelessness

Last time, General Bytes suffered what you might call a malwareless attack, where the criminals didn’t implant any malicious code.

The 2022 attack was orchestrated simply through malevolent configuration changes, with the underlying operating system and server software left untouched.

This time, the attackers used a more conventional approach that relied on an implant: malicious software, or malware for short, that was uploaded via a security loophole and then used as what you might call an “alternative control panel”.

In plain English: the crooks found a bug that allowed them to install a backdoor so they could get in thereafter without permission.

As General Bytes put it:

The attacker was able to upload his own Java application remotely via the master service interface used by terminals to upload videos and run it using batm user privileges.

We’re not sure why an ATM needs a remote image-and-video upload option, as though it were some sort of community blogging site or social media service…

…but it seems that the Coin ATM Server system does include just such a feature, presumbly so that ads and other special offers can be promoted directly to customers who visit the ATMs.

Uploads that aren’t what they seem

Unfortunately, any server that allows uploads, even if they come from a trusted (or at least an authenticated source) needs to be careful of several things:

• Uploads need to be written into a staging area where they can’t immediately be read back from outside. This helps to ensure that untrustworthy users can’t turn your server into a temporary delivery system for unauthorised or inappropriate content via a URL that looks legitimate because it has the imprimatur of your brand.
• Uploads need to be vetted to ensure they match the file types allowed. This helps stop rogue users from booby-trapping your upload area by littering it with scripts or programs that might later end up getting executed on the server rather than simply served up to a subsequent visitor.
• Uploads need to be saved with the most restrictive access permissions feasible, so that booby-trapped or corrupt files can’t inadverently be executed or even accessed from more secure parts of the system.

General Bytes, it seems, didn’t take these precautions, with the result that the attackers were able to perform a wide range of privacy-busting and cryptocurrency-ripping actions.

The malicious activity apparently included: reading and decrypting authentication codes used to access funds in hot wallets and exchanges; sending funds from hot wallets; downloading userames and password hashes; retrieving customer’s cryptographic keys; turning off 2FA; and accessing event logs.

What to do?

• If you run General Bytes Coin ATM systems, read the company’s breach report, which tells you how to look for so-called IoCs (indicators of compromise), and what to do while you wait for patches to be published.

Note that the company has confirmed that both standalone Coin ATM Servers and its own cloud-based systems (where you pay General Bytes a 0.5% levy on all transactions in return for them running your servers for you) were affected.

Intriguingly, General Bytes reports that it will be “shuttering its cloud service”, and insisting that “you’ll need to install your own standalone server”. (The report doesn’t give a deadline, but the company is already actively offering migration support.)

In an about-turn that will take the company in the opposite direction to most other contemporary service-oriented companies, General Bytes insists that “it is theoretically (and practically) impossible to secure a system granting access to multiple operators at the same time where some of them are bad actors.”

• If you have used a General Bytes ATM recently, contact your cryptocurrency exchange or exchanges for advice about what to do, and whether any of your funds are at risk.

• If you are a programmer looking after an online service, whether it’s self-hosted or cloud-hosted, read and heed our advice above about uploads and upload directories.

• If you’re a cryptocurrency enthusiast, keep as little of your cryptocoin stash as you can in so-called hot wallets.

Hot wallets are essentially funds that are ready to trade at a moment’s notice (perhaps automatically), and typically require either that you entrust your own cryptographic keys to someone else, or temporarily transfer funds into one or more of their wallets.