Not sure if anyone actually cares about this, but thought I might just throw it out here: I found out a while ago that if a server is running IIS (or something else which accepts windows-style paths), then it is possible to get cookies sent to paths that they do not belong to by using an encoded backslash to indicate a directory delimiter like this: http://www.microsoft.com/en/us/test/..%5Cdefault.aspx

It works on all the browsers I tested (latest versions of IE, Firefox, Opera & Safari).

Not really useful, maybe on the off chance that, say, you need httpOnly cookies for some reason, and you can see headers for part of a path (e.g. because there's a phpinfo page in the root, but the cookie is for /app), or whatever, supposedly this was considered a security issue by Secunia way back when you could use %2e%2e/ on all servers in all browsers: http://secunia.com/advisories/9680/ (Though I think the premise for that bug is that you can't jump pages, which is of course wrong)

1. STLSec. Shawn @ Agurasec yelled at me for not letting everyone know that St. Louis has an active CitySec meetup:

   The next STLSec is July 10 @ the Fox and Hound. Be there or be square.

We had a great crowd our second time out, about 15-20 folks, roughly the same as the first one, with a number of new faces. That’s VERY impressive considering that CITYSec groups in cities three times our size get less turnout than that… Cool, huh?

If you haven’t came out yet, please do. CitySec is what you make it, so drop by, have a few beers and help us all figure out why we’re all crazy enough to do this crap for a living. Plus, beer. I mentioned that, right?

Directions, as always, at http://www.stlsec.org

1. NYSEC. The next NYSEC will be on July 15th.

2. LinkedIn. STLSec, NYSEC and CHISEC all have LinkedIn groups.

3. Twitter. Matasano has a corp. twitter account. How could you not want to see us have to communicate in 140 characters or less?!

Finally, if you are in the US, enjoy the long weekend. If you aren’t, enjoy the normal weekend.

Almost 2 years ago, Dino declared Python to be the “lingua-franca of over-the-hill hackers”, boldly asserting that 5 out of 6 security hackers under the age of 30 preferred Ruby instead. Being 30 at the time, I was an easy psychological target for this argument. I made the switch and haven’t regretted it. You can tell me all you want that “named nested functions are just as good as lambdas”, or that “you can fake Ruby blocks with a for loop and a generator”. Ruby is just nicer to write testing code in, and makes me feel at least 2 years younger and less experienced than I really am. Thanks, Ruby!

I’ve been meaning to write a long post about our house Ruby style, and some of the Ruby tips and tricks we’ve picked up along the way. But every time I sit down to write it, that post starts sounding a lot like work. So instead, I’d like to inaugurate a new series of much easier posts: Ruby for Pen-testers.

Where was I?

1. Use Modules For Lists Of Constants

If you test protocols or C code, you run into lists of magic numbers all the time. For example, here’s a bit of ptrace(2):

This is gross, but it’s C code, so you give them a break. But here’s some code from Pedram’s PyDbg:

Now, Pedram does have the excuse of writing in Python. But here’s Ruby-MySql:

This code has no excuse. (Here’s a rewrite that is much faster). Now, let’s look at net-ssh; if you haven’t read Jamis’ net-ssh code, you shouldn’t write any more packet processing code until you do.

Getting closer. But not there yet. Here’s an even better way:

That’s right: one module per set of constants. In other words, substitute “module” for “enum”. This has many benefits:

1. It’s clean. You can immediately find all the related magic numbers, both from the list, and by looking at code that uses the magic numbers —- you see Ragweed::EFlags::CARRY, you know to look for “EFlags”.

2. Modules come with special bonus features.

For instance:

… which is super nice when you’re printing out the contents of packets.

Hello, Bill here.

I wanted to let you know that we just posted our Advance Notification for next week’s bulletin release which will occur on Tuesday, July 8, 2008 around 10 a.m. Pacific Standard Time.

It is important to remember that while the information posted below is intended to help with your planning, because it is preliminary information, it is subject to change.

