At this point it is clear that one should not connect anything firmware-based to the big internet
without any special protection - firewall, web proxy, etc. Even connecting to the intranet
is not very safe - for example at CERN, which has a very well managed and policed intranet,
I see all kinds of scans and port probes going on all the time.

For firmware-based devices, count - IPMI BMC controllers (as reported here), web managed
raid controllers, web managed network switches, video cameras, IP KVMs, web managed power bars, etc.

None of such devices ever passed any security audits (and I doubt any will ever pass) and
presence of backdoors, old bugs, old vulnerabilities, "default passwords" has been reported many times.


K.O.


On Mon, Jun 23, 2014 at 08:38:48AM -0400, Michael Tiernan wrote:
> As a member of LOPSA http://lopsa.org I recently got this message and I
> thought I'd share it with this group.
> 
> I realize this isn't specific to SL but I wanted to make sure everyone
> is as aware as possible.
> 
> -------- Original Message --------
> 
> Date: Fri, 20 Jun 2014 16:12:50 -0700 (PDT)
> From: Paul Heinlein
> To: [log in to unmask]
> Subject: [lopsa-tech] Supermicro IPMI mitigation
> 
> You've undoubtedly seen reports of the vulnerability in Supermicro's BMC
> implementation that allows IPMI usernames and passwords to be retrieved
> via a simple HTTP GET query to port 49152:
> 
> http://blog.cari.net/carisirt-yet-another-bmc-vulnerability-and-some-added-extras/
> 
> I ended up taking two different remediation tacks.
> 
> First, in our local server room, all IPMI interfaces are connected to a
> single subnet. Our room is small enough that they're all connected to a
> single Cisco switch, but the same mitigation would work with a
> VLAN-based subnet. I created an access list that only allows tcp access
> to the http and https ports. All other tcp requests get blocked.
> 
> More tricky was a single server we have running in a remote data center
> that I manage via IPMI. The Supermicro web interface allows firewall
> configuration based on source IP address, so most pokes at port 49152
> would be rejected -- but our local network setup is such that a visitor
> to our office could conceivably contact that port.
> 
> Thankfully it's Linux and iptables under the hood, so
> 
> 1. Launch ssh session to remote BMC.
> 2. Upon login run "shell sh" to get a command-line shell.
> 3. # iptables -I INPUT -m tcp -p tcp --dport 49152 -j DROP
> 4. # iptables-save > /nv/ipctrl/rultbl.sav
> 
> I'm not yet clear what will happen to the new rule if we reconfigure the
> firewall from the web gui (presumably, it will get wiped out, but I'm
> just not sure) -- but for now it gives me some level of comfort.
> -
> Paul Heinlein
> [log in to unmask]
> 45°38' N, 122°6' W
> 
> -- 
>   << MCT >>   Michael C Tiernan xmpp:[log in to unmask] +1 (617) 324-9173
>   MIT - Laboratory for Nuclear Science - http://www.lns.mit.edu
>   High Perf Research Computing Facility at The Bates Linear Accelerator
>     Please avoid sending me MS-Word or MS-PowerPoint attachments.
>     See http://www.gnu.org/philosophy/no-word-attachments.html

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada