tssci security

xckd and exploits of a mom

Been busy the past couple days, just started work again and haven't gotten around to posting. I promise though, there'll be stuff coming up soon. In the mean time, enjoy latest comic from xkcd:

Exploits of a Mom

|exploits_of_a_mom.png|

What do you mean threat?

This is in reply to Richard Bejtlich's post, "Someone Please Explain Threats to Microsoft." Richard takes issue with people (especially those who should know better) who misuse defined terms. We say a lot of things with the expectations of those who are listening or reading to understand "what we mean." I hope this post clarifies some of that and what I believe is the proper definition of threat.

A threat is the mere possibility an attacker will exploit a vulnerability to compromise an asset. The attacker is not a threat by himself, for he needs a vulnerability to exist. Richard uses the term "threat agent" to describe an attacker or malware that can exploit a vulnerability. Threats are dependent on an attacker (or threat agent), the presence of a vulnerability, and the possibility for exploitation. You would not call someone a threat agent who does not have the ability to exploit a vulnerability, and thus, proves no threat to you. In other words, I don't think an attacker poses a threat if he cannot exploit a vulnerability. Looking back, that first sentence might be a little confusing, but I don't have any other way of describing it. Maybe a visual, some hand waving and throwing a Shmooball at you will help you understand it. :P

In his book, The Tao of Network Security Monitoring, Richard describes a threat as "a party with the capabilities and intentions to exploit a vulnerability in an asset." That's exactly right... a threat is a party! Party as in music, beer, people -- like your average birthday or Christmas party. It is comprised of multiple factors that exhibit various characteristics. A party does not imply an individual and therefore, a threat is not individualistic in nature.

Sometimes we say different things because we expect people to understand what we mean (even though we are wrong) and we tend to forget what we had defined them as. It's what makes us human and what differentiates us from computers. I can't tell how this differs with Richard's definition of threat, or if this is what he means. It feels like as of lately, his definition has veered and taken on a slightly different meaning.

Watch out for this hacker

Alright, so... I logged into Facebook (yes I know.. and probably easy to find as well, whatever), checked my messages and noticed I received an invitation to a group called "watch out for this hacker." From the description:

If somebody called bm_tnoo7@hotmail.com adds you to their facebook account DONT accept it because its a hacker. Tell everyone on your list because if somebody on your list adds them you get them on your list he'll figure out your ID computer address. So copy and paste this message to everyone even if you hate them and fast because if he hacks their mail he hacks yours

The group has almost 2000 members, and I just gotta say... this is hilarious. WTF is a "ID computer address?" o_O

So a bunch of people, some smarter than others, start talking about how this is possible/not possible/etc. The group starter, responds to the flurry of comments with this:

LET ME STOP ALL THIS COMMOTION....I CREATED THIS GROUP IN HOPES THAT I CAN PREVENT YOU GUYS FROM BEING HACKED...I KNOW WAT IM TALKING ABOUT, AND IT IS NOT THRU YOUR IP ADDRESS THAT HE'LL GET INTO THE SYSTEM...HE USES DIFFERENT METHODS. ALL THESE NERDS TALKIN ABOUT THEY ARE AN EXPERTISE, DONT NO SHIT...NOT EVEN CLOSE...IF ONLY U KNEW....ILL STOP RITE THERE

Yup.. okay buddy. Best comment I read so far:

"ID computer address"... wow. Someone get Ted Stevens on the line.

Stop Wordpress 2.3 "phoning home"

A new release of Wordpress 2.3 was shipped last night. One of the features it sports is:

Our new update notification lets you know when there is a new release of WordPress or when any of the plugins you use has an update available. It works by sending your blog URL, plugins, and version information to our new api.wordpress.org service which then compares it to the plugin database and tells you what the latest and greatest is you can use.

The new release does not allow you the option of disabling this functionality. Here's a quick hack to disable it by changing the URL it attempts to establish a connection with (api.wordpress.org). There are two files located under the root directory: ``wp-admin/includes/update.php`` and ``includes/update.php`` that contain the code we will be editing.

Edit wp-admin/includes/update.php line 82 and 90, and remove or change the url to your liking.:

82   $http_request .= "Host: api.wordpress.org\r\n";
     ...

90   if( false != ( $fs = @fsockopen( 'api.wordpress.org', 80, $errno, $errstr, 3) ) && is_resource($fs) ) {

Secondly, edit includes/update.php line 27 and 33 as well.:

27   $http_request .= "Host: api.wordpress.org\r\n";
     ...

33   if ( false !== ( $fs = @fsockopen( 'api.wordpress.org', 80, $errno, $errstr, 3 ) ) && is_resource($fs) ) {

In other words, who is in support of forking Wordpress? Perhaps we can revamp the entire architecture and make it more secure... just a thought.

PCI DSS questions left unanswered

Chris Eng of Veracode, attended the first PCI Community Meeting in Toronto, an organized panel that brings QSAs, ASVs and those subject to PCI together with the PCI DSS council, and lives toblog about it. Several days ago, I posted some thoughts on the PCI DSS and several of it's ambiguous requirements. Chris is left with some of the same unanswered questions and more after attending two panel discussions -- one covering the Payment Application Data Security Standard (PA-DSS) and Requirement 6.6 of the PCI Data Security Standard (PCI-DSS).

On PA-DSS and Visa's Payment Application Best Practices (PABP):

The panel outlined the changes to PABP as follows:

  • Explanation/Clarification. Just providing additional text around the best practices, presumably to make them easier to understand.
  • Enhancements. Things necessary to turn a Best Practices document into a standard. The panel did not go into exhaustive detail on the enhancements, but the examples given were requiring assessors to use forensic tools to examine the output of the PA, introducing stronger lab requirements, and requiring a penetration test of the PA to identify common (e.g. OWASP-style) vulnerabilities.

Unfortunately, this was the extent of the detail. I wanted more information on the enhancements but didn't get a chance to ask a question due to time constraints. Specifically, it would be nice to understand whether code analysis would be an alternate option for the penetration test requirement. Or what exactly they meant by using forensic tools to examine the application's output.

Interesting... I'd like to know more about "using forensic tools to examine the application's output" as well. In my previous post, I specifically wrote in regards to PCI DSS Requirement 6.6:

*6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:*

  • Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security.
  • Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.

So which method is it? One or the other or both? Installing a WAF lets you skimp on code review? What about maintaining the WAF after installation? This requirement should be reviewed and changed to specify what is required and like Requirement 1.1.6/7, should have an extra clause.

Well, the panel did not answer much about that either, and Chris had other question's regarding automated source code analysis and whether it would satisfy the requirement for code review. Due to false positives/negatives, an automated source code analysis would not satisfy it and would still require a security professional to do the review. Chris brings up a point on benchmarking WAFs for false positives/negatives -- since as it's written, Requirement 6.6 is an either-or and a security compromise to take.

So there are a lot of questions left unanswered, and unfortunately the questions asked were ones that any QSA/ASV should be able to answer. The technical meat behind PCI was left on the backburner. doh!

« Newer entries — 23 — Older entries »

blog comments powered by Disqus