Category Archives: Pen Testing & Vuln Mgmt

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!

When The System Works, It Really Works! :)

Posted on by
5

OK gang, so here is our part of the story.

As many of you may now know, the NCUA issued a fraud alert this week based on a social engineering test we were doing for a client natural person Credit Union. You can find some of the materials at the following URLS:

NCUA Media Release

SANS Storm Center

NetworkWorld

Once we saw the alert from the NCUA, we immediately contacted our Credit Union client about the situation. The client had received the letter and CD set in the mail, just as intended and called for in their testing agreement. However, on their side, the person responsible for the penetration test was out the day the letter arrived. The receiver of the letter followed their incident response process and reported the suspicious activity to the NCUA Fraud Hotline, just as they are supposed to do.

Upon our contact with the CU, the entire situation became apparent and we quickly identified how the process had proceeded. The employee of the CU had followed the process, just as they should, and alerted the proper authorities to the potential for fraud. We immediately contacted the NCUA Fraud hotline and explained that the process was a part of a standard penetration test. Eventually, we talked with executive management of NCUA and offered them any information they desired, including the source code to the tools on the CDs. The NCUA was wonderful to work with, understood the situation and seemed appreciative of our efforts to help ensure that their members were meeting the requirements of NCUA 748, which calls for the protection of member data against illicit access, including social engineering attacks like these.

During our discussion with NCUA executive management, we discussed me reaching out to SANS and such to clarify the situation and to explain that the “attack” was simply a part of a penetration test. I did this as soon as I hung up the phone with NCUA. The handlers at SANS and I traded emails and phone calls and they amended their release to include the penetration testing scenario. The whole point of this was to add clarification and to prevent people from getting “spun up”, since there really was no ongoing attack in progress.

However, in typical Internet fashion, the story had already taken on a life of it’s own. The next thing we know, the press is picking up the story, there’s an article on slashdot and people are in alert mode. We then set about trying to calm folks down and such on Twitter, through email and such.

The bottom line here is this. This was a controlled exercise in which the process worked. The social engineering attack itself was unsuccessful and drew the attention of the proper authorities. Had we been actual criminals and attempting fraud, we would have been busted by law enforcement. The NCUA did a great job of getting the word out that such an attack had occurred and the media and security folks did a great job in spreading the word to prevent further exposures to this threat vector. Everyone, and I do mean everyone, is to be congratulated here for their efforts!

The system worked. Had we been bad guys, we would have been busted. The world was protected, once more, thanks to the vigilance and attention of the NCUA and the security community.

Now, about the testing. MicroSolved, Inc. does, indeed, test social engineering attack vectors as a part of our standard assessments. The social engineering threat is a powerful and valid attack vector that often leads to compromise. Our process for testing these engagements is well scoped, well organized and intensely controlled. The threats we emulate are very real (in this case, we even included typos and such in the fake letter). The simulated malware we use is a custom application, developed in house by my team of engineers and does not propagate in any way. It is safe, effective, tested and has been in use with ongoing revision and testing for more than five years. The entire process for testing social engineering has been performed thousands of times for thousands of clients and will continue to be a part of our testing methodology. We truly believe that information security starts and ends with the people involved in protecting the data.

I hope this answers any questions you may have about the process or the alert. If not, drop me a line at bhuston@microsolved.com and I will try and assist you, if I can. I would really like to thank the NCUA, SANS, my technical team and the customer CU for their help and attention on this project. Thanks also, to all of the security folks and CU folks who helped spread the word about this attack vector. Though the awareness campaign was unintended, it certainly has raised the bar for would be attackers if they hope to exploit this in the future. Thanks for all of your hard work and attention!

Oh, and lastly, no, it is not us sending the laptops to governors of the states. It might not even be us sending the next round of CDs, USB keys or whatever new fraud schemes emerge in the future. But, regardless of whether or not it is us doing a test for your organization, or real criminals attempting to exploit you, don’t fall for it! Report these events to the authorities and let’s make use of the process that we have clearly established!

Thanks for reading and make it a great day!

