Easiest Way into a Company

May 22, 2008

One web page and one email is all you need to gain access to a major corporation’s internal network. Catchy I know, but this is not an exaggeration of what an attacker can do to gain access on their internal network. In culmination with exploiting a few systems on the internal network, they can have free reign. Securing your network infrastructure begins with your employees. I don’t think you will be able to extract any new techniques or any new concepts from this post; however, this should shed some light and acknowledge the importance of safe end user practices as well as securing internal networks and resources.

Much of the governance and regulatory focus is securing your external networks, but what if they get in? We have seen a rise in external vulnerability scans and a decrease in internal/external penetration tests. Did we forget security awareness, defense in depth, network architecture or even the most basic administrative practices? Not surprisingly, it seems corporations are searching for that check mark on their audit and not concerned with actual security.

So what, right?

Even the most security-aware corporations’ are still falling victim to social engineering exercises. Valuable resources which an attacker can use are found in the most trivial places such as social networking sites. Anyone can acquire an adequate employee list in minutes with all the social networking sites such as Linkedin, Facebook, Myspace, etc. From the vast amount of information that can be collected from social networking sites, message boards, and online-groups you can realistically create an organization chart (which helps addressing employees and providing focus for your phishing attack).

Scenario:

Currently, much of the workforce has logged into a VPN or OWA once in their lifetimes. Corporations are offering many services remotely to keep their workers adequately connected. These basic infrastructure items seem the most prone and widespread systems for an attacker to prey on. The first step an attacker makes is basic recon and choosing their targets. Often employees in administrative or sales roles are selected because they tend to login to resources remotely. Next, an attacker will search for an external facing login prompt to clone it to a dummy system with a basic logging to record IP and user credentials. After that, well crafted emails directing unsuspecting users to the dummy login…Done. Simple as that, login credentials obtained within minutes.

How do we protect from here:

There are three fronts that could dramatically improve the outcome of these scenarios. First off, end user training and policies geared towards making employees more aware of possible attacks and best practices. I am not talking about handing a policy to the employee and having them read it either. Second, internal penetrations tests still are viable and will cover a number of areas that will protect from employee attacks as well as minimizing potential sophisticated attacks. This may include additional tasks of hardening of hosts, segregation of networks/assets, and adjusting the appropriate policies. Third, static passwords on critical systems externally facing should be changed to a more secure method such as token authentication. The truth is there is no magic bullet to prevent phishing or social attacks, we will always be combating the human tendency to trust.


My $0.02 on PCI DSS 6.6.

May 6, 2008

The PCI Security Council on April 15, released clarification on DSS requirement 6.6.

Requirement 6.6 states that all web facing applications are protected against known attacks by having a code review or installing an application-layer firewall (WAP) in front of the web application.

I am of the opinion that the clarification document for requirement 6.6 still does not address the issue adequately, and leaves mis-interpretations about code review and WAP.

Let’s start off with observation #1.

From the Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified document:

“Manual reviews/assessments may be performed by a qualified internal resource or aqualified third party. In all cases, the individual(s) must have the proper skills andexperience to understand the source code and/or web application, know how to evaluate each for vulnerabilities, and understand the findings. Similarly, individuals using automated tools must have the skills and knowledge to properly configure the tool andtest environment, use the tool, and evaluate the results. If internal resources are being used, they should be organizationally separate from the management of the application being tested. For example, the team writing the software should not perform the final review or assessment and verify the code is secure.”

What qualifies a qualified internal resource? Does the QSA qualify this internal resource?

There currently is no standard certification in our industry for code review, and in my experience, very few organizations have any staff that could perform adequate code review if the focus is on identifying security relevant issues.

Scenario 1: Development team uses someone from the IT/QA group to run a web application vulnerability scanner against their web application.

Does this meet Requirement 6.6?
Absolutely not.

Web application vulnerability scanners do not find all vulnerabilities, in addition, they throw out a lot of false positives.. Here at Neohapsis we have seen that and so have others, Rolling review: Web Application Scanners.

“Ultimately, you can’t automate your way to secure software–any combination of analysis tools is only as effective as the security knowledge of the user. As Michael Howard, co-author of Writing Secure Code (Microsoft Press, 2002) and one of the lead architects of Microsoft’s current security posture, put it in his blog: “Not-so-knowledgeable-developer + great tools = marginally more secure code.”

We recommend taking advantage of documented processes, including Microsoft’s SDL (Security Development Lifecycle), The Open Web Application Security Project’s CLASP (Comprehensive Lightweight Application Security Process) and general techniques available at the National Cyber Security Division’s “Build Security In” portal (Automated Code Scanners.” Network Computing Magazine, April 16, 2006).

Web application vulnerability scanners should be used as a tool in conjunction with a full code review.

Observation #2: Option #2 in Requirement 6.6.

I find this to be the band-aid approach to passing 6.6. Web application firewalls, WAF, should be used as an additional layer of security, not a band-aid and avoiding code reviews. Would we consider an IDS or a firewall to be the resolution to running unnecessary services on a system, or a solution to avoid us from hardening or configuring systems to best practice of vendor recommended guidelines? Similarly, WAF’s are another step in the principle of Defense-in-Depth (DiD), but are in no means a solution to securing an application.

There needs to be a balance found with Requirement 6.6 to include source code review, using a web application vulnerability scanner as a tool, and a WAP for it to be taken seriously. There are ways to do this. If an organization implements a solid SDL process, you only need to do sample source code review during the development phase, since a lot of the initial threats were identified during the threat analysis phase. Also, you have secure coding practices and modules that already address a lot of issues such as poor input validation etc. If one is looking to spend less time on finding security issues after a production / environment has to be deployed, one has to look at security right from the start. This holds true when you are building out a security network or DMZ, and also holds true when it comes to the design and development of an application.

The bottom line is that the clarification does not really help out overall.

PCI or not, a proper SDLC implementation and process, developers going through secure code training, and having a proper set of tools will lead to a more secure application.