Tag Archives: administrative privileges

Was können wir aus dem Kaseya-Supply-Chain-Angriff für die Cybersicherheitsstrategie ableiten?

17 Juli 2021

Die Analyse des Kaseya-Supply-Chain-Angriffs offenbart 3 Schwachstellen im Software- und Systemdesign von Lösungsanbietern:

  1. Ausführung mit administrativen Berechtigungen

SophosLabs hat den Ablauf auf dem Endpunkt im Detail analysiert.(1) Die Kommandos, die der Kaseya-Agent nach der Auslieferung der Malware ausführt, erfordern administrative Berechtigungen. Das bedeutet, dass der Agent mit administrativen Berechtigungen arbeitet.

Klartext: Jede Anwendung, die mit administrativen Berechtigungen ausführt werden muss, stellt ein Sicherheitsrisiko dar. Das Risiko erhöht sich drastisch, wenn die Anwendung ferngesteuert werden kann.

Gerade die Entwickler von Remote-IT-Management-Lösungen sollten sparsam mit administrativen Berechtigungen umgehen, damit die Angriffsfläche des Netzwerkes nicht vergrößert wird. Windows und Linux bieten Entwicklern Funktionen an, die einen weitgehenden Verzicht darauf ermöglichen.

Tipp: Die Nutzung von administrativen Berechtigungen sollte ein Auswahlkriterium bei der Produktauswahl sein.

  1. Antivirus-Ausnahmen

Der Kaseya-Agent erfordert zur korrekten Ausführung mehrere Antivirus-Ausnahmen.(2) Die Remote-Control-Komponente benötigt weitere Ausnahmen.(3) Die Ausnahmen müssen für jeden Endpunkt, auf dem die Software genutzt werden soll, definiert werden.

Klartext: Jede Antivirus-Ausnahme reduziert das Sicherheitsniveau des gesamten Netzwerkes. Das Risiko erhöht sich drastisch, wenn die Ausnahme auf allen Endpunkten erforderlich ist.

Die Analyse von SophosLabs zeigt, dass ohne die Ausnahmen der Angriff mit hoher Wahrscheinlichkeit selbst von klassischen Antimalware-Lösungen erkannt worden wäre.

Tipp: Das Zusammenspiel mit vorhandenen Sicherheitslösungen sollte ein Auswahlkriterium bei der Produktauswahl sein.

  1. Sichtbarkeit von IT-Management-Systemen in der DMZ

Das DIVD CSIRT berichtet am 4. Juli, dass zu Beginn des Angriffs 2.200 Kaseya VSA Server in den DMZ von Unternehmen sichtbar waren.(4)

Prinzipiell ist jedes Managementsystem in der DMZ, das für alle Internetteilnehmer sichtbar ist, ein Sicherheitsproblem. Wird in der Anwendungssoftware eine kritische Schwachstelle entdeckt, so beginnt ein Wettlauf gegen die Zeit.

Klartext: Die Sichtbarkeit von Managementsysteme in der DMZ ist auf die notwendigen externen Systeme einzuschränken. Vom Internet eingehende Verbindungen erhöhen das Risiko drastisch.

Tipp: Die notwenigen Kommunikationsverbindungen mit dem Hersteller sollten ein Auswahlkriterium bei der Produktauswahl sein. Ausgehende Punkt-zu-Punkt-Verbindungen (Server in der DMZ initiiert die Kommunikation) sind zu bevorzugen.

Tipp: Überprüfen Sie nach der Inbetriebnahme, ob der Systembetreiber die Anforderungen des Herstellers umgesetzt hat. Führen Sie die Prüfungen regelmäßig durch.

Fazit

Die hier identifizierten Schwachstellen müssen in die Cybersicherheitssstrategie eines Unternehmens einfließen: “The strategist must concentrate less on determining specific actions to be taken and far more on manipulating the structure within which all actions are determined.”(5)

Werden die identifizierten Schwachstellen bei Entwicklung, Auswahl und Betrieb von Softwareprodukten konsequent adressiert, so ändern sich die Rahmenbedingungen, in denen Cyberkriminelle agieren können. Die Widerstandsfähigkeit gegen Cyberangriffe wird dauerhaft erhöht.

Quellenangaben

1.         Loman M, Gallagher S, Ajjan A. Independence Day: REvil uses supply chain exploit to attack hundreds of businesses [Internet]. Sophos News. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://news.sophos.com/en-us/2021/07/04/independence-day-revil-uses-supply-chain-exploit-to-attack-hundreds-of-businesses/

2.         Kaseya. Anti-Virus and Firewall Exclusions and Trusted Apps [Internet]. Kaseya. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://helpdesk.kaseya.com/hc/en-gb/articles/229014948-Anti-Virus-and-Firewall-Exclusions-and-Trusted-Apps