As part of our regularly scheduled bulletin release, we’re currently planning to release:

 

·        Four Microsoft Security Bulletins rated as Important. These updates may require a restart and will be detectable using the Microsoft Baseline Security Analyzer.

 

As we do each month, the Microsoft Windows Malicious Software Removal Tool will be updated.

 

We are also planning to release high-priority, non-security updates on Windows Update and Windows Server Update Services (WSUS) as well as high-priority, non-security updates on Microsoft Update and Windows Server Update Services (WSUS). For additional information, please see the Other Information section of the Advanced Notification.

 

Finally, in late July, we’ll also be releasing KB946928 which updates the infrastructure of the Windows Update client itself. For more information on this update, please visit the Microsoft Update blog.

 

As always, we’ll be holding the July edition of the monthly security bulletin webcast on Wednesday, July 9, 2008 at 11 a.m., Pacific Standard Time.  We will review this month’s release and take your questions live on-air with answers from our panel of experts. As a friendly reminder, if you can’t make the live webcast, you can listen to it on-demand as well. You can register for the webcast here: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032374629&Culture=en-US

 

Thanks,

 

Bill Sisk

*This posting is provided "AS IS" with no warranties, and confers no rights.*

For those interested we’ve released a whitepaper on how Vulnerability Assessment Plus and Web Application Firewall (VA+WAF) function independently and collectively. We spend a few pages describing the technical fundamentals of both which many should find educational – especially on the WAF side with industry material in painfully short supply. Very few people really understand the nitty gritty details of how WAF work and deployed in the real-world. I've learned a great deal in the last couple months talking with those who have. There is a little F5 ASM marketing in the paper so beware! :) Enjoy, snippets:

“WAFs at their core are designed to separate safe Web traffic from malicious traffic before it’s received by the website. And, if an attack does find a way to sneak past a WAF, it still has the ability to prevent sensitive information from leaving the trusted network. To get a better understanding of how the technology works, it’s helpful to view a WAF’s functionality as three discrete components - policies, policy generation, and policy enforcement. Depending on the particular WAF in use, they may go about implementing each component in a number of different ways. No one particular way has proven to be the right way, as each has its pros and cons.”

“Every effective vulnerability assessment program requires a cohesive combination of people, process, and technology. Qualified people are necessary to carry out day-to-day tasks, manage the technology, and interpret the results to make them meaningful to the business. Process is required for coordinated efforts between executive management, IT Security, and software development groups to share information, prioritize vulnerability fixes, and enable organizational improvements. The right technology is essential for consistency, efficiency, and comprehensiveness. Whether an organization chooses to perform vulnerability assessments with internal resources, a consultancy, or a Software-as-a-Services vendor, the overall vulnerability program must always account for people, process, and technology. If not, the effort will cost more in time and dollars than it should. Or worse, simply not work.”

You may have already seen the news about the new XSSFilter in IE8.0 but I wanted to echo it here as well, because it’s a pretty major new release. It does a great job of preventing most of the reflected XSS attacks out there for default users of the browser when it hits production. Very cool stuff. By the way, the second link above also has a sneak peek as to another security feature in IE8.0 if you look closely.

Think of XSSFilter like noscript in Firefox, but without the turning off JS portion of the functionality, and unlike noscript, it’s default in the browser, so it will impact a lot more people. David Ross (the guy who came up with the term Cross Site Scripting in the first place, btw) wrote this tool to start tackling a problem he’s been thinking about for 8 or more years since that paper was first authored. It’s not perfect, don’t get me wrong, but it’s a huge leap forward in the right direction, and I was hugely honored to be a part of it, since I think it will have a great positive impact on consumer security while us security knuckle draggers figure out a way to get websites to start securing themselves.

Next on my wish list? Content restrictions!

We are very pleased to announce the availability of Matasano’s Playbook!

What is Playbook?

Playbook is a web-based command center for network firewalls. From a single console, Playbook allows firewalls teams to search firewall rulesets, design access rules with full change tracking, and push them out to one, ten or one hundred devices with a single click.

Playbook helps organizations with multiple network firewalls to better manage their policies by providing a centralized and version controlled repository of rulesets, which can be easily browsed or searched via the web. Network operators can review all recent rule changes affecting the London branch, document a recently provisioned firewall at corporate offices, and rollback to the last known version of rules for the North-East group after an update gone wrong with only a couple of clicks and without having to log into 50 different devices. 

Playbook takes advantage of an expressive wiki engine to help you document rulesets, protocols, and your network infrastructure, so that you not only have a complete audit trail of all your changes, but you also know why those changes are there in the first place.

There is more information at the product’s official website. We’ll keep you posted as Playbook continues to evolve.

If you currently manage multiple firewalls and are are interested in learning more about Playbook we’d love to talk with you. Shoot us an e-mail or give us a call at 1-888-677-0666 x7529 (PLAY).

I’m sure other people have noticed this, at least I hope so, but never mentioned it publicly. If you read PCI-DSS 1.1 section 6.5, the part that covers “Cover prevention of common coding vulnerabilities in software development processes”, you’ll notice the list is identical to that of the OWASP Top Ten 2004 while the latest version is 2007:

6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management

I guess technically speaking anything that’s in v2007 and not v2004 you don’t have to worry about. That means you still have to code against Buffer Overflows and Application DoS, but not Malicious File Execution, Insecure Direct Object Reference, and Cross Site Request Forgery (CSRF). Ahh, fun fun. Gotta love compliance. :)

CSO magazine was kind enough to publish an opinion piece where I present a top-down view of the current state of web application security. I nervously expect a “spirited” flow of blog comments because it questions the value of certain best-practices and deeply held personal philosophies. Fortunately though our general public discourse has advanced a great deal recently and the community at large is a lot more informed of the challenges at hand. I pulled out a snippet to give a feel.

"It is unreasonable to expect publishers, enterprises and other site owners to restart and reprogram every website securely from scratch. Nor can we fix the hundreds of thousands (maybe millions) of custom Web application vulnerabilities one line at time. The very thought sounds insane to me. It would take too long (probably never finish), cost far too much (billions per year), and the bad guys are already ahead of us. Conservative estimates put the total annual IT security spend in the US at $50 billion and e-crime losses at $100 billion. We're losing two dollars for every dollar spent."

Enjoy!

The security book that I'd like to see written (and which I'd buy)

Good security books are few and far between. But IF someone writes the following book, I'll pre-order it immediately, even if it costs a hundred dollars:

"100 UNIX commands to issue on other people's systems"

Generally, I am horrible at all things *nix, and there are few enough good books around which teach you clever things to do with a shell. Unfortunately, there is no book that teaches people what to do with a shell on someone else's box.

Someone from Matasano told me they'd post their favourite commands if I wrote this blog post - so let's see it ! :)

