Sunday, October 5, 2014

BAD USB Opportunities and GOOD USB Drives

The first thought that immediately came to mind wasn't so much just counterfeit or cheaply made USB devices, but also USB chargers. We plug our android, blackberry, and iPhones into inexpensive chargers bought off Amazon.… Makes me wonder if it's really a good deal. Or just an incredibly wonderful opportunity for a nationstate that manufactures those devices and already understands this and many other exploits capable of going unnoticed.

Reading articles such as this well-written bit by , thinking about Cottonmouth, and considering the pervasiveness of potential compromised devices.... you can understand the effectiveness of this attack vector. Then consider the likely reuse of these compromised devices. They are going to be around for a long, long time.

GitHub Link: https://github.com/adamcaudill/Psychson

By the way, trusted USB devices… Excellent opportunistic marketing for a device that was ahead of its time... Smart company.

IronKey USB Drives
  • http://www.ironkey.com/en-US/solutions/protect-against-badusb.html
  • IronKey Enterprise 250 flash drives are FIPS 140-2 Level 3 validated with AES 256-bit hardware encryption.
  • Enforce device-specific policies and mitigate risks of data loss by remotely disabling lost or stolen drives.
  • A ruggedized, waterproof metal chassis resists physical break-ins and is tamper-proof.
If you work on a security or audit team – take advantage of the perks that come along with the position and apply for a free evaluation: http://resources.imation.com/ikenterprise-evaluation.

Thursday, September 25, 2014

What's in a Name? Shell Shocked. Deserves a 10.

This one deserves a 10. This is in regards to http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271.

Original release date: 09/24/2014
Last revised: 09/24/2014
Source: US-CERT/NIST

Overview

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

Impact

CVSS Severity (version 2.0):
CVSS v2 Base Score: 10.0 (HIGH) (AV:N/AC:L/Au:N/C:C/I:C/A:C) (legend)
Impact Subscore: 10.0
Exploitability Subscore: 10.0

 

Tuesday, September 23, 2014

MAC vs DAC vs RBAC

Recently had a discussion regarding mandatory access controls, discretionary access controls, and role-based access controls. The goal of the discussion was to discuss and understand use cases in the context of risk – which is driven by the business impact of a loss in the confidentiality, integrity, or availability of data.

Take for example an environment that does not handle sensitive data whereby a loss in confidentiality would have significant and sustainable impact. However, there are situations in which the delivery of the processed data is mission-critical for the company to continue operations. Therefore, a violation of the integrity of the data or availability of the data would have significant impact.

Discretionary Access Controls (DAC) and Mandatory Access Controls (MAC) describe the permissions required to access an object in relation to other objects. Role Based Access Controls (RBAC) simply describes the grouping of identities and application of permissions to those groups. The Reference Monitor (RM) concept and requirements still apply when building the environment, such as situational context, forensic auditing, and visibility into permissions.

DAC suggests someone can give you access to an environment, and you have free reign within that environment without knowledge of any particular object sensitivity. Your permissions are governed by your identity.

MAC suggests that in addition to permissions associated with your identity, every object inside the environment has its own label associated with the object. Now, based upon permissions granted to me, perhaps associated with my role or group, I can only perform actions on tagged objects if an explicit policy grants me access to the object. Conversely, a policy can be written based upon tags/labels to explicitly deny me (or my role/group).

Thursday, September 4, 2014

Quiz: What do these companies have in common?

This was some quick research simply to prove a point. Security is important to your customers. If it's not, then it should be.
 
Highlight of a recent conversation with a Fortune 500 company who called me while I was at DEFCON. Network team, firewall team, and others were on the call. They have special awards for companies like this.
 
Customer: I need ports, protocols for the administrative network.

Me: Excellent. Not a problem. Can you explain the use case?
Customer: It's for DMZ access.
Me: Are you going to expose the management network to the DMZ?
Customer: Yes.
Me: On the face of it this seems like a really bad idea. This is a massive compute platform. Can you explain what kind of segmentation you have inside the DMZ?
Customer: I have no idea what kind of segmentation we have inside the DMZ.
Me: At this point I could do one of two things. I can either give you the information you want and trust that you have a security team that will look into this, or I can recommend you take a step back and understand what you are trying to accomplish – including the potential risk implications.
Customer:… Silence… Maybe we should set up a meeting…

Okay – onto the quiz.
 
Question: What do these companies have in common? 
  • The Home Depot
  • JP Morgan Chase
  • UPS
  • REI
  • CVS/Caremark
  • Rite Aid Pharmacy
  • Northern Trust Company
  • Wall Street Journal
  • Bank of America
  • Apple
  • Goodwill
  • CNET
  • Boeing
  • Lockheed Martin
  • Goldman Sachs
  • PF Chang's
  • AT&T
  • Walgreens
  • And 100+ more that were fortunate to find something special.
