Category Archives: Puzzling discussions

Discussions about IT security issues really puzzling me.

Think Before You Sync. Why just moving to the cloud does not solve the ransomware threat.

27 July 2019

On May 7th, 2019 the city of Baltimore was hit by a ransomware attack.  Although the city hired Microsoft and five other firms it has not fully recovered from the attack yet.(1)

Since the city’s email system was down officials started to use Gmail accounts for communications.(1)(2) This makes sense in the case of an emergency. Not communicating in the case of a publicly visible cyber-attack commonly has a large financial impact on businesses; but in the case of cities this may result in the loss of public security.

The ransomware attack on Norsk Hydro on March 19th, 2019 impressively shows the effect of good communications(3)(4): Investor’s confidence was not endangered at any time, the share price remained unchanged.

But from a strategic point of view, just moving to the whatever cloud is not a good idea. Google’s idea behind ChromeOS was simply clever: If everything (applications and data) is stored in the cloud the impact of e.g. ransomware will be negligible because the malware cannot jump across the https barrier to your cloud storage. The same holds for O365.

Unfortunately, users are not used of this way of working in the browser. It’s often slow, requires a change in working habits, travelling requires extra preparation, etc. So, Microsoft invented OneDrive and Google came up with Sync for Windows. Similar tools are available for Box and DropBox, and for all desktop operating systems, even for Linux.

Linux Setup Online Accounts

Linux setup online accounts during first login

With these syncing tools, the data stored in the cloud is made available on the user’s desktop. Changes to local files are synchronized immediately to the cloud and vice versa. And with this, the ransomware problem still exists because if a ransomware encrypts the synchronized files on the local copy the change is immediately synchronized to the cloud.
Game over.

So, if you want to take advantage of the cloud you have to run a vast change project: The whole working environment with all forms, templates, etc. must be provided in the cloud. And the employees must get used of the new way of working.

We need change!

We need change!

But the effort pays off: Your network becomes more resilient against cyber-attacks, workstations can be easily exchanged, the endpoint complexity can be reduced, windows domains and in the end, the campus network, will become dispensable.

So, think before you sync!

Have a great weekend.


  1. Duncan I. Google Pitches to Baltimore after Ransomware Attacks [Internet]. Government Technology. 2019 [zitiert 27. Juli 2019]. Verfügbar unter: https://www.govtech.com/computing/Google-Pitches-to-Baltimore-after-Ransomware-Attacks.html
  2. Cyber-spies tight-lipped on Baltimore hack. BBC News [Internet]. 27. Mai 2019 [zitiert 27. Juli 2019]; Verfügbar unter: https://www.bbc.com/news/technology-48423954
  3. Norsk Hydro. Update: Hydro subject to cyber attack [Internet]. 2019 [zitiert 24. Mai 2019]. Verfügbar unter: https://www.hydro.com/de-DE/medien/news/2019/update-hydro-subject-to-cyber-attack/
  4. Norsk Hydro ASA. Norsk Hydro: Update: Hydro subject to cyber-attack – 19.03.19 – News – ARIVA.DE [Internet]. de. 2019 [zitiert 24. Mai 2019]. Verfügbar unter: https://www.ariva.de/news/norsk-hydro-update-hydro-subject-to-cyber-attack-7476743

HiddenWasp malware targets Linux systems – Don’t Panic!

23 June 2019

Ignacio Sanmillan’s excellent post(1) on the HiddenWasp malware could have been truly frightening: HiddenWasp targets Linux systems, the technology used is really impressive, and the detection rate on VirusTotal was zero as of 29 May 2019.

Unfortunately, the infected systems were already under the attacker’s control. Even if anti-malware solutions for Linux would have better detection capabilities it would hardly have mattered. Also, there is no need to implement sophisticated anti-malware evasion technologies. In the easiest case, the attacker must only define an anti-malware exception for the files to be downloaded.

Pattern based anti-malware solutions are reactive protective means. The anti-malware solution provider must first analyze the new malware and create a detection pattern. Thus, it is unsurprising that the detection rate on VirusTotal was and is still low.

The big questions remain open:

  • How was the RAT (Remote Access Trojan), the precondition for the infection with HiddenWasp, initially installed?
  • How did the attackers get root privileges?

Very often, it is lack of cyber hygiene that results in the takeover of a system. Implementation of cyber security best practice will raise the bar. Extended by a restrictive SELinux configuration will reduce the likelihood of getting compromised dramatically.

