Tag Archives: Vulnerability

A brief introduction to Trusteer Apex Advanced Malware Protection

18 October 2014

The Trusteer approach to malware protection could be ground-breaking in the defence of zero-day exploits and phishing attacks.

Trusteer analysed millions of applications exposed to the Internet and created lists of valid application states and operations in a database.

For example, saving a web page to OneNote is a legitimate operation when it’s run from a process created by the user. In this case the Windows Explorer is the so-called parent process. If this operation is performed by an internet explorer process that has no valid parent process, it is very likely that a malicious operation is executed.

A watchdog process is monitoring the applications exposed to the Internet. If an application executes a sensitive operation the watchdog process checks its database and approves the operations if it’s valid. Invalid operations are rejected.

Brilliant idea! A watchdog process that checks the state of an application. I would appreciate it to get this for my windows phone. The ‘Here Drive+’ app hangs sometimes, in particular in foreign cities when you need it the most. A watchdog process could check the state and restart the process in such cases. This would be very helpful.

For more details about Trusteer Apex see the Trusteer Apex Product Flyer.

Unfortunately there are some minor flaws.

Trusteer Apex monitors only applications exposed to the Internet like Browsers, Java applets, Flash player or Office applications. Although the technology could also be used for protection against traditional malware like computer viruses, the product does not support this.

This means that Trusteer Apex is only useful in addition to traditional security products like an antivirus product.

Remember that every additional product increases the attack surface of your computer or network. It is not only the continuous patching to mitigate known vulnerabilities. Trusteer Apex receives e.g. application state updates across the internet, which could be tampered by an attacker. Moreover, the Trusteer computer scientists get their raw data from millions of computers operating in untrusted networks. If an attacker tampers some raw data and masks malicious states as valid, the entire installed base could be tampered.

This is the first signs of paranoia. I’m doing definitely too much threat modelling at the moment. But remind the words of Sigmund Freud:

‘The paranoid is never entirely mistaken.’

Just think of the impact of an attack against the master pattern database of a well-known provider of anti-malware software…

Don’t Panic!!

Software manufacturers have no sense for IT security

27 September 2014

Manufacturers of scientific software could make one’s life really hard. For ease of their own business they make detailed specifications about the software versions required for the operation of their software, e.g. Apache HTTP server version 2.4.2, Tomcat version 7.0.12, Java Version 1.6, Oracle Patchlevel 8 for a 3-tier application. In the worst case they will not offer support if discrepancies are found.

Actually, you have to freeze the system and hope for the next patch or minor release before you can install urgently needed security patches to the operating system, HTTP service, middle ware, etc.

Unfortunately the attack surface of a company increases when unpatched systems and applications are operated inside the company network.

Hilbert curve, first order. Source: Wikipedia

Hilbert curve, first order.

In a well-protected IT system, where all known vulnerabilities are mitigated, the attack surface could be visualized as a first order Hilbert curve. This a curve of limited length. Everything’s under control, the CIO isn’t losing any sleep over the matter.

Hilbert curve, first and second order. Source: Wikipedia

Hilbert curve, first and second order.

Adding an unpatched application system to your network may result in a Hilbert curve of second order.

Hilbert curve, sixth order. Source: Wikipedia

Hilbert curve, sixth order.

Usage of default passwords for your database and file servers could be visualized as Hilbert curve of third order. Operation of lots of unpatched application systems may result in a Hilbert curve of sixth order.

This is a beautiful Picture, but the message is clear:
Nothing’s under control in this environment. 

By adding this vulnerabilities the attack surface, respectively the length of the Hilbert curve, has been increased significantly. And the CIO suffers from sleeplessness.

I often hear from application operators: Don’t panic! Everything will go well because ultimately, we run the systems inside the company network. People from Cologne would say ‘Et hätt noch emmer joot jejange!’ (Constitution of Cologne, Paragraph 3)

Sadly, I can’t share this view. Remind the latest security breach of the Healthcare.gov website. It took a month until the intrusion was detected. This was enough time to attack other systems inside the network. And unpatched systems, which are built upon open source software, are truly worthwhile Targets.

