In a recent article published on ‘The Register’ , Trusteer have attempted to “rebuff[...]” the “bank security bypass claims” apparently made by Digit Security in an article published in the Times  on the 1st October 2011. The article is almost exclusively composed of what are presumably quotes from the CEO of Trusteer, Mickey Boodaei. At no point prior to the publication of this article on the 11th October 2011 was Digit Security made aware of the article, nor were Digit Security asked to provide any information relating to the claims made by Mickey Boodaei.
With regards to the article published by John Leyden of ‘The Register’, Digit Security would like to make the following response. The remainder of this post takes the form of a rebuttal of the claims made by Mickey Boodaei, the CEO of Trusteer, and in doing so demonstrate the dedication of Trusteer in trying to discredit our research.
“An article published in The Times of London Money Section on October 1st 2011, describes a method to bypass Trusteer Rapport’s anti-keylogging mechanism and suggests that “millions of customers are at risk of fraud because of a fundamental flaw”. We investigated the claim and found it to be a speculative threat that is not currently incorporated in malware. We fixed the issue, but asked The Times for a few days to complete our testing. They decided to run the story anyway.”
To start, with regard to “speculative threat”, the English dictionary defines ‘Speculative’ as “engaged in, expressing, or based on conjecture rather than knowledge” or “theoretical, rather than practical”. As such, Trusteer are claiming the issue is a threat based on conjecture and theory and not knowledge. That is clearly false, Trusteer have never denied that any of the information given in the 44con talk was anything but fact as opposed to theory. Indeed they have often stated the contrary, if one was for instance to view the history of the Trusteer Wikipedia page you will clearly see a “Company Response” that clearly states Trusteer acknowledge the validity of the ‘claims’.
With regard to the statement, “We fixed the issue, but asked The Times for a few days to complete our testing.”. This statement is misleading, firstly Trusteer did not give any information regarding a timeline. The first contact Digit Security has with Mickey Boodaei was on the 05/09/2011 via a telephone call ‘discussing’ the issues whilst being constantly told Rapport “protects against all malware”. The Times ran the article on the 01/10/2011, between the 05/09 and 01/10/2011, both myself and the Times were unaware of any ‘fix’. However, in an email dated 28/09/2011, Trusteer claimed to have “been able to fix the vulnerability you’ve identified.” At this point we approached Trusteer with an offer to verify the ‘fix’, the offer was rejected with the statement that we would not be provided with the ‘fix’ “until next week”. Upon asking for other evidence or explanation regarding the techniques Trusteer had employed to ‘fix’ the “vulnerability [we had] identified”, Trusteer stated the following,
“The vulnerability that was used against the software is the ability to access our driver and use its interface to either turn it off or read info from the driver. But we have watchdogs that are constantly running on your computer and they’re supposed to watch all the [communications] between the [different] components of the product. So if something is trying to even access our driver, and its not part of the Trusteer suite then we’re supposed to block it[.] The problem was that this mechanism was not applied on the driver itself. It’s applied on other components of the products, but [not the driver].
The fix was to make sure that any access or attempt to communicate with the driver is only done by components that are signed by Trusteer.”
At this point Digit Security provided a response detailing potential problems with the above statement, all of which were published in the Times article .
Digit Security has never seen any request made by Trusteer for time to “complete [their] testing”. Indeed, the statement made by Trusteer that they required “a few days to complete [their] testing” seems to conflict with a reply obtained from Trusteer prior to the publication of the Times article  stating that “we’ve been able to fix the vulnerability you’ve identified”. Furthermore, after the article was published, a reply from Trusteer was obtained in which Trusteer stated that they “had already fixed the “vulnerability” described in the article prior to the [publication of the article on the] 1st October and this was reported by Trusteer on the FAQ page of the Trusteer website.” At this point we might ask why Trusteer would have to request time to “complete [their] testing” when Trusteer were already certain that they “had already fixed the “vulnerability” described in the article” prior to its publication, did Trusteer push out a fix without having tested it? Furthermore, an honest person might want to ask themselves the following question, why was it necessary to ‘fix’ a ‘speculative’ problem? that is a problem based on conjecture and not fact?
Further, up to that point Digit Security had been unable to obtain any fix for the ‘speculative’ problems, nor found any mention of a fix date on the Trusteer support pages other than the statement that the “fix will be rolled out in the next minor release of Rapport during October/November 2011″ . On the same support posting, Trusteer made a new report available “demonstrating the effectiveness of other Rapport layers of protection against financial malware” . The testing took the form of previous Trusteer ‘testing’, that is to test Rapport “against the ZeuS malware”, the authors state that they were at “liberty [to] choos[e] the samples and versions of Zeus used in this test” . However the requirement for the malware to be a variant of Zeus remained, the results obtained are the expected.
“This situation illustrates why the information security industry has self-instituted a responsible disclosure process. Most researchers follow this practice, and do not disclose a vulnerability publicly until they have advised the software developer of the problem and given them the opportunity to fix it. This is designed to protect users. In this instance, the vulnerability code was made public without sharing it with us first, even though we made multiple requests to see it.”
To start, the statement that “the information security industry has self-instituted a responsible disclosure process” is a rather contentious statement. Indeed, it can be easily shown that the ‘industry’ has not “self-instituted” any disclosure process. The adherence to any disclosure process is entirely at the behest of the individual or Company involved. To state that “the information security industry has self-instituted a responsible disclosure process” is to imply that a consensus has been reached resulting in an explicit agreement between all parties in the “information security industry”. To our knowledge, no such agreement has been reached, and furthermore, if such an agreement does exist, we are not aware of any documentation detailing it. The next statement, namely “[m]ost researchers follow this practice, and do not disclose a vulnerability publicly until they have advised the software developer of the problem and given them the opportunity to fix it”. Firstly, it is unclear as to what ‘practice’ Mickey Boodaei is referring to as described above. Secondly, Digit Security is not aware of any evidence demonstrating that the majority of publicly disclosed vulnerabilities are disclosed prior to the “software developer” being informed and given the “opportunity to fix it”.
With regard to the statement, “In this instance, the vulnerability code was made public without sharing it with us first, even though we made multiple requests to see it.” To start, the “vulnerability code” was provided to Mickey Boodaei less than one hour after the phone call that he made to Neil Kettle of Digit Security on the 05/09/2011. Neil Kettle provided full and complete details in the form of the presentation slides used at 44con which contained all the information required for Trusteer to understand the problem in its entirety. Neil Kettle contends that he has never received any further request from Trusteer for the “vulnerability code” other than the initial verbal request from Mickey Boodaei himself. As such the statement that “we made multiple requests to see it” is completely, and demonstrably false. Further, with regard to the “vulnerability code” itself, it is clear from Trusteer’s statement that Trusteer are claiming that Digit Security, and as a corollary, Neil Kettle has distributed an ‘exploit’. In fact Mickey Boodaei explicitly accused Neil Kettle of doing just that in a private email sent to Neil Kettle on the 05/10/2011. Mickey Boodaei stated that,
“I personally fail to understand how posting a fully baked exploit code helps the public but I guess a couple of guys in Nigeria would beg to differ.”
In response to Mickey Boodaei’s accusations, Neil Kettle responded stating that his accusation did not hold water, and that we had not distributed an ‘exploit’ or “vulnerability code”, but had simply documented the design of Trusteer Rapport. The response stated the following,
“An ‘exploit’ exploits a coding flaw, a one off mistake, what you call ‘fully baked exploit’ code simply precisely mimics *your* code, that is code within Rapport itself. As a corollary, if I published ‘fully baked exploit’ code, then you yourself are guilty of the same offense in distributing Rapport itself since you implement the ‘exploit’. A strange conclusion, but valid (but then again design flaws are like that).”
The argument was based on the grounds that since Neil Kettle’s code precisely mimics code found in Rapport itself, Trusteer are guilty of distributing “vulnerability code” by Mickey Boodaei’s own measure since Rapport itself implements the “vulnerability code”. As such, Neil Kettle, and as a corollary, Digit Security have not distributed “vulnerability code” since if we had Trusteer would be guilty of the same offense, and thus by the nature of their own disparaging statement in the ‘Register’ article, shown themselves to be hypocrites. As expected, no response has yet been received from Mickey Boodaei.
“Fortunately, the exploit code published by the researcher (http://www.digit-security.com/files/exploits/rapport-listen.c) doesn’t represent a real threat for the following reasons. First, it requires the user to be an administrator, which is not the default mode on Mac computers. Second, this code triggers the operating system to ask for the user’s admin password each time the code tries to read keystrokes. Finally, the code cannot be used to read password fields due to restrictions set by the system.”
To start, consider the statement, “it requires the user to be an administrator”, this is misleading, the code in fact requires the user to either be an administrator, or have “Enable access for assistive devices” enabled in the “Universal Access” preferences pane. Further, note that this is a security feature of Apple OSX and not Trusteer Rapport. Continuing with Trusteers argument, “which is not the default mode on Mac computers”, this is also false, the first user created upon installation of Apple OSX is an administrator. Furthermore, it is unclear as to what Mickey Boodaei is trying to prove with such statements. For instance, with regard to the first statement, that is “the exploit code” “requires the user to be an administrator”, note that that is a feature of Apple OSX as previously stated and is thus true of all keyloggers on the Apple OSX platform irrespective of whether Trusteer Rapport is installed. As such, since it is clear that Trusteer did endeavour to implement anti-keylogger functionality in the Apple OSX version of Trusteer Rapport, it is also clear that they did so knowing that any such keylogger would have to be running as an administrator. At this point we pose the following question, if the “exploit code” does not “represent a real threat” because “it requires the user to be an administrator”, which is true of all keyloggers on Apple OSX, why did Trusteer bother to implement the ‘protections’ at all as surely no keylogger is a ‘threat’ on Apple OSX? Furthermore, the statement by Trusteer appears to indicate that Trusteer believe that malware is not capable of compromising a system with administrative privileges, a statement which is simply not true.
Moving on, with regard to the following, “Second, this code triggers the operating system to ask for the user’s admin password each time the code tries to read keystrokes. Finally, the code cannot be used to read password fields due to restrictions set by the system.”. The code does not trigger the OS to ask for the user admin password each time the code tried to read keystrokes. If the user is not an administrator, the OS will ask for the administrator password but only to create the ‘EventTap’ upon start-up, not every time “the code tries to read [a] keystroke”. Finally, the remainder of the statement is actually true! However, as before, this is a security feature of Apple OSX and not Trusteer Rapport and as such would be true irrespective of whether Trusteer Rapport is installed or not. An honest commentator would give credit where credit is due, so thank you Apple.
“Even if this threat were real, our customers would not be at risk. That’s because Trusteer provides a wide range of defences against fraud. It prevents malware from installing on the computer and accessing information inside the browser; it verifies the legitimacy of the website that the customer is currently using to prevent the submission of sensitive information to fraudulent websites; it detects malware activity and removes the files associated with it; and it monitors web pages loaded into the browser and removes malicious content that tries to exploit vulnerabilities in the browser or its add-ons.”
Digit Security will not comment on any of that as it is obviously marketing literature and marketing claims, no verifiable proof or design documentation that would permit any of the above statements to be shown to be true has ever been released by Trusteer. Furthermore, if we take just one of those claims, “It prevents malware from installing on the computer”. That statement seems to suggest that Trusteer claim Rapport can stop all malware from installing on the computer, how can they make such a claim? are all anti-virus products now useless in the face of Trusteer Rapport?
To finish, Digit Security would like to say that it is rather interesting that Trusteer have never mentioned nor commented on the remainder of what was demonstrated at 44con, despite having all the relevant details. There is in fact another piece of code reverse-engineered from Trusteer Rapport for Apple OSX that simply ‘switches-off’ keyboard ‘encryption’ entirely. Note that this code does not require any privileges in order to function. As such any keylogger remaining on the system can then read the keyboard without any encryption.
No mention or comment has ever been made of the vulnerabilities in the Microsoft Windows version of Trusteer Rapport. This includes both the userland and kernel based anti-keylogger protections. Furthermore, no mention has ever been made as to the reasons why Digit Security refrained from distributing any code detailing the design of the anti-keylogger protections on the Microsoft Windows platform. The reason this was not distributed was the obvious fact that such information would be of much greater utility to malicious hackers. Why is this fact never mentioned?
No mention has ever been made of the fundamental problems in the ‘encryption’ used by Rapport. Neil Kettle documented the algorithm and demonstrated the design at 44con. The algorithm is simply not encryption, but obfuscation.
Finally, with regards to the ‘fix’ that Trusteer claim to possess, we have reviewed the ‘fix’. However, Digit Security will be holding onto any subsequent findings for a later date, we are as always willing to discuss the findings with Trusteer. However, what we are not willing to enter into is a discussion dismissing the findings as ‘speculative’ and of “[no] real threat” simply because of marketing literature/claims or underlying Operating System functionality, claims for which Trusteer have never offered any verifiable proof, or can be easily refuted using elementary logic.
From the above, and our dealings with Trusteer, it is clear that Trusteer absolutely do not want the focus to be on the technical merits of the problems. Instead, they are trying very hard to move the focus on to advertising and marketing claims which are often used to ‘prove’ the security of their product. It should be noted that to our knowledge, no serious attempt has been made by Trusteer to prove the validity of any of their claims regarding the functionality of Trusteer Rapport, indeed Trusteer still claim that “Rapport prevents tampering and reading of data by encrypting sensitive information from the moment it is typed into the keyboard until it reaches the browser”, a claim that can be, and has been shown to be false.
In the recent 44con security conference held at The Grange Hotel in London UK, Neil Kettle of Digit Security Ltd gave a presentation detailing the design of just one of the protections that Trusteer claim their product, namely Trusteer Rapport is capable of providing users.
The information disclosed detailed both the design and implementation of the anti-keylogger protections that Trusteer claim are an integral part of Trusteer Rapport and in doing so revealed the ease with which said protections can be both ‘switched-off’ and ‘by-passed’ by using functionality provided by Trusteer Rapport itself. As a corollary, it is quite clear that the information disclosed represents a flaw in the design of the protection itself and is not merely a ‘software issue’ or ‘bug’. The flaw affects both the Apple Mac OSX and Microsoft Windows versions of Trusteer Rapport, presumably for all versions up to and including Emerald Release 3.6.1105.54 (OS X).
This research is to our knowledge, the first attempt made to discover the internal mechanisms utilised by Trusteer Rapport to “protect[...] web communication between enterprises, such as banks, and their customers and employees.”  Previous attempts at testing Trusteer Rapport have only sought to prove the efficacy of Rapport against known and existing malware that Trusteer presumably have specifically designed Rapport to protect users against . We believe therefore that this research constitutes the first potential disinterested review of the internal mechanisms of just one aspect of the protection that Trusteer claim Rapport provides users. Suffice to say, given the results obtained thus far, it will be interesting to see what else can be “turned-up” or is still waiting to be found inside Trusteer Rapport or indeed how Trusteer will attempt to mitigate the design flaws identified by Digit Security. In the absence of a detailed design document, which only Trusteer themselves can possibly possess, the prospect of reverse engineering Trusteer Rapport may be the only effective avenue available to people for whom marketing claims are simply not enough to convince them that a solution or offering is secure or even fit for purpose.
Finally, whilst the flaws provide a means to effectively by-pass the anti-keylogger protections of Trusteer Rapport, it is important to understand that no current malware is known to utilise said flaws and as such uninstalling Trusteer Rapport on your system is not a solution nor is it advisable. Until such a time as malware developers take into account the presence of Trusteer Rapport, Rapport is still effective against existing malware. However, one thing is clear, the more prevalent Trusteer Rapport becomes, the more likely a target it will be for financial malware developers.
The first vulnerability advisory, albeit covering many vulnerabilities in and of itself, affecting Securstar DriveCrypt has been released.
The vulnerability in question exists due to the improper validation of a user-supplied pointer within a structure passed as argument to the IOCTL interface exported from the globally accessible “\\.\DCR” device. An attacker exploiting this vulnerability may execute arbitrary code with kernel mode privileges, or cause a Denial of Service attack via a page fault caused by an invalid pointer dereference. All versions of Securstar DriveCrypt <= 5.2 are affected.
Whilst Digit Security typically waits for vendors to release verifiable patches for the issues and vulnerabilities we discover, the following comment from Securstar should be noted with respect to some of the fixes applied in the latest version of DriveCrypt:
“The user mode app still leverages the driver for some of the I/O, but in a way which cannot be exploited as easily as before, without some prior transient elevation to admin level. I am still checing [sic] a couple of aspects to be sure it is reasonably secure, IE less easy to exploit.”
The exploit targeting the recently released vulnerability in DESLock+ has been updated to target later versions of DESLock+. The exploit can be found on the research page! or, if you prefer, by visiting digit-labs.org.
The first vulnerability advisory affecting Data Encryption Systems DESlock+ has been released in the hope that a two and a half year old vulnerability will finally be fixed.
The vulnerability in question exists due to the improper validation of a user-supplied pointer within a structure passed as argument to the IOCTL interface exported from the globally accessible “\\.\DLPTokenWalter0” device. An attacker exploiting this vulnerability may execute arbitrary code with kernel mode privileges, or cause a Denial of Service attack via a page fault caused by an invalid pointer dereference. All version of DESLock+ are affected, including the CESG CCTM (http://www.cctmark.gov.uk/) approved version (v3.2.7), however, it should be noted that whilst Data Encryption Systems Ltd continue to tout the CCTM accreditation, the accreditation itself expired in May 2010.
Data Encryption Systems Ltd received the best “Encryption Solution of the Year” at “The Computing Security Awards 2010″ (http://www.computingsecurityawards.co.uk/).
Welcome to the new digit-security.com website! Much in keeping with the previous one, this design is completely XHTML standards complaint (and hopefully a little more pleasing on the eye!).
Anyway, come back soon or sign-up to our Newsletter to make sure you never miss the release of our next article, vulnerability advisory, or just to keep up-to-date with the latest news and updates from Digit Security.