(I'd like to start this by posting, but honestly -- I wouldn't be asking if I knew anything I'd not be embarrassed about. I mentioned above that I suck at all things *nix)

Why am I qualified to write about this?

In a former life, I was a malware analyst.  It was my job to analyze incoming samples and determine if they were false positives, or false negatives.  I also worked on automating the process, and it was a very neat job.  Unfortunately for me, economic realities and the precarious nature of startup companies dictated other career paths.  I had analyzed literally thousands of samples, and took notes on characteristics to help improve the anti-malware product.

Eventually after a while of doing this, I have some observations on where malware is going, and I’m going to share some of them in this post.

Growing Internationalization

In the past, an anti-malware company could focus on English-targeted samples.  But an increasing percentage of malware samples are international in origin and targeting international machines.  I saw numerous cases of Chinese malware targeting Chinese software or hosts.  This was quite a challenge to determine if it was malware or not for several reasons.

Cultural Impact

One of the most fascinating facets of the increasing internationalization of malware is the cultural assumptions around such software.  What is considered malware in the US may be commonly accepted in China or Japan, and this is largely due to the society that it exists in.

Anti-cheating rootkits are very common in games released in these countries.  What is considered to be invasive in the North American or European world is acceptable there.  These anti-cheating rootkits would hook into the kernel space in a very invasive way, and have the behavioral characteristics of malware such as hooking into the keyboard driver.  This made it very difficult from a purely technical standpoint to distinguish them.  These kits were attempting to protect the application from being tampered with while running, i.e. to reduce the incidence of bots, or modifications to the presentation layer to allow people to see through walls.  They would watch for kernel debuggers, or running processes that did specific characteristic behavior.  These very techniques would flag them as malware as many such samples would behave similarly to avoid antivirus or to prevent someone from easily reverse engineering them.

If I applied US standards to these particular samples and declared them a true positive, then we would have many angry international customers when their games no longer worked.  This also applied to extremely intrusive adware.  But these pieces of software could run on US machines as well, so it was a very tricky balance.

Linguistic Barriers

In the past, if I ran into a piece of malware that had foreign language strings in them, I could muddle through them if they were a Latin-derived language.  Spanish or French, I did not have any issues with.  But when it comes to languages that come from an entirely different root such as Chinese or Japaense written in hanzi or kanji, I was losing vital clues.

By looking at the behavior of the sample alone, I would declare it malware.  But what if it was one of the aforementioned game rootkits?  How do I know that the game actually includes it, or if it was indeed a trojan’ed game?  With English language samples, I would simply look at the strings, or use Google.  But I had to muddle through pages in a writing system that I could not easily begin to comprehend.

So, if you want to be a malware analyst, it would be in your best interest to become conversant or fluent in one or more of the non-Roman languages.

Internationalization of Antimalware Tools

As we are dealing more and more with malware samples that are international in scope, it becomes important that the tools themselves are internationalized. With the growth of samples targeted at other languages, the automatic tools that I wrote primarily dealt with ASCII and were becoming inadequate.  String and keyword analysis did not work well.  Tools need to be Unicode and multi-lingual.

Hints for International Malware Analysis

• Pay close attention to the signers of samples, whether they are signed or not.  Once you have verified a signed application, consider it the baseline.
• Once you have multiple samples of what appears to be the same application but has different checksums, pay close attention to file size, and the version, vendor strings.  Interestingly, many trojaned applications do not have the correct version and vendor strings.
• Use entropy to your advantage.  Measure the entropy of the binary segments that you have.  If they have very similar entropy values, and have a minor increment in version, the probability of it being a trojan is much lower.
• Pay close attention to the vendor and version strings of samples.  See if you can get an authoritative version of the application from the vendor’s site and compare it.  Once you have a sample that you can declare as as false positive, all other similar samples are much easier to analyze.
• Take note of what binary packers they are using.  Certain packers have a higher probability of being used by malware.  But there are legitimate use of packers, and some antivirus products will trigger a false positive on a packed application, no matter what.
• Build a library of samples, and understand the cultural context of the country of origin and destination.  Categorizing the sample characteristics by these criteria will help you determine if it is a true or a false positive for that particular market. 

Conclusion

It is becoming more and more important that entire infrastructure of malware analysis, from anti-malware client to backend infrastructure to the analyst herself become multilingual and multicultural.   It is a difficult challenge that is going to crop up more and more in the future.

A bit over a week has now gone by after critical vulnerabilities in ruby’s runtime were announced and a couple of interesting developments occurred:

• The new official ruby releases which include patches for the vulnerabilities actually break critical functionality. In fact, some of the most popular ruby frameworks segfault with any of these releases.

• It turns out that the breakage brought by the new releases is not due to the security fixes for Drew Yao’s vulnerabilities, but to other changes that were merged into each release’s branch.

• No response or timeline from ruby’s maintainers to produce a good release has been made public.

• In an attempt to provide a workable middle ground, third-parties create their own patches, and so do distributors. Some start from a patched release and then work back through the changes until tests pass, others take the opposite approach and start with a last “known-good” release against which they apply selected patches to plug the security holes. Needles to say, the results of each approach are not equivalent.

Developers relying on any of these frameworks are then faced with a difficult choice: wait an indeterminate amount of time for a good release from the official maintainers (and remain vulnerable in the meantime), or apply a patch from a third-party which may not plug all the security holes, or may include unforeseen bugs. This is clearly a problem. In the meantime maintainers have to scramble to get ruby back to a good state that actually plugs the holes while people complain. Everyone loses.

To some extent this is the other side of security response we sometimes advocate for and now we got a taste of: we want our patches and we want them now! And we got them, but our apps don’t work.

The beauty of open-source is not just that we get stuff for free but that we also get a privileged view into the processes around building and maintaining wildly popular software. This is a great opportunity for us as both security and software people to look into why these processes failed and hopefully learn something. Here are my top 3 takeaways:

Keep a “last-known-good” branch to apply critical patches to. The fact that patches had to be applied to unreleased versions of the code means that it is impossible to measure the impact of the change. IMHO this is the single most important mistake behind this state of affairs. This is almost akin to not using version control. Security problems will pop up unpredictably outside of any planned release schedule, and often require a rapid response. End-users may not be able to afford upgrading to a release with new features and even bug fixes every time this happens. It is then highly desirable that a new release which only includes the necessary security patches is made available, to minimize the risk of getting pwned by a new bug or some defiant kid. Are you ready to release critical patches to all the deployed versions of your software even as you are working on its next version?

Open line of communication with your community. It is hard to believe that passing Rails’ tests isn’t an acceptance requirement for every Ruby release, since Rails is the driving force behind Ruby’s adoption. The success of any platform depends on the applications it supports, without the apps the platform doesn’t matter. Microsoft learnt this a long time ago, and that’s why you’ll see them test third-party apps with new releases and security patches, even though technically is not their responsibility. Who are the relevant members of your community? Are you involving them in your release process?

Be more open about vulnerability details. When the vulnerabilities were originally announced very few details were made available (CVE entries for the vulns have been updated with more details since then, though there’s still no entry for the Bignum bug). Because ruby is an open-source project anybody can go and access their source control system to figure out what was actually patched. The fact that you can should be no news to readers of this blog, as people have been doing the same with binary patches for quite some time. Having direct access to not only source but the full source control system is a luxury! Given that the official release didn’t work it was important to isolate the security fixes, and to easily test if 3rd party patches were effective against the flaws. In fact, one of the test cases showed that the official release missed one of Drew’s patches. Lack of details just made it harder for the people trying to help. Do you have a policy about disclosing vulnerability details in your software? Would partners and customers have enough information to evaluate the impact of your patch to their infrastructure?

Just yesterday Apple released a security update which includes fixes for the ruby vulnerabilities. The patched build appears to deal correctly with all test cases, including the string concatenation case, and with Rails’ tests. The official ruby downloads still have issues with both.

I got forwarded this link today from businesswire about how Google and Yahoo are now going to be armed with the information necessary to look at and extract information out of SWF files. Ho-boy, here we go. The link was sent to me with the “bad juju” caveat, and I’m pretty sure I agree.

The problem is, like anything, if the search engines start pulling down rich applications that actually interact with the web application, there is untold issues that could arise. For instance, Flash applications have quite a bit of rich features in them, and some of that could be dangerous if they interact with back end applications. Also, if the word “test” appears in a Flash movie, does that mean it should get indexed? Or is it a frame that’s not visible, or off the side of the page, or whatever? What if it takes ten minutes to find that particular line of text or dozens of sub-menus? Are people really going to sit for that?

Do people really want to load a Flash movie when they query for things? I know I sure don’t! I’m already annoyed when I get linked to PDF files or .docx files. I think this just takes searching to a new level where people don’t actually want to go. Instead of crawling deeper and refining their search, the search engines are going to new mediums to stave off the people (like myself) who have argued that Flash isn’t a good medium for accessibility, usability and SEO. SEO is going to be off the table soon enough, leaving accessibility and usability.

But seriously, what’s next? Are the search engines going to decompile Java applets looking for text? As a side note, this should, at least in the short term, lead to a new round of Flash hacking, once it goes live. I’ll give a tee-shirt to the first person who writes a Google dork for internal Flash text that leads to exploitation.

As Microsoft released the Office file specs for the upcoming Office 2007, I can’t stop from thinking that even though these are specs for Office 2007 files, they must have similarities and are at least partly backward compatible with Office 200x.

This means they can be used by vulnerability researchers (good and bad) to more easily discover new vulnerabilities in Office as with the spec laid out, complete and systematic searching can be done.

Time will tell - lets start counting how many Office related vulnerabilities are released over the next few months - and see if we can find a correlation.

-

Is your site XSS Attacks safe? Signup for Beyond Security Vulnerability Scanner today!

On this week’s show we’re talking Web Application firewalls with Jeremiah Grossman. He’s the founder and CTO of WhiteHat Security — and he’s also a semi regular guest on Risky Business.

On this week’s podcast Jeremiah chats about WAFs, or Web Application firewalls, which he says come in quite handy. Admittedly he’s biased, having done some work on WAFs that work with F5 kit, but he provides some pretty compelling arguments as to why these things are assets.

It takes typical organisations around 130 days to fix sequel injection bugs in code. But you can mitigate these sorts of things with a Web app firewall, and you won’t even have to deal with the development team! Hooray!

Check Point Software’s Steve MacDonald also drops by for this week’s sponsor interview, which is about considering allowing staff to bring their own laptops to work.

ZDNet Australia’s Munir Kotadia is sick this week, so Kiwicon organiser and Winlockpwn creator Adam Boileau steps in to fill his shoes.

On this week's show we're talking Web Application firewalls with Jeremiah Grossman. He's the founder and CTO of WhiteHat Security -- and he's also a semi regular guest on Risky Business. On this week's podcast Jeremiah chats about WAFs, or Web Application firewalls, which he says come in quite handy. Admittedly he's biased, having done some work on WAFs that work with F5 kit, but he provides some pretty compelling arguments as to why these things are assets. It takes typical organisations around 130 days to fix sequel injection bugs in code. But you can mitigate these sorts of things with a Web app firewall, and you won't even have to deal with the development team! Hooray! Check Point Software's Steve MacDonald also drops by for this week's sponsor interview, which is about considering allowing staff to bring their own laptops to work. ZDNet Australia's Munir Kotadia is sick this week, so Kiwicon organiser and Winlockpwn creator Adam Boileau steps in to fill his shoes.

Hi. Bill here.

 

I want to let you know that we have just posted Microsoft Security Advisory 954960, which contains information regarding deployment Issues with Microsoft Windows Server Update Services (WSUS) version 3.0 and 3.0 Service Pack 1. Under specific conditions, the issue does not let clients detect any updates from a WSUS server on systems with Microsoft Office 2003 installed.

 

While the notification of this issue went out as a Security Advisory, this issue is not a security vulnerability in WSUS or Microsoft Office 2003, but it does address customers’ overall security. This issue only affects the ability of client machines to synchronize with a WSUS server.

 

We encourage affected customers to implement the manual workarounds, included in the Advisory, which enable clients to synchronize with a WSUS server and will be updated when our ongoing work in testing the permanent solution is complete.

 

This issue is not related to Microsoft Security Advisory 954474 where systems were blocked from deploying security updates using System Center Configuration Manager 2007.

 

Thanks,

 

Bill Sisk

*This posting is provided "AS IS" with no warranties, and confers no rights.*