During a recent penetration test, a friend encountered some really strange findings that he asked me to review. Several of the desktops located in one of the departments had a process listening on an ephemeral, nonstandard TCP port. He provided his <a href="http://nmap.org/" target="new">Nmap</a> and <a href="http://www.nessus.org/nessus/" target="new">Nessus</a> findings, which both reported an Apache Web server was running on this mysterious port. The fact they were all running Apache was cert

John H. Sawyer, Contributing Writer, Dark Reading

January 28, 2009

3 Min Read

During a recent penetration test, a friend encountered some really strange findings that he asked me to review. Several of the desktops located in one of the departments had a process listening on an ephemeral, nonstandard TCP port. He provided his Nmap and Nessus findings, which both reported an Apache Web server was running on this mysterious port. The fact they were all running Apache was certainly a shock, but the most interesting part was Apache and the included version of PHP were outdated and vulnerable!We set out trying to exploit Apache remotely -- only to find that every directory we found disallowed directory listings, the root Web directory was locked down from everywhere but probably the local machine, and no Web pages or files could be found via Nikto/Wikto. The only avenue for attack was essentially from the client side, which was out of scope at the current time. (I guess management knows their users like to click on bad things. ;-) )Since we couldn't proceed, we called the client to see why Apache was running on the hosts.

After about 15 minutes of walking the local admin through netstat, tasklist, and finally Sysinternals Process Explorer, it turned out that Apache2 was part of the Marvell Raid Utility for managing the local RAID controller! Why, on what equates to a consumer desktop, would a hardware manufacturer use a Web server like Apache for local RAID disk management? More important, how do the users and local IT know to keep it patched since it was probably outdated and exploitable when first installed? I guess that's why the manufacturer makes the interface accessible only from the local host, but that could easily be circumvented through some social engineering and a well-crafted e-mail.

For infosec professionals who are responsible or have helped design patch management programs, did you take into consideration hardware vendor software? Sure, there have been exploits in hardware drivers, but I'm referring to things like HP OpenView, Dell DRAC, and the Marvell RAID Utility. Have you included those in your patch management process? The same goes for printers and their embedded management software. If you haven't included them, it's time to review your environment and see what's missing.

Pentesters can delight because hardware vendors are introducing vulnerabilities where none existed previously, providing new avenues of attack. Awesome...or not...depending on the role you play in your organization.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

About the Author(s)

John H. Sawyer

Contributing Writer, Dark Reading

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights