Social media often gets crazy, but not often as crazy as this.
Many prominent, verified Twitter accounts have been tweeting out cryptocoin scams, with fake tweets reported from an eclectic range of high-profile people and companies, apparently including Joe Biden, Elon Musk, Barack Obama, Bill Gates, Apple and many others.
The scam tweets reportedly included catchy – if highly unlikely – messages such as “Feeling greatful [note spelling blunder], doubling all payments made to my Bitcoin address,” urging people to pay out $1000 and get $2000 back.
Of course, it’s all a pack of lies – after all, if someone already had $1000 to gift you, why wouldn’t they just send it to you, instead of making you pay in $1000 first and then giving you your money back plus another $1000?
Nevertheless, these tweets really did come from verified accounts, so you can see why people might fall for this – it’s not like receiving an email that is signed off “Elon Musk” if the tweet genuinely seems to have come from his account.
Twitter has taken the unusual but understandable step of closing down parts of its service while it investigates, and its own support account has just tweeted to say that the company is “continuing to limit the ability to Tweet, reset your password, and some other account functionalities while we look into this:
We’re continuing to limit the ability to Tweet, reset your password, and some other account functionalities while we look into this. Thanks for your patience.
Until we know exactly how these scam tweets were sent, it’s difficult to suggest what actions you might take, particularly given that access to services such as password changes (and presumably also changing details such as two-factor authnetication numbers) is being restricted.
However, these scammers will only succeed if people fall for their unlikely messages – which rely on people suspending their disbelief simply because the tweet comes from a celebrity or someone they are inclined to trust.
What you need to know
So you can nevertheless protect yourself by following these three simple steps:
If a message sounds too good to be true, it IS too good to be true. If Musk, Gates, Apple, Biden or any well-known person or company wanted to hand out huge amounts of money on a whim, they wouldn’t demand that you hand them money first. That’s not a gift, it’s a trick, and it’s an obvious sign that the person’s account has been hacked. If in doubt, leave it out!
Cryptocurrency transactions don’t have the legal protections that you get with banks or payment card companies. There is no fraud reporting service or transaction cancellation in the world of cryptocurrency. Sending someone cryptocoins is like handing over banknotes to in an envelope – if they go to a crook, you will never see them again. If in doubt, don’t send it out!
Look out for any and all signs that a message might not be real. Crooks don’t have to make spelling mistakes or get important details wrong, but often they do, like the word “greatful” in the example above. So if the crooks do make a blunder, such as writing 50$ when in your country the currency sign comes first, making a mess of their own phone number, or using clumsy or unnatural language, don’t let them get away with it. Treat it with doubt unless everything checks out!
Yesterday was Patch Tuesday, and with 123 bugs fixed, including 20 in the “critical” category, we’re saying what we always do, namely, “Patch early, patch often.”
As often happens, however, one BWAIN (that’s shorthand for Bug With An Impressive Name) that was patched in the Windows DNS server is flying high in the headlines because Microsoft itself has come straight out and said:
We consider this to be a wormable vulnerability, meaning that it has the potential to spread via malware between vulnerable computers without user interaction. DNS is a foundational networking component and commonly installed on Domain Controllers, so a compromise could lead to significant service interruptions and the compromise of high level domain accounts.
The vulnerability turned out to be a long-standing bug that needing fixing in every supported version of Windows Server from 2008 to the present day.
The bug has been dramatically dubbed SIGRed, presumably in a cheeky historical nod to the Code Red worm of 2001, but it’s more officially known as CVE-2020-1350, and it has been given a CVSS Base Score of 10.0.
CVSS stands for Common Vulnerability Scoring System, and it’s a cybsecurity bug measurement system promoted by the US government’s National Institute of Standards and Technology (NIST) that tries to reduce bug severities to a single, dimensionless number between zero and 10.
In truth, this reductionist approach isn’t always helpful – an A-grade washing machine that you use excessively because “the label says it’s green” is much worse for the environment in the long run than an E-grade light bulb you turn on occasionally for the cool effect it produces…
…but in this case, we’re prepared to say that a CVSS score of 10.0, where the absolute maximum is 10.0, is something that really does scream, “Patch now.”
The good news for most of us, at least in terms of patching, is that this vulnerability only affects Windows servers, because the bug is in the Windows DNS server code, not in the Windows DNS client code.
The bad news for many of us, of course, is that this vulnerability affects Windows servers.
If you’re hooked up – whether at the office or from home – to a company network that relies on Windows, crooks who find a way to exploit this bug could directly or indirectly put you at risk, even if you’re not running Windows yourself, by hacking into the core of the network.
The bug and where to find it
As you probably know, DNS is short for Domain Name System, and it’s a distributed, global database that converts human-friendly computer names such as nakedsecurity.sophos.com into network numbers that computers can use, such as 192.0.66.200. (At least, that’s what the name-to-number mapping was for us at 2020-07-15T12:00Z.)
Loosely speaking, there are two broad classes of DNS software: clients that send out requests asking questions such as “where is nakedsecurity to be found?”, and servers that work out the answers to those requests and send back the responses.
Interestingly, the CVE-2020-1350 bug exists in a part of the Windows DNS software that listens for DNS responses coming back, rather than in the part that listens for DNS questions sent out the first place.
In other words, you’re probably thinking that this bug would have to be in the client code, and would therefore affect every Windows computer on the network – after all, DNS servers are there to receive requests, while it’s DNS clients that receive responses.
But DNS servers often need to perform client-like functions, for example by passing on requests that they can’t answer themselves to other servers that can, reading in the replies and reformatting them to reply to the original client request that came in.
So many, if not most, DNS servers – including the Windows DNS server – have code built into them that not only listens for requests but also processes reponses from other servers.
This bug, according to the Check Point researchers who discovered it, is unique to the Windows DNS server software (dns.exe) because the Windows DNS server and client programs don’t seem to share any code.
Having completely different implementations of the make-requests-and-process-replies code in the Windows DNS server program and the Windows DNS client software may sound unusual, but it is not surprising. DNS servers typically need to handle a much broader set of possible DNS requests and replies than pure-play DNS clients, notably for exchanging data with other DNS servers.
How it works
If you’re interested in the innermost technical details of CVE-2020-1350, the researchers who discovered it have dug into it in some detail.
However, unless you already have a basic understanding of the low-level layout of DNS network traffic, as well as some experience in reverse engineering, you might find the deep-dive version rather hard to follow.
So we’ll try to explain what went wrong here, sticking to plain English.
Back then, memory space and network bandwidth were in short supply – modems typically ran at 1200bits/sec or 2400bits/sec, and even a fully-loaded IBM PC-XT had at most 640KB of directly usable system memory.
Data wasn’t exchanged in expressive, self-documenting formats such as JSON, as it often is today, but instead packed as tightly as possible into small, dense binary gobbets.
Today, you might encode various on/off settings into a comfortable but bulky JSON representation such as {"compress":true, "retry":true, "log":true, "urgent":false}, but in the 1980s you would pack these settings into a single byte, using one bit each.
The recipient would have to know in advance which byte contained these settings, and which bit position in the byte stood for each of them.
Likewise, today, we might send a chunk of data as a named JSON string, and let the recipient decode it, allocate memory as it goes along, and work out the final size of the data for itself, as in the JSON expression {"data":"ROz\u0002X-TT\u0000\u0000"}.
But in DNS replies, every byte mattered – in fact, DNS was designed with the assumption that almost all common requests and replies would fit into 512 bytes (minus 12 bytes of header data), with a special but slower transmission method defined for longer replies, formatted as two bytes denoting the data length followed by that many bytes of data.
The biggest number you can fit into two bytes, or 16 bits, is 216-1, which is 0xFFFF in hexadecimal or 65,535 in decimal, so DNS replies max out at that size.
There are many sorts of DNS reply, known in the jargon as RRs, short for Resource Records, denoted using 16-bit numbers referred to as TYPEs, each of which is known by a mnemonic name, for example:
Number Known as What it tells you
------- -------- -----------------------------------------------
Type 1 A IP address of this domain name
Type 2 NS The official DNS server for this domain
Type 15 MX Where to send mail for this domain
Type 16 TXT Text strings giving special info (e.g. SPF data)
Most RR types include numerous data fields, packed together in a binary lump as tightly as possible, and one field type that is common across many RRs is known as a NAME, a text string that is encoded as a single byte denoting its length (thus maxing out at 0xFF or 255 bytes), followed by the NAME data.
You can probably guess where this is going by now.
What happened?
When DNS was extended in the 1990s to support digital signatures in order to make it hard for crooks to inject fraudulent requests and replies into the heart of the sytem, a new RR type with the number 24 and the mnemonic code SIG (short for signature) was defined.
That record type didn’t last long, soon being superseded by record type 40, known as RRSIG (the RR- prefix is tautological, givem that it is an RR by definition, but the text string SIG had obviously already been used).
RRSIG records have the same format as SIG records, but are subject to different rules about how the data in them gets formatted.
At this point, we can only guess at what happened – but we suspect that someone at Microsoft copied some or all of the code that was used to process SIG replies, used it to help build the code that would handle the new-fangled RRSIG replies, made numerous changes, bug fixes, improvmements and extensions, as programmers do with good reason…
…while the original code to handle SIG replies sat there unloved, untouched and, in fairness, almost totally unusued, given that SIG records probably never turned up in real-world traffic any more.
Integer overflow – from years ago
Anyway, as the Check Point researchers discovered while on a spelunking expedition, the code that handles SIG records seemed to make the following assumptions:
The largest amount of data that can possibly appear in a DNS reply is 65,535 bytes.
Therefore the maximum amount of memory that will be needed to store that data when it’s unravelled is 65,535 bytes.
Therefore an unsigned short int (a 16-bit number) gives enough numeric precision for the length calculations.
Unfortunately, SIG records include a NAME field that can be transmitted in compressed form, using DNS’s rudimentary compression algorithm, so that a NAME string that ultimately requires as much as 255 bytes of storage when extracted may take up as little as two bytes in the DNS reply itself.
SIG records also include a field for the digital signature data itself, which can be of arbitrary length, so it’s easy to construct a booby-trapped reply such that the total amount of data sent in the actual reply is right on the 65,535 byte limit.
But the code used a 16-bit integer value when calculating how much memory it would need after decompression – so if you imagine the code being confronted with 65,535 bytes of raw data in the response plus (say) another 40 bytes extra denoted by an attacker using a cunningly-crafted compressed NAME field…
…it would compute the sum as 65,535+40 but wrap around back to 39, in the same way that when you wind an analog clock forward 3 hours from 11 o’clock, you wrap around at 12 and end up with 11+3 = 2 o’clock, not at 11+3 = 14 o’clock as you might expect on a digital timepiece or a railway timetable.
The DNS server would then incorrectly allocate just 39 bytes of memory for its SIG record, but immediately try to shovel 65,535+40 bytes into the hopelessly undersized memory buffer, thus crashing the DNS server.
Only one bug?
Other parts of the Windows DNS server code process similar types of RR data, and you might therefore expect this bug to be repeated elsewhere in the code, notably in the section where newer-style RRSIG records are handled.
But even though the researchers went looking to see if they could find other instances of this problem, or something like it, they came up empty.
Indeed, they reported that some similar parts of the code explicitly checked for an integer overflow, so we’re therefore willing to guess that the bug survived in the SIG reply handler simply because of code rot.
We suspect that because SIG records never showed up in real-life DNS traffic, the bug was never triggered, so the incorrect code attracted neither interest nor suspicion, languishing there unseen and unpatched.
Until now.
Interestingly, one reason why the RRSIG code might not have inherited this bug, even if it started off as a copy-and-paste of the SIG handler, is that the specification for RRSIG resource records explicitly states that compression of the NAME field is not permitted.
Even if the RRSIG code started life with a possible integer overflow that no one noticed, modifying the code to enforce the new “no compression allowed” rule would have sidestepped the bug anyway by making it impossible to create the condition needed to trigger it.
Is it exploitable?
So far as know, no one has yet figured out how to exploit this bug beyond merely crashing the Windows DNS server.
Check Point admitted that it wasn’t able to get further than that, saying:
Due to time constraints, we did not continue to pursue the exploitation of the bug […], but we do believe that a determined attacker will be able to exploit it. Successful exploitation of this vulnerability would have a severe impact, as you can often find unpatched Windows Domain environments, especially Domain Controllers. In addition, some Internet Service Providers (ISPs) may even have set up their public DNS servers as WinDNS.
In Microsoft’s words:
An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the Local System Account. Windows servers that are configured as DNS servers are at risk from this vulnerability.
So, given that Microsoft is calling this a “wormable vulnerablity”, we reiterate our earlier warning to patch now.
In the registry, locate the key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters Find (or create if not present) the DWORD value called: TcpReceivePacketSize Set the value data to: FF00 (hexadecimal) or 65280 (decimal) Then restart the DNS server.
Where to go and what to add in the Windows registry.Right click on DNS Server in the Services app and choose Restart.
We’re assuming this workaround protects you because 65,535-65,280 = 255, and 255 is the maximum length that a NAME field in a SIG record is supposed to have, even after decompression.
So if the DNS server rejects all incoming replies bigger than 65,280 bytes, the integer wrap-around condition will never be reached – there will is always enough space for any compressed NAME data to grow up 255 bytes longer, thus preventing the crash even in the face of a booby-trapped reply.
If you’re not sure whether Windows DNS Server is running or not on a computer you look after, you can use the command sc query dns at an Administrator command prompt to find out:
Above. Output of sc query if DNS Server is not installed. Below. Output of sc query if DNS Server is running.
Two months ago, we wrote about a malware gang that we dubbed RATicate.
These criminals have been actively disseminating a range of remote access Trojans – thus the letters RAT in their nickname – aimed at giving them almost complete control over infected computers, all from a distance.
As we explained earlier in the year, the jargon term RAT is very commonly associated with malware that gives criminals remote access to your webcam, usually for sleazy, voyeuristic purposes.
Indeed, the name RAT was originally coined as a metaphor that referred as much to the criminals that deployed the malware as to the malware itself.
But few RATs were ever just about surreptitious access to webcams and screenshots.
Remote access tools of this sort are more generally known as bots, short for software robots, or zombies, because they lie in wait for commands to arise and wreak havoc.
And almost every zombie out there supports, in addition to any built-in features such as file stealing, screen capturing and webcam snooping, a generic command by which it can update and replace itself with completely new malware, or download and install new malware to run alongside itself.
As we wrote back in May 2020:
The RAT variants delivered by this group of crooks included the zombie malware families Betabot, Lokibot, Formbook, AgentTesla, Netwire, Bladibindi and more.
SophosLabs has been tracking the RATicate crew since its last report, and has just published a follow-up article detailing new findings about the way the gang operates.
RATicate is what we call a MaaS group, short for malware-as-a-service, a play on legitimate offerings such as SaaS (software-as-a-service) and IaaS (infrastructure as a service).
The new report gives an intriguing insight into what you might call the artisan economy in the cyberunderground, where different groups of crooks focus on different cybercrime services.
The RATicate operators even seem to have given their “customers” nicknames that we dubbed actor_tags, such as lanre, bill, aus, h0ly and pope.
Change in delivery
Two months ago, we described how RATIcate’s malware delivery tool of choice was the NSIS installer, a legitimate and widely-used toolkit for packaging applications into single-file bundles that can be double-clicked to install.
NSIS installers have the upside, for criminals at least, of having an air of legitimacy – many software products use NSIS, so using it for wrapping up malware is, in effect, hiding in plain sight.
But the downside is that NSIS installers aren’t meant to be devious or obfuscated – by design, they’re meant to follow a well-defined format, making them comparatively easy for security researchers to extract and analyse.
The RATicaters worked around this by packing their installers full of decoy files, including text documents, source code, Python scripts, images, XML data and legitimate program files (EXEs and DLLs) that weren’t malicious and might reasonably be expected in a genuine installer.
Guess what?
The RATicate crew recently switched to a more devious sort of software packer that went out of its way to make analysis and extraction of the embedded contents difficult.
Unfortunately, the packer they chose – originally dubbed GuLoader – itself turned out to be a commercial software obfuscation tool known as CloudEyE.
You might imagine that any sort of software obfuscation system that is clearly designed to make a program’s behaviour hard to test and analyse would be worthy of blocking by default. But legitimate software vendors often use software-shrouding tools as a way of keeping hackers and pirates out, so banning all “packed” programs outright would prevent many mainstream applications from working, too.
Read the SophosLabs report to learn what happened next – with the operators of CloudEyE as good as forced by industry pressure to shut down about a month ago…
…only to reopen their code-crypting service last weekend with a brand new promise of greater accountability and faster shutdown of rogue accounts.
Here’s a bureaucratic nightmare that unfolded over the weekend
Digicert is one of the Big Five commercial CAs, short for certificate authorities – companies that sign and vouch for the digital certificates that put the the S in HTTPS and the padlock in your browser’s address bar.
As we’ve mentioned before, web certificates and HTTPS (secure HTTP) aren’t just about protecting you from surveillance by encrypting the data that flows between your browser and the websites you visit.
They’re refered to as certificates rather than just encryption keys because they provide some sort of assurance that the people running the site you’re reading have some sort of authority – for various interpretations of the word “authority” – to do so.
Note that the certificate doesn’t vouch for the safety or the accuracy of the content on the site, so cybercriminals who set up their own sites can acquire certificates for those sites. But the web certificate system does make it harder for crooks to set up imposter sites using existing website names.
The simplest form of web certificate is called self-signed, and anyone can create a self-signed certificate in seconds that claims to represent any web property they like.
Here, we’ve used OpenSSL, via a simple series of Lua script commands, to produce a public/private keypair, put the public key into a web certificate, make the certificate valid for 7200 seconds (two hours), and set the certificate to be authoritative.
In the last line, we self-signed it with the private key we generated up front:
We ended up with a private key that we can use to set up HTTPS connections, plus a certificate to send to the other end to vouch for our website, tied cryptographically to our own private key:
As you can imagine, no browser accepts self-signed certificates directly from websites by default – by replacing the text string example.test in the code above, we can generate a self-signed certificate in any name we want, valid for as long as we like, so self-signed certificates provide no authentication at all.
Certificates in real life
In real life, you can’t rely on self-signed certificates, because there’s no one to vouch for them except the self-signer, who could be anyone.
To acquire a certificate to use on your own website, you create your own certificate, as we did above, but then get someone else to sign it rather than just vouching for it yourself.
That means getting a certificate authority to vouch for you in some way, typically using:
Domain validation. The CA asks you to “prove” that you actually control the website or the server named in the certificate. Typically, this involves you placing some random text string into a DNS record associated with the site, or onto a webpage that is part of the site – and that’s all. Domain validation (DV) is based on the idea is that if crooks already have your web hosting password in order to cheat their way past the certificate validation test, then they already have enough to take over your web brand anyway.
Extended validation. The CA performs some background checks, for example by email and over the phone, to confirm not only that you have access to the website for which you want the certificate, but also that you represent the organisation concerned and therefore probably have the legal authority to access to the website. Extended validation (EV) certificates cost more (in particular, there aren’t yet any CAs who will provide them for free), take longer to get, and show your company name when visitors to your website use their browser’s View Certificate option.
For reason of scale, CAs don’t generally sign website certificates directly, but sign them using an intermediate certificate that is signed by a root certificate that does belong directly to the CA itself.
Website certificates are generally known as leaf certificates, because they’re at the very end of a chain of signatures, and the chain of trust goes like this:
The leaf certificate is vouched for by an intermediate certificate that belongs to the CA or to an authorised business partner.
The intermediate certificate is vouched for by a root certificate, directly owned by the CA.
The root certificate is self-signed, but your browser trusts it because it’s part of a small, trusted list of approved root certificates built into your browser or held by your operating system.
This three-level system reduces the number of root certificates that browsers need to keep track of (Firefox’s own database currently [2020-07-13T12:00Z] contains just 138 root certificates.)
It also means that if a CA devolves signing powers to numerous different offices or to business partners around the world, it doesn’t need to share its master signing key (the aptly named private key) with any of them.
Also, if one of those offices or partners makes a blunder or goes rogue, the CA can revoke just one intermediate certificate instead of being forced to invalidate its own root certificate, which would typically cause a much bigger disruption than the “divide and conquer” approach of the leaf-intermediate-root three-level system.
The Digicert revocation
Unfortunately, Digicert was faced over the weekend with the task of revoking a whole raft of certificates – ironically because of a bureaucratic blunder that went unnoticed until now, rather than because of any sort of active attack.
DigiCert has identified an issue where some of our intermediate CAs (ICAs) were not listed as part of our most recent WebTrust EV audit.
To explain: as part of a regular community auditing process, CAs are supposed to submit a list of subsidiaries and business partners that are authorised to sign extended validation certificates as intermediaries on the CA’s behalf.
In other words, if any company X has an EV certifcate that is vouched for by intermediate company Y that is in turn vouched for by a trusted root CA certificate from company Z, then Z has to make sure company Y is listed whenever it submits its extended validation audit documents – in the understandable interests of transparency .
Because Digicert just realised that it hadn’t been reliably submitting its “company Y” list, it was faced with two choices, mandated by the WebTrust EV audit specifications.
Either…
Revoke all intermediate certificates on the “company Y” list, thus implicitly revoking all certificates signed by those companies, including domain validation certificates that didn’t need revoking at all.
Or…
Explicitly revoke all extended validation certificates issued by anyone on the “company Y” list, thus avoiding the collateral damage of revoking an enormous number of DV certificates at the same time.
Digicert opted for the latter approach to minimise disruption to browser users, though apparently it meant revoking 50,000 individual EV certificates instead of just six intermediate certificates.
What to do?
If you run a website and your certificate has been revoked, you’ll probably realise when you or any of your customers try to visit it, because you will see a security warning.
But you may as well check the validation chain on your certificate anyway, and one easy visual way to do this is with the Firefox browser.
Visit your own site and click the padlock icon:
If you see a line that says Certificate issued to, followed by the name of your company or the company that does your web hosting, then you have an extended validation certificate. (DV certificates aren’t issued to any specific company, so this line will not appear.)
If you have an EV certificate, click the Right arrow icon, then More Information, then View Certificate, which shows you, from left to right, the validation chain of your certificate:
The middle entry at the top is the name of the issuer of the intermediate certificate, and if it is one of these six then you are affected:
DigiCert Global CA G2 GeoTrust TLS RSA CA G1 Thawte TLS RSA CA G1 Secure Site CA NCC Group Secure Server CA G2 TERENA SSL High Assurance CA 3
(Above you can see that the www.sophos.com site doesn’t have a root CA of Digicert, and was therefore unaffected.)
All EV certificates signed by the above intermediate CAs have now been revoked, but any regular domain validation certificates will remain valid until they expire naturally.
Those above six CA names will not be used to sign any more certificates at all, so if you have a revoked EV certificate that needs reissuing, it will come from one of these new intermediates instead:
DigiCert EV RSA CA G2
GeoTrust EV RSA CA G2
Thawte EV RSA CA G2
If your Digicert EV certificate is already signed by one of these three then it’s already been renewed and you are done.
How to renew and replace revoked ceritificates is described in Digicert’s ICA Replacement knowledgebase article.
By the way, if you’re a website visitor and you see a certificate revocation warning over the next few days, please don’t ignore and bypass the warning just because you’ve heard about a mass revocation and assume “that’ll be the reason” – just steer clear of the site until the owner reissues and replaces the certificate.
Would you like to keep up with all the stories we write? Why not sign up for our daily newsletter to make sure you don’t miss anything. You can easily unsubscribe if you decide you no longer want it.
