By: Nat Puffer
On a recent internal penetration test two basic issues were identified when reviewing automated scan results. The first a series of web servers with odd IP allocations. No vulnerabilities were reported for the web server, but they were in an IP block on a segment that was primarily network infrastructure. In addition, the operating system was listed as ‘EthernetBoard OkiLAN 8100e’. A bit of Google time with the manufacturer information and it was clear that this was a management interface for a fibre channel card; in this case, a set enabling a SAN.
Thirty seconds with the card manual gave up the following:
A couple of seconds later and I was in a position to reconfigure and restart the the SAN fibre channel cards. Hilarity would not follow.
A few minutes later the second issue of this type was revealed. The punchline of this one was username ‘apc’ password ‘apc’, and the ability to turn off power to a set of servers. This information is also easily obtainable with a quick search.
Is any of this new? No. The fact that this issue is so old is actually what I found shocking. In reality, combos like root::Password and vendor::vendor are among the first that are tried when a new interface is found. The only reason I’ve highlighted the ability to look up this information is to demonstrate that it’s available to anyone researching the device.
As a pentester, I made the client aware and moved on. Relative to the other items we found (Domain Admin was enjoyed by all), it’s likely that the readout won’t warrant more than a passing comment. In addition, when the inventory of web servers is performed, do you think that “FibreChannel Card 01″ will appear on the list? Right. So when the internal audit comes looking for appropriate hardening and configuration, what’s the likelihood this is making onto the list? Right again.
However, these issues scream “Disgruntled employee. Please come play with me!”. I don’t want to be a harbinger of FUD, but while the chances are minimal the risk is there. It would take a few minutes to disable the HTTP interface or change the password (set Password xxx, pg 107 of the manual if you were wondering). This is basic due diligence, and an hour learning how to protect the device seems a sound investment.
The biggest issue however, is knowing to look for this in the first place. When I asked the client about these issues, the answer was predictable. We had no idea those interfaces were even there.