Category Archives: Pen Testing & Vuln Mgmt

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!

Guest Blog Post: Less Pwn, More Help!

Posted on by
5

By: Mick Douglas (@bettersafetynet)

The client looked at us from across the table, grimacing as they gulped the foul coffee (sure it’s awful, but hey it’s a free perk!).  They leaned in and said conspiratorially “So can you… umm… sort of… help us get the inside scoop on how we can pass this pentest?” 

I pause and close my eyes for a second.  I’ve heard pleas like this throughout my career.  If you’re a veteran pentester, no doubt you have too.  And what I always think… no matter how large or small the client…  Nobody passes pentests!   It’s their turn to suffer under our boot as we hijack the network and have shells fall down on us like rain.  Nobody… nobody passes a pentest.  There’s always a way in.  Once we’re in, we make their worst nightmares come alive right under their own nose!  No, pentests aren’t for passing.  They’re to be endured.
 
Strong though the predatory instinct is, I must push it aside.  The “pop ’em all” approach — while immensely fun — is not the way of the true pentester.  All too often InfoSec practitioners focus on the technical aspect of the pentest.  If you’re reading this site, chances are good you’re a techie… not a suit.  So unless fate has given you a tour of duty on the other side of the table, you have no idea what hell you’re about to bring to someone who’d rather be doing anything else than deal with you — the pentester.  Things are about to get ugly, and your shell count has nothing to do with it.  You are about to turn their world upside down in ways you cannot begin to fathom.
 
It doesn’t matter if you’re internal, external, a consultant… whatever… you are the enemy.. and not in the way you think.  Sure, you’re the “enemy” as The Almighty Red Team here to cause mayhem and pop boxes.  However, what you might not realize is that the havoc is just getting started once you leave the engagement.  Next to nobody will remember the pivots, the recon, or the OSINT you did.  None of that really matters… What they will remember is that “Jake the InfoSec Guy” failed at his job — miserably. But wait there’s more!  Not only did he fail, but someone — who doesn’t know our systems — was able to use freely available tools from the internet to compromise our entire network!! To make matters worse, it was done in under a week!! It’s a safe bet that soon the client will look at the budget spent on firewalls, AV, IDS, even the salaries — everything — and think “All this spending… for what? They brushed aside our best efforts as if they were nothing more than cobwebs!”
 
If all your client gets out of your pentest is that they’ve got a crappy infosec program, then know what? You’re a crappy pentester.  

You may hate to hear this, but you *owe* your client.  
 
You need to give them a complete assessment which checks for multiple paths to the victory conditions.
 
You need to give them reports which are understandable, actionable, and brief.
 
You need to teach them what you did so they can re-test for themselves.
 
You have to show what’s wrong, but also give them multiple options on how to fix, remediate, or compensate for the findings.
 
You need to offer “quick win” fixes so the infosec program can start rebuilding their credibility after you clipped their wings.
 
You need to give them suggestions on how to alter business operations to better avoid risks altogether.
 
You need to give them a road map on how to get better tomorrow… and the next day after.
 
You need to give and give.
 
Most of all, you need to give them hope.
 

About the Author:

Mick Douglas (twitter.com/bettersafetynet) does R&D, PenTesting, and profesional services for Diebold Inc.  When he’s not doing tech stuff, he’s off in the woods somewhere hiking or trying — mostly in vain — to improve his photography chops.

Thanks to Mick for contributing. I think he’s right on with what we need to do as penetration testers. — Brent Huston

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.

Exposed Terminal Services Remains High Frequency Threat

Posted on by
4

GlobalDisplay Orig

Quickly reviewing the HITME data gathered from our global deployment of HoneyPoint continues to show that exposed Terminal Services (RDP) on port 3389 remains a high frequency threat. In terms of general contact with the attack surface of an exposed Terminal Server connection, direct probes and attacker interaction is seen on an average approximately two times per hour. Given that metric, an organization who is using exposed Terminal Services for remote access or management/support, may be experiencing upwards of 48 attacks per day against their exposed remote access tool. In many cases, when we conduct penetration testing of organizations using Terminal Services in this manner, remote compromise of that service is found to lead to high levels of access to the organization’s data, if not complete control of their systems.

Many organizations continue to use Terminal Services without tokens or VPN technologies in play. These organizations are usually solely dependent on the security of login/password combinations (which history shows to be a critical mistake) and the overall security of the Terminal Services code (which despite a few critical issues, has a pretty fair record given its wide usage and intense scrutiny over the last decade). Clearly, deploying remote access and remote management tools is greatly preferred behind VPN implementations or other forms of access control. Additionally, upping Terminal Services authentication controls by requiring tokens or certificates is also highly suggested. Removing port 3389 exposures to the Internet will go a long way to increasing the security of organizations dependent on RDP technology.