It’s free, and ready-to-use.

Have a great week.


    References
  1. Sanmillan I. Intezer – HiddenWasp Malware Stings Targeted Linux Systems [Internet]. Intezer. 2019 [cited 2019 Jun 2]. Available from: https://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/

Email Data Breach Exposes Over Two Billion Personal Records – Has Cyber Security failed?

20 April 2019

Scott Ikeda’s report(1) on the Verifications.io data breach makes one thing clear: The incurable disease named cyber-security carelessness that leads inevitably to data breaches caused also this incident.

First of all, the company misjudged the criticality of the data. Although the exposed information is publicly accessible the compilation in few data sets simplifies the job of cyber criminals. Phishing emails are just more credible if high quality data(1) is used.

Secondly, the information in the MongoDB was accessible for everyone with internet access. This is not an isolated case. As of today, about 64,000 MongoDB(2) are visible in the internet, thereof about 18,000 with authentication not enabled.

MongoDB accessible to the internet.

MongoDB accessible to the internet.

The system developers ignored the vendors security advice provided in section ‘Limit Network Exposure’ of the MongoDB security checklist(3):

“Ensure that MongoDB runs in a trusted network environment and limit the interfaces on which MongoDB instances listen for incoming connections. Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available.”

This is easy to implement, at low cost.

Cyber security is about people, processes and technology. In this case, lack of cyber security awareness and missing security processes caused the incident. Nevertheless, security solution vendors advice(1) to implement new security technology for preventing such incidents:

“Security tools that automatically protect your data such as data loss prevention (DLP) and digital rights management (DRM) help secure your sensitive information. In the event that an important cloud vendor doesn’t have the right data protection, you can wrap their applications with a cloud security broker to provide the necessary cloud security and protection for your data.”

The big question is: Are such solutions effectively mitigating the risk if the system is accessible from the internet, without authentication?

I very much doubt because the number and extent of data breaches is continually growing, despite annually increasing investments into cyber security. Technology does just not cure cyber-security carelessness.

Have a great weekend.


References

  1. Ikeda S. Largest Leak in History: Email Data Breach Exposes Over Two Billion Personal Records [Internet]. CPO Magazine. 2019 [cited 2019 Apr 14]. Available from: https://www.cpomagazine.com/cyber-security/largest-leak-in-history-email-data-breach-exposes-over-two-billion-personal-records/

  2. The Shadowserver Foundation. The Shadowserver Foundation: MongoDB NoSQL Server Scanning Project [Internet]. 2019 [cited 2019 Apr 19]. Available from: https://mongodbscan.shadowserver.org/

  3. mongoDB. Security Checklist — MongoDB Manual [Internet]. https://github.com/mongodb/docs/blob/v4.0/source/administration/security-checklist.txt. [cited 2019 Apr 19]. Available from: https://docs.mongodb.com/manual/administration/security-checklist

What is the Most Secure Web Browser?

23 September 2018

For some weeks now I am busy with patch strategy and vulnerability management. When new critical vulnerabilities shows up two questions must be addressed:

  1. How fast must we patch the vulnerable systems?
  2. What vulnerabilities must be patched with highest priority? Or mitigated, if a patch is not available in due time.

Speed is the key in cyber security. The faster we find and patch vulnerable systems the greater is the chance that cyber criminals cannot exploit the vulnerabilities.

The exploit is the weapon in cyber warfare. A vulnerability as such increases the potential risk only. Once an exploit is published that can leverage the vulnerability, the vulnerability becomes a real risk. And if the exploit is “in the wild”, i.e. if the exploit is actively used by cyber criminals for attacks, the IT organization is on red alert.

Unfortunately, no one knows when an exploit spreads in the wild. Therefore, the cautious answer to the above questions is:

“The moment an exploit for a critical vulnerability is published it must be patched directly, at least on critical systems. If a patch is not available proper protective measures must be applied to mitigate the risk effectively.”

Browsers are the most critical systems because they are used in a hostile environment. Browsers are very complex applications, thus prone of errors.  Between 2013 and 2017 about 11% of 40671 vulnerabilities in total were found in the 4 major browsers Chrome, Firefox, Internet Explorer and Edge.

Market Share Browsers 2013 - 2017

Market Share Browsers 2013 – 2017. Data source: StatCounter

Browser Vulnerabilities 2013 - 2017

Browser Vulnerabilities 2013 – 2017

