Malware Attacks on Electronic Signatures Revisited

Monday, October 04, 2010

Eli Talmor

7af56c65866a442699d6dd1dfb02b528

This post is especially relevant in the context of Zeus Trojan attacks. In my previous posts the issue of malware resilience was raised:

In 2006 Dr. Hanno Langweg had outlined the scheme to analyze the malware attack on electronic signature generating software. He investigated attacks on six different smart-card based electronic signature software products:

"We investigate attacks for which an expert attacker invests less than a day and uses no specialized equipment to find architectural vulnerabilities in the software as it was purchased. Exploitation should be possible automatically by laymen with appropriate tools"

"In terms of the Common Evaluation Methodology we hence operate with an attack potential at level “Low”. We require neither physical presence nor possession of the signature card, and we assume some programming skills. Special knowledge of the signature software is not needed, apart from what is publicly available or what is obtained from having the product at hand."

"Privileges for executing the resulting malicious programs are determined by the respective user and are usually those assigned to the subject associated with that user. No “administrator” or “super user” privileges are required for exploitation."

"Data to be signed is prepared with an application program (and then typically transferred to a signature creation application (SCA) ) The SCA offers the signatory to present the data to be signed and after confirmation transmits data to the signature creation device (SCD), usually a smart card."

"The SCD receives a personal identification number (PIN) – either via the SCA or via the card terminal – to authenticate the signatory and verify their presence). Data is then transmitted from the SCA to the SCD that computes the signature. The signature is sent back to the SCA and can then be stored together with the data used as input to the signing process."

The following figure illustrates the problem tackled by Dr. Langweg: http://sentry-com.net/blog/wp-content/uploads/2010/10/Langweg.jpg

In our case (of Transaction Verification solution as described at http://www.sentry-com.net/Transaction.html) an application program is a browser.

In our case signature creation device is the integral part of Transaction Verification solution and therefore no extra hardware is necessary. The flow is illustrated below: http://sentry-com.net/blog/wp-content/uploads/2010/10/WebFormAuthorization.jpg

Signed Filled Form is delivered over HTTP to the website serving the form and is retained for future audit by the client who signed this form. It contains the transaction details and signature details. But can we trust it? http://sentry-com.net/blog/wp-content/uploads/2010/10/Trust.jpg

The following table consists of the following columns: attack and results of smart-card based products, attack description, countermeasure proposed by Dr. Langweg and our implementation of defense against respective attack.

Our analysis is based upon the same assumptions of attack potential, user privileges, etc.
http://sentry-com.net/blog/wp-content/uploads/2010/10/blog_table.jpg

We conclude that under the following conditions:

  • Exploitation should be possible automatically by laymen with appropriate tools without requiring physical presence, i.e. Trojan.
  • No “administrator” privileges are required for exploitation.

Our solution solves the vulnerabilities exposed by Dr. Langweg

Cross-posted from http://sentry-com.net/blog/

Possibly Related Articles:
14114
Viruses & Malware
malware Attacks
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.