In my opinion, software manufacturers must build their software such, that the dependencies on the underlying software systems are minimized. This will give us the opportunity to mitigate vulnerabilities shortly after they are published.

Moreover, this will cut costs because we do not have to operate such systems in very special security islands.

Have a good weekend.

All Pictures: Source Wikipedia, Hilbert curve

Webinar: WordPress Security Simplified — Six Easy Steps For a More Secure Website sponsored by Incapsula

15 September 2014

WordPress Security Simplified — Six Easy Steps For a More Secure Website sponsored by Incapsula.

I got this invitation some days ago. This webinar might be a good starting point to dive in the exciting world of application security.


Review – US nuclear regulator hacked several times over three years

24 August 2014

In post US nuclear regulator hacked several times over three years. from 19 August 2014 Warwick Ashford talks about attacks on the U.S. Nuclear Regulatory Commission (NRC).

The big question is: What makes the NRC so interesting for attackers? Reports of safety audits containing information that should not be made public? I really doubt it.

In Exclusive: Nuke Regulator Hacked by Suspected Foreign Powers you get an idea about the real reasons:

‘Federal systems are constantly probed by hackers, but those intrusions are not always successful.’

Thank goodness this is absolutely correct! In nuclear power plants very old IT technology is used that can not be attacked easily. But the detailed description of vulnerabilities found in audit reports will make successful attacks more likely.

Perhaps you remember the film ‘War Games’? Although the Maximum Credible Accident in a nuclear power plant is not comparable to a nuclear world war, the impact on health and environment is catastrophic. Therefore such events must be taken extremely serious.

By the way, the statement above talks about the known attacks on federal systems. The total number of successful attacks may be much higher …

Don’t Panic!

Rule No. 5: Minimize the The Attack Surface

21 August 2014

Complex applications are composed of many infrastructure layers, e.g. database and file services or web services. Services are provided by one or many systems through complex software packages. All systems communicate with each other and with infrastructure systems like directory, naming or backup services. In order to simplify matters we omit the users.

Every operating system, software package, infrastructure service, etc. has vulnerabilities which could be used to attack the application. For example, the U.S. National Vulnerability Database (NVD) lists 9 vulnerabilities for the often used middleware JBOSS, all published in the past 3 month . On top we add some self-made vulnerabilities by our application design.

The set of all vulnerabilities is the known attack surface.

Please keep in mind:

[1] The whole is more than the sum of its parts!

[2] The unknown attack surface is greater than the known attack surface, and millions of hackers are working hard every day to detect new vulnerabilities.

Today’s standard answer to this challenge is patching, patching, … But from my point of view Security by Design shows a way out of the chaos. Application systems should be designed according to

Rule 5: Minimize the total attack surface!

What does this mean for the application/system design?

  • Decompose the application into separate functions, if possible provided by separate services
  • Minimize the number of interfaces between the application components
  • Minimize the number of 3rd party components
  • Relocate services onto separate encapsulated systems
  • Minimize the number of installed software packages per system
  • Minimize the dependencies on infrastructure services

The effort for build and run will be definitely higher, but the known attack surface will be much smaller.

Keep it smart and simple!

Security testing – The new magic trick?

14 August 2014

Security testing is one of the top issues in the media at the moment.

Security testing will definitely support companies in delivering less error prone and vulnerable software to their customers. It is an old truth that the cost to fix an error after rollout is considerably higher than before. But when it comes to security relevant vulnerabilities, errors can have catastrophic effects on a company.

In my opinion, standalone security testing wil not lead to more secure software in the long-term. Security should be built into the entire development process from requirements specification to user acceptance test, with verification and validation in each step. And it is very important to make it crystal clear to the customer that security comes at a price.

Security by design is the means by which less vulnerable software products could be delivered.

In particular the coding phase is critical for the vulnerability of a product. To create less vulnerable software, developers have to unlearn old programming habits, and to acquire the well known best practice for developing secure products. To ensure success, this transformation process should be embedded in a change process.

Drive the change!