IT News

Explore the MakoLogics IT News for valuable insights and thought leadership on industry best practices in managed IT services and enterprise security updates.

Game over: Apex Legends players locked out by protest message

Messages placed directly in or around games is a common hack technique. It can be used for trolling, phishing, scams, or anything else the message-placer can think of. Messages can also be placed in games for the purposes of advertising but that’s a tale for a different day.

Recently, players of Apex Legends have found themselves blocked from playing the game, thanks to said message placement. The multiplayer title had server playlists switched out for commentary on the state of Titanfall. This is an older game made by the same developers, Respawn Entertainment.

Levelling up a pyrrhic victory

Fans have complained for a while now that Titanfall has become unplayable due to hacks and cheaters. As such, this message – “Save Titanfall, TF1 is being attacked so is Apex” gave the same treatment to Apex Legends that Titanfall has been plagued by. Can’t play one game? Sorry, then you can’t play this game over here either. A sort of mutually assured destruction played out in games over screens.

Game developers Respawn have come out all digital guns blazing, claiming the attacks “achieved nothing of value”. This is because the messages referenced a campaign to “save” Titanfall which they were already aware of. Besides the extra work for the devs and a ruined weekend, the biggest reputation hit belongs to the Save Titanfall campaign. They’ve had to place a message at the top of their site which reads

IMPORTANT MESSAGE: This website, nor the Discord servers listed below, are in no way associated with the recent Apex Legends hack.

Plugging the DDoS gap in gaming

Ouch. DDoS attacks in video game land have been around forever. As the Respawn dev points out, solving such problems in gaming environments isn’t easy. Being locked out of multiplayer only games isn’t something the players can fix, so all eyes will be on the dev team to see what they can do about the current, occasional lack of a state of play.

It’s possible more antics will take place in Apex land until such time as Titanfall is back to full health, so gamers should be on their guard.

The post Game over: Apex Legends players locked out by protest message appeared first on Malwarebytes Labs.

3 things the Kaseya attack can teach us about ransomware recovery

Only rarely do companies allow us a look inside their organization while they are recovering from a ransomware attack. Many find it more convenient to keep a low profile or to be secretive.

A positive exception to this is found in the Dutch managed service provider (MSP) VelzArt, one of the many unfortunate victims of Friday’s enormous, cascading supply-chain attack on Kaseya. The attack used a zero-day vulnerability to create a malicious Kasaya VSA update, which spread REvil ransomware to some of the MSPs that use it, and then on to the customers of those MSPs.

Instead of avoiding the limelight, VelzArt has blogged meticulously since Friday about how it and its customers were affected, and the steps it has taken to get them up and running.

VelzArt offers its customers a broad spectrum of ICT solutions, delivered using remote administration tools. One of those tools is Kaseya VSA. The company writes that it was in the process of switching to another remote administration platform at the time of the attack, but Kaseya software was still installed on some customers’ systems. Since Friday it has been working to recover those customers.

Here are five lessons we can all learn about recovering from ransomware, thanks to VelzArt’s admirable transparency.

1. Know when to communicate

Communication is key during times of crisis. VelzArt writes that after learning about the ongoing attacks in the evening of July 2, it immediately informed the customers it managed using Kaseya software by mail, phone, and newsletters. It also started the blog that became the basis for this article.

This open communication allowed it to triage more effectively. A production company that works 24/7 needs their servers more urgently in the weekend than a law firm that needs everything ready by Monday morning.

During the evening and night, VelzArt says it limited its customer contact to email, in order to prioritize actually getting the recovery procedures done. While it is understandable that anxious customers want to be kept informed, there has to be time for actually getting the work done.

2. Backups take time

Recovering from a ransomware attack normally means rebuilding everything from backups. And that makes backups a target for ransomware.

VelzArt writes that on most servers and some of the workstations, it was able to restore from backups without any major problems. However, stopping the attackers getting to the backups is only half the battle. Machines that have been attacked by ransomware may be harbouring other malware, so backups need to be loaded on to a clean machine, and that takes time: Restoring backups is not a quick fix.

VelzArt says that the servers that were taken offline to stop the attack had to be picked up from clients, checked, reinstalled, and then made ready for normal operations. The company writes that it took quite some effort to pull that off, with staff working in teams through the night. Extra power circuits had to be set up to handle the extra demand.