3.         Kaseya. Antivirus Exclusion list for Remote Control components. [Internet]. Kaseya. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://helpdesk.kaseya.com/hc/en-gb/articles/229008988-Antivirus-Exclusion-list-for-Remote-Control-components-

4.         Gevers V. Kaseya Case Update 2 [Internet]. DIVD CSIRT. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://csirt.divd.nl/2021/07/04/Kaseya-Case-Update-2/

5.         Dolman EC. Pure strategy: Power and principle in the space and information age. London ; New York: Frank Cass; 2005. 218 S. (Cass series–strategy and history).

Windows malware Sarwent got an upgrade. Thou shalt not work with permanent administrative privileges!

23 May 2020

Catalin Cimpanu (1) reports in his post „Windows malware opens RDP ports on PCs for future remote access“ published on ZDNET that the Windows malware Sarwent got an upgrade: It is now capable of using the windows command line and PowerShell, adding users, and opening ports in the Windows firewall for RDP access from remote. Since the latter features require administrative privileges on the victims machine, it is very likely that the victims worked with permanent administrative privileges.

To mitigate the risk, the best approach is to revoke any administrative privileges from standard users. This will not reduce the likelihood of occurrence, but it will reduce the severity of impact of an infection with Sarwent. Furthermore, since the attacker is forced to download tools to fully compromise the victims computer, the likelihood of detectability is increased.

Revoking administrative privileges from standard users is a low-cost, high-impact means to enhance resiliency against cyber-attacks, thus should be part of each security strategy.

But it is hard to implement. Managers will face lots of discussions if users must give up beloved habits. It is very important to keep the number of exceptions as small as possible because every exception lowers the overall security level of the company.

Have a great weekend.

  1. Cimpanu C. Windows malware opens RDP ports on PCs for future remote access [Internet]. ZDNet. 2020 [zitiert 22. Mai 2020]. Verfügbar unter: https://www.zdnet.com/article/windows-malware-opens-rdp-ports-on-pcs-for-future-remote-access/

RYZENFALL, MASTERKEY, FALLOUT, CHIMERA – Don’t Panic!

3 April 2018

CTS-Labs publication (1) of new branded security flaws in AMD’s latest Ryzen and EPYC processors attracted much media attention.

Much Ado About Nothing

Much Ado About Nothing. Made with WortArt.com.

Two facts on RYZENFALL, MASTERKEY, FALLOUT and CHIMERA:

  • In all cases the attacker requires administrative access to exploit the processor flaws.
  • For exploitation of MASTERKEY the attacker needs to re-flash the bios.

For a good overview see post ‘AMD Flaws’ (2) in the Trail of Bits blog.

To put it succinctly:: An attacker managed to fully compromise a system based on an AMD Ryzen or EPYC processor and to stay undetected. Then he starts exploiting Masterkey, flashes the BIOS and reboots the system. As a result he gets directly detected.

That makes no sense. Once I fully compromised a system I have plenty opportunities to run a deep dive into the victim’s network and, to stay undetected. The risk of getting detected when exploiting e.g. MASTERKEY is just too high.

The world of threat actors can be divided in two classes: Non-Nation State Actors and Nation State Actors. In particular MASTERKEY fits perfectly in the cyber weapon arsenal of the latter because only they have the resources to compromise the processors where it is most convenient, in the supply chain.

I don’t like branded vulnerabilities because they keep us from dealing with really important security issues.

Have a great week!

  1. CTS-Labs. Severe Security Advisory on AMD Processors [Internet]. AMDFLAWS. 2018 [cited 2018 Apr 3]. Available from: https://safefirmware.com/amdflaws_whitepaper.pdf

  2. Guido D. “AMD Flaws” Technical Summary [Internet]. Trail of Bits Blog. 2018 [cited 2018 Apr 3]. Available from: https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-summary/

How to defeat antivirus evasion and privilege escalation techniques

4 February 2018

Last weekend I read two very informative posts on Antivirus Evasion by Mattia Campagnano. But part 2 [1] puzzled me somewhat.

“Following up to my previous post Tips for an Information Security Analyst/Pentester career – Ep. 43: AV Evasion (pt. 1), we’re going now to perform the same attack on a genuine Windows 10 machine, where all latest updates have been installed.”

For a moment I thought ‘a security professional mistakes compliance for security’ because ‘fully patched’ means not that the system is resilient against cyber-attacks. But both posts show that even the most secure Windows ever is vulnerable against privilege escalation and AV evasion if the basic configuration is not changed and fundamental elements of cyber hygiene are missing.

Why are such attacks successful?

