It was brought to our attention that the research published had flaws. To read our response, please click here:
https://community.webroot.com/t5/Security-Industry-News/Update-to-the-Target-breach-theory/m-p/77825
An update to the Target breach theory.
Reading Time: ~ < 1 min.
I believe the title of your article is slightly misleading. It should read “unpatched software possible cause of Target security breach” While it is unknown if they were even using any Novell software, a quick web search yields the following:
http://www.novell.com/support/kb/doc.php?id=3260263
Based on that creation date, those are some neglected systems if that was actually the case.
In case any reader decides to take this post seriously, the conclusions this article draws are invalid. The first screenshot illustrates a function, purportedly from the malware used in the attack against Target, that makes use of Microsoft Visual Studio’s exception handling mechanism. The author then searches the Internet for a string found in the screenshot, finds a partial match in the write-up for a security vulnerability, and then concludes (or rather, speculates), that on the basis of this match, that therefore this vulnerability was used as part of the breach of Target. The author also notes that the line “my_target = target” within that exploit “can’t be overlooked”.
The reasons why these conclusions are erroneous:
A) Nearly every program compiled with Microsoft Visual Studio will have code similar to the snippets shown in this article. This is boilerplate code that occurs in every function that uses exception handling.
B) That particular vulnerability was discovered and fixed in 2008: http://xforce.iss.net/xforce/xfdb/43460 I imagine that, unless the security teams at Target are completely incompetent, that those security patches may have been applied in the meantime.
C) There is no reason to suspect (and certainly the article provides none) that, because this common sequence of code is purportedly used within the malware found on the Target point of sale terminals, that it reflects in any way upon what method was used to breach Target. Why would the malware have the same code as a piece of vulnerable software? Even if the malware did contain an exploit for that particular vulnerability, there is no reason for the same code from the vulnerable program to be duplicated inside of the malware.
D) The appearance of the string “my_target = target” makes logical sense within that exploit. Is the author seriously suggesting that the author of the Metasploit exploit is the attacker behind the breach of Target based upon this standard of evidence?
This is extremely shoddy research, and my assessment of Webroot as a source of credible technical information has just plummeted. Technical professionals do not do their jobs by searching for random strings on Google and then writing articles based upon conclusions drawn from that.
Oh, you changed the comment widget. I couldn’t post this earlier. This article is wrong. Beyond wrong. I cannot emphasize enough the depths of the fundamental misconception of the premise of this article.
All you have discovered is – horrific while the fact may be – both the vulnerable Novell driver and the Target malware were compiled with Visual Studio. This is a structured exception handler. It even says so RIGHT THERE in the screen shot.
I would not be this, well, harsh with a beginner posting for help on some forum. I’m scarcely an intermediate reverser myself. But this is clickbait on a corporate blog, posted by someone who claims to have been working with malware for almost a decade.
companionsphere Not to mention that the Novell Client is not required to run SUSE Linux Point of Service. How could they use a vulnerability that isn’t there?
Sorry, what? You’re basing this claim upon the fact that both of them use C++ exception handlers? Just because you Google’d a partial instruction, in a very specific tool’s output format, for a very mundane type of structure, and got a Google-whack, does NOT mean these two things are in any way the same. This is classic confirmation bias: you search online for a string emitted by a common malware analysis tool, then get a result related to malware, and suddenly 2+2=0x18.
For a start, that -18h value you’re looking at is an offset constant for the stack. It’s a fixed value that is used to identify the position of the CPPEH_RECORD struct relative to the stack frame base pointer (ebp). The two values are the same because CPPEH_RECORD is the same size no matter what application you’re writing – the sizeof the struct is 0x18.
CCPEH_RECORD is the name that IDA gives to C++ exception handler descriptors. These structures sit on the stack, at the start of stack frames, and contain various parameters related to exception handling. This is why ebp-0x18 gives you the pointer to the record. It’s a similar affair to SEH – the idea being that when an exception is thrown, the exception handling chain is traversed for a valid handler record for the exception type, and when one is found control flow is passed to the handler routine. Such structures are often a target for stack buffer overflows, because if you can overwrite the stack you can overwrite the exception handler, and can then gain control over the instruction pointer by causing an exception. This means literally nothing in the context you’ve framed it, though.
This entire fragment is likely a compiler-generated artefact and has nothing to do with malware, apart from the fact that SEH structures on the stack are often overwritten by stack buffer overflows. Even if it were vaguely relevant (which it isn’t) you’d still comparing apples to oranges.
The two pieces of code you posted are *completely* different and there is no reason to believe that they’re related in any way, other than that they both were probably written in C++ and compiled in Visual Studio.