The company expected 70 percent of servers to be restored by the start of Tuesday. On Tuesday, they hoped to get started with gathering all the workstations that had a back-up option, and Wednesday would be the day to get the re-installed workstations back into their operational status, meaning they would get the necessary software installed, and connected to the network.

3. Help can come from unexpected places

Recovering from ransomware doesn’t just take time, it takes people, too. If you are recovering from a ransomware attack there is a good chance that you will need external help.

VelzArt writes that it worked with one customer on a trial for self-remediation. Because of a lack of information from Kaseya it was not sure how much work would be needed for every individual workstation. The company hoped that the trial would produce a method they could use with other customers.

On Sunday afternoon they asked customers to turn on their workstations, without logging in, stating that they found an automated way to restore workstations remotely. The activated workstations gave VelzArt an idea of what the impact of the attack had been. A warning was given to the customers that the reset procedure for the affected workstations would result in a total loss of local data and installed software. Basically, the system would be flattened and reinstalled.

By Monday morning the automated script it had worked out with the help of one willing company was ready to help the others.

VelzArt also noted that friendly competitors had offered to help them resolve the situation. An offer they were happy to tell their customers they had accepted, in order to speed up the recovery.

Insight from another victim

VelzArt’s unusual level of communication provides us with a rare insight in what a company has to go through when they’re recovering from a ransomware attack. Their transparency will help other victims and we wish them luck on a speedy recovery.

Although rare, there are other organizations that have gone public with the details of what it takes to recover from a ransomware attack.

In the latest episode of the Lock and Code podcast, host David Ruiz speaks to Ski Kacoroski—a system administrator with the Northshore School District in Washington state—about the immediate reaction, the planned response, and the long road to recovery from a ransomware attack. You can listen to it below, or on Apple PodcastsSpotify, and Google Podcasts.

This video cannot be displayed because your Functional Cookies are currently disabled.

To enable them, please visit our privacy policy and search for the Cookies section. Select “Click Here” to open the Privacy Preference Center and select “Functional Cookies” in the menu. You can switch the tab back to “Active” or disable by moving the tab to “Inactive.” Click “Save Settings.”

The post 3 things the Kaseya attack can teach us about ransomware recovery appeared first on Malwarebytes Labs.

Kaseya CEO: “The impact of this incredibly sophisticated attack is very minimal”

The official YouTube channel of Kaseya, the latest organization attacked by no less than the criminals behind REvil ransomware, released a video of Fred Voccola, Kaseya’s CEO, giving a first-hand account of what happened during the attack, the facts on affected customers, and the next steps they’re taking to get clients back up and running as quickly as possible.

On Friday afternoon, the 2nd of June, Kaseya started receiving reports of “suspicious things happening,” Voccola said in the video.

“We weren’t quite sure exactly what it was, but as third parties, the community, our own monitoring customers, we started noticing some strange behaviors,” Voccola recounted in the video. “Within an hour, we immediately shut down VSA.”

The service shut down has painfully disrupted all their VSA users, but it was an easy decision to make and not without basis, Voccola said. “Our cybersecurity playbook states very clearly [that] the first thing to do is to protect and make sure anything that’s potentially dangerous doesn’t have a chance to harm multiple parties,” Voccola said.

Voccola said that, in part due to the modular nature of Kaseya’s security architecture, the company’s rapid response team—with extensive support from Homeland Security, the FBI, and the White House—managed to contain the breach to one module of IT Complete, Kaseya’s remote monitoring and management (RMM) module. The attack affected just one module of IT Complete out of the 27 modules. That module includes approximately 50 customers out of approximately 37,000 customers, Voccola said. Kaseya’s customers are primarily managed service providers (MSPs), who outsource IT services to approximately 800,000 to a 1,000,000 SMBs around the world. Kaseya believes that those SMBs directly affected by the REvil ransomware attack are between 800 to 1,500 in number.

As for what Kaseya is doing now to get the affected RMM module back up and running, Voccola gave the “incredibly conservative” timeline of “in the coming hours” today, the 6th of July.


If you’re a Kaseya client, you can get first-hand updates on the VSA incident here.


Voccola also directly addressed the 50 customers who were breached: “We hope this message does not sound like we’re diminishing it by saying less than 0.01 percentage of our customers were breached… We are here to help.”

Kaseya’s CEO also imparted some advice for other organizations.

“When something happens, it’s how prepared the organization was, how quickly the organization is to admit something happened and not try to it,” Voccola said. “Seek help from people and try to get focus on the customers and get information out there.”

