Tag Archives: Attack Surface

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).

Some thoughts on “Protecting against ransomware using PCI DSS and other hardening standards”

20 May 2018

Post “Protecting against ransomware using PCI DSS and other hardening standards” (1) published this week by Paul Norris in SC Media UK is really worth reading. Hardening is a proven method to reduce the attack surface of a computer network. If well done, the spreading of ransomware and thus the impact on an organization can be limited.

Hardening, patching, etc. serve a common goal in cyber war: Describing the limits of conflict. Everett Dolman writes in chapter 5 of “Pure Strategy: Power and Principle in the Space and Information Age” (2):

“Tactical thinkers seek to define and describe situations. Decision-making in real-time tactical mode requires it. The more knowledge of the limits to conflict, the more creatively the tactical genius can deploy, maneuver, and engage forces. Knowing completely what cannot be done allows for an investigation what can be done.”

Hardening, patching, etc. decrease the number of options / attack vectors an attacker can use for getting on and exploring a network. IT security groups can then focus on the remaining attack vectors, and prepare for the unknown.

Let me give two examples to illustrate this.

  1. If all external storage devices are technically blocked in your organization an attacker cannot use them for delivery of weaponized documents. Furthermore, if users have no chance to change this your IT security group can focus on investigating other attack vectors.

  2. If you implemented the measures for mitigation of high and medium risk findings described in the DoD “Windows 7 Security Technical Implementation Guide” (3) you can be sure that attacks based on bypassing UAC to get elevated privileges are no longer possible.

But be aware that the attacker also knows what cannot be done after a standard is implemented…

Have a great week.

  1. Norris P. Protecting against ransomware using PCI DSS and other hardening standards [Internet]. SC Media UK. 2018 [cited 2018 May 20]. Available from: https://www.scmagazineuk.com/opinion/protecting-against-ransomware-using-pci-dss-and-other-hardening-standards/article/761956/

  2. Dolman EC. Pure Strategy: Power and Principle in the Space and Information Age [Internet]. Taylor & Francis; 2004. (Strategy and History)

  3. Department of Defense. Windows 7 Security Technical Implementation Guide [Internet]. STIG Viewer | Unified Compliance Framework®. 2017 [cited 2018 May 20]. Available from: https://www.stigviewer.com/stig/windows_7/

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.

Some thoughts about: People and process remain the soft underbelly of banks

25 April 2015

In post ‘Security Think Tank: People and process remain the soft underbelly of banks’, John Colley discusses on the example of the Carbanak attack some new concepts for surviving the cyber war.

I like the idea of sharing knowledge about attack vectors and best practice for the defense against cyber-attacks across industries. But what is the proper scope for action?

John Colley writes:

‘Even worse, the persistence of bad cyber security practices is driving banks to try to protect badly designed systems by hiding them from view. Many banks try to prevent attackers discovering what internal programs they use; yet it shouldn’t matter if outsiders know what software a bank uses for its internal systems, if that software is secured properly in the first place.’

I am discussing such issues for months now. My advice is crystal clear:

Before you start sharing information about your internal systems with whatever partner, carefully consider

  • what information and what level of detail is required, and
  • how the information must be protected.

Every available information about your internal systems will support attackers in finding vulnerabilities in your systems. Remember: It’s merely a matter of time before cyber criminals break into your company network…

Too many details increase the attack surface of your company!

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.

The technology dimension of social engineering

7 February 2015

In his post ‘Weird Security Term of the Week: “Social Engineering”’ Kurt Ellzey talks of ‘Social Engineering’ as the ‘Art of Getting Information’ about a person.

A short query on Google reveals a multitude of information that could be used to create a rough profile of a person. A malicious insider could easily enhance this profile by personal information gathered from e.g. a company intranet or SharePoint MySites.

Besides this ‘personal information’ a rich set of easy to extract ‘technical information’ about an employee is available from a company network.

A Windows workstation is a universal machine. It can be used to run an application as well as to administer a server or network. For example, the built-in ‘net’ command could be used to retrieve detailed employee account data from the Active Directory.

Some colors to fight the winter depression.

Some colors to fight the winter depression.
50°53’28.3″N 4°21’31.9″E

IAM (Identity and Access Management) systems, very often deployed as self-services to improve user satisfaction, could be used to get detailed information about the applications used by employees to get their job done.

But the worst is that this information sources are available for all employees, irrespective of whether they are needed in the job. This is a massive violation of the Principle of Least Privilege.

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

And, when enriched with technical information, a personal profile becomes an invaluable information source for targeted attacks.

Just some suggestions on how to tackle these problems.

As general design principle I would strongly recommend to enforce the principle of least privilege for all information systems. Software restriction policies could be used to reject standard user access to administrative commands. IAM systems should offer only user related information on a user’s request.

I dream of an operating system which provides only those commands and applications which are essential for a user’s job. This could reduce the attack surface of a company dramatically.

Have a nice weekend!

The human factor a key challenge to information security!

11 December 2014

I returned from a business trip to Berlin yesterday in the late evening. In the morning I presented the results of the threat analysis of a complex application, which we performed in the past weeks, to the application steward. To be honest, I am not fully satisfied with the outcome, although we agreed in a lot of protection packages to secure the database and the application layer. Some of the weak points, e.g. the access from the users to the application server and the distribution of the software to the user Workstations, are still not sufficiently mitigated.