First, the user was logged in with permanent administrative privileges. This makes life easy for attackers and fosters lateral movement.

Revoking permanent administrative privileges on workstations and servers must be a basic element of any cyber security program. Under normal conditions, standard users should not have any administrative privileges for their devices at all. If needed, they can be temporarily granted through User Account Control (UAC).

Second, UAC was not set to the highest level “Always notify me”. Unfortunately this is the standard setting after a fresh installation of Windows. With this, privilege escalation is possible without user notification. If configured properly, UAC will notify the user even if he works with administrative privileges.

The BypassUAC method in the meterpreter attack framework will fail, if UAC is set to the highest level. The following excerpt of the code [2] makes this clear

case get_uac_level
 when UAC_PROMPT_CREDS_IF_SECURE_DESKTOP,
      UAC_PROMPT_CONSENT_IF_SECURE_DESKTOP,
      UAC_PROMPT_CREDS, UAC_PROMPT_CONSENT
 fail_with(Failure::NotVulnerable,
  "UAC is set to 'Always Notify'. This module does not bypass this setting, exiting..."
 )
 when UAC_DEFAULT
    print_good('UAC is set to Default')
    print_good('BypassUAC can bypass this setting, continuing...')
 when UAC_NO_PROMPT
    print_warning('UAC set to DoNotPrompt - using ShellExecute "runas" method instead')
    shell_execute_exe
  return
end

Standards like the DISA STIG for Windows 10 [3] activate all UAC features to make life for the attackers as difficult as possible. From my point of view, the STIGs should be considered also in industry to create workplaces resilient against cyber-attacks. And Microsoft should raise the Windows default for UAC to “Always notify me” for all versions. If a user wants to reduce the security level, he should do this on his own responsibility.

Besides the secure configuration of IT systems and cyber hygiene is user awareness training the third essential pillar of a security program. Users and help desk staff must take proper actions if their system unexpectedly enters the secure desktop and asks for permissions of an action they never asked.

Have a good weekend.

  1. Campagnano, M. Tips for an Information Security Analyst/Pentester career – Ep. 44: AV Evasion (pt 2). The S@vvy_Geek Tips Tech Blog
  2. Rapid7 bypassuac_vbs.rb  Metasploit Framework. (Accessed: 3rd February 2018)
  3. Windows 10 Security Technical Implementation Guide. STIG Viewer | Unified Compliance Framework® Available at: https://www.stigviewer.com/stig/windows_10/. (Accessed: 3rd February 2018)
  4. Campagnano, M. Tips for an Information Security Analyst/Pentester career – Ep. 43: AV Evasion (pt.1). The S@vvy_Geek Tips Tech Blog

Oh dear! Oh dear! I shall be too late! – The White Rabbit

29 October 2017

WannaCry, NotPetya, and now: Bad Rabbit. The good news is that Bad Rabbit isn’t spreading as fast as WannaCry and NotPetya. According to a DARKReading report from October 25th the outbreak appears to die down already.

The bad news is, that it happened again. Like the White Rabbit in Alice’s Adventure in Wonderland, IT departments seem to mutter only “Oh dear! Oh dear! I shall be too late!”, instead of increasing the security baseline of their company networks.

Bad Rabbit uses similar techniques as WannaCry and NotPetya for spreading in the networks:

Open SMB shares, Mimikatz alike ways to dump credentials from the affected systems, a hardcoded list of credentials, … For more technical details see this post from Malwarebytes Labs.

The methods to avoid this are well-known and easy and cheap to implement:

  • Run a user awareness campaign.
  • Reduce the number of users and administrators working with permanent administrative privileges to zero. This is a leadership task!
  • Apply the measures to mitigate Pass-the-Hash attacks to all Windows systems and networks.
  • Limit the functionality of technical users to local systems and the lowest possible privileges. Use individual passwords, eliminate default passwords.
  • Review all firewall rules. Question every required connection. Limit the use of the SMB protocol as far as possible. Eliminate the use of unsecured protocols as far as possible. Patch the systems at the endpoints of firewall rules.

The above list is not exhaustive, but if implemented, the attacker’s ability to explore the network is clearly reduced.

It appears to me, that everyone is waiting for Windows 10 to solve some of the issues. This however is the wrong approach. Windows 10 cannot be introduced with a big bang. In particular in the production, lab, and building automation domain, it will take a few years until we can shutdown Windows XP/7 completely. And during this years, our networks are at risk.

With this, there is no time to lose. The White Rabbits returns.

Have a great week.

netsh – The Cyber Attacker’s Tool of Choice

3 February 2016

For IT pros the Windows built-in command netsh is one of the tools of choice for troubleshooting network issues.

