I wouldn’t describe myself as a hoarder, but I am generally quite reluctant to throw things away. That old floppy disk on my shelf is a nostalgic reminder of how long it would take to install Windows NT 3.1 in my first proper IT Job. The Iomega Zip drive reminds me of a simpler time when that was enough to backup everything important on my home PC. And I actually regret that we threw away my old ZX81.
Some memories in my house I have forgotten I have, and in fact only exist because the act of doing the organizing, sorting and cleaning really doesn’t seem worth the reward. That is until my wife found an old valentines card from a previous girlfriend in an old box filled with photos and receipts I had brought with me from my bachelor apartment – I had intended to sort through the box but the time never seemed right or the effort worth it. Of course, this risk-reward assessment proved wrong the day my wife found the card in the box and wanted to know why I had “deliberately held onto the card.” My initial (in hindsight, foolish) tack of trying to downplay any significance to having the card didn’t do me any favors…
So why am I bringing up this somewhat awkward personal story? Partly a desire to validate my wife’s claim that she reads my blog posts, but primarily because of two vulnerabilities in Cisco’s WebEx applications recently discovered and disclosed by Federico Muttis, Sebastian Tello and Manuel Muradas. Some folks who don’t know me or Core well have the mistaken impression that we simply wait for a vulnerability to surface and then write a commercial-grade exploit. The natural truth is that sometimes this is what happens – no one expects us to find every vulnerability ourselves or to ignore public (I am using the loosest definition of that word) information. Core's Exploit Writing Team (EWT), and in fact a lot of technical folks at Core outside of the EWT, have specific time allocated and dedicated to looking at software in an attempt to find and responsibly disclose software vulnerabilities to better protect the consumers of those programs.
That is what happened with Cisco here, and the discovery process is interesting in itself, but first let’s talk about the vulnerabilities. One was found in the Cisco WebEx Player. If you’ve ever signed up for a WebEx-based meeting and not attended the live presentation, you may have been sent a pointer to the recording – this could have been a WRF file – and to view the presentation you would have had to install a WebEx WRF player. The reality is that, like my box of photos (etc.), you may have viewed the webcast content and had all intentions of removing the WRF player, but the phone rang, your email chime dinged, or any number of other events caused you to move on. Unfortunately the player is still resident, much like a forgotten Valentine’s Day card. All it takes is someone to send a specially crafted file with the .wrf extension and, when you click on the pointer, the WRF player will rear its dusty unused head and provide that someone with code execution on your machine… (I bet the Core Impact customers among you can hear those magic words, “New Agent Deployed”)
Here's a video demonstration of this vulnerability being exploited using Core Impact Pro:
The second vulnerability we found had the potential to be quite nasty, for those of you who have attended a WebEx Meeting in the past you may have noticed that WebEx supports polling – that is asking all the attendees a question and recording their answers. Due to vulnerability within the WebEx Meeting Center polling capabilities a malicious user could introduce a poll in a WebEx meeting and gain control over all the attendees’ machines (talk about guerilla marketing!). You can imagine the scenario: An email is sent to your organization with a relevant subject for a webcast and perhaps the promise of an iPad to the attendees. When people sign up and attend the webcast, you suddenly have agents on multiple machines within the organization.
So how did this come about? I asked Federico, a Core exploit writer and one of the discoverers of both vulnerabilities, to explain:
As Alex mentioned, Core Security employees are encouraged and allocated time to search for new vulnerabilities. People who work in different areas at Core meet in small teams to target specific software and software families.
One of those teams targeted Cisco and conducted some attacks against Cisco’s WebEx software. Why? Well, we use it for our own presentations, and we felt we owed it to the people who attend our webcasts to evaluate the software.
Cisco WebEx happens to be widely deployed, but many people only use it once in a while to attend meetings and webcasts. For example, if you installed the WebEx WRF player to view a recorded webcast a couple of months ago, and you haven’t used WebEx since, then you have outdated and vulnerable software on your system (unless, of course, you uninstalled it).
There were two bugs found that we confirmed as exploitable. One in a WRF recording, and the other one in an ATP poll file.
The WRF bug was found by using the most archaic fuzzing method:
- Open a working file
- Modify one byte
- Save the file
- Test it
This resulted in a problem "executing" an unallocated memory address. That unallocated address happened to be in the kernel space, so we suspected that the "address" wasn't an address after all, but an overflowed pointer instead. We were right; the first return address in the stack was pointing to a call instruction. And we got luckier when we found that exact "address" in the fuzzed file. The pointer was being overflowed with user-supplied data.
Doesn’t get much better, right?
Two minutes later, we discovered that DEP wasn't enabled on that process... and the stack is always in the same address space! SafeSEH isn't a problem in this scenario, but it seems that it’s not enabled either.
So a pointer was overflowed in a program without DEP and with a fixed stack address. By jumping to the stack (like it's 1990), we had a working proof of concept that spawned the calculator in about 10 minutes.
The ATP (the polling functionality in Cisco WebEx Meeting Center) vulnerability was found in the Cisco WebEx Meeting Center software. This vulnerability was found with an even simpler method. One team member opened a previously exported ATP file with a text editor (it happened to be XML). He then manually replaced a string with a new, overly long string. Then he published the Poll in a conversation and his client crashed. This appeared to be a local-only crash. That alone would have been good enough for a client-side Cisco WebEx Meeting Center exploit.
By investigating the crash in more detail, we found that the problem was in the execution of a unicode and unallocated address. The stack was full of user-supplied data, and the execution flow was redirected by the exception handling mechanism. We just overflowed the SEH, again locally, on the client that initiated the poll.
The vulnerability got even more interesting when we discovered that, after waiting 2 or 3 minutes, other meeting participants were starting to have the same problem! The vulnerability slowly iterated across all the participants of the meeting until everyone had crashed. From there, it was easy to make another proof of concept; since the SEH overwrite exploitation is pretty simple.
Alex here – as most of you know we are Cisco WebEx customers, so finding this vulnerability was both important to us to reduce the attack surface of our user base and as part of our responsibility to people who attend or view our webcasts. I think it is also important to remember that all of the above work would have less positive value if we hadn’t responsibly disclosed this vulnerability. We have worked with Cisco to ensure that they are able to address these vulnerabilities and provide solutions for the customers before information about the vulnerabilities was made public.
So what are the fixes?
The good news first: Because Cisco WebEx Meeting Center is essentially a cloud-based service, Cisco can push out the updated Meeting Center client to people when they next join a meeting. So the remediation will happen automagically the next time you attend a Cisco WebEx Meeting. That means you can join your next WebEx meeting knowing Cisco and Core Security worked together to protect you from this vulnerability.
The not-so-good news: The WRF player is a standalone application, it has no auto-update or check for update capabilities. So if you have the vulnerable version installed (i.e., did you install it before this blog was published?), you should uninstall that version and download and install the latest WRF player from WebEx (assuming you need it).
If it’s installed on your machine, the WRF player should be listed as “WebEx Recorder and Player” in your applications list. You can download the latest version here: http://www.webex.com/downloadplayer.html
So what have we learned today?
- Just because you haven’t used a program or have forgotten it is installed doesn’t mean it can’t come back to haunt you.
- Having a world-class exploit writing team makes the difference between discovering a DoS and releasing a commercial-grade client-side exploit.
- Alex’s personal life isn’t as glamorous as the glasses and accent would lead you to believe.
- Alex Horan, senior product manager