Later in the afternoon I found an email titled ‘The human factor a key challenge to information security, say experts’ in my inbox.

The key message of the study discussed in this report is:

“People will always be the most vulnerable part of any organisation’s information security, because people make mistakes and they are easily manipulated.”

Yes, I fully agree! But software suppliers, who deliver bad configured software, and business leaders, who constantly run IT cost-reduction programs, contribute also substantially to this security problems.

People who use complex software to run complex business processes create more help-desk calls and support effort than people who use office applications only. But cost cutting programs are not aware of this trivial insight. From a pure economic point of view such applications does not exists, although they may contribute substantially to the success of a company.

IT groups are doing a great job in automation of support processes to deliver fast and high quality support to their users. Unfortunately, security suffers under cost pressure. If the number of complaints of e.g. low performance of an application is large enough IT groups are far too ready to define exceptions from security standards. But exactly this self-made vulnerabilities could be used by attackers to get access to the computers in a company…

Sony is everywhere!

The new first line of defence?

22 November 2014

In his latest post at ComputerWeekly.com Warwick Ashford reviews the CyberArk Report ‘Exploits of Privileged Accounts Shift the Front Lines of Security’. His post is absolutely worth reading.‘

‘“One of the reasons for this is smaller, less well-defended organisations have become a prime target for attackers who are ultimately aiming at larger partners in the supply chain,” said Mokady.’

That’s definitely true. Perhaps you remember the Home Depot data breach? This breach was caused by stolen credentials of a third-party vendor.

‘“Securing privileged accounts represents the new first line of defence in the ongoing cyber battle companies are fighting,” he added.’

Very well said. But what really confuses me is that Udi Mokady talks about the new first line of defense. 

The majority of the big data breaches have been caused by stolen credentials. With a Two Factor Authentication (TFA) most of this breaches could have been prevented.

It’s definitely very important to secure privileged accounts. With admin privileges it is very easy to change log settings or tamper audit records. But it is definitely not enough to secure only privileged accounts. Because even with standard user privileges you may have access to business critical data to do your job.

Let me give you an example. Oracle Transparent Data Encryption and SQL*Net encryption and integrity checking are easy to implement measures to secure an Oracle database. This will prevent man-in-middle attacks, eavesdropping of the data traffic and direct access to the database files.

Sounds pretty secure, doesn’t it? Unfortunately it isn’t. Even an unprivileged user, and even more a malicious insider with stolen credentials, is able to install an oracle instant client and use Excel and ODBC to create a copy of all data he could use with his standard user rights.

With TFA enabled, at least on all business critical systems, and for all users, the probability of such an event is dramatically reduced.

Securing accounts with TFA is the very first line of defense.

In addition you should decide about granting privileged access on a per task basis. For business critical infrastructure and applications an administrator should receive an authorization and one-time-password for just one task. At log off the authorizations are dropped. In the best case the admin group for a windows servers is empty. Only the local admin could always logon, but his password is in a safe place.

The authorization process should be implemented with strict application of the separation-of-duties principle, and the permissions should be granted with strict Application of the principle of least privilege. Important: The employees who grant authorizations and privileges should never have the possibility to grant whatever privileges to themselves.

Moreover the consistent application of the principle of least privileges even for standard users and processes will significantly reduce the attack surface of your company.

Nothing really new, just the same old story.

Glacier near by Grächen, Switzerland

Glacier near by Grächen, Switzerland

Have a good Weekend.

Risk management keeps the attack surface on an acceptable level

20 November 2014

In post ‘Experts: Cyber risk management requires teamwork, preparation’ Sharon Shea reports about the 2014 Advanced Cyber Security Center conference.

“‘You are not going to eliminate the risk of attacks, you are going to manage the risk’ said Michael Chertoff, former secretary of the U.S. Department of Homeland Security and executive chairman and co-founder of the Chertoff Group, during his keynote presentation at the 2014 Advanced Cyber Security Center conference.”

Well said, I fully agree. The four ways to treat risks are to transfer, eliminate, accept, or mitigate them.

To eliminate a risk is more of academic value. Eliminating the risk means eliminating the function, thus, in the worst case, eliminating the business.

The fifth option, ignore, is not acceptable for an enterprise because the hours until you are out of business could be counted on the fingers of one hand.

Risk management always starts with identifying and evaluating the risk. This is the responsibility of the business groups, with support of IT. Once you have evaluated the risk you could start managing it. Managing the risk means to bring the risk to an acceptable level, e. g. by applying mitigation measures or accepting it.

For risk evaluation it’s very important to treat attacks by malicious insiders with the same probability as attacks at servers on the perimeter of your network. If this assumption is taken into account during risk evaluation you will come to a balanced approach.

The concept of the attack surface is perfectly suited to make this clear. Even a single, not hardened, server operated inside your network increases the attack surface of your IT system dramatically because it could be used by an attacker as a gateway into your system.

Risk management should always keep the overall attack surface of a company on an acceptable level.

Minimize your attack surface, and have a good day.