About James Klun

Eldergeek - 30+ years of Mainframe/Unix/etc systems programming, administration, and technical management. 15+ years of Infosec. Endless amounts of what might pass for English prose. "We have met the enemy, and he is us" http://en.wikiquote.org/wiki/Walt_Kelly

Home HPSS detection of SANS topic: “More Device Malware: This is why your DVR attacked my Synology Disk Station (and now with Bitcoin Miner!)”

One of the SANS topics discussed in March and early April caught my attention recently: 


More Device Malware: This is why your DVR attacked my Synology Disk Station (and now with Bitcoin Miner!

Quote from the link:

 “Update:Just found what looks like a bitcoin miner on the infected DVR. There are two more binaries. D72BNr, the bitcoin miner (according to the usage info based on strings) and mzkk8g, which looks like a simplar http agent, maybe to download additional tools easily (similar to curl/wget which isn’t installed on this DVR by default). I will add these two files to https://isc.sans.edu/diaryimages/hikvision.zip shortly.

Last week, we reported that some of the hosts scanning for port 5000 are DVRs (to be more precise: Hikvision DVRs, commonly used to record video from surveillance cameras [1] ).”

Basically what is claimed is that compromised video equipment (HIKVISION) is scanning TCP 5000 looking for network attached storage devices (SYNOLOGY) that have a flaw:  http://www.scip.ch/en/?vuldb.10255
And also – that the compromised video equipment has had bitcoin mining software installed.  Nice touch. 

I have an Internet-facing honeypoint listening on TCP 5000 – I did it out of curiosity.

Got this within 30 minutes

satori received an alert from 177.206.XXX.XXX at 2014-03-31 18:18:45 on port 5000
Alert Data: GET /webman/info.cgi?host= HTTP/1.0
Host: 71.XXX.XXX.XXX:5000
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

Then I took a look at: 177.206.XXX.XXX  ( IP is in Brazil )

21/tcp    open     ftp
23/tcp    open     telnet
443/tcp   open     https
554/tcp   open     rtsp
990/tcp   open     ftps
8001/tcp  open     vcom-tunnel

Screenshot of the site – below: 


Here is the html source for the page: 

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
    <meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″>
    <link rel=”stylesheet” href=”../css/base.css” type=”text/css” />
    <link rel=”stylesheet” href=”../css/login.css” type=”text/css” />
    <script type=”text/javascript” src=”../script/jquery-1.7.1.min.js”></script>
    <script type=”text/javascript” src=”../script/jquery.cookie.js”></script>
    <script type=”text/javascript” src=”../script/login.js”></script>
    <script type=”text/javascript” src=”../script/common.js”></script>
    <script type=”text/javascript” src=”../script/Translator.js”></script>
<body onload=”initLogin()”>
<div id=”container”>
            <select id=”LanguageSelect” name=”LanguageSelect” onchange=”changeFrameLanguage(this.value)”></select> 
                    <label id=”lausername” name=”lausername”></label>
                    <input type=”text” id=”loginUserName” maxlength=”16″ />
                    <label id=”lapassword” name=”lapassword”></label>
                    <input type=”Password” id=”loginPassword” maxlength=”16″ />
                <span onclick=”doLogin()” onmousemove=”this.className=’loginbtnon'” onmouseout=”this.className=’loginbtn'”>
                    <label id=”lalogin” name=”lalogin” ></label>
        <label name=”laCopyRight”>©Hikvision Digital Technology Co., Ltd. All Rights   Reserved.</label>

Bingo – so I have a confirmed case of compromised video equipment in Brazil scanning my home Internet IP for a vulnerability affecting NAS storage devices.

Small world, no? 

This was genuinely fun for me as it allowed me to take an interesting but somewhat remote piece of the constant security news-stream and render it immediate and real – that was MY IP being scanned.  

BTW: Does your organization  have video equipment with exposed interfaces on YOUR Internet perimeter?  Many of you do… and don’t know it. 



Avatar, Know Thyself!: The view of your organization from the Internet

“….(His) Inner eye opened to the stepped scarlet pyramid of the Eastern Seaboard Fission Authority burning beyond the green cubes of Mitsubishi Bank of America, and high and very far away he saw the spiral arms of military systems, forever beyond his reach.”

from “Neuromancer“, William Gibson 

… and off in the corner of that vast array of light and shadow – that brave new world we have created beyond the pixels – sits you and your organization.  Your company, your school, your governmental organization….visible in a way you may have never seen.

 And that’s the problem.  

William Gibson’s protagonist has the ability to “jack into the matrix” and see this new world for what it is: A universe of manipulable interfaces and data constructs that radiates beyond the physical world.  Invisible to those not so gifted. 

My experience over the last few years has made me aware that many organizations that have a face they present to this new world are unaware of what it looks like. 

Attackers do.  They see your presence on the Internet with bright clarity.

Its not the building you drive to everyday. Its not the office, cubicle farm, memos, meetings, and daily internal dramas that occupy so much of our work day.

It’s not these windows an attacker sees:  


It’s windows like this one – visible to any Internet attacker: 



… or this: 


There’s nothing inherently wrong with having such a “window” on the Internet, just as there’s nothing wrong about having windows in your house.  But – you know ALL the windows in your house.  You make sure they are closed, locked, and in some cases you replace the more vulnerable ones with glass brick, or remove them entirely. 

Do you know the windows your enterprise shows to the Internet?   And if your reaction is, “Well, I don’t, but I’m sure someone does.”  – you may be surprised to find they don’t. Your techs – including your networking techs – may know the exposures they are responsible for – but they may be completely unaware of exposures created 10 years ago by some previous group.  These exposures live on, potentially populated by systems no longer being maintained.   It happens – a lot.

What to do?   How to learn who you are on the Internet? 

  • Talk to your network admins about the Internet ranges assigned to your organization. 
    • They will know what they manage – but that may be all they know.
    • They may be unaware of network ranges that are in use ( or were at one time)  by other portions of your enterprise now or in the past.
    • If your organization has grown as a result of mergers an acquisitions there could very well be ranges in use they are completely unaware of. 
    • Be aware also that “mistakes happen”.  Firewall rules are typo’ed and unintended exposures occur. 
  • Contact your Billing department.
    • Make sure you can account for all payments to Internet Service Providers (ISPs) by your organizations.  Get contact info. 
  • Contact your known ISPs.
    •  Ask them what IP ranges you are assigned.  Be aware that you may be told   a range of IP addresses that is actually larger than what you are assigned – a range that encompasses other organization’s assignments.  You will have to check.
  • Become familiar with ARIN (American Registry for Internet Numbers) and the other “Regional Internet Registries” (RIR). 
    • ARIN handles IP range registration for North America
    • IP ranges may be specifically allocated to your organization, or they may be suballocated by your Internet Service provider (ISP) functioning as a “Local Internet Registry
    • Try a lookup of one of your known IP address at: https://www.arin.net/
    • Be aware that your primary public web site may be at a hosting facility and not at an IP address actually allocated to your own organization.  FTP, VPN and other such services are more likely to be “yours”. 
  • Become familiar with the WHOIS command, available on all Linux variants. 
    • Do WHOIS lookups based on IP addresses you know to be yours. 
    • Various web services provide WHOIS lookup:
    • Depending on the diligence of your ISP ( and that of any upstream providers they in turn use) you may find specific information about your sub-allocation. If not – talk to your ISP 

Verify your new list of Internet IP addresses!  ( as in “trust, but verify“) 

  • FIRST! – Let you ISP know you will be doing checks against your assigned IPs. 
  • Examine each Internet IP address for its service exposure – look for returned banners and check each web server exposure with a browser.  
  • Are they all yours?  – If not ( and it happens) contact your ISP to resolve. 
  • Make a definitive list of your confirmed IP addresses and their services. 
  • Circulate that list within your organization – look for confirmation or objection.
  • Publish the list when finalized – make sure everyone who could remove or create a new exposure knows that they must keep that list current!

Your organization now knows what it looks like on the Internet. 

  • Keep the list updated and disseminated within your organization. 
  • Either perform or commission regular (quarterly?) security assessments against ALL your Internet services.  
  • These assessments will test the security of your services AND inventory them. 
  • You may be surprised when new services appear or old ones disappear. Change management is a great – when it works.  😉
  • Act quickly to resolve any security findings.  No internal excuses for public vulnerabilities!

Following the above steps will help you to know what your organization looks like in the “new” real world and will help ensure that look is a secure and confident one.

Questions?   Email: info@micrsosolved.com






Egress Filtering

As I mentioned in my last post (Datacenter Attack Surfaces), I’d like to take some time to discuss the basics of “Egress Filtering“.  

Egress = “the action of going out of or leaving a place“.  In the context of controlling information flow within a datacenter,  egress filtering is the practice of examining, and potentially denying, outbound communication to external networks such as the Internet. The topic is discussed in the Wikipedia article on Egress Filtering, an article I have helped maintain. 

Here is a diagram that shows the type of environments I typically encounter that have no egress filtering. The risks are illustrated. 


Employee laptops go home to an environment beyond your control. Regardless of your “end-point” security, a subset of those laptops will be compromised and under the control of attackers.  That control will be re-asserted the minute the laptop fires up within your organization and makes that unfiltered outbound connection. The diagram above shows what can – and does,  in my experience – happen. 

The next diagram shows an environment with egress filtering in place. 


Egress filtering as depicted above has a chance of minimizing the potential impact to your organization from a compromised laptop.  By tightly controlling outbound access and paying strict attention to denied attempts you will be able to quickly zero in on a subset of your compromised internal machines. 

Various proxy or “content filtering” solutions exist that will satisfy the basic requirements for an intermediary device that examines outbound connection attempts.   An open-source Squid proxy alone can blunt the effect of much malware. More elaborate (and costly) commercial solutions exist that can update restrictions in real-time based on malware events being reported globally.   

Finally, as discussed in the “Datacenter Attack Surfaces”  post, try to limit the network visibility your core servers have from the vantage point of your employee’s machines. That will limit the ability of a compromised laptop being used as a attack platform against your datacenter. 

Minimizing your internal attack surfaces and controlling egress gives you a fighting chance against modern malware.  If you have trouble convincing management that the cost and effort is worth it, get in contact with us.  We can help you make the case. 

Good luck… and as always: Watch your logs!







Datacenter Attack Surfaces

Hello!  I’m Jim Klun – a comparatively recent addition to the team here at Microsolved. 

I have worked over the years to protect large datacenter environments from compromise.  I want to take moment to share a way to look at the external security risks facing such an environment .  I’ve used it effectively to explain (usually to senior management)  the reality of risks that often go unplanned for.

 Essentially, I have come to view a typical datacenter environment as presenting three major “doorways” that external attackers will attempt to break through.  These are often described as “attack surfaces” in the literature and are illustrated below:

Let’s take a look at each side of this “attack surface” triangle


An organization’s Internet presence – the Internet-facing services offered to the public over the Internet – is usually well understood as an attack surface.  Organizations with at least some security awareness will ensure that servers with publicly exposed services are protected by a firewall, offer only a limited number of secured services to the Internet and tightly monitor those services for signs of potential abuse or compromise.  Best practice also dictates that they be in a separate network segment (e.g. a “DMZ”) with limited access into the rest of the datacenter.  Segmentation makes it more difficult for an attacker who has gained access to an Internet server to extend their control inward without being detected.

But – note the other attack surfaces shown in the diagram. These are the ones often ignored by organizations.  The reason is invariably a misplaced sense of “trust”. 

Private Connections

These are the various “private” pathways into your datacenter provided to vendors, business partners or customers.  Communication may be over dedicated non-Internet communication channels or possibly via site-to-site VPN over the Internet.  Portions of some other organization’s internal infrastructure is connected to yours via such paths.  Your organization becomes dependent on their internal security.

Regardless of the private communication mechanism, the special nature of the relationship invariably instills a sense of trust in the security of the connection.  The assumption is the folks at the other end are “doing the right thing” and pose a limited risk.   But of course you have no way of really knowing that.  A compromise of a vendor site that has a direct connection into your datacenter so that the vendor can perform maintenance work on your servers is a  real and serious risk to you.  As an attacker, I would delight after compromising a support vendor to find such maintenance connections.
Hopefully one would not be to your datacenter.

Unless you have complete, assured control of the infrastructure at such sites, you must assume they are potentially hostile.  Firewalls, logging, segmentation, and intrusion detection are as much a requirement here as they are for the Internet.


“We trust our employees!”   Of course you do.  But trust here goes beyond trust of the individual human being.  The trust is of a combined entity – your employee AND that company laptop they take home every night.  Few people are capable of using a Windows-based laptop in such a way as to avoid compromise over the long term.  You may have a full array of anti-malware solutions running on company laptops, but the simple fact of modern digital life is a subset of them will be compromised and you will not detect it.

The trick is to limit the damage that any one such compromised laptop can do to the security of your datacenter.  If you have no firewalls between your internal employee space and your datacenter and you have no controls on outbound traffic from your employee space to the Internet (porn filters are not enough), then an attacker who has remote control of that laptop can simply use it as an internal attack platform against your datacenter.   This has become a major vector for data-center compromise.

Employee desktop/laptop/smartphone IP-space should be entirely different from that used internally within your datacenter.  Firewalls should lie between those spaces. Strict limits must be imposed on what your non-technical users “see” of your datacenter.  If they can see everything, then an attacker who has taken control of their machine can see it all as well. Ideally all access to datacenter servers by technical administrators is by way of “jump hosts” that sit at the boundary between the datacenter and employee space. Two factor authentication for access to such administrative jump-hosts is  a requirement.  System admins are just as likely as any other user to have traditional credentials stolen.

By limiting what your internal users can see of your datacenter and logging all access attempts, you have some chance of limiting the opportunities for attack from a compromised laptop and at least some chance of detecting it if it does occur.

Don’t think it happens?   http://spectrum.ieee.org/riskfactor/computing/it/south-korean-banks-weeklong-system-failure-affecting-30-million-an-inside-job


For my next post,  I’d like take a look at a topic closely related to the above: Egress Filtering.  Don’t do it?   You need to.  See: http://en.wikipedia.org/wiki/Egress_filtering