Perpetual IT

Heads up, Microsoft Office 365 users: It’s time to take some important steps in securing your account. The US Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) has released some recommendations to help secure the online productivity service.

In May 2019, CISA released a report detailing some security shortcomings in Microsoft’s cloud-based productivity system. CISA published its latest advisory to press home the recommendations made during that report, in part because of the move to remote working during the current health crisis, it said:

While the abrupt shift to work-from-home may necessitate rapid deployment of cloud collaboration services, such as O365, hasty deployment can lead to oversights in security configurations and undermine a sound O365-specific security strategy.

CISA continues to see instances where entities are not implementing best security practices in regard to their O365 implementation, resulting in increased vulnerability to adversary attacks.

The Agency has several recommendations for Office 365 users, mainly covering access controls.

One such recommendation concerns administrator access to Azure Active Directory (Azure AD). This is a cloud-based counterpart to the Active Directory system that has long shipped with Windows Server, and it houses user information for users of Microsoft’s cloud services along with their privileges.

Companies should use Global Administrator (GA) accounts sparingly because of their unparalleled privileges, it suggested. For example, these accounts can delegate other admins. Instead, use other built-in admin roles that have privileged access but don’t carry the same God-like powers. To be fair, this is something that Microsoft also suggests.

Microsoft doesn’t enable multi-factor authentication (MFA) for admins by default, warns the advisory, which adds that they should turn it on to protect these highly privileged accounts. It should do the same for normal users too, it said, pointing to the possibility of phishing attacks (like this one) that use Microsoft’s cloud productivity services.

MFA might be a problem when authenticating to Exchange Online using legacy protocols that don’t support it, warns the Agency, including POP3, IMAP, and SMTP. That’s why it recommends turning those off and relying completely on Azure AD as an authentication mechanism instead.

That’s timely advice because Microsoft has joined Google in delaying related security upgrades while everyone grapples with COVID-19. Soon enough, though, it will turn off the Basic Authentication mechanism on which these protocols rely.

In the meantime, if you really must support these protocols for users that refuse to move away from insecure clients, then at least turn them off for everyone else, CISA says.

Other recommendations include using Office 365’s Unified Audit Log (UAL) feature. This logs events from the service’s applications, including SharePoint Online, Azure Active Directory, and Microsoft Teams. Integrating the logs with a security information and event management (SIEM) tool will help you to spot dodgy-looking activities, CISA says.

On that note, it also advises enabling alerts within the Security and Compliance Centre to notify admins of suspicious events. At the very least, you should turn on red flags for logins from suspicious locations and for accounts exceeding sent email thresholds.

Finally, the Agency advises companies to use Microsoft’s Secure Score tool, which grades your security posture based on which measures you have turned on. It isn’t perfect, but every little helps, it says:

These recommendations provided by Microsoft Secure Score do NOT encompass all possible security configurations, but organizations should still consider using Microsoft Secure Score because O365 service offerings frequently change.

Isn’t there a way to just turn on all the necessary security by default? Yup. Microsoft has a security defaults feature for Azure AD that provide a basic level of security out of the box. Accounts created after 22 October, 2019 might have them turned on already, the company says, but old accounts won’t. It’s at least a simple switch to flip. It requires all your users to register for MFA in 14 days, eventually blocking them from sign-in until they do, and kills Basic Authentication.

---

Latest Naked Security podcast

Last year, we wrote about an conference paper from Google’s Project Zero with the catchy title Look, no hands! – The remote, interaction-less attack surface of the iPhone.

One of the researchers involved in that project has just published an interesting follow-up article on the Project Zero blog,

This article doesn’t have the intriguing, PR-friendly title of the conference paper, because it’s written in just two words of jargon: Fuzzing ImageIO.

But for cybersecurity researchers interested in how and why apps misbehave, those two words definitely are attention-grabbing.

Fuzzing is a bug-hunting technique that you might call 60% science, 30% art, 25% alchemy and a lot of patience.

In its simplest form, you take well-constructed input files and mutate them thousands, millions, even billions of times each in deliberate and systematic ways before feeding them into software that is supposed to make sense of them.

The idea is that instead of, or better yet as well as, trying to construct a small but representative sample of test files by hand that you know will carefully exercise the error-checking capabilities of your code…

…you automatically create a truly enormous and widely varied sea of test files, and then keep an eye on your program to see if any of these (it doesn’t really matter whether they are well-formed or not) cause weird or dangerous behaviour in your code.

