What I'm Reading

Shared by Chris
This update adds a whole batch of exploits, including embedded executables in PDFs.

also some minor cleanups here and there

This update adds a whole batch of exploits, including embedded executables in PDFs.

This is bound to be an unpopular viewpoint.  I’ve struggled with how to write it because I want to inspire discussion not a religious battle.  It has been hard to keep it an incomplete thought. I’m not sure I have succeeded

I’d like you to understand that I come at this from the perspective of someone who talks to providers of service (Cloud and otherwise) and large enterprises every day.  Take that with a grain of whatever you enjoy ingesting.  I have also read some really interesting viewpoints contrary to mine, many of which I find really fascinating, just not subscribed to my current interpretation of reality.

Here’s the deal…

While our attention has turned to the wonders of Cloud Computing — specifically the elastic, abstracted and agile delivery of applications and the content they traffic in — an interesting thing occurs to me related to the relevancy of networking in a cloudy world:

All this talk of how Cloud Computing commoditizes “infrastructure” and challenges the need for big iron solutions, really speaks to compute, perhaps even storage, but doesn’t hold true for networking.

The evolution of these elements run on different curves.

Networking ultimately is responsible for carting bits in and out of compute/storage stacks.  This need continues to reliably intensify (beyond linear) as compute scale and densities increase.  You’re not going to be able to satisfy that need by trying to play packet ping-pong and implement networking in software only on the same devices your apps and content execute on.

As (public) Cloud providers focus on scale/elasticity as their primary disruptive capability in the compute realm, there is an underlying assumption that the networking that powers it is magically and equally as scaleable and that you can just replicate everything you do in big iron networking and security hardware and replace it one-for-one with software in the compute stacks.

The problem is that it isn’t and you can’t.

Cloud providers are already hamstrung by how they can offer rich networking and security options in their platforms given architectural decisions they made at launch – usually the pieces of architecture that provide for I/O and networking (such as the hypervisor in IaaS offerings.)  There is very real pain and strain occurring in these networks.  In Cloud IaaS solutions, the very underpinnings of the network will be the differentiation between competitors.  It already is today.

See Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where… or Incomplete Thought: The Cloud Software vs. Hardware Value Battle & Why AWS Is Really A Grid… or Big Iron Is Dead…Long Live Big Iron… and I Love the Smell Of Big Iron In the Morning.

With the enormous I/O requirements of virtualized infrastructure, the massive bandwidth requirements that rich applications, video and mobility are starting to place on connectivity, Cloud providers, ISPs, telcos, last mile operators, and enterprises are pleading for multi-terabit switching fabrics in their datacenters to deal with load *today.*

I was reminded of this today, once again, by the announcement of a 322 Terabit per second switch.  Some people shrugged. Generally these are people who outwardly do not market that they are concerned with moving enormous amounts of data and abstract away much of the connectivity that is masked by what a credit card and web browser provide.  Those that didn’t shrug are those providers who target a different kind of consumer of service.

Abstraction has become a distraction.

Raw networking horsepower, especially for those who need to move huge amounts of data between all those hyper-connected cores running hundreds of thousands of VM’s or processes, still know it as a huge need.

Before you simply think I’m being a shill because I work for networking vendor (and the one that just announced that big switch referenced above,) please check out the relevant writings on this viewpoint which I have held for years which is that we need *both* hardware and software based networking to scale efficiently and the latter simply won’t replace the former.

Virtualization and Cloud exacerbate the network-centric issues we’ve had for years.

I look forward to the pointers to the sustainable, supportable and scaleable 322 Tb/s software-based networking solutions I can download and implement today as a virtual appliance.

/Hoff

Related articles by Zemanta

• Does the Cloud Need a Specialized Chip? (gigaom.com)
• Dear Public Cloud Providers: Please Make Your Networking Capabilities Suck Less. Kthxbye (rationalsurvivability.com)
• Can We Secure Cloud Computing? Can We Afford Not To? (rationalsurvivability.com)
• NESSessary Question: Will Virtualization Undermine Network Equipment Vendors? (rationalsurvivability.com)
• Cloud: Over Subscription vs. Over Capacity – Two Different Things (rationalsurvivability.com)
• Cloud Computing Security: (Orchestral) Maneuvers In the Dark? (rationalsurvivability.com)
• From the X-Files – The Cloud in Context: Evolution from Gadgetry to Popular Culture (rationalsurvivability.com)

Security budgets are often based on combination of last year's spending, this year's threat du jour(s), and "best" practices, i.e. what everyone else is doing. None of these help to address the main goal of information security which is to protect the assets of the business. The normal security budgeting process results in overspending (as a percentage) on network security, because that's how the budget grew organically starting from the 90s. 