If you would like to discuss the metrics around port 3389 attacks in more detail, drop us a line or reach out on Twitter (@microsolved). You can also see some real time metrics gathered from the HITME by following @honeypoint on Twitter. You’ll see lots of 3389 scan and probe sources in the data stream.

Thanks for reading and until next time, stay safe out there!

Don’t Forget About VoIP Exposures and PBX Hacking

Posted on by
6

 

 

 

 

 

 

I was browsing my usual data alerts for the day and ran into this set of data. It motivated me to write a quick blog post to remind folks that VoIP scans and probes are still going on out there in the wild.

These days, with all of the attention to mass compromises, infected web sites and stolen credit card data, voice systems can sometimes slip out of sight.

VoIP compromises and intrusions remain a threat. There are now a variety of tools, exploits and frameworks built for attacking VoIP installations and they are a target for both automated tools and manual hacking. Access to VoIP systems can provide a great platform for intelligence, recon, industrial espionage and traditional toll fraud.
 
While VoIP might be the state of the art for phone systems today, there are still plenty of traditional PBX, auto-attendant and dial-up voicemail systems around too. Now might be a good time to review when those systems were last reviewed, audited or pen-tested. Traditional toll fraud is still painful to manage and recover from, so it’s probably worth spending a few cycles on reviewing these devices and their security postures. 
 
Let us know if your organization could use assistance with these items or with hardening voice systems, implementing detection techniques for them or otherwise increasing voice system security.

MSI Strategy & Tactics Talk Ep. 21: The Penetration Testing Execution Standard

Posted on by
2

Penetration Tests have been done for years but yet there has often been confusion regarding what a penetration test should deliver. Enter the beta release of the Penetration Testing Execution Standard (PTES). What does it mean?  In this episode of MSI Strategy & Tactics, the techs discuss the current state of penetration tests and how PTES is a good idea that will benefit many organizations. Take a listen! Discussion questions include:

  • What is PTES? How does it differ from the current state of the industry?
  • What is the importance of industry standardization? Is it a good thing or a bad thing?
  • What does it mean for the future of vulerability and penetration testing?
Panelists:
Adam Hostetler, Network Engineer and Security Analyst
Phil Grimes, Security Analyst
John Davis, Risk Management Engineer
Mary Rose Maguire, Marketing Communication Specialist and moderator

Click the embedded player to listen. Or click this link to access downloads. Stay safe!

Powerless No More! Making Your Threat-Centric Penetration Testing Work for You

Posted on by
Reply



By now, even small organizations should know that they need periodic penetration testing focused on their critical processes if they hope to secure and protect their data. The question is, when this testing is being performed, are they getting something of value or just another checkbox on a compliance form? At MicroSolved, we believe in the first and we think you should get the latter naturally from the exercise. The problem is, the effort is NOT vice-versa.

Compliance-centric penetration testing is when the simulated attacker really takes the eye of an auditor. They focus only on testing the surfaces, elements and data sources absolutely required by the standard you are being tested against. These “penetration tests” are usually little more than a vulnerability scan and a run through by an engineer who “validates” that you are vulnerable. Little attention is paid to impact of compromise, how compromised systems and their information could be leveraged to get to the critical information or data and vulnerability chains (complex failures that cascade) are often ignored or completely unidentified. You can tell if the assessment is compliance-centric if the assessment doesn’t include items like testing multi-stage attacks, simulated malware and simulated social engineering failures. In many cases, for example, in the MicroSolved testing methodology, these attack surfaces are exercised, monitored, modeled and then regardless of outcome, emulated as if they failed during internal assessments to ensure reliable, real-world impacts are measured.

Threat-centric penetration testing, which by now, you probably know, is what MicroSolved is famous for. Our process doesn’t focus on compliance. It focuses on protecting your assets against the real world threats. We perform like an attacker, NOT like an auditor. We map attack surfaces, compare them to the real world, real-time data streams we get from the HoneyPoint Internet Threat Monitoring Environment (HITME) every day. We take our knowledge of what attackers do and how they work and apply it to your organization. We test the attack surfaces and note how they respond. We model what would happen if your controls succeed and what happens when they fail. Our testing takes a little while longer, and in some cases is a bit more expensive than the “scan and verify” providers, because our penetration team measures your systems against complex, multi-stage leveraged attacks just like you should expect from a real-world attacker targeting your data. We crack passwords, steal documents, social engineer your team, root through your electronic trash (and sometimes even the physical trash) and tear into your internal networks just as if we were a bot-herder, a malware author or a bad guy who got a job in customer service or the mailroom. We work with you to establish the scope and bounds of the exercise, but in the end, you get a real, true and holistic look at your defenses and the ways you can improve. You also get the capability to check that compliance box with the full knowledge and confidence that you tested not just their limited scope or with blinders on approach, but against a real-world, bleeding edge group of attackers focused on getting YOUR data.