The post Kaseya CEO: “The impact of this incredibly sophisticated attack is very minimal” appeared first on Malwarebytes Labs.

Racing against a real-life ransomware attack, with Ski Kacoroski: Lock and Code S02E12

At 11:37 pm on the night of September 20, 2019, cybercriminals launched a ransomware attack against Northshore School District in Washington state. Early the next morning, Northshore systems administrator Ski Kacoroski arrived on scene. As Kacoroski soon found out, he and his team were on a race against time—the ransomware actively spreading across servers holding data necessary for day-to-day operations. And importantly, in just four days, the school district needed—by law—to pay its reachers. That was now at risk.

Today, we speak to Kacoroski about the immediate reaction, the planned response, and the eventual recovery from a ransomware attack. Tune in to hear Kacoroski’s story—and any lessons learned—on the latest episode of Lock and Code, with host David Ruiz.

This video cannot be displayed because your Functional Cookies are currently disabled.

To enable them, please visit our privacy policy and search for the Cookies section. Select “Click Here” to open the Privacy Preference Center and select “Functional Cookies” in the menu. You can switch the tab back to “Active” or disable by moving the tab to “Inactive.” Click “Save Settings.”

You can also find us on Apple PodcastsSpotify, and Google Podcasts, plus whatever preferred podcast platform you use.

The post Racing against a real-life ransomware attack, with Ski Kacoroski: Lock and Code S02E12 appeared first on Malwarebytes Labs.

A week in security (June 28 – June 4)

Last week on Malwarebytes Labs:

Other cybersecurity news

Stay safe, everyone!

The post A week in security (June 28 – June 4) appeared first on Malwarebytes Labs.

Shutdown Kaseya VSA servers now amidst cascading REvil attack against MSPs, clients

A severe ransomware attack reportedly taking place now against the popular Remote Monitoring and Management software tool Kaseya VSA has forced Kaseya into offering urgent advice: Shutdown VSA servers immediately.

“We are experiencing a potential attack against the VSA that has been limited to a small
number of on-premise customers only as of 2:00 PM EDT today,” Kaseya wrote on Friday afternoon.

“We are in the process of investigating the root cause of the incident with an abundance of caution but we recommend that you IMMEDIATELY shutdown your VSA server until you receive further notice from us.

It’s critical that you do this immediately, because one of the first things the attacker does is shutoff administrative access to the VSA.”

The attack is reportedly delivered through a Kaseya VSA auto-update that maliciously pushes the Revil ransomware onto victims’ machines. Kaseya is a popular software developed for Managed Service Providers that provide remote IT support and cybersecurity services for small- to medium-sized businesses that often cannot afford to hire full-time IT employees, due to their limited size or budgets.

Complicating the attack is the fact that, according to cybersecurity researcher Kevin Beaumont, the malicious update carries administrator rights for clients’ systems, “which means that Managed Service Providers who are infected then infect their client’s systems.”

For a company that says it has 40,000 customers, this could be a disaster.

During the attack, the cybercriminals reportedly shut off administrative access to VSA, and several protections within Microsoft Defender are disabled, including Real-Time Monitoring, Script Scanning, and Controlled Folder Access.

A screenshot from Malwarebytes reveals a ransom note delivered to an infected Windows machine. In the note, attackers warn:

“|—=== Welcome. Again. ===—

[-] Whats HapPen? [-]

Your files are encrypted, and currently unavailable. You can check it: all files on your system has extension 7pc78r01. By the way, everything is possible to recover (restore), but you need to follow our instructions. Otherwise, you can’t return your data (NEVER).”

REvil wallpaper

Malwarebytes customers are currently protected from REvil, as shown in the screenshots below, and Malwarebytes is committed to continuing this protection. (Malwarebytes detects REvil as Sodinokibi)

Detections

We will update this post with more information as it becomes available, but the immediate guidance from Kaseya cannot be overstated: Shutdown VSA servers immediately.

Indicators of Compromise (IOCs)

Loader