It remarkable to see that 67% of all browser vulnerabilities are related to IE, Edge and Firefox although they have only a small market share (11% in 2017).

Exploit publication date relative to CVE publication date

Exploit publication date relative to CVE publication date 2013 – 2017

The graphic above shows the number of exploits that are published within one month before the CVE is published compared to the number of exploits published within one month after the CVE is published.

Except for Chrome and Firefox the majority of exploits is published after the vulnerability is published. Nevertheless, we have to patch immediately on publication of a CVE.

How many exploits spread in the wild? This question is hard to answer. The Symantec attack signatures give a useful indication. “An attack signature is a unique arrangement of information that can be used to identify an attacker’s attempt to exploit a known operating system or application vulnerability.” 

Exploits in the Wild 2013 - 2017

Exploits in the Wild 2013 – 2017

This is an amazing result, isn’t it.

Have a great week!


Data sources

  1. NIST. NVD Database. https://nvd.nist.gov/
  2. Offensive Security. Exploit Database. https://www.exploit-db.com
  3. Andrea Fioraldi. CVE Searchsploit.
    https://github.com/andreafioraldi/cve_searchsploit/tree/master/cve_searchsploit
  4. NIST. EXPLOIT-DB Reference Map. http://cve.mitre.org/data/refs/refmap/source-EXPLOIT-DB.html
  5. Symantec.com. Attack Signatures.  https://www.symantec.com/security_response/attacksignatures/

Triton: Dangerous and Puzzling – Part II

11 March 2017

Part II: Some thoughts on the access vector

For preparation of the attack the attacker had to gain in-depth knowledge about the victim’s network and SIS installation.

SIS installation

According to Schneider Electric such attack could only be successful for Triconex Tricon controllers configured with the model 3008 Main Processor and firmware versions 10.0 to 10.4.(1) Only this controller family seems to use PowerPC processors. Older Tricon controllers use National Semiconductor, newer systems use ARM processors.(2)

Since the binary malware components inject.bin and imain.bin were compiled in PowerPC byte code the attacker hat detailed knowledge about the installation, in particular the controller version. Without this knowledge about the controller version the attack would have failed because of a code mismatch.

Network

If the SIS controller and engineering station are operated in an isolated SIS network this attack is not possible. For remote control, the Remote Access Trojan (RAT) needs to open at least an outgoing connection to its Command and Control server (C&C) outside the production network.

Blocking incoming traffic to SIS network but allowing outgoing traffic from the SIS network to applications, e.g. a historian, in other production network partitions is industry standard (ISA-99). Unfortunately, the latter recommendation is often misunderstood. Instead of opening only connections to dedicated systems / ports in adjacent partitions the security devices are often opened for all outgoing network traffic, sometimes across partitions.

With this, once the RAT is installed on the engineering station a weak implemented industry standard fosters the connection with the attacker’s C&C server.

Attack vector: Compromised Supply Chain

At first sight this sounds like a bad thriller. But it gives some good answers to some important questions.

How did the attacker get the knowledge of the victim’s facilities?

  1. In-depth knowledge of the plant network and the SIS installation can be extracted from documentation stored on the plant operators computer systems or on the Engineering Service Providers (ESP) computer systems.
  2. An ESP network is in general less well protected against cyber-attacks than a highly secured production network.

Conclusion: It is very likely that the attacker compromised the ESP network and the systems used for developing the SIS software.

How could the attacker develop such mature code?

Once the attacker hijacked the ESP network he was able to develop and test his attack framework on a system very similar to the production SIS.

How was the SIS network / engineering station infected?

With the next project update the ESP transferred the compromised code, e.g. by USB stick, to the production network.

Have a great week.


  1. Hand A. Triton Gone Wild | Automation World [Internet]. Automation World. 2018 [cited 2018 Mar 3]. Available from: https://www.automationworld.com/triton-gone-wild
  2. Analyzing the TRITON industrial malware [Internet]. Midnight Blue Labs. 2018 [cited 2018 Mar 5]. Available from: https://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware

Triton: Dangerous and Puzzling – Part I

4 March 2018

Jim Finkle’s report ‘Hackers halt plant operations in watershed cyber attack’ (1) published on December 14th, 2017 on Reuters made me curious and nervous at the same time.

The report deals with a cyber-attack on Safety Instrumented Systems (SIS). SIS work independently of the Process Control Systems (PCS). They guarantee that the industrial process, e.g. a reactor or a cracker, can be safely shutdown if the PCS can no longer control the process. Since compromising an SIS may cause significant negative effects on people and environment, the most important task in Production IT Security is to prevent cyber-attacks on SIS.

