CSRF flaws that pack a punch

Note: These findings were responsibly disclosed and vendor updates have been issued.
See the eBbox Platform advisory here and the Snare advisory here.

A year after DEFCON 17, cross-site request forgery (still one of my favorite bugs) continues to present itself in some mighty interesting places.
I've already talked about it in the likes of wireless routers, UPS units, and a variety of web apps.
But it gets more sketchy when the vulnerable application gives up the keys to the castle via CSRF.
I don't mean just admin rights to the app, I mean compromise leading to control of the OS or platform itself.
Before I go into detail please know that both vendors in question responded instantly, provided fix time-lines, and met them precisely with corrective updates.
Two cases in point, keeping in mind that CSRF is often referred to as the one-click attack.
First, eBox Platform.
eBox Platform describes itself as a catchall that can act as a Gateway, Infrastructure Manager, Unified Threat Manager, Office Server, Unified Communication Server or a combination of them. One single, easy-to-use platform to manage all your network services.
Er, or one really broad attack surface.
Give away all that power to one tiny code snippet.


Figure 1

Failure to tokenize requests to the application means successful compromise with one errant victim click. Sending a halt order as seen in Figure is but a pittance as any request submitted via the browser-driven web management interface can be maliciously manipulated.
Preventing this attack clearly should be prioritized by developers; CSRF is number six in the OWASP Top 10 for a reason.

Next on our list: Snare from InterSect Alliance.
From their website: Snare for provides front end filtering, remote control, and remote distribution for audit log and event log data.
One agent to rule them all; one CRSF bug to rule all agents.
Meh.
Even though the web app for the Snare client can be configured with a password and localhost restrictions, an attacker need only convince a victim to click a link; it's simple GET request CSRF to finish the job.
http://192.168.248.231:6161/setremote?str_RestrictIP=192.168.248.235&dw_Password=on&str_Password=password&dw_PortChange=on&dw_WebPort=84
This request resets the password and the port, restricts IP access as well (in case you couldn't tell ;-)) and, as an example, via Snare for Windows, allowing the attacker to dump local users, domain users, registry, etc. On the likes of an AIX system add "remote control, and remote distribution for AIX audit data, interfacing with the underlying AIX audit subsystem as a custom stream object."
Scary.

eBox has issued the following fixes:
The problem can be corrected by upgrading your system to the
following package versions:

eBox Platform 1.4:
ebox 1.4.7-0ubuntu1~ppa1~hardy1
libebox 1.4.5-0ubuntu1~ppa1~hardy1
ebox-remoteservices 1.4.7-0ubuntu1~ppa1~hardy1

Snare has issued the following fixes:
SnareWindows - 3.1.8
SnareWindowsVista - 1.1.5
SnareAIX - 1.5.1
SnareIrix - 1.4.1
SnareSolaris - 3.2.4
EpilogWindows - 1.5.4
EpilogUNIX - 1.3

Typical recommendations apply.
For system owners, be on the lookout for vulnerabilities of this nature as you make use of convenient web-based system management interfaces such as eBox and Snare.

For vendors, make use of SDL or SDLC methods, and mitigate these risks in advance of release.

Convenience and efficiency are critical to success in enterprise computing environments, but with great power comes great responsibility. ;-)
Cheers.