And ImageIO, as its name suggests, is Apple’s built-in programming library that anyone writing an app that handles images is urged to use:

Image I/O provides the definitive way to access image data because it is highly efficient, allows easy access to metadata, and provides color management. […] Any developer currently using image importers or other image handling libraries should read this document to see how to use the Image I/O framework instead.

In other words, instead of laboriously adding support for dozens of different image formats to your app by writing code for each new filetype one-by-one, you can just use ImageIO functions and let the operating system take care of figuring out what image type it is, whether it’s supported, and how to read it in.

You don’t need to worry, or even care, whether it’s JPEG, GIF, PNG, BMP, TIFF or even a file format you’ve never heard off such as KTX (they’re graphics texture files, apparently).

So the drawcard here for a security researcher is the juxtaposition of the word fuzzing, which means going all-out to find weirdly-corrupted files that reveal bugs in the underlying code, and the word ImageIO, which refers to the core code that gets triggered pretty much any time any iPhone app encounters an image file.

Image files, even those considered unsophicaticated such as BMPs, are notoriously tricky to read and digest reliably.

For example, many BMP files have a header near the start that tells you about the size of the image and how it’s organised.

The header starts with 4 bytes denoting the size of the header – but what if that size is wrong and the header gets misread?

There’s a 2-byte value to denote the number of bits per pixel, often 24 (RGB) or 32 (RGBA) – but what if it claims something bizarre such as that there are 32,000 bits per pixel?

There are two 4-byte values for the image width and height – but what if they are negative, or don’t quite match the contents further on in the file?

Programmers can and should check for these anomalies to avoid their app choking or crashing, but how can you be sure they checked for all possible mismatches or corruptions?

In his article, Google’s Stefan Groß describes how he enumerated a list of image file formats that ImageIO supports, and then how he set about “fuzzing” the code in the ImageIO libraries.

Groß started with just 700 representative files, which he calls “seed images”, for the image formats supported.

He then ran his fuzzer for several weeks to see whether any of the fuzzer inputs would cause problems for the ImageIO code.

What happened?

He ended up finding six bugs that caused incorrect access to memory, allowing a mixture of “read where you aren’t supposed to” holes and “write where you aren’t allowed to” errors.

Out-of-bounds memory reads could allow an attacker to leech data that was supposed to be kept secret, including getting at information such as what system components are where in memory.

Memory layout information is usually and deliberately randomised by the operating system so that crooks who already know how to crash your phone nevertheless don’t know enough that they can crash it and then reliably control happens next.

Out-of-bounds memory writes could allow attackers not only to alter the data that a program is relying on, but also to inject changes to the code in order to implant malware.

All of those bugs were fixed some time ago by Apple, as you might expect.

Interestingly, one of the bugs turned out to be in Apple’s code for handling OpenEXR (high dynamic range image) files.

Groß noticed that Apple was using an open source library here, and for good measure, he “decided to fuzz it separately as well.”

That led to eight more bugs serious enough to get CVE numbers, all of which were fixed in the next release of the relevant library.

Zero-click attacks

One tricky problem with image handling bugs, especially on mobile devices, is that there are numerous apps in which you expect to see images automatically, without having to click anything first.

As Groß points out, obvious examples are messaging apps, where the message might be indecipherable without at least some indication – a preview or thumbnail – of what the images in it look like.

This leads to the same irony that exists in the attack known as Bluejacking, where a creepy stranger close by – in a train carriage or on a bus, for example – anonymously sends you an offensive image.

Naturally, they know you’ll reject the image, but they also know that the popup that lets you decide includes a tiny thumbnail – how else to know if you want it or not? – so that you basically have to see the image in order to choose not to see it.

In so-called zero-click image attacks, it’s not your eyes that have to deal with a nasty image in order to protect your eyes from it, but the code that handles images, which on iPhones almost certainly means ImageIO.

So even messages that you yourself would delete without opening because you can see they’re going to be risky and could crash your phone or worse…

…may get processed first, images included, and could crash your phone or worse before you get a chance to decide.

What to do?

Unfortunately, there isn’t a lot you can do, although you can probably reduce your risk slightly from some apps if you turn off notifications, because those often necessitate processing the messages first to present decent-looking popups.

If you’re an app developer, of course, you can help like Groß did by fuzzing your own code to look for bugs.

