Tuesday, November 26, 2013

Thoughts on vulnerability scans with indirect connections

A long while back, I gave a talk at AHA about various thoughts I had on sort of an "inversion of control" notion of managing vulnerability scans on a network. The high level point was to be decentralized and let the network manage discovering and scanning itself, and to allow remote machines to ask for scans from the vulnerability management system (as opposed to having scans shoved down their throat).

There some problems with monolithic vulnerability management systems. Firstly, they are only ever discovering new hosts for a very short amount of time compared to the amount of time spent actually assessing hosts (or sitting idle in between scans). They cannot give you a good idea of how volatile your networks are. In a BYOD world like today, I am sure there are devices popping on and off you have no idea about and that you cannot gauge risk on. This means that the VMS has only a small picture of your network in most cases. In fact, it only has a picture of the static machines on your network. Now, there are things like the Nexpose vDiscover technology that greatly aid in virtualized environments and helps remediate this problem. But this might solve the problem for a small fraction of home or business owners.

Secondly, being able to let the clients ask for scans means that the VMS no longer has the responsibility of discovering (or being told about) the asset before using it. Many enterprise solutions use computer images to sustain homogenous environments (even if this mean being lax on patches) and having a small agent that automagically pings the VMS when brought up allows network admins to work on something better than adding hosts to their VMS, like watching videos of cats.

Lastly, most VMS solutions today require the VMS be on-premise since it needs to be able to log in to the other machines via SSH or SMB. There is no real support for a connect-back scan, where the VMS listens on a port for a connection from the machine, which would help cloud offerings bypass NAT firewalls. This is a major hurdle for breaking into home end-users and small/medium-sized businesses who just can't maintain a VMS solution and can't hire someone to do it. Some cloud offerings exist (I won't call them out, you can Google), and I am not sure how they work. However, the method I will propose is technically agnostic to the VMS you are using and would allow you to use multiple systems transparently.

I took a weekend a few weeks ago to hammer out a system that allowed an arbitrary VMS to performs authenticated scans with no knowledge of the credentials needed by the remote machine and no direct connection between the two. I accomplished this using the SSH protocol only, but have some ideas on accomplishing a similar goal with SMB.

I first set up a middleman server. This middleman server would essentially be a proxy between the VMS and the machine being scanned. When the remote machine decides it wants a scan, it tells the middleman server it wants to be scanned. The middleman server sets up a temporary local user that will be used by the VMS. This temporary user will have a special, very simple shell:

mkfifo /tmp/{FIFO}-$$.in
mkfifo /tmp/{FIFO}-$$.out

echo "$@" > /tmp/{FIFO}-$$.in

cat /tmp/{FIFO}-$$.out

When the user is created, the middleman service creates a target on the VMS and provides the credentials for this special user. When the VMS logs in, all commands will be written to the FIFO. These will be read by a small C# application that has a file-system watcher watching for FIFO's matching a regex. This service also manages the connection with the agent and knows how to talk to each major VMS (yay bindings). It will pass the commands to the remote machine, and the agent runs them and returns the results. These results are written to the FIFO with the .out extension and the special shell returns the output to the VMS by reading the out FIFO.

I use a FIFO to reduce the possibility of race conditions. I don't want the agent or the VMS getting ahead of one another.

Using this, I was successfully able to scan the machine as root with the VMS never knowing the root password of the machine. This method would allow a home computer behind a router to be fully scanned with no work on the end-user besides installing the agent. The agent has no idea which VMS has scanned it as that was all managed by the middleman service.

There are a few caveats. This method is about 3x slower than a normal scan by my rough tests. I am sure a large bottleneck is the FIFO mechanism, this could be performed in memory.

Second caveat is the VMS still portscans the middleman. Not sure how to resolve this.

Third caveat is it isn't obvious how to tell the difference between report items for the middle (port scan results) and authed results. You can infer it using XML reports and various data, but with PDF reports you would probably have no idea. You can also get around this simply by taking an XML diff of a port scan of the VMS with no authed reported vulns.

No github code yet, really a pile right now and not worth putting up yet. This serves a technical explanation of what my code does.

No comments:

Post a Comment