At MicroSolved, we think that if you’re going to spend money on penetration testing, you should get what you pay for. You should get a real measurement against real threats and a real idea of what needs to be improved. If all you want is a checkbox, you can find plenty of folks to “scan and forget” with prices starting at FREE and ending at hundreds of thousands of dollars. Their cookie-cutter processes should let you check the box on your next set of forms, but maybe not sleep at night while you wonder if the data is really OK. On the other hand, working with a real-world emulating, threat-centric team, might cost a little more in the short run, but just of the money you’ll be saving in fines, legal fees and forensics costs for each attack vector mitigated in the event of a compromise. Give us a call. We’ll be happy to tell you more or work with you to set up a project to help you evaluate other penetration testing teams where MSI might not be a perfect fit.

Keep Your Eyes on This Adobe 0-Day

Posted on by
Reply

A new Adobe exploit is circulating via Flash movies in the last day or so. Looks like the vulnerability is present across many Adobe products and can be exploited on Android, Linux, Windows and OS X.

Here is a link to the Dark Reading article about the issue.

You can also find the Adobe official alert here.

As this matures and evolves and gets patched, it is a good time to double check your patching process for workstation and server 3rd party software. That should now be a regular patching process like your ongoing operating system patches at this point. If not, then it is time to make it so.

Users of HoneyPoint Wasp should be able to easily any systems compromised via this attack vector using the white listing detection mechanism. Keep a closer than usual eye out for suspicious new processes running on workstations until the organization has applied the patch across the workstation environment.

MSI Says: Know Yourself – Unlock a DoS by Asking: Who Has Access?

Posted on by
Reply

Recently, a client was experiencing interesting issues during a scheduled assessment of their internal networks around the world. It appeared as if the assessment was causing a Denial of Service and affecting a specific location due to automation controllers within their environment. An interesting anomaly, considering these controllers are deployed at other locations. However, only one specific location seemed to be having issues. The DoS was even more intersting from our perspective because it was literally locking the doors to the facility in question! We weren’t testing for this vulnerability; but found it was a side effect of an internal assessment we completed to provide metrics and action plans according to our 80/20 guidelines. These are exactly the type of issues that help our clients understand the value of these ongoing assessments.

So what’s the big deal? Let’s say an employee just got nagged about their three 15 minute smoke breaks every hour. Let’s also say he has knowledge of the environment and/or experience with a vulnerability scanner. Technically, he could lock the facility down while searching out possible ways to retaliate and his employer wouldn’t even know it. Worse yet, those who know this flaw exists could exploit it at will with a few keystrokes from their workstation. Not a good thing!

Controllers and sensors of similar types are used in businesses around the globe. This case study provides another point for enclaving in any environment. The overall threat could have been reduced significantly simply by segregating traffic. There are few reasons these specific hosts should be accessed by most workstations. Fortunately, the issues didn’t last long. After some communication with the manufacturer, a firmware update was released that appears to have resolved the issues previously experienced.

So the bottom line is know your environment. It is the foundation for our 80/20 Rule for Security (link) and can lay the groundwork for discovering where vulnerabilities may lurk. Forewarned is forearmed.

Penetration Testing vs. Vulnerability Assessments

Posted on by
Reply

Some think penetration testing and vulnerability assessments are one and the same. However, this isn’t true. A penetration test is a method of evaluating the security of a computer system or network by simulating an attack by a malicious hacker. The process involves an active analysis of the system for any weaknesses, technical flaws or vulnerabilities. This analysis is carried out from the position of a potential attacker, and can involve active exploitation of security vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution.

A vulnerability assessment is the process of identifying and quantifying vulnerabilities in a system. The IT department submits the information regarding the system as opposed to an internal or external person hacking into the network. When a company hires us to do a vulnerability assessment, they have given the team specific parameters for the assessment.

Brent Huston, CEO for MSI says, “A penetration test cannot be expected to identify all possible security vulnerabilities, nor does it offer any guarantee that an organization’s information is secure. But penetration testing can serve as a start for pinpointing a system’s security vulnerabilities.”

So what are some of the areas a penetration tester might explore? An organization’s intranet is an attractive target. So is an internal phone system or database. What is becoming more vital than ever is a consistent schedule of testing. Penetration testing can no longer be done just once a year to give an accurate assessment of an organization’s vulnerabilities. There are new exploits released daily. Adding new services can also create the opportunity for a new breach. Let MSI help you arrange a subscription service for you!