Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog - Trust Relations, Defense in Depth, and Printers InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Trust Relations, Defense in Depth, and Printers

Published: 2007-03-20
Last Updated: 2007-03-20 23:24:10 UTC
by Scott Fendley (Version: 1)
0 comment(s)
Recently, I ended up doing a bit of consulting work for a couple of friends who work for a large scale printing shop.  These couple of techs are actually fairly security concious and are moving toward a fairly good network/system architecture for a small business network.  They do take all the appropriate measures to keep the production servers away from the test and development systems and from the general workstations. So if you include the large scale printing system as a separate entity and effectively another security realm, then we have 4 security realms.  When you look within the 3 of the 4 realms, they do have additional layers of security as they have a reasonably good patch management system, and use personal firewalls and anti-virus products as appropriate.  And the shop is small enough that the staff have endured training on good passwords, opening unexpected attachments in email, not visiting websites that are not business related.  And because of all of their defenses internally, they rarely have any incidents.  Even their broadband DSL provider does some amount of filtering for this mom and pop business as a part of the business agreement. which in reality probably amounts to filtering the netbios ports, sql server and few other wide scale attack vectors.

However, despite the best efforts of the IT staffer (all 2 of them), they had an odd incident.  They were contacted last week via the postmaster@ address stating that their mail server was compromised and was spewing spam. They went to their mail server and looked at its logs and couldn't see anything amiss with the system.  Through a bit of correspondence, they received a copy of the original spam email with full headers.  Turns out it was their test mail server was the one acting as the relay not the production server..  However, the test server was configured to only accept mail from local systems while testing.  The little sonicwall firewall they had even configured to ensure that no one outside of their business could even start a connection to that system.  However, the test server was allowed to start connections itself.   Looking closely at the logs on the test system they identified that their black box of a printing press was the system that was spewing the spam.  Confused at what was going on, they contacted me.

It turns out that despite their defense in depth mentality, it all came crumbling down because of a single system.  When they purchased this brand new state of the art  digital printing press, it came with a Unix based computer that acts as print queue repository, controller, web server, and countless other nifty features to make their life easier and better.   However, as you can see below the Unix system has many services installed and operational.  And the company that supports this printing press had requested that they have internet access to the system should a problem arise and the small business calls in for support.

To the best of my ability to look into the compromised system, it appears that the system was compromised through either an SSH or a web server vulnerability (both logs had been purged so I have a "chicken or the egg" problem).  Once compromised, the attacker turned around and added some software to the webserver directory to help keep remote access to the system, and appears to have probed inside the local network to identify local mail servers.  It found both the production server and the test server and used both of them to spew the junk mail.   Thankfully, the production mail server had anti-spam software installed on it which deleted the vast majority of the mail sent through that system (too bad for the spammer  :-) )


As a lessons learned, the company is actually pretty good at their security mindset.  However, one system potentially could have blown  the overall security posture of all of the other security realms in their organization due to the trust relations.   The manufacturer of the printing device should be chastised for making a system that has so many services enabled without documentation on what needs to be enabled for what types of activities.  For those that think you can figure out all of that without proper documentation, please see the results of the nmap scan and you will see why i think  it is a little more difficult then just a deny all policy and try to add back ports one a time.   




(The 65479 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
21/tcp open ftp?
22/tcp open ssh SunSSH 1.1 (protocol 2.0)
80/tcp open http Apache httpd
111/tcp open rpcbind 2-4 (rpc #100000)
139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
515/tcp open printer
609/tcp open rpc.unknown
614/tcp open ndbserver58 1 (rpc #536871002)
631/tcp open http Apache Tomcat/Coyote JSP engine 1.1
1234/tcp open hotline?
2020/tcp open xinupageserver?
2049/tcp open nfs 2-4 (rpc #100003)
2346/tcp open unknown
4045/tcp open nlockmgr 1-4 (rpc #100021)
4321/tcp open rwhois?
6000/tcp open X11 (access denied)
6080/tcp open tcpwrapped
7100/tcp open font-service Sun Solaris fs.auto
8009/tcp open ajp13?
8080/tcp open http Apache httpd 1.3.31 ((Unix))
9021/tcp open unknown
32771/tcp open status 1 (rpc #100024)
32772/tcp open fmproduct 1 (rpc #1073741824)
32773/tcp open metad 1-2 (rpc #100229)
32774/tcp open mdcommd 1 (rpc #100422)
32775/tcp open rpc.metamedd 1 (rpc #100242)
32776/tcp open metamhd 1 (rpc #100230)
32777/tcp open mountd 1-3 (rpc #100005)
32784/tcp open rpc
32785/tcp open dtcm 5 (rpc #1289637086)
32808/tcp open rpc
32811/tcp open rpc
44492/tcp open rpc.unknown
44493/tcp open unknown
44504/tcp open unknown
44505/tcp open rpc.unknown
44515/tcp open rpc.unknown
44516/tcp open rpc.unknown
44517/tcp open ndbserver67 1 (rpc #536871011)
44520/tcp open unknown
44523/tcp open rpc
44528/tcp open rpc.unknown
44536/tcp open unknown
44537/tcp open unknown
44538/tcp open unknown
44539/tcp open unknown
44540/tcp open unknown
44541/tcp open unknown
44542/tcp open unknown
44558/tcp open rpc.unknown
44559/tcp open rpc.unknown
44586/tcp open rpc.unknown
44744/tcp open rpc.unknown
45693/tcp open rpc.unknown
46380/tcp open rpc.unknown
Keywords:
0 comment(s)
Diary Archives