df2d6ef0450660aaae62c429610b964949812df2da1c57646fc29aa51c3f031e
dc6b0e8c1e9c113f0364e1c8370060dee3fcbe25b667ddeca7623a95cd21411f
d55f983c994caa160ec63a59f6b4250fe67fb3e8c43a388aec60a4a6978e9f1e
aae6e388e774180bc3eb96dad5d5bfefd63d0eb7124d68b6991701936801f1c7
66490c59cb9630b53fa3fa7125b5c9511afde38edab4459065938c1974229ca8
81d0c71f8b282076cd93fb6bb5bfd3932422d033109e2c92572fc49e4abc2471
1fe9b489c25bb23b04d9996e8107671edee69bd6f6def2fe7ece38a0fb35f98e

REvil/Sodinoki DLL

d8353cfc5e696d3ae402c7c70565c1e7f31e49bcf74a6e12e5ab044f306b4b20
d5ce6f36a06b0dc8ce8e7e2c9a53e66094c2adfc93cfac61dd09efe9ac45a75f
cc0cdc6a3d843e22c98170713abf1d6ae06e8b5e34ed06ac3159adafe85e3bd6
0496ca57e387b10dfdac809de8a4e039f68e8d66535d5d19ec76d39f7d0a4402
8e846ed965bbc0270a6f58c5818e039ef2fb78def4d2bf82348ca786ea0cea4f
8dd620d9aeb35960bb766458c8890ede987c33d239cf730f93fe49d90ae759dd

The post Shutdown Kaseya VSA servers now amidst cascading REvil attack against MSPs, clients appeared first on Malwarebytes Labs.

Beware password-spraying fancy bears

The NSA, FBI, and CISA, in cooperation with the UK’s National Cyber Security Centre (NCSC), have issued a report that describes in detail why, and how, they think that a Russian military unit is behind large-scale brute-force attacks on the cloud-IT resources of government and private sector companies around the world. The report states:

Since at least mid-2019 through early 2021, Russian General Staff Main Intelligence Directorate (GRU) 85th Main Special Service Center (GTsSS), military unit 26165, used a Kubernetes® cluster to conduct widespread, distributed, and anonymized brute force access attempts against hundreds of government and private sector targets worldwide.

The agencies are pointing their collective fingers at military unit 26165 of the Russian General Staff Main Intelligence Directorate (commonly know as GRU), which you will find often referred to as Fancy Bear, APT28, Strontium, and some other names.

The targets

Most of the named activity is aimed at organizations using Microsoft Office 365 cloud services, but the attacks are certainly not limited to those. They also targeted other service providers and on-premises email servers using a variety of different protocols. I use the present tense on purpose as these  attacks are almost certainly still ongoing.

The campaign is said to have targeted hundreds of US and foreign organizations, including US government and defense entities. While the sum of the targeting is global in nature, it has predominantly focused on entities in the US and Europe.

The method

The report includes a graphic that explains the most prevalent attack method.

Brute Forski

Some attacks used known vulnerabilities that allowed remote code execution (RCE), while others started by trying to identify valid credentials through password spraying. Password spraying involves using a limited list of credentials against a large number of accounts, a brute-force tactic that’s useful if you don’t really care which accounts you take over.

The attacks were launched from a Kubernetes cluster. A Kubernetes cluster is a “container orchestration” system for running a large number of containerized applications. The applications in the cluster used TOR and commercial VPN services to avoid revealing their IP addresses.

Once initial access had been secured, attackers used a variety of well-known tactics, techniques, and procedures (TTPs) to escalate privileges, establish persistence, move laterally, and collect additional information.

If any of the cloud service credentials the attackers discovered were sufficiently privileged, they were used to exfiltrate data. Where this was not an option, for example when mail was not handled in the cloud, the threat actor used a modified and obfuscated version of the reGeorg web shell to maintain persistent access on a target’s Outlook Web Access server. The reGeorg webshell creates a socks proxy for intranet penetration and as such can be used as a means to gain persistence.

Mitigation and detection

The report contains a number of mitigation methods but makes a special plea for multi-factor authentication (MFA).

Network managers should adopt and expand usage of multi-factor authentication to help counter the effectiveness of this capability. Additional mitigations to ensure strong access controls include time-out and lock-out features…

MFA stops password spraying and other forms of brute-force attacks in their tracks. It doesn’t matter how long your password list is, or how many password attempts you make—if you don’t have a user’s second authentication factor, such as a numeric code or fingerprint, you cannot get access. Time-out and lock-out features are useful for strengthening weak passwords by reducing the number of guesses an attacker can make.

The report also mentions the mandatory use of strong passwords as a useful mitigation. It is, but if that were easy, the other mitigations wouldn’t be necessary. Aim for strong passwords, but plan for bad ones.

Other mitigation methods mentioned in the report include:

  • Implementing a Zero-Trust security model.
  • Captcha, when human interaction is required.
  • Analytics for detecting anomalous authentication activity.

For detection purposes the report lists a few incomplete or truncated versions of legitimate User-Agent strings that the attackers used:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.1 Safari/605.1.15
Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7162; Pro
Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7143; Pro)
Microsoft Office/15.0 (Windows NT 6.1; Microsoft Outlook 15.0.4605; Pro)

The report also provides a Yara rule matches the reGeorg variant web shell used by the actors.

rule reGeorg_Variant_Web shell
{
    strings:
        $pageLanguage = "<%@ Page Language="C#""
        $obfuscationFunction = "StrTr"
        $target = "target_str"
        $IPcomms = "System.Net.IPEndPoint"
        $addHeader = "Response.AddHeader"
        $socket = "Socket"
    condition:
        5 of them
}

The report warns that the rule does not uniquely GRU activity since the web shell is publicly available.

The post Beware password-spraying fancy bears appeared first on Malwarebytes Labs.

PrintNightmare 0-day can be used to take over Windows domain controllers

In a rush to be the first to publish a proof-of-concept (PoC), researchers have published a write-up and a demo exploit to demonstrate a vulnerability that has been dubbed PrintNightmare. Only to find out they had alerted the world to a new 0-day vulnerability by accident.

What happened?

In June, Microsoft patched a vulnerability in the Windows Print Spooler that was listed as CVE-2021-1675. At first it was classified as an elevation of privilege (EoP) vulnerability. Which means that someone with limited access to a system could raise their privilege level, giving them more power over the affected system. This type of vulnerability is serious, especially when it is found in a widely used service like the Windows Print Spooler. A few weeks after the patch Microsoft raised the level of seriousness to a remote code execution (RCE) vulnerability. RCE vulnerabilities allow a malicious actor to execute their code on a different machine on the same network.

As per usual, the general advice was to install the patches from Microsoft and you’re done. Fast forward another week and a researcher announced he’d found a way to exploit the vulnerability to achieve both local privilege escalation and remote code execution. This actually happens a lot when researchers reverse engineer a patch.

Only in this case it had an unexpected consequence. A different team of researchers had also found an RCE vulnerability in the Print Spooler service. They called theirs PrintNightmare and believed it was the same as CVE-2021-1675. They were working on a presentation to be held at the Black Hat security conference. But now they feared that the other team had stumbled over the same vulnerability, so they published their work, believing it was covered by the patch already released by Microsoft.

But the patch for CVE-2021-1675 didn’t seem to work against the PrintNightmare vulnerability. It appeared that PrintNightmare and CVE-2021-1675 were in fact two very similar but different vulnerabilities in the Print Spooler.

And with that, it looked as if the PrintNightmare team had, unwittingly, disclosed a new 0-day vulnerability irresponsibly. (Disclosure of vulnerabilities is considered responsible if a vendor is given enough time to issue a patch.)

Since then, some security researchers have argued that CVE-2021-1675 and PrintNightmare are the same, and others have reported that the CVE-2021-1675 patch works on some systems.

Whether they are the same or not, what is not in doubt is that there are live Windows systems where PrintNightmare cannot be patched. And unfortunately, it seems that the systems where the patch doesn’t work are Windows Domain Controllers, which is very much the worst case scenario.

PrintNightmare

The Print Spooler service is embedded in the Windows operating system and manages the printing process. It is running by default on most Windows machines, including Active Directory servers.

It handles preliminary functions of finding and loading the print driver, creating print jobs, and then ultimately printing. This service has been around “forever” and it has been a fruitful hunting ground for vulnerabilities, with many flaws being found and fixed over the years. Remember Stuxnet? Stuxnet also exploited a vulnerability in the Print Spooler service as part of the set of vulnerabilities the worm used to spread.

PrintNightmare can be triggered by an unprivileged user attempting to load a malicious driver remotely. Using the vulnerability, researchers have been able to gain SYSTEM privileges, and achieved remote code execution with the highest privileges on a fully patched system.

To exploit the flaw, attackers would first have to gain access to a network with a vulnerable machine. Although this provides some measure of protection, it is worth noting that there are underground markets where criminals can purchase this kind of access for a few dollars.