Even though it generally takes a long time, most of the fuzzing process can run largely unattended in the background and doesn’t require the full-time intellectual engagement of a programmer.

The other solution, for app and operating system developers, is to dial back the range of supported image formats a bit, or at least to allow well-informed users to turn off image formats they don’t absolutely need.

In Groß’s own words:

On the messenger side, one recommendation is to reduce the attack surface by restricting the receiver to a small number of supported image formats (at least for message previews that don’t require interaction). In that case, the sender would then re-encode any unsupported image format prior to sending it to the receiver. In the case of ImageIO, that would reduce the attack surface from around 25 image formats down to just a handful or less.

As programmers often find, less can very definitely be more.

---

Latest Naked Security podcast

After a light Patch Tuesday earlier this month, Adobe has issued an unexpectedly large bundle of critical security fixes for flaws affecting its Magento, Bridge and Illustrator products.

These might look out of band but in fact Adobe often staggers its patches throughout the month.

Nevertheless, with a total of 35 CVEs to fix in this update, including 24 described as ‘critical’, it’s likely the company has been saving up this patching haul from its bug bounty programme for some time.

Users will be pleased to have them, however, given how many can be exploited remotely to compromise a target system and are given high CVSS ratings.

Unfortunately, there appear to be a few of these, with users of Bridge, a component of Adobe Creative Suite, getting the most work to do. There are 17 fixes, of which 14 are critical, collectively identified as APSB20-19. The vulnerabilities affect version 10.0.1 and earlier for Windows and updates to Bridge version 10.0.4 for both Windows and macOS.

The different versions of the Magento ecommerce platform, Open Source and Enterprise (previously known as Community and Commerce) offers fixes for 13 CVEs, including six rated critical in APSB20-22, and individually listed with PRODSECBUG numbers.

Of the six critical flaws, all either allow command injection or security bypasses. The update affects Open Source version 2.3.4 and updates to 2.3.4-p2. For Magento Enterprise Edition the affected version is 1.14.4.4 and earlier and updates to version 1.14.4.5.

Finally, Illustrator 2020 gets fixes of five critical flaws in update APSB20-20. The affected version is 24.0.2 and earlier with the update taking the software to version 24.1.2.

Applying these patches isn’t window dressing – Adobe products are quickly targeted once vulnerabilities become known about.

For instance, recent attacks on Magento have included an exploit targeting an SQL injection flaw in April last year. And there’s always the tide of card skimming attacks on the platform to contend with.

It doesn’t help that many sites still run Magento 1.x, which prompted Visa to warn earlier this month that sites should be upgraded to 2.x before the software’s end-of-life in June this year and to dodge the skimming threat posed by Magecart.

---

Latest Naked Security podcast

Starting in 2012 and on up to his arrest while mulling a menu in a Czech restaurant in 2016, Yevgeniy Nikulin allegedly triggered mega-breaches at big-name online companies LinkedIn, Dropbox and Formspring.

Justice has already been slow in this case, and the pandemic isn’t helping: His trial has been postponed for a third time.

Nikulin’s trial in San Francisco federal court began 9 March but was paused on 18 March because of the coronavirus. It was supposed to restart on 4 May, but on Tuesday evening, US District Judge William Alsup postponed it yet again, rescheduling it to 1 June because some jurors and witnesses were hesitant about showing up at the courthouse during the pandemic.

That’s cutting it close. At this point, San Francisco’s lockdown has been extended to the end of May. If the trial gets extended past 1 June, Judge Alysup well may declare a mistrial, meaning that it will all have to start over from the beginning.

“I’m a little bit worried”

You can read jurors’ thoughts on the matter in their responses to a court questionnaire proposed by the lawyers and approved by Judge Alsup. They range from a “let’s plough ahead” attitude to a juror who says they’re a doctor on the frontlines, others’ concerns about underlying conditions and age, and somebody else whose friend became ill and doesn’t know if they themselves were exposed or not.

More than half of the 14 jurors and alternates – a total of nine – expressed concern about resuming the trial.

From one juror’s response:

I’m a little bit worried as my immune system has not been very strong, but if we all have fair distance, I think it should be okay. … I’m wondering if there’s any way we can do this remotely via video or the phone at home.

Law360 reports that on Monday, prosecution and defense were in the midst of an argument over whether or not video depositions would constitute constitutional testimony when the trial resumed. Two of the witnesses are regarded as high risk because of underlying health conditions:

