OpenVAS DevCon 1, reversing protocols and other short stories

2006-01-25 12:13:00

By Tim Brown

It's been a busy few months, so I thought I'd take the time to post a catch up post on a few things that have been happening.

First up we have OpenVAS DevCon 1 on the cards, sponsored by some folks in Germany and roughly pencilled in for a weekend sometime in March. It will be good to get together and hack the code especially since we've got a major patch bundle to roll in to the CVS version. I'll be starting on that next week, but I suspect it will not be an easy transition to make. Basically one of the guys I've been talking to online has gone ahead and made the rebranding happen. Haven't looked at his code yet, but I'm pretty excited. I put a call out on the mailing lists earlier in the week regarding build testing and the submission process, not had much feedback as yet, but I'm sure it will come.

Secondly I've been doing some fairly heavy lifting work, reversing the protocols for a rather interesting tool that carries out software license audits after I came across it during a test. After some scratching of my head, I stumbled on a very well hidden link to an evaluation download and began to reverse the code. This one had me working to silly hours and looks to have the makings of a nice advisory, but without giving too much more away here are some of the steps I took:

  • Stuck a copy of netcat on the port used by the endpoint and used the evaluation version to connect to it
  • Ran strings across the binary searching for keywords identified during the netcat sessions
  • Ran a debugger on the endpoint as I fuzzed backwards and forwards based on previous routines recorded and identified by previous analysis
  • Analysed the running endpoint binary for signs of known passwords using a debugger
  • Grepped the various ini files for known obscured passwords and then analysed the ini files permissions
  • Figured out how to remotely trigger the logging routines without authentication and how to change the file path at which they're stored
  • Figured out how to remotely execute code using the standard routines
  • Began to analyse the routines used to obscure the password on the wire and in ini files
  • Failed miserably to identify how to trigger one of the identified (but unused) routines
  • Discovered that the logging routines are vulnerable to a heap overflow! w00t!

So what do we have? Remote/local code execution which can lead to remote/local compromises, DoS based on unauthenticated log triggers, directory enumeration and potentially system file corruption, weak password obscuring and a routine I just can't trigger right now. UNf!

I also have a nice way of identifying Windows patch levels based on a backup tool, but I need to work on that a little more.

Finally, a few short stories.

Mood: random()

Music: Nothing playing right now

You are unknown, comment

/blog