Tag Archives: device security

3 Things Attackers Can Leverage From a Device Configuration Leak

Posted on by
Reply

One of the questions I often get around our ClawBack data leak detection SaaS product is “What can a hacker get from a leaked config?”. I put together this quick post about three of the most common and powerful elements that we often find in leaked configurations we discover.

1) Credentials – Let’s face it, credentials are often the easiest way to leverage leaked configs. Sure, it might be for an edge router or some network gear, or maybe it’s for the VPN. Configs often contain sets of credentials, either in plain text or in hashed form. Hashes need to be cracked, sure, but that is often quite possible. Even when the credentials aren’t able to be used remotely, they often help us tune our password guesses and learn more about the policies and password requirements of other systems. You wouldn’t believe the number of times, though, that the credentials from a leaked config simply work across the network or enterprise and often at a significantly powerful level. 

2) Encryption Keys – Leaked router, firewall or VPN device configurations often contain encryption keys. While these still require an attacker to be in a position to gather traffic, they are very useful to well resourced attackers with that capability. If you’re at the level of risk where you need to worry about nation-state or politically motivated attackers, you really don’t want to leak your encryption keys. In addition to simply being a significant issue going forward, leaking encryption keys is a “long tail” vulnerability, because it provides cryptanalysis capabilities to adversaries who might have historic traffic archived, that the leak makes possible for them to leverage. Thus, the life of the key becomes the window of vulnerability. This is especially true when static cryptographic protocols are in use.

3) Network Recon Data – From IP addresses to firewall rules and from SNMP strings to dynamic routing data, device configurations can provide a veritable treasure trove of recon data about your environment. Partner connections, vendors with remote access, interconnects with other environments and the general day to day operations of the computing systems can often be found in leaked configurations. Depending on the type and criticality of the device, the config can often give up a complete view of the guts of the organization.

That’s just the top 3. We’ve seen thousands of leaked configurations in our work on ClawBack and penetration testing. It’s no doubt that leaked configs are useful to the attacker. The big question is, if you had leaked configurations out in the world, would you know about it? Would you know how to hunt them down, claw them back and mitigate the damage? If not, or if the idea makes you nervous, give us a call. We’re happy to help you solve these problems. You can get in touch by calling 614-351-1237 or drop us an email at info@microsolved.com. 

Ask The Experts: New Device Check Lists

Posted on by
2

This time around on Ask The Experts, we have a question from a reader and it got some great responses from the team:

 

Q: “I need a quick 10 item or less checklist that I can apply to new devices when my company wants to put them on our network. What kinds of things should I do before they get deployed and are in use around the company?”

 

Bill Hagestad started us off with:

The Top 10 checklist items a CISO/or equivalent authority should effectively manage before installing, configuring and managing new devices on a network includes the following;

 

1)Organize your staff and prepare them for the overall task of documenting and diagramming your network infrastructure – give them your commander’s network management intent;

2)Create a physical and logical network map – encourage feedback from your team regarding placement of new hardware and software;

3)Use industry standards for your network including physical and logical security, take a good look at NIST Special Publication SP 800-XX Series;

4)Make certain that you and your team are aware of the requisite compliance standards for your business and industry, it will help to ensure you are within legal guidelines before installing new devices or perhaps you may discover the hardware or software you are considering isn’t necessary after all;

5)Ensure that after you have created the necessary network maps for your infrastructure in Step 2) above, conduct a through inventory of all infrastructure which is both critical and important to your business, then document this baseline;

6)Create a hardware/software configuration change procedure; or if you already have his inlace, have your team review it for accuracy; make certain everyone on the team knows to document all changes/moves/additions on the network;

7)Focus not only on the correlation of newly implemented devices on the internal networks but also look at the dependencies and effects on external infrastructure such as voice/data networks – nothing worse than making an internal change to your network and having your Internet go down unnecessarily;

8)Ensure that new network devices being considered integrate gracefully into your existing logging and alerting mechanisms; no need to install something new only to have to recreate the proverbial wheel in order to monitor it;

9)Consider the second & third order effects of newly installed devices on the infrastructure and their potential impact on remote workers and mobile devices used on the network;

10)Install HoneyPoint Security Server (HPSS) to agentlessly & seamlessly monitor external and potential internal threats to your newly configured network….

 

Of course a very authoritative guide is published by the national Security Agency called appropriately “Manageable Network Plan” and available for download @:

 

http://www.nsa.gov/ia/_files/vtechrep/ManageableNetworkPlan.pdf


Jim Klun added:

1. Make sure the device is necessary and not just a whim on the part of management.   Explain that each new device increases risk. 

2. If the device’s function can be performed by an existing internal service, use that service instead. 