What happened?
Over what time period?

Hint…Quote from Olaf...
“Oh, I don’t know why, but I always loved the idea of summer, and sun, and all things hot.”

 
 

Answer: Summer 2014 – these companies were burned by a data breach.
http://www.privacyrights.org/data-breach/new
 

Wednesday, September 3, 2014

Documenting Privilege – PCI-DSSv3

Yes, I understand the importance of Requirement 7. Restrict access to cardholder data by business need to know.

Increasingly, my respect grows for peers that communicate in plain English. Why? Because I understand how well you must understand material to [1] discuss it vs. [2] discuss it plainly.

Several years ago I was listening to a public radio tribute for a great Nobel prize-winning physicist. He had recently passed away, and his mark on society wasn't just his great research. It was his ability to plainly explain complex concepts in a way that people understood, and in a way that excited people. Creative passion. Made people want to understand and know even more. He made physics accessible to the average person.

Like many of you, I'm asked to understand a wide variety of topics. That means that I'm often coming back to topics that I've worked with before, and noticing new things.

As an example, requirement 1.1.5 is nicely done:
  • Requirement 1.1.5
    • Description of groups, roles, and responsibilities for management of network components
  • Testing Procedure
    • 1.1.5.a Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components. 
    • 1.1.5.b Interview personnel responsible for management of network components to confirm that roles and responsibilities are assigned as documented.
  • Guidance
    • This description of roles and assignment of responsibilities ensures that personnel are aware of who is responsible for the security of all network components, and that those assigned to manage components are aware of their responsibilities. If roles and responsibilities are not formally assigned, devices could be left unmanaged. 
  • Plain English: Validate everything is managed.… No device left behind… 
 
Now here's an example of much-needed simplification with respect to roles. The extended original version is fine if you work with this every day. But if you don't, I believe it's incredibly important to keep it simple. I think it would be a fun exercise to see how short and direct you could make the PCI-DSS.
 
Plain English version:
  • Plain English: 7.1.1 – Validate privileges following least privilege rule are documented.
  • Plain English: 7.1.2 – Validate privileges are appropriate with management.
  • plain English: 7.1.3 – Validate process exists whereby users are correctly assigned.
  • Plain English: 7.1.4 – Validate access approvals are documented.
 Extended playlist:

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.
7.1  Examine written policy for access control, and verify that the policy incorporates 7.1.1 through 7.1.4 as follows:
·    Defining access needs and privilege assignments for each role
·    Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities
·    Assignment of access based on individual personnel’s job classification and function
·    Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved.
The more people who have access to cardholder data, the more risk there is that a user’s account will be used maliciously. Limiting access to those with a legitimate business reason for the access helps an organization prevent mishandling of cardholder data through inexperience or malice.
7.1.1  Define access needs for each role, including:
·    System components and data resources that each role needs to access for their job function
·    Level of privilege required (for example, user, administrator, etc.) for accessing resources.
7.1.1  Select a sample of roles and verify access needs for each role are defined and include:
·    System components and data resources that each role needs to access for their job function
·    Identification of privilege necessary for each role to perform their job function.
In order to limit access to cardholder data to only those individuals who need such access, first it is necessary to define access needs for each role (for example, system administrator, call center personnel, store clerk), the systems/devices/data each role needs access to, and the level of privilege each role needs to effectively perform assigned tasks. Once roles and corresponding access needs are defined, individuals can be granted access accordingly.
7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.
7.1.2.a  Interview personnel responsible for assigning access to verify that access to privileged user IDs is:
·    Assigned only to roles that specifically require such privileged access
·    Restricted to least privileges necessary to perform job responsibilities.
When assigning privileged IDs, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator.

 
7.1.2.b   Select a sample of user IDs with privileged access and interview responsible management personnel to verify that privileges assigned are:
·    Necessary for that individual’s job function
·    Restricted to least privileges necessary to perform job responsibilities.
Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings.
Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID.
7.1.3 Assign access based on individual personnel’s job classification and function.
7.1.3 Select a sample of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function.
Once needs are defined for user roles (per PCI DSS requirement 7.1.1), it is easy to grant individuals access according to their job classification and function by using the already-created roles.
7.1.4 Require documented approval by authorized parties specifying required privileges.
7.1.4  Select a sample of user IDs and compare with documented approvals to verify that:
·    Documented approval exists for the assigned privileges
·    The approval was by authorized parties
·    That specified privileges match the roles assigned to the individual.
Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function.