Although the attack was intensively discussed in the media and by security researchers many questions are still open. With this three-part blog series I like to examine some details more closely. A detailed attack analysis gives IT security strategists the chance to derive improved means for protection of SIS.

Part I: Some facts about the Triton attack

Malware naming

FireEye named the malware TRITON (2). Triton is an attack framework created to interact with Schneider Electric Triconex Safety Instrumented Systems. Other sources name the malware TRISIS (3) or HATMAN (4).

Indicators of Compromise

“In the incident, hackers used sophisticated malware to take remote control of a workstation running a Schneider Electric Triconex safety shutdown system, then sought to reprogram controllers used to identify safety issues. Some controllers entered a fail safe mode, which caused related processes to shut down and caused the plant to identify the attack, FireEye said.” (1)

From the FireEye report, we learn: “The attacker gained remote access to an SIS engineering station and deployed the TRITON attack framework to reprogram the SIS controllers. During the incident, some SIS controllers entered a failed safe state, which automatically shutdown the industrial process and prompted the asset owner to initiate an investigation. The investigation found that the SIS controllers initiated a safe shutdown when application code between redundant processing units failed a validation check — resulting in an MP diagnostic failure message.” (2)

With this, the IoC was: A production process was shutdown by the SIS although no indicators for a failure condition were signaled by the PCS.

Preconditions for a successful attack

At least the SIS Engineering Station must be accessible from the network. The FireEye (2) and Dragos (3) report confirmed that this was the case.

The Triconex memory protection key switch must be left in Program mode long enough to allow the attacker to run the attack. The FireEye (2) report confirmed that this was the case:

“The attacker could have caused a process shutdown by issuing a halt command or intentionally uploading flawed code to the SIS controller to cause it to fail. Instead, the attacker made several attempts over a period of time to develop and deliver functioning control logic for the SIS controllers in this target environment. While these attempts appear to have failed due one of the attack scripts’ conditional checks, the attacker persisted with their efforts.”

The code is publicly available from GitHub. (5)

Threat Actor

From the FireEye (2) and Dragos (3) analysis it is clear, that this was a sophisticated attack. In-depth knowledge of Schneider Electric Triconex SIS and network intrusion technology is required to perform such kind of attack and stay undetected for a while. This indicates a state-sponsored threat actor.

What does this really mean?

Production Network Reference Architecture

Production Network Reference Architecture

The cyber attacker worked his way through the business DMZ, the business network, the production DMZ and the production partition 1 to the SIS engineering station in zone 2 of production partition 2, without being noticed by any security device, SIEM or endpoint protection. That is truly amazing.

It seems like some basic protective measures were either not fully in place or misconfigured or no one checked the logs regarding IoC and IoA.

 

From my point of view this sounds very unlikely and mysterious. I will present some alternative access scenarios in part II.

Have a good weekend.


  1. Finkle J. Hackers halt plant operations in watershed cyber attack. Reuters [Internet]. 2018 Dec 14 [cited 2018 Feb 4]; Available from: https://www.reuters.com/article/us-cyber-infrastructure-attack/hackers-shut-down-infrastructure-safety-system-in-attack-fireeye-idUSKBN1E8271

  2. Caban D, Krotofil M, Scali D, Brubacker N, Glyer C, Johnson B. Attackers Deploy New ICS Attack Framework “TRITON” and Cause Operational Disruption to Critical Infrastructure [Internet]. FireEye Threat Research Blog. 2017 [cited 2018 Feb 12]. Available from: https://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html

  3. TRISIS-01.pdf [Internet]. [cited 2018 Mar 3]. Available from: https://dragos.com/blog/trisis/TRISIS-01.pdf

  4. MAR-17-352-01 HatMan—Safety System Targeted Malware_S508C.pdf [Internet]. [cited 2018 Mar 3]. Available from: https://ics-cert.us-cert.gov/sites/default/files/documents/MAR-17-352-01%20HatMan%E2%80%94Safety%20System%20Targeted%20Malware_S508C.pdf

  5. ICSrepo. TRISIS-TRITON-HATMAN: Repository containting original and decompiled files of TRISIS/TRITON/HATMAN malware [Internet]. 2018 [cited 2018 Feb 5]. Available from: https://github.com/ICSrepo/TRISIS-TRITON-HATMAN