3. Inventory new devices by name, IP addresses, function and – most importantly – owners.  There should be a device owner and a business owner who can verify continued need for the device.  Email those owners regularly,   querying them about continued need. Make sure that these folks have an acknowledged role to support the application running on the devices and are accountable for its security. 

4. Research the device and the application(s) its support.  Have no black boxes in your datacenter.  Include an abstract of this in the inventory. 

5. Make sure a maintenance program is in place – hold the app and device owner accountable. 

6. Do a security audit of the device wehn fully configured. Hit it with vulnerability scanners and make sure that this happens at least quarterly. 

7. Make sure monitoring is in place and make very sure all support staff are aware of the device and any alerts it may generate. Do not blind-side the operations staff. 

8. If the device can log its activities ( system and application ) to a central log repository, ensure that happens as part of deployment. 

9. Make sure the device is properly placed in your network architecture. Internet-exposed systems should be isolated in an Internet DMZ.  Systems holding sensitive data should similarly be isolated. 

10. Restrict access to the device as narrowly as possible. 

 

Finally.. if you can, for every device in your environment, log its network traffic and create a summary of what is “normal” for that device.  

Your first indication of a compromise is often a change in the way a system “talks”. 

 

Adam Hostetler chimed in with: 

Will vary a lot depending on device, but here are some suggestions

 

1. Ensure any default values are changed. Passwords, SNMP strings, wireless settings etc.

2. Disable any unnecessary services

3. Ensure it’s running the latest firmware/OS/software

4. Add the device to your inventory/map, catalog MAC address, owner/admin, etc.

5. Perform a small risk assessment on the device. What kind of risk does it introduce to your environment? Is it worth it?

6. Test and update the device in a separate dev segment, if you have one.

7. Make sure the device fits in with corporate usage policies

8. Perform a vulnerability assessment against the device. 

9. Search the internet for any known issues, vulnerabilities or exploits that might effect the device.

  1. Configure the device to send logs to your logging server or SEIM, if you have one.

 

And John Davis got the last word by adding: 

From a risk management perspective, the most important thing a CISO needs to ensure is in place before new devices are implemented on the network is a formal, documented Systems Development Life Cycle or Change Management program. Having such a program in place means that all changes to the system are planned and documented, that security requirements and risk have been assessed before devices have purchased and installed, that system configuration and maintenance issues have been addressed, that the new devices are included in business continuity planning, that proper testing of devices (before and after implementation on the network) is undertaken and more. If a good SDLC/Change Management program is not in place, CISOs should ensure that development and implementation of the program is given a high priority among the tasks they wish to accomplish.

 

Whew, that was a great question and there is some amazing advice here from the experts! Thanks for reading, and until next time, stay safe out there! 

 

Got a question for the experts? Give us a shout on Twitter (@microsolved or @lbhuston) and we’ll base a column on your questions!

Surface Mapping Pays Off

Posted on by
Reply

You have heard us talk about surface mapping applications during an assessment before. You have likely even seen some of our talks about surface mapping networks as a part of the 80/20 Rule of InfoSec. But, we wanted to discuss how that same technique extends into the physical world as well. 

In the last few months, we have done a couple of engagements where the customer really wanted a clear and concise way to discuss physical security issues, possible controls and communicate that information to upper management. We immediately suggested a mind-map style approach with photos where possible for the icons and a heat map approach for expressing the levels of attack and compromise.

In one case, we surface mapped a utility substation. We showed pictures of the controls, pictures of the tools and techniques used to compromise them and even shot some video that demonstrated how easily some of the controls were overcome. The entire presentation was explained as a story and the points came across very very well. The management team was engaged, piqued their interest in the video and even took their turn at attempting to pick a couple of simple locks we had brought along. (Thanks to @sempf for the suggestion!) In my 20+ years of information security consulting, I have never seen a group folks as engaged as this group. It was amazing and very well received.

Another way we applied similar mapping techniques was while assessing an appliance we had in the lab recently. We photographed the various ports, inputs and pinouts. We shot video of connecting to the device and the brought some headers and tools to the meetings with us to discuss while they passed them around. We used screen shots as slides to show what the engineers saw and did at each stage. We gave high level overviews of the “why” we did this and the other thing. The briefing went well again and the customer was engaged and interested throughout our time together. In this case, we didn’t get to combine a demo in, but they loved it nonetheless. Their favorite part were the surface maps.

Mapping has proven its worth, over and over again to our teams and our clients. We love doing them and they love reading them. This is exactly how product designers, coders and makers should be engaged. We are very happy that they chose MSI and our lab services to engage with and look forward to many years of a great relationship!

Thanks for reading and reach out on Twitter (@lbhuston) or in the comments if you have any questions or insights to share.