A simple three step process to achieving a Security Budget that maps to business reality rather than security silver bullet fantasies is as follows:

Step 1. Gather the relevant data for where the enterprise is investing its dollars in IT. Let's assume our company is Jones Widgets.

Step 2. Apply a "flat tax" for security budgeting, for this example let's say 7%, so if Jones Widgets invests $5M in its Customer relationship systems, $2M in Order Management, and $1M in ERP, this is the starting point for assigning priorities on security budgets. This is the part that security people miss, you don't need to do asset valuation - there is a whole group of people in the business that have already done that for you. Your job is to enable the intent that they have already clearly communicated in budget decisions. 

So applying the flat tax, our Jones Widget's budget look like this

IT System IT Budget Initial InfoSec Budget Customer Systems $5M $350k Order management     $2M $140k ERP $1M $70k

Notice that the starting point in this step is aligning the budget with overall Enterprise IT spending. Its not based on whatever area that infosec happened to invest in last year, or what someone at a conference said, its about starting by aligning with what your business values. Its not about security foo-fa-ra, its about Jones Widgets.

Step 3. Efficacy. Let's assume that the Customer Management and ERP systems are behemoth packages that are purchased third party apps, and the Order management system is built in house so you have the source code. The way that you choose to deliver security to third party purchased systems versus the ones where you design, build, and deploy the code will vary. So the next step after initially rationalizing the budget is to assess what's the most effective security I can get for each area. 

Its not that the business budget should trump the infosec budget, but its a very useful starting point. Moving off of those priorities should require a statement of efficacy that some security dollars are better spent in say the Order Management system, because the company controls the code. So if Jones Widgets' Order Management system is built in house, and the business relies on that to process orders, if that Order Management asset is compromised then its not like Jones Widgets can go and buy another Order system off the shelf from a vendor. Its their core business, their DNA.

So let's assume that Jones Widgets wants to scan its code, invest time in threat modeling and so on for its core business asset. This results in pulling 20% in from the ERP and Customer systems

IT System IT Budget Updated InfoSec Budget Customer Systems $5M $280k Order management     $2M $224k ERP $1M $56k

There's no need to get wrapped around the axle on asset valuation, the business gives you a starting point, use it. Then only move away from that when you can make a concrete case on improving efficacy by altering priorities. Or put another way - its your job. Do it.

Shared by Chris
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/

Shared by Chris
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 Zeltser

Shared by Chris
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

Shared by Chris
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.

Imagine you're a martial arts student. One day you have a guest instructor, accompanied by some of his black belts. They're experts in so-called "pressure point fighting." You've heard a little of this system, whereby practitioners can knock out adversaries with a series of precise strikes that lack the power of a brute-force approach. Until today you've had no direct experience. You may be skeptical, or maybe you believe such techniques are possible.

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(author unknown)15922148165619612147

GSM SRSLY (Shmoocon 2010) Video Tutorial(author unknown)15922148165619612147

"What Am I Doing Wrong?"

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.

Seeing Is Believing

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.

Conclusion

Getting 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.

Shared by Chris
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:

1. Uncertainty due to the lack of data
2. 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 is a Ruby library for the Nessus XML-RPC interface. It comes with an example command line program that shows how easy it is to interact with the Nessus scanner.(author unknown)03346282748764641903

LinuxSecurity.com: "Martin Beck, who in 2008 co-wrote a paper describing a way to inject packets into a secured Wi-Fi system, is back with a more extensive exploit. His 'Enhanced TKIP Michael Attacks' still don't allow extraction of a key, and are limited to TKIP (not AES-CCMP) WPA-protected networks. Still, he's figured out how to put in large payloads, and to extract data sent from an access point to a client - all without cracking the network key. The attack requires proximity to sniff and inject data, but it's another crack in the older key standard (TKIP) that no one with serious security interests should still be using."(author unknown)12733250356068973250

Shared by Chris
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?”

About me: http://www.chuvakin.org

Prelude IDS + OSSEC = Open source SIEM

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

Since everyone else is releasing code to check for/exploit the vmware server/esx/esxi directory traversal vulnerability I pushed up my checker module to the metasploit trunk as an auxiliary scanner 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.

Sucuri Security has a post over on their site that describes a harrowing situation with a virtual server that they rented from GoDaddy. Sucuri is a bit paranoid (aren't we all?) and moved secure shell from the default port of 22/tcp to an obscure port, and then placed a honeypot on 22/tcp (very smart). One day he noticed these entries: Jan 8(author unknown)023271954997522281301681878903684310520414989776657917525319

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

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

Camera discovery process through subdomain bruteforcing

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.txt

Next, 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.*WVC

Please 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:

• No active items found!
• GNUCITIZEN 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!