If they can secure any kind of access, they can potentially use PrintNightmare to turn a normal user into an all-powerful Domain Admin. As a Domain Admin they could then act almost with impunity, spreading ransomware, deleting backups and even disabling security software.

Mitigation

Considering the large number of machines that may be vulnerable to PrintNightmare, and that several methods to exploit the vulnerability have been published, it seems likely there will soon be malicious use-cases for this vulnerability.

There are a few things you can do until the vulnerability is patched. Microsoft will probably try to patch the vulnerability before next patch Tuesday (July 12), but until then you can:

  • Disable the Print Spooler service on machines that do not need it. Please note that stopping the service without disabling may not be enough.
  • For the systems that do need the Print Spooler service to be running make sure they are not exposed to the internet.

I realize the above will not be easy or even feasible in every case. For those machines that need the Print Spooler service and also need to be accessible from outside the LAN, very carefully limit and monitor access events and permissions. Also at all costs avoid running the Print Spooler service on any domain controllers.

For further measures it is good to know that the exploit works by dropping a DLL in a subdirectory under C:WindowsSystem32spooldrivers, so system administrators can create a “Deny to modify” rule for that directory and its subdirectories so that even the SYSTEM account can not place a new DLL in them.

This remains a developing situation and we will update this article if more information becomes available.

The post PrintNightmare 0-day can be used to take over Windows domain controllers appeared first on Malwarebytes Labs.

SMS authentication code includes ad: a very bad idea

SMS authentication codes are back in the news, and the word I’d use to summarise their reappearance is “embattled.”

I can still remember a time where two-factor authentication (2FA), authentication grids, regional lockouts, Yubikeys, and offline authentication apps simply did not exist. And if they did, people out there sitting next to you, or on the bus, or in your office, typically did not use them. If you were phished, that was it. Your account was gone unless a non-convoluted recovery process was available.

Then, two-factor authentication slowly became a thing. The uptake still isn’t great, but it’s an improvement. If you’re phished now, it (probably) won’t hurt you because the attacker also needs your authentication code. If they don’t have the code, they’ll sit and stare forlornly at your password then give up.

You’re going to ask me about the “probably” bit now, aren’t you.

Which flavor of two-factor do you prefer?

There are caveats to two-factor, and it largely depends which kind of two-factor we’re talking about.

Most people I know, and a majority of people I encounter online, use 1 of the following types:

  • SMS codes. These are sent to your mobile, via your carrier. The code is punched into the website after you enter a password, and that combined with the code lets you log in. Codes typically expire after a short period of time to ensure lots of valuable codes aren’t left lying around all over the place.
  • Authenticator apps. These are apps which generate codes between short intervals, and they work offline. Do you find yourself in a location where you have no carrier signal? It doesn’t matter with an authenticator app. I’ve known people who changed complex passwords to very basic ones they could remember when going overseas so they could still use their accounts. This isn’t great, and a common workaround in the days before apps became widely available.

Of the two, apps are recommended as the more secure approach.

What’s the problem with SMS?

You’ve had your account password stolen. You’re still safe. They can’t get in without the SMS code. You’re still safe. The attacker’s decided to contact your network provider. You’re still…wait, what? They’re on the phone to customer support, pretending to be you. You’re…possibly in a bit of trouble here. They claim to have lost your phone, and could the network please redirect authentication codes to a “replacement” device.

You’re basically doomed, sorry.

An Authenticator victory is (mostly) assured

With authenticators, there’s nobody outside of your control at the phone company being phished. This stacks the odds heavily in your favour. However, I don’t want to give you the wrong impression. Nothing is 100 precent bulletproof. Apps can occasionally fall foul to the most inventive of schemes.

Of the two, using an authenticator is still the best way to do things. So, then.

Embattled.

Of SMS codes and carrier ads

A developer Tweeted that they encountered a bizarre situation with a Google SMS code. Namely: the Google verification code came with an advert for a VPN service bolted on. You could even “tap to load preview”.

The initial thought was “Why is Google placing ads on these codes”? That was quickly cleared up, however. Google wasn’t responsible for this. The network carrier was to blame.

Introducing doubt into security practices

Consider that we’re talking about codes designed to make your security stronger, with whatever privacy friendly enhancements such a thing may bring. The aim of the game is retreating to your hidey-hole and watching the attacks pass by harmlessly.