For a cyber attacker netsh is the tool of choice once he managed to get access to the company network. ‘netsh trace’ may be used to record every key stroke a user sends e.g. to the login dialog of web application or a banking application in plain text.

Using netsh trace is disturbingly easy:

[1] Start the recording session for programs connecting to internet services

netsh trace start scenario=InternetClient capture=yes tracefile=NetTrace-ICP.etl level=4

[2] Wait for the user to connect to a service …

[3] Stop the recording session

netsh trace stop

[4] Convert the trace file into readable format

netsh trace convert input=NetTrace-ICP.etl output=NetTrace-ICP.etl.xml dump=XML

[5] Open the file with notepad and search for the user name donot.like@get.phished:

<EventData>
<Data Name="RequestHandle">0xCC000C</Data>
<Data Name="Length">502</Data>
<Data Name="Headers">loginfmt=donot.like%40get.phished&amp;passwd=-Plain-Text-Here-&amp;login=donot.like%40get.phished&amp;……</Data>
</EventData>

Thus netsh trace can replace key loggers or tools like Mimikatz or Lazagne. Since the attacker must not reload utilities from the C&C server the likelihood of detection decreases.

Fortunately the attacker must run netsh trace in administrative context, but since many users always work in admin context this is not a real hurdle.

Apart from cyber attacks users should be concerned about privacy issues. If a support technician starts netsh in a remote troubleshooting session the likelihood is high that he may see your password or PIN. To prevent trouble users should always change their passwords after netsh was used to solve network issues.

Take care!

Technical Account = Privileged Account = Member of the Administrators Group – It’s time to break this vicious circle

16 January 2015

I had some discussions in the past weeks about technical accounts in the administrators group. To be honest, I am a strong supporter of the ZERO administrators doctrine: Under normal conditions the administrators group of a computer has no members. If required, an account is added to the group and removed directly after the job is done. Strict implementation of a ZERO admin doctrine requires the implementation of a smart PAM solution to avoid undue delays in the case of trouble.

What really worries me is that technical accounts are always seen as privileged accounts. And that they are very often assigned to the administrators group for convenience, even though a system login is not required.

For example a technical account for querying a database needs no system privileges at all. Even a login to the application or database server is very often not required. In the best case the technical account only needs the privilege to open a database connection and to get access to a well-known set of database objects. Granting whatever system privileges to such accounts or assigning them to the administrators group enlarges only the attack surface of the system.

As always, the Principle of Least Privilege shows the direction. Grant privileges only if required, carefully evaluate if membership in the administrators group is necessary, and treat membership in the administrators group as an exception. To keep the attack surface small it’s wise to check the administrative groups for unnecessary technical accounts regularly.

Have a good weekend.

Anthem hacked – 80 Million data sets lost

11 February 2015

This was a really long winter break. The Sony hack is all water under the bridge now. The hackers have gone back to work, with a bang. 80 Million data sets lost. Anthem was hit particularly hard, and Anthem’s customers are hit by a wave of phishing emails.

The main question is always: How could it happen? And, what can be done to prevent such thefts in the future?

I found an interesting statement in a report published 2/4/2015 by Steve Ragan at CSO-Online:

“On January 27, 2015, an Anthem associate, a database administrator, discovered suspicious activity – a database query running using the associate’s logon information. He had not initiated the query and immediately stopped the query and alerted Anthem’s Information Security department. It was also discovered the logon information for additional database administrators had been compromised.”

This makes it clear: The attackers got access to at least the database login information of some database administrators. In addition, they had to steal some at least standard user credentials for access to company computers. This is required to start the database queries. The rest is easy!

Remind: Attackers can read in company networks like in an open book.

Once they got access to some computers, social engineering could be used to find information about the business critical databases. With an e.g. Oracle client and Microsoft Access as front end, they are able to read all data, even if the database is fully encrypted. In the case of an SQL-Server backend you do not even need a database client software installed because the ODBC driver is part of the Office installation.

The big problem is that any company workstation could be used to launch a query. Even if e.g. an Oracle client is not installed, an instant client, which could be installed by the user, is absolutely enough for access to the business critical data.

The attack surface is enormous. But it’s easy to shrink it. Most database providers offer whitelisting technologies to restrict access from computers to the database server. In the best case, only some application servers, backup systems and admin workstations must have access to the database. Include only this systems in the white list, and exclude all other computers in the black list. That’s it.

For Oracle, parameter TCP.INVITED_NODES specifies the white list, TCP.EXCLUDED_NODES the black list in the SQLNET.ora configuration file.

The only question remaining is: How could the attackers get access to the login credentials of the database admins and the standard users? Unfortunately I haven’t found any hints so far…

That’s it for today.