What I'm Reading
OpenSSH 5.4 couples standard local input with server ports
Adds a -W host:port option that redirects stdio to the remote port. Lacks some netcat features such as telnet options, configurable source port, and UDP. Good writeup at: http://blog.rootshell.be/2010/03/08/openssh-new-feature-netcat-mode/ As well as a range of bug fixes, OpenSSH 5.4 includes a netcat mode which couples a local system's standard input to another computer's network port. There are also enhancements to the SFTP subsystem
Adds a -W host:port option that redirects stdio to the remote port. Lacks some netcat features such as telnet options, configurable source port, and UDP. Good writeup at: http://blog.rootshell.be/2010/03/08/openssh-new-feature-netcat-mode/
Simple Log Review Checklist Released!
Great incident response log review cheatsheet from Anton Chuvakin and Lenny Zeltser
Today, many people are looking for very simple solutions to big and complex problems – and the area of logging and log management is no exception. Following that theme, we have created a "Critical Log Review Checklist for Security Incidents" which is released to the world today.
In addition to HTML, PDF or DOC versions are available as well (alternative hosting location is here). Feel free to modify the checklist for your own purposes or for internal distribution in your organization - but please keep the attribution to the authors.
The log cheat sheet presents a checklist for reviewing critical system, network and security logs when responding to a security incident. It can also be used for routine periodic log review. It was authored by Dr. Anton Chuvakin and Lenny Zeltser (BTW, Lenny has other useful security cheat sheets on malware analysis, security architecture, DDoS, etc here)
Here is the embedded version from DocStoc:
Critical Log Review Checklist for Security Incidents -
Enjoy!
About me: http://www.chuvakin.org Great incident response log review cheatsheet from Anton Chuvakin and Lenny ZeltserTraffic Talk 10 Posted
Very interesting site for finding and sharing protocol information I just noticed that my tenth edition of Traffic Talk, titled Pcapr.net -- where Web 2.0 meets network packet analysis, has been posted. From the article:
Solution provider takeaway: Pcapr.net is a free packet collaboration site hosted by Mu Dynamics. Solution providers can participate in the community to exchange, analyze and gather traces for testing products or processes for their customers, including network packet analysis.
Not many networking solution providers are happy with the apparently limited number of network traces available for testing their products or processes. Hardly a day goes by on a network-focused mailing list without a participant asking, "Where can I download network traffic to test X?" Fortunately for anyone who wants to take network traffic exchange to a new level, Mu Dynamics has answered the call. Its Pcapr.net site is the self-proclaimed "Web 2.0 for packets." In this edition of Traffic Talk, we'll take a tour of Pcapr.net to see what features it offers networking solution providers, including network packet analysis. Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com) Very interesting site for finding and sharing protocol information
Fiserv to Banks: Stay on Outdated Adobe Reader
We should have a CVE equivilent for vendors that don't allow customers to apply security fixes.
One of the nation’s largest providers of money-transfer and online banking services to credit unions and other financial institutions is urging customers not to apply the latest security updates for Adobe Reader, the very application most targeted by criminal hackers and malicious software.
At issue is a non-public advisory issued by Fiserv, a Fortune 500 company that provides bank transaction processing services and software to more than 16,000 clients worldwide.
A reader who works in security for a mid-sized credit union shared with me a notice posted prominently to the “collaborative care” portion of Fiserv’s site, a section dedicated to security and IT managers at partner financial institutions.
In the notice, dated Feb. 16, 2010, Fiserv instructed its customers to avoid the latest Adobe Reader updates, apparently in favor of one that was released two years ago:
“NOTICE: Please do not upgrade Adobe Acrobat Reader past Version 8.1.”
The notice continues:
“The following is of importance to all credit unions.
Until further notice, please do not upgrade Adobe Reader past version 8.1. We have recently found that there are potential compatibility issues with some of our Adobe-based products. If you have already upgraded past this version you can try uninstalling to a lower version. This may or may not be successful. For instructions on uninstalling, please visit www.Adobe.com.
We will provide you with further information when it is available.”
I have requested more information from Fiserv about what prompted this advisory, and will update this post when/if they respond.
Adobe 8.1 was first released in October 2007. But even if we give Fiserv the benefit of the doubt and assume that they really meant to say “Don’t migrate your systems past the latest 8.1 version — Adobe Reader 8.1.7 (released in October 2009) that would still leave financial institutions dangerously exposed to the Reader flaw that criminals are very actively exploiting to install data-stealing software, via spam and hacked or malicious Web sites.
According to a report issued last month by Web security firm ScanSafe, 80 percent of the Web-based attacks from malicious and hacked Web sites targeted Adobe Reader vulnerabilities in the last three months of 2009. Security firm F-Secure also has noted that Adobe Reader vulnerabilities by far are the most popular for use in targeted e-mail attacks.
This kind of advisory may seem shocking, but it’s incredibly common, said Didier Stevens, an IT security researcher who has done some extensive research on Adobe vulnerabilities. As Stevens noted, many application providers or companies will urge users to remain on outdated and insecure software platforms because upgrading may break functionality in custom software. Stevens said Fiserv’s advisory to customers is probably related to a similar custom-built application.
“I can imagine that in their software they are using some components of Adobe, for example, a component to display a PDF inside of a financial application, and they just haven’t upgraded that application yet,” Stevens said.
Indeed, just last month I wrote about opening up a new account at a local bank and noticing that the branch manager was still browsing the Web with Internet Explorer 6, just days after news surfaced that a zero-day vulnerability in IE6 was used in targeted attacks against Google, Adobe and a host of other Silicon Valley companies recently. For its part, Google said it would no longer support IE6 in its applications.
We should have a CVE equivilent for vendors that don't allow customers to apply security fixes.Making a Point with Pressure Points
The seminar starts. You watch the guest instructor explain his techniques. He starts knocking out his black belts. Maybe you believe what you see, or maybe you don't. Then the instructor asks for volunteers, and several of your fellow students agree. The instructor knocks them all out, including a student you really trust to not "take a fall" to make the guest "look good." You ask the student "what happened?" and he replies "that dude knocked me out!"
Next the black belts fan out through the class to help teach pressure point techniques. They ask you if you want to get knocked out with a three-strike technique, or if you just want to feel disoriented with a two-strike technique. You decide you're a believer at this point, but you want to see what it feels like to receive a two-strike technique. Sure enough, two rapid strikes later, you're wondering what happened but are still conscious. That's all you need to believe; you're glad you're not lying on the floor, out cold!
The class ends. Several bystanders were watching through the studio's windows. Some of them are laughing. They think the whole class was fake, a joke, or stupid. Some witnesses are curious. They believe what they saw and want to know more. A few ask questions. Others mumble to themselves incoherently, probably intoxicated or mentally ill.
One of the students decides to talk to a famous yet local news reporter about his experience. This widely-read newspaper reports the story the next day, attracting a lot of attention.
With a wider audience, an extended discussion takes place about this pressure-point fighting activity.
One company conducts a Webcast and a spokesperson says "my mom used to knock me out with a frying pan when I was a kid!" He also says there's no difference between pressure-point fighting and getting punched in the face.
Another company decides to register a domain name called "pressurepointfighting.biz" and starts talking about how it works, applying what they know from Western boxing. This misses the mark but uninformed observers can't really tell the difference.
A third company jumps on the pressure point fighting bandwagon, issuing supposedly original research, inventing its own analysis, and integrating the technique into its marketing material. It turns out someone at the company had a confidential agreement with the original pressure point fighting instructor, but unilaterally decided to take a few pages out of his notebook and run to the market to make a fast buck.
A fourth company knows a lot about pressure point fighting. It writes original reporting based on its experience. Critics claim this company is just offering marketing based on the new craze.
Reaction to the news among those without direct experience is mixed, as might be expected.
Some readers are martial artists themselves. They fear being irrelevant. They are afraid their skills are not sufficient. They decide to ridicule anyone who participated in the seminar, or who has knowledge.
Some readers distrust authority. They think these techniques are just a government conspiracy to justify additional police powers. The only reason anyone is talking about such affairs is their need to get greater budgets for their oppressive police powers, man!
Some readers think the whole affair is "fear, uncertainty, and doubt" (FUD). Who could knock out a person by hitting a few pressure points? It's all a lie, or just the latest craze. It must be fake.
Some readers have been learning and practicing pressure point fighting for the last several years. They know it isn't a joke, and it is real. Also, some readers without experience realize they should learn more about pressure point fighting. That knowledge could save their lives, or the lives of those close to them. These like-minded people communicate privately, since the public arenas are now clogged with too many false discussions.
Aside from the fact that advanced persistent threat is an adversary, and not a fighting technique, this story explains the last 6 weeks of APT activity in the security industry. Not all factors are included, but enough to make my point.
Incidentally, the pressure point class is true, at least as far as the class content is described.Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)
Stealing Guests the Vmware Way Video Tutorial
GSM SRSLY (Shmoocon 2010) Video Tutorial
The Value Of Credentialed Vulnerability Scanning
I am often asked, "What am I doing wrong in regard to security?". This question is usually in reaction to some event, such as a failed audit, a network outage as a result of malware or worm or a breach that was detected in the environment. I ran into this situation while doing incident response for a large university. It was my job to monitor the network and respond to the major incidents that were occurring (it was also up to me to determine what was "major" and what was not). I worked with many different network and system administrators on campus to help them improve the security of their respective departments. However, this was an academic environment full of students and professors who wanted to work in a free and open environment, which turns out is one of the most difficult to secure!
If a department had a compromise, I would do my best to help them figure out what happened and take measures to prevent it from happening again. A comprehensive assessment would next be performed to gain a better understanding of the security shortcomings and appropriate remediation measures. These types of assessments can be a daunting task for any security professional. Nessus was one of the primary tools we used to get a handle on the vulnerabilities in the environment. While it is important to scan for vulnerabilities such as missing patches or buffer overflows, assessments need to go deeper than that because attackers will use any approach they can to breach a system. A mis-configured system does not necessarily have a CVE or BID entry. The more comprehensive the audit, the better chance I had of making a recommendation that would effect change and result in better security (which really boiled down to me not having to come back in “incident response mode”).
Credentialed scanning with Nessus is something that I wish I did more of when doing post-compromise follow-up assessments. This type of scan has several benefits:
- Not disrupting operations or consuming too many resources Because the scan is performed with credentials, operations are executed on the host itself rather than across the network. Everything from operating system identification to port scanning is done by running commands on the host, then sending the results of those commands back to the Nessus server. This allows Nessus to consume far less system and network resources than performing a traditional network scan that probes ports and services remotely.
- Definitive list of missing patches Rather than probe a service remotely and attempt to find a vulnerability, Nessus will query the local host to see if a patch for a given vulnerability has been applied. This type of query is far more accurate (and safer) than running a remote check.
- Client-side software vulnerabilities are uncovered By looking at the software installed and its version, Nessus will find client-side software vulnerabilities that are otherwise missed in a traditional network-based audit.
- Several other "vulnerabilities" - As you will see in the examples below, Nessus can read password policies, obtain a list of USB devices, check anti-virus software configurations and even enumerate Bluetooth devices attached to scanned hosts.
I recently had an opportunity to review results from a credentialed Nessus scan. The information provided was very interesting to analyze and useful to determine a plan for improved security architecture within the organization. Below are some examples of Nessus credentialed scanning results and recommendations that would follow:
USB device listing
Containing threats from USB devices can be a daunting task. Viruses can use USB thumb drives to propagate, U3 can enable thumb drives to compromise systems without user interaction and the risk of intellectual property leaving your organization on a USB thumb drive is always present (This one is perhaps my favorite). While it’s good to know what devices are being plugged into USB ports on your systems, I was surprised to see how detailed the results were. In the example above, we can see that a Palm Pre phone is being used on one of the systems. This Nessus plugin is a great way to enforce policies, especially those that govern the use of smart phones.
Bluetooth Device Enumeration
Bluetooth may not be seen as the highest priority threat against your organization but it is a channel that can be used to gain access to sensitive information, such as Bluetooth eavesdropping (Video), Man in the middle attacks against Bluetooth keyboards (Video) or even exploiting the protocol itself. The Nessus plugin shown above can enumerate Bluetooth devices connected to computers in your environment, allowing you to enforce policies aimed at stopping these threats.
Missing Client-Side Patches Report
Perhaps the most attacked client-side software, right next to Internet Explorer, is anything made by Adobe. They are responsible for some of the most popular client-side software including Adobe Acrobat, Adobe Flash and to a lesser extent Adobe Air. The ability to seek out Adobe products with missing patches in your environment, without running a client-side penetration test, is a win. You may have a system patching program in place, but why wait for an attacker to send exploits to test it when you can do it yourself first?
Anti-Virus Software Check
We can debate the effectiveness of anti-virus software, but let’s face it, a determined attacker will bypass your anti-virus defenses with little effort. However, for protection against known threats and common malware, anti-virus software provides a good line of defense. To maximize your investment in this technology, you have to keep software engines and virus definitions up-to-date. Nessus has a great plugin to help you keep tabs on this: plugin 16193 reports the anti-virus software installed on the system, its version and the latest revision of the virus signatures.
Password Policy Report
I've been known to say "Passwords are just so easy to abuse", and this couldn't be truer today. Attacks on end-user passwords and default passwords on embedded systems are extremely common, mostly because they are successful. Having a password policy is important, and even more important is to be certain the policy is enforced on all of the systems in your environment. Nessus provides a great way to check your systems’ password policies without going through the lengthy process of password brute forcing (you can tell Nessus to do password brute forcing as well).
Missing Microsoft Patches Report
While so-called "0-day" exploits get a lot of attention in the press, the dirty little secret of penetration testers (and most likely attackers) is that you don't need "0-day" exploits to compromise systems. Most successful penetration tests and breaches by attackers are accomplished by exploiting vulnerabilities for which the vendor has already released a patch, but the target organization has not yet applied. You may have a "world class" patch management system, but an attacker needs only one vulnerability on just one system in order to gain a foothold on your systems and network. You need a process of checks and balances to ensure that patches are being applied properly to all of your systems. Nessus plugin 38153 provides a nice report of missing Microsoft patches on a given host to ensure that the systems you think are patched really are.
ConclusionGetting a handle on the security posture of an organization can be a daunting task. Regular vulnerability scans, penetration tests and audits are all a part of the ongoing task of risk management. Credentialed Nessus scans provide your organization with a more accurate snapshot of the current environment, allowing you to quickly, safely and easily collect information about your network and systems. This information can be used to fill the gaps in your security architecture and make better decisions on how to improve your information security program.
Verizon Incident Metrics Framework Released
Interesting framework from Verizon Business for incident classification.
Many of you who read our blog regularly are familiar with our ‘Data Breach Investigations Report’. We hope that you’ve found past reports informative, useful, and above all, actionable.
The production of the DBIR has been driven by our desire to help solve what we see as two of the most significant problems facing our industry:
- Uncertainty due to the lack of data
- Equivocality due to the lack of a common framework
Basically, we believe that until we can all be on the same page regarding what terms mean and why those terms are useful, we’re going to have a problem creating meaning from any data we *do* get.
One of the reasons we feel that the DBIR is so useful is because it translates the incident narrative (the attacker did this, then that, then the other thing) into a data set. To accomplish this translation, we used a set of metrics developed internally. Think of it as a framework of incident elements we believe will, when gathered consistently, help people better interpret data and manage risk.
Today we’re making a version of that framework, the Verizon Incident Sharing Framework (VerIS), available for you to use.
In the document that you can download here, you’ll find the first release of the VerIS framework. You can also find a shorter executive summary here. Our goal for our customers, friends, and anyone responsible for incident response, is to be able to create data sets that can be used and compared because of their commonality. Together, we can work to eliminate both equivocality and uncertainty, and help defend the organizations we serve.
We hope that you’ll use and even take an active interest in the VerIS Framework. To that extent, we’ve set up an online forum for questions and answers, and have put in place an advisory board of independent security experts to work with the community for the better growth and evolution of the framework as it’s used outside of Verizon.
We truly believe that together, we can begin to make a real difference, and it is our hope that this “common language” will be the first step towards creating an era of shared knowledge and collaboration for our industry.
Interesting framework from Verizon Business for incident classification.nessus-xmlrpc-0.2.tar.gz
A New Wi-Fi Exploit, Limited But Clever
Short Observation on Open Source SIEM
Prelude IDS + OSSEC = Open source SIEM
Check out these two pictures, grabbed from my blog’s Google Analytics:
Open source SIEM Open source log management
These show that people are desperately looking for “open source SIEM” all the time. In fact, open source SIEM is of higher interest than open source log management. I am really curious about that, but my guess is that folks who are looking for open source logging tools don’t think of them as “log management” in their heads… Vendors, buy me a beer at RSA for this insight :-)
BTW, the next few posts will be about RSA conference– all other blogging activity is hereby STOPPED :-)
Possibly related posts:
- “On Open Source in SIEM and Log Management”
- “Why No Open Source SIEM, EVER?” (BTW, I am slowly but surely moving away from this view… long story)
- “Open Source CLOUD SIEM, Anybody?”
Troubled times with Adobe Acrobat
Every week the RISK Team gets together to discuss the week’s events, and, among other things, we look into the future to try to predict what we think might become a significant problem. Late in 2007 our predictions looked like this:
- Increased incidents of reputation attacks (Human Factors)
- Increased JavaScript Exploits
- Increased IPv6 vulnerability chatter
- Vulnerability disclosure and exploits in MS Office documents
- Increased exploitation of web sites/web apps that offer up 3rd party content that can be scripted or include code that executes on the visitor’s system
- Fourth age worm attack
- (New) Exploitation of Barnacleware: Bundled and Helper software and utilities. Software that is installed by the OEM or is picked up through routine usage but is not supported. Examples: quick launch buttons, acceleration, quicktime, adobe, realplayer, webex, zip etc…
Our concern was based not only on vulnerabilities in these products appearing more frequently, but more in the following beliefs:
- These applications are everywhere, on virtually all systems
- These applications are often installed for the user, so the user may not even know they’re there or that they need to be maintained/patched/updated
- Most, if not all, have no automatic (no user interaction) update mechanism
We felt this was forming a perfect storm. Largely unknown applications sitting on peoples’ machines, vulnerable for extended periods of time. As it turned out, we weren’t wrong. Throughout 2008 and 2009 we saw a distinct shift from attacks against the operating system to attacks against the applications, particularly barnacleware.
As the vulnerabilities in Adobe Acrobat Reader were announced, or attacked before being announced, we noticed a recurring trend that we felt was disturbing. The trend was, and still is, that Adobe isn’t the one discovering the majority of the vulnerabilities in Acrobat Reader. Third party security researchers, or criminals, have been the source for all but a couple of security vulnerabilities Adobe has patched in Acrobat Reader from what we can see. Couple this with the announcement from Scansafe that their analysis shows that criminally-crafted PDF exploits accounted for 80% of all exploits via the web in the fourth quarter of 2009.
What we didn’t expect in 2007 when we first made our prediction was that any one piece of barnacleware would be so abused without the product’s vendor taking distinct action to resolve the problems. You may remember that Microsoft shut down development of Windows Vista in order to take a serious stab at addressing the vulnerabilities in Windows XP, resulting in Windows XP SP2 which did make a big difference in the security of the operating system. In Adobe’s case, however, we have seen continual bloating of Acrobat Reader with new features and a significant increase in code base. What we haven’t seen is a new updating mechanism, one which ensures Acrobat Reader stays up-to-date without significant user interaction. Also, advice from Adobe on how to turn off Javascript completely was lacking until late 2009. When it did arrive it was via third party supporters who offered registry hacks that would achieve the goal. Even today, Adobe’s own link for “Managing JavaScript Execution in the Acrobat Family of Products ” is broken. In May 2009 Adobe introduced new functionality to restrict Javascript, allowing for the blacklisting of specific Javascript APIs. While extremely granular, it remains to be seen whether it is effective since the vulnerable APIs are not blacklisted until Adobe finds out they are vulnerable, unless the user is in an enterprise environment where Enterprise Administrators could establish their own blacklist. This certainly seems to be in line with Adobe not discovering vulnerabilities themselves, giving users the ability to disable functionality without relying on an update from Adobe.
There are numerous alternatives for reading PDF documents and we believe that you should consider whether you can deploy an alternative in your environment. We believe that the vast majority of PDF viewers do not need all of the functionality that Acrobat Reader offers, and so could be productive with an alternative. If you can find a way to get some or all of your users using an alternative, it will significantly reduce the attack surface of your enterprise. While appreciating that replacing Acrobat Reader is no small task, we do recommend you consider the risk reduction possibilities.
Finally, here is our current list of predictions:
- Increased incidents of health record compromise resulting from implementation of HITECH Act in the ARRA
- Increased targeting of EHR due to activism opposed to the health care reform debate
- A new and improved security infrastructure purposed for defending the enterprise from social networking risks
- Adoption of Business Intelligence platforms for security intelligence extraction
- High-profile financial services firm attacked through their web site
- The tipping point is imminent or has been reached for risk to mobile devices and enterprise policy will be compelled to mitigate it with controls and products, for example: anti-virus, secure “wallets,” device and application controls, etc
VMWare Directory Traversal Metasploit Module
If you want to just download a full guest host check out:
GuestStealer -- http://www.fyrmassociates.com/tools/gueststealer-v1.1.pl
or the
nmap script -- http://www.skullsecurity.org/blog/?p=436
I don't feel like re-implementing it and I for sure don't want anything ever auto-downloading several gigabytes of information for me, so if you want that functionality write it or use the above tools. Gueststealer works great.
Vulnerability References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3733
http://www.vmware.com/security/advisories/VMSA-2009-0015.html
The module:
The module is simple enough. By default it checks for:
FILE /etc/vmware/hostd/vmInventory.xml
If it receives a 200 to the traversal string and file it says its vulnerable. If you want to see the output of the file you can uncomment the following line from the code:
#print_status("Output Of Requested File:\n#{res.body}")
reload the module, then change the file to what you want (example: set FILE /etc/shadow).
Since VMWare runs as root you pretty much have access to anything on the file system.
GoDaddy Has My Passwords?
New Adobe Download Manager Bug
Within days of Adobe’s release of out-of-band security updates for both Acrobat and Reader, word now comes from security researcher Aviv Raff, of another new vulnerability in an Adobe product.
The flaw was found in Adobe Download Manager (DLM), an application Adobe uses to deliver common applications (e.g., Flash and Reader) to users’ systems. Normally, it cannot be used to download non-Adobe files onto users’ systems. However, according to Raff, a vulnerability in DLM that allows third parties to download and install files onto users’ systems, in effect, making it vulnerable for use as a malware downloader.
Raff has not released specific details about this vulnerability and has indicated that he would not do so until the problem has been resolved by Adobe. On Tuesday, Adobe released a new security bulletin indicating that they have resolved this issue. Users who used Adobe DLM to download either Flash or Acrobat from February 23, 2010 onwards are safe; everyone else is advised to removed the Adobe Download Manager entry in the Add/Remove Programs applet in the Windows Control Panel.
This is not the first time DLM has proven vulnerable to malicious attacks. In fact, in January of this year, a remote code execution vulnerability in the application was among those Adobe patched.
This was on top of a bug that Raff also discovered earlier, which allowed DLM to be triggered to download Adobe or Adobe-approved applications by going to a specific URL on the company’s site. In a situation where an unpatched vulnerability in an Adobe product was thus present, this bug could allow cybercriminals to install vulnerable applications onto users’ systems, which they could then exploit to execute malware.
Security Has a Price—Problems with Security Updates
Trend Micro researcher, Rajiv Motwani, notes that the combined impact of fixing these and other similar holes in a relatively short period of time are becoming problematic for users, particularly enterprises. In theory, Adobe is supposed to release quarterly security updates for its products but regular discoveries of new flaws have significantly been undermining its plan.
Though unscheduled patches pose problems for home users and small businesses, large enterprises face greater risks. System administrators traditionally loath to use automatic updates on enterprise systems, as this may cause disruptions to important business operations.
The burden of updating systems will then fall either on users or administrators—neither of whom think this is an appealing proposition. It is also likely that systems will not be updated, leaving them wide open to exploits. A Trusteer study found that this was exactly the case for Adobe products, revealing that only 7 percent of the total number of product users had updated versions of Acrobat applications while only 19 percent had updated Flash versions.
These concerns are always present for applications. However, for Adobe products like Flash and Acrobat, the risks are greater due to the vendor’s success. The same Trusteer study found that more than 90 percent of the total number of users run some version of Flash while 99 percent run Acrobat or Reader applications.
As Motwani notes, these two factors—Adobe’s high market penetration and users’ failure to regularly patch their systems—not only raises the number of systems that can potentially be affected. It also means that organizations face the added burden of testing each patch for stability and/or performance issues and of rolling it out in a phased manner.
Solutions and Best Practices
Consumers and small businesses will benefit most by applying any Adobe patch as soon as it is released. Both Flash and Acrobat products now include standard auto-update features that can be scheduled to check for updates on a regular basis.
OfficeScan enterprise users with the Intrusion Detection Firewall (IDF) plug-in helps protect against threats of this nature, thus providing protection until system administrators deem it acceptable to roll out relevant patches.
Post from: TrendLabs | Malware Blog - by Trend Micro
New Adobe Download Manager Bug
Hacking Linksys IP Cameras (pt 6)
This article is a continuation of the following GNUCITIZEN articles: here, here, here, here and here.
As we know, there are several ways one could go about hunting for IP cameras on the net. The slowest way would be to portscan random IP addresses for certain ports and programmatically detect if the web interface of a given camera was available on the open ports found. This method definitely works, but it can be very time consuming as it consists of scanning random IP addresses hoping that we’ll eventually come across the type of device we’re interested in.
The second method, which would be much faster in finding our target devices, would be to use a search engine and query content that is unique to our target devices (e.g.: URLs, HTML title). This method, popularized by GHDB is simple and effective. The only issue I find with this strategy is that many of these IP cameras found happen to respond very slowly. This is probably due to other curious individuals running the same searches and accessing the same cameras.
The third method which would allow you to find more “hidden” Linksys IP cameras (i.e.: not cached by search engines a.k.a. the hidden web), would consist of bruteforcing subdomains within dynamic domain names (DDNS) used by our target devices (Linksys IP cameras in this case). For instance, the following are some of the dynamic domain names supported by the WVC54GCA and WVC80N Linksys IP camera models:
- linksys-cam.com
- mylinksyscamera.com
- mylinksyshome.com
- mylinksyscam.com
- mylinksysview.com
- linksysremotecam.com
- linksysremoteview.com
- linksyshomemonitor.com
We first save the aforementioned domains in a file, doms in this case. Then we use dnsmap to bruteforce subdomains for each of the domains included in doms.
Using dnsmap’s built-in wordlist:
$ for i in `cat doms`;do dnsmap $i -r ~/ -i 64.14.13.199,216.39.81.84&done;Using a user-supplied wordlist, wordlist_TLAs.txt in this case, which is a three-letter acronym wordlist included with dnsmap v0.30:
$ for i in `cat doms`;do dnsmap $i -w wordlist_TLAs.txt -r ~/ -i 64.14.13.199,216.39.81.84&done;Note: dnsmap’s ‘-i’ option allows ignoring user-supplied IP addresses from the results. In this case, 64.14.13.199 and 216.39.81.84 belong to the DDNS service provider, and would therefore be regarded as false positives in this case (we’re only interested in IP cameras setup by their respective owners after all). For more info on how to use dnsmap, checkout the README file.
We then parse the IP addresses of the subdomains discovered by dnsmap:
$ grep \# dnsmap*.txt | awk '{print $4}' | sort | uniq > ips.txtNext, we scan for ports that could potentially be used by a Linksys IP camera web server. In this case, we choose TCP ports 80, 1024 and 1025 as candidates:
$ sudo nmap -v -T4 -n -P0 -sS -p80,1024,1025 -iL ips.txt -oA nmap_http_ports.`date +%Y-%m-%d-%H%M%S`This leaves us with a lot of discovered services, but we don't quite yet know which of them correspond to actual Linksys IP cameras web interfaces. There are many ways to fingreprint the web server of a Linksys IP camera. In this case we chose to create our own amap response signature, and then scan the open ports with amap.
Before amap is capable of identifying our target Linksys IP cams, the following response signature needs to be added to appdefs.resp, and amap then needs to be recompiled. Otherwise amap won't take the new signature into account:
http-linksys-cam::tcp::^HTTP/.*\nServer: thttpd/.*Accept-Ranges: bytes.*WVCPlease note that the previous amap response signature was only tested against the WVC54GCA and WVC80N Linksys IP camera models. So I'm not sure if it will work against other models. You've been warned!
Once recompiled, amap can be used to identify Linksys IP cameras from nmap's open ports results.
$ amap -i nmap_http_ports.2010-02-22-102001.gnmap -R -S -o amap_results.`date +%Y-%m-%d-%H%M%S`We finally parse the IP addresses and open ports for all discovered Linksys IP cameras:
$ grep http-linksys-cam amap_results.2010-02-22-102253 | awk '{print $3}' | cut -d \/ -f1 x.x.167.245:1024 x.x.228.231:1025 x.x.228.231:80 x.x.64.22:80 x.x.206.70:1024 x.x.31.4:1024 x.x.164.28:1024 [snip]At this point we have accomplished the task of creating a list of Linksys IP cameras without resorting to search engines or scanning random IP addresses. In order to discover more Linksys cameras, a more comprehensive wordlist would need to be used with dnsmap.
Of course, even further automation would be possible. For instance, an attacker may wish to programmatically identify which Linksys cameras from the previous list allowing video viewing to unauthenticated users:
$ amapfile=amap_results.2010-02-22-102253;for i in `grep http-linksys-cam $amapfile | awk '{print $3}' | cut -d \/ -f1`;do url="http://$i/img/main.cgi?next_file=main.htm";if curl --connect-timeout 2 -s -I --url $url | grep ^"HTTP/1.1 501">/dev/null;then echo $url;fi;done; x.x.206.70:1024/img/main.cgi?next_file=main.htm x.x.105.221:1024/img/main.cgi?next_file=main.htm x.x.105.221:80/img/main.cgi?next_file=main.htm x.x.181.195:1024/img/main.cgi?next_file=main.htm x.x.243.154:1024/img/main.cgi?next_file=main.htm x.x.243.154:1025/img/main.cgi?next_file=main.htm x.x.30.196:1025/img/main.cgi?next_file=main.htm [snip]
In addition to automatically checking for anonymous video viewing on all cameras found, other tasks such as checking for default credentials (admin/admin) could also be scripted, although this will NOT be included in this post (or any other at GNUCITIZEN).
---
gnucitizen information security gigs part of the cutting-edge network:
---
recent posts from the gnucitizen cutting-edge network:
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5
Hacking Linksys IP Cameras (pt 6)
dnsmap v0.30 is now out!
Links between forensics and pen tests
Last year on the show, Marcus J. Carey presented a tech segment about using memory analysis in penetration tests. Memory acquisition came into its own for incident responders a few years back. Even before tools like Volatility, Memoryze or HBGary's Responder were available, many incident responders, including me, used the strings command to perform rudimentary searches and "analysis" of memory artifacts.
Figure 1: strings output of a Linux VM's memory image. The highlighted "forensics" happens to be the root password.
Shortly after Carey's presentation, DarkOperator posted a Meterpreter script that would dump memory and save it offline for later analysis. Passwords are a high value memory artifact for penetration testers. As someone working in app sec and incident response, Carey got me thinking about other things that forensics practitioners may find commonplace, but that may be overlooked by penetration testers. Both disciplines inform each other.
Let's say you're a penetration tester (or an Amortized Perennial Threat as Shawn Moyer says he is) and you're working for a client who wants you to go beyond the shell. Your client has requested that you go after important company data. Databases are an obvious target, but companies also have critical information floating around in Microsoft Office documents (e.g. business plans, bid contracts, vulnerability remediation tracking information, etc.).
What is the best way to locate these documents? You could manually navigate the various common directories where people store documents, read the directory listings and copy down those files that look interesting. But this is a labor intensive process and you may miss something if the user has tucked important files in odd locations.
If only there were a place on the file system that held information about files, a place where we could look and see all of the files that had been opened on the system and that would map back to the location of those files, even if those files were on network shares or removable media. Fortunately for us, there is such a location, in fact, there are two well known ones.
Windows systems have a feature that creates shortcuts for common document types, including Office files when those files are opened by a user. The idea of using these shortcuts during a pen test is not new. In fact, it was mentioned before on Security Focus' Pen-Test mailing list, but I don't believe it's been ahem, weaponized until now.
These shortcuts or link files are created by Windows to facilitate the "Recent" document features of modern Windows operating systems. For Windows XP the default location for link files is under Documents and Settings\<username>\Recent with Microsoft Office files having their own location in Documents and Settings\<username>\Application Data\Microsoft\Office\Recent\. Vista and later versions of Windows have moved the recent link files to Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\ and Users\<username>\AppData\Roaming\Microsoft\Office\Recent. There may be other locations specific to other applications as well.
For the two common locations, I have created a Meterpreter script port of Harlan Carvey's lslnk.pl that is commonly used by forensics analysts to dump the contents of Windows' .lnk files.
dumplinks.rb can be used with the Meterpreter to dump the contents of Windows' .lnk files either to the Metasploit user's local file system, or to the console. By default, dumplinks.rb, runs in a less verbose mode than Carvey's lslnk.pl, in that it only reports the time stamps for the .lnk files themselves, then prints the time stamps contained within the .lnk files that are time stamps for the target file and finally, the target file's location is printed.
Enough drivel, here's a couple of screen shots:
Figure 2: dumplinks help screen
And one of the script in action, dumping to the console:
Figure 3: dumplinks sending everything to the console
Of course there are other tools and techniques that cross-over from forensics to penetration testing. I will be back with another, as soon as I can find the time. For now, enjoy the dumplinks.
Dave Hull describes his working life as on the Venns between incident response, forensics and web applicaiton security. He will be teaching SANS Forensics 508: Computer Forensics Investigation and Incident Response in Boston, March 15 - 20
Identifying Opportunities for Improvement in Security Architecture
Here's a report that should surprise nobody - people pick predictable passwords (say that five times fast).
After the security breach, database security firm Imperva analysed the passwords used, publishing a report entitled Consumer Password Worst Practices.
The data found that the most common passwords were:
1. 123456
2. 12345
3. 123456789
4. Password
5. iloveyou
6. princess
7. rockyou
8. 1234567
9. 12345678
10. abc123
The analysis revealed a large amount of users had chosen "easy-to-crack" passwords, the most common being "123456", which was chosen by 290,731 users, or almost one percent.
'Nicole' was the 11th most commonly chosen code, followed by 'Daniel' in 12th. Other names appearing in the top 20 passwords include 'Jessica' and 'Michael'.
What is surprising is that this "secret" along with other great "unknowns" like Social Security Number, is what's used in standard practice Information Security to bootstrap the whole access control program. When the users are spoofed, phished, pharmed, and otherwise tricked into clicking on something that allows the bad guys in, they're routinely insulted as "how could they be so dumb" to click on that or whatever. But is it any dumber than architecture that relies on storing & shipping the dynamite and the detonator in the same truck?Here is the process view of a typical, simplified software architecture
That looks fine, right? The Subject (users, web service, client) is separated from the Object (Web App, Server, Web Service, data), but let's look at storage of the above.
Notice anything? The Object logic and data is stored in the same domain as the Subject *and* the Subject's secrets. Does this make any sense? I will now bash my head on my desk repeatedly.
The current architecture is not a security architecture in any meaningful sense, its an operational and deployment convenience. If you are building out security architecture like this for Web apps, Web Services, and Cloud, then please stop. Step away from the keyboard and look at using something else.
Start here for some ideas
Its not that any of these new identity standards are silver bullets, but they do something important. They move to enforce a separation of the Subject environment and the Object environment. They get the dynamite and detonators out of the same truck and into different trucks.
Not only that, but it changes the management process to enable each domain to do what they can do best.
The lifecycle management of the Subject - such user registration, account maintenance, user authentication, is kept separate from the lifecycle management of Objects like service versioning, app deployment, instance level authorization, business rules and so on. The third rail being the agreement points in the federation, like contracts, between the domains (such as across organization, business units, and technologies). Carving out the responsibilities this way, gives each domain a chance to execute, and the standards like SAML enable moving the tokenized version of this around so it works at runtime.
From a security architecture standpoint there's no real excuse to spray username/password around everywhere any more. The role of architecture is to separate concerns and place functionality and ownership in places where they have the most knowledge and resources to accomplish the task. In identity the knowledge and resources required to identify and manage users are totally separate from those required to identify and manage apps and servers, yet they are often combined into a lowest common denominator. The new identity standards like Information Cards, SAML, and oauth are widely supported in products, best of breed and open source. Investigate them and find the best fit for your company and systems. The only thing worse than a weak/guessable password is lots and lots of weak/guessable username/passwords. And that's what we have now.
BLADE: Hacking Away at Drive-By Downloads
The online version of Technology Review today carries a story I wrote about a government funded research group that is preparing to release a new free tool designed to block “drive-by downloads,” attacks in which the mere act of visiting a hacked or malicious Web site results in the installation of an unwanted program, usually without the visitor’s consent or knowledge.
The story delves into greater detail about the as yet unreleased software, called “BLADE,” (short for Block All Drive-By Download Exploits). That piece, which explores some of the unique approaches and limitations of this tool, is available at this link here.
As I note in the story, nearly all of the sites that foist these drive-by attacks have been retrofitted with what are known as “exploit packs,” or software kits designed to probe the visitor’s browser for known security vulnerabilities. Last month, I shared with readers a peek inside the Web administration panel for the Eleonore exploit pack — one of the most popular at the moment.
The BLADE research group has been running their virtual test machines through sites infected with Eleonore and a variety of other exploit packs, and their findings reinforce the point I was trying to make with that blog post: That attackers increasingly care less about the browser you’re using; rather, their attacks tend to focus on the outdated plugins you may have installed.
Phil Porras, program director for SRI International — one of the research groups involved in the project – says that so far none of the exploit sites have been able to get past BLADE, which acts as a kind of sandbox for the browser that prevents bad stuff from being written to the hard drive. Yet, because the tool allows the exploit but blocks the installation of the malicious payload, the group has been able to collect a great deal of interesting stats about the attacks, such as which browsers were most often attacked, which browser plugins were most-targeted, and so on.
The following graphs were taken from the latest version of BLADE’s evaluation lab, which is constantly updated with results from new exploit sites. The charts below show the breakdown from 5,154 drive-by download infections blocked by BLADE.
Here are the vulnerable applications that were most targeted in the drive-by attacks the BLADE group saw:
We can see the BLADE team found that the Eleonore exploit kit was among the most used to infect sites:
Researchers also found lackluster detection of the exploits by the industry’s top anti-virus products (Porras said the data below is an average of the detection rates for each malicious binary delivered by the exploit sites):
I’ll be sure to let readers know when this tool is publicly available for download.