The aim of the game is not to have adverts bolted on to security code texts, from carriers able to read everything. Depending on ad tech used, it’s entirely possible to make the ads “relevant” or targeted to the content of the SMS. Of all the things the ad could’ve been about, it’s interesting that it happens to be about VPNs and staying safe from hackers.

This also opens up discussions on consent, who the ad network is, what’s happening to your data/messages, and what kind of say you have in the matter. Worst case scenario, the ad leads to a rogue page or phishing site. There can’t be many more ways to damage the reputation of using SMS codes as an added layer of security.

Keep using codes, but consider migrating to apps

Bottom line: this is a bad idea, will certainly put people off an already beleaguered security measure, and shouldn’t be happening.

Authenticator apps are available on pretty much all mobile platforms at this point, and there’s never been a better moment to consider making the switch. This is not a great thing to see happening, but hopefully Google casting an “Oh dear, what are you up to” eye over the carrier will deter others from replicating. Should you happen to see ads bolted on to your SMS codes, consider politely reaching out to some of the many Google security folks on twitter.

We don’t need to see any more adverts attached to authentication codes.

The post SMS authentication code includes ad: a very bad idea appeared first on Malwarebytes Labs.

Microsoft exec reveals “routine” secrecy orders from government investigators

Microsoft executive Tom Burt told Congressional lawmakers Wednesday that Federal law enforcement agencies send “routine” secret orders for customer information from the Seattle-based company, numbering anywhere from 2,400 to 3,500 such requests a year.

“While the recent news about secret investigations is shocking, most shocking is just how routine secrecy orders have become when law enforcement targets an American’s email, text messages, or other sensitive data stored in the cloud,” said Burt, Microsoft’s corporate vice president for customer security and trust, at a hearing held by the House of Representatives Judiciary Committee. “This abuse is not new. It is also not unique to one Administration and is not limited to investigations targeting the media and Congress.”

Burt’s comments come amidst a roiling crisis of government overreach and press freedom, and as several members of Congress explore legislative options to limit federal law enforcement powers within secret investigations.

In May, several newspapers and outlets revealed that the Department of Justice during President Donald Trump’s administration secretly obtained the phone and email records of journalists at The Washington Post, The New York Times, and CNN, and just one month later, some of those same publications revealed that in 2018, the Department of Justice also secretly subpoenaed Apple for the data of two Democrats on the House Intelligence Committee—as well as the data of the Democrats’ current and former staffers and family members.

Apple complied with the subpoena but said it did not know that the data being requested belonged to two members of Congress. Further, Apple said it could not disclose the request because of a secrecy order that came with it.

“In this case, the subpoena, which was issued by a federal grand jury and included a nondisclosure order signed by a federal magistrate judge, provided no information on the nature of the investigation and it would have been virtually impossible for Apple to understand the intent of the desired information without digging through users’ accounts,” said Apple spokesperson Fred Sainz in the statement. “Consistent with the request, Apple limited the information it provided to account subscriber information and did not provide any content such as emails or pictures.”

Burt’s testimony on Wednesday highlighted the many perceived problems with such secretive orders.

One problem, Burt said, is the sheer volume. If Microsoft alone received about 3,500 requests in one year, then “add the demands likely served on Facebook, Apple, Google, Twitter, and others, and you get a frightening sense of the mountain of secrecy orders used by federal law enforcement in recent years.”

Second, Burt said, is the problem that obtaining a secrecy order is simply too easy. According to Burt, the template that the Department of Justice relies on to apply for a secrecy order “does not even require facts justifying the need for secrecy.”

And finally, one of the largest problems with secrecy orders is that many of them, Burt asserted, are misguided:

“Examples of some of the recent abuse we’ve seen are secrecy orders when the account holder was a victim, not a target of the investigation. Or when the investigation targets just one account at a reputable company, government, or university, but the secrecy order bars notice to anyone in that organization. Or where the government has secretly demanded records in order to evade on ongoing discovery dispute.”

Burt said that Microsoft takes it upon itself to scrutinize and challenge certain secrecy orders in court, but, he added “litigation is no substitute for legislative reform.”

Burt likely found a sympathetic audience within the House Judiciary Committee, as members of both political parties on the committee have voiced support for stripping secretive authorities away from the Department of Justice. During the hearing held Wednesday, Committee Chairman Jerrold Nadler made his stance clear:

“We cannot trust the department to police itself.”

The post Microsoft exec reveals “routine” secrecy orders from government investigators appeared first on Malwarebytes Labs.