Update: Thanks to NetworkWorld for their help on getting the word out. Thanks to @alexhutton as well for this article.

Interview with Syhunt CEO

Posted on by
Reply

This week I got a chance to ask a couple of questions about Syhunt SandCat and the future of web application security. Here is the exchange with some great insights into where the web and attackers are heading!

Quick Interview with Felipe Aragon, CEO of Syhunt.

Q: The 3.8 release represents a significant step forward in application security scanning, especially around Javascript. What are the key features that application testers should know about in the 3.8 product?

R: Browsers and the web evolved significantly over the past years. Sandcat has evolved together with the new advancements and now has a lot in common with modern web browsers. This is essential because if you want to seriously hunt security breaches in web 2.0 applications you have to emulate modern Web technologies. So, naturally Sandcat evolved to understand JavaScript, AJAX and PHP and is now what is known as a hybrid web application security scanner. We also implemented multi-thread sessions, making each host scan a different process (Google Chrome, for example, employ a similar technique, making each tab a different process). Other important features we got working in Sandcat is the ability to simulate user interaction and multi-layer defense evasion. Sometimes, after evading a WAF (web application firewall), the last layer of defense against exploitation is a regular expression filter, which can also be bypassed by using many different techniques, so we got this working in Sandcat. Unfortunately weak filters were popularized and today many websites are vulnerable to this attack.

Q: How are Javascript threats influencing the state of application security today?

R: Thanks to JavaScript, Web applications are becoming increasingly more sophisticated, so next-generation web applications must be handled like desktop applications. Browsers like Opera, Firefox, Safari, Chrome are now adding faster JavaScript VMs each release because this is where the Web is going. Increased usage of JavaScript changes everything. It changes the way web developers build web sites, and the way hackers search for vulnerabilities or take advantage of weak spots in web applications. It makes more difficult for web developers to build secure web applications and, of course, for pen-testers that are unskilled web programmers to fit in in this new world. JavaScript can be used to steal cookies, spread worms, launch XSRF attacks and many other malicious purposes. The attacks are limited only by the attacker’s imagination.

Q: Where do you see application security heading in the next 12 months? What types of attacks should we be paying attention to that are slipping below our radar right now?

R: Right now we are monitoring the emergence of new web platforms (such as the recently announced Google Wave) that will make the 3.0 version of the Web possible. I believe we are heading towards the end of an era for the Web, a Web OS is materializing. These web 3.0 platforms and extensions built for these platforms will be a major target for cybercriminals. We have a set of new vulnerability classes and combined attacks (using both old and new classes) on the horizon. It will take a lot of time for web developers to understand how certain lines of code, client-side or server-side, translate to some serious security issues and how to avoid them. It might actually never happen because the Web and attack methods will continue to evolve faster. Without innovation, there is no future for the web, but I hope organizations will do whatever they can to understand and minimize security risks within their Web systems and not allow the cyberspace to become more insecure than it is today.

Check out SandCat’s new release at http://www.syhunt.com.

PS – In fair disclosure, MSI has a business relationship with Syhunt.

Microsoft IIS 6.0 WebDav Vulnerability – Urgent

Posted on by
Reply

We recently received a report of a vulnerability we thought everyone should be aware of. The vulnerability is in the Microsoft IIS 6.0 implementation of the WebDAV protocol. According to Wikipedia, “Web-based Distributed Authoring and Versioning, or WebDAV, is a set of extensions to the Hypertext Transfer Protocol (HTTP) that allows users to edit and manage files collaboratively on remote World Wide Web servers.” A common tool used as a WebDAV client, is Microsoft’s FrontPage.

The vulnerability describes a way for an attacker to retrieve protected files without any authentication. From a technical standpoint, all an attacker needs to do is insert a certain unicode character in the URI request. This make this vulnerability trivial to exploit. The vulnerability allows attackers to list all of the files in the WebDAV folder, and then access them individually.

As of this morning, there is no known mitigation for this vulnerability save disabling WebDAV for the time being.

Businesses employing an IIS 6.0 Web Server with WebDAV authoring method should carefully analyze their need for such service, and disable it if possible until a fix is released.