Trusteer ‘respond’ to Rapport Issues

In a recent article published on ‘The Register’ [1], Trusteer have attempted to “rebuff[...]” the “bank security bypass claims” apparently made by Digit Security in an article published in the Times [2] 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 [2].

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 [2] 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″ [3]. On the same support posting, Trusteer made a new report available “demonstrating the effectiveness of other Rapport layers of protection against financial malware” [4]. 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” [4]. 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.

[1] “Trusteer rebuffs bank security bypass claims”
[2] Flaw in software puts online savers at risk
[3] Trusteer Support (retrieved 11/10/2011)
[4] Trusteer Nucleus Efficacy Assessment