• Ganesh Krishnan, a former LinkedIn employee who led its security response to an attack that led to millions of passwords being put up for sale on the dark web, and
• Federal investigator Emily Odom, who’s set to testify about an alleged co-conspirator’s ties to Nikulin.

The defense said no to remote testimony, however: Nikulin said that it would violate his Sixth Amendment right to confront witnesses. The Sixth Amendment also grants criminal defendants the right to a public trial that’s speedy, but no absolute time limit has ever been explicitly established.

The charges

Nikulin, a Russian citizen from Moscow, was 29 when he was indicted in 2016. According to the indictment, he allegedly targeted a LinkedIn engineer with malware so as to steal his access credentials. Then, he allegedly did the same thing to Dropbox.

Nikulin stands accused of damaging the computers of both the LinkedIn employee and to Dropbox by “transmitting a program, information, code, or command”. In other words, infecting the systems with malware. He and his co-conspirators were allegedly plotting to do the same to Formspring, a social networking service now known as Spring.me that’s a portal for the dating service Twoo.

He’s also suspected of trying to break into WordPress maker Automattic’s systems, by similarly posing as employees. He’s looking at a potential 10 years in prison if found guilty, though maximum sentences are rarely handed out.

Cold War tug-of-war

In March 2018, Nikulin was extradited from Prague to the US, where he pled not guilty. The extradition – the first delay in this much-delayed trial – took 18 months because Russia didn’t want it to happen. The country said it wanted to prosecute him for separate allegations, but as The Register has reported, it’s claimed that Russia actually recruited Nikulin to do hacking on its behalf and that the charges it wanted to bring against him were trivial in comparison to those in the US.

After he finally got to the US, Nikulin’s trial was delayed yet again by concerns over his mental health. He’s gone through multiple mental competency evaluations, ordered after his refusals to meet with psychiatrists or leave his cell.

Two doctors came to differing conclusions. A Russian doctor picked by the defense found that Nikulin was unfit to stand trial due to chronic post-traumatic stress disorder (PTSD) stemming from a family history of mental illness and trauma, abuse at the hands of his father, and his brother’s suicide.

The court didn’t put much stock in the evaluation, noting that it was the doctor’s first formal competency evaluation of a defendant and that he didn’t use common forensic tools.

The other doctor, picked by the prison board, concluded that Nikulin is fit to stand trial, his only problem being that he’s a narcissist: somebody prone to “a pervasive pattern of grandiosity, need for admiration, and lack of empathy.” In fact, according to court documents, Nikulin believes that he’s the only person competent enough to defend himself.

At any rate, the court agreed that he is in fact able to understand the charges he’s facing, to properly assist in his own defense, and to follow trial proceedings with the help of a Russian translator. … whenever these pandemic conditions allow that trial to proceed, that is.

A vulnerability discovered last year in the defunct OneTone WordPress theme plugin is now being exploited by hackers to compromise entire sites while installing backdoor admin accounts.

The attacks were noticed earlier this month by security company Sucuri, and are believed to be ongoing.

The vulnerability that makes it possible is a cross-site scripting (XSS) flaw that allows attackers to inject malicious JavaScript into the plugin’s settings, redirecting innocent visitors to the attacker’s landing page.

In addition, JavaScript is injected via HTML <script> tags, which allows attackers to detect and hijack authenticated admin sessions.

If successful, hijacking this session in turn allows them to create a backdoor admin account as well as set up additional PHP backdoors through the WordPress dashboard for added persistence. Luke Leal from Sucuri said:

Planting a variety of backdoors ensures the success of the campaign – in the event that the vulnerability is patched or the JavaScript injection is removed, the attackers will still be able to access the compromised environment.

Unfortunately, because the plugin seems to have stopped being updated in early 2018, and the company behind it hasn’t replied to Sucuri’s contacts, it seems reasonable to assume it will never be patched beyond its current version 1.1.1.

A company called NinTechNet first reported the flaw to WordPress.org last September, where it is now listed with a warning about its status for the 10,000 sites believed to still be using it.

The vulnerabilities that make compromise possible are now identified as CVE-2019-17230 and CVE-2019-17231.

The issue of vulnerable plugins is now a perennial issue for WordPress sites which is why the platform’s maintainers recently started testing a tool to manage this process automatically.

The problem with OneTone, of course, is that no update appears likely to arrive. If the OneTone plugin is installed on your site, the best advice is simply to uninstall it as soon as you can.

---

Latest Naked Security podcast