I can’t believe the number of security “specialists” (many well known guys) who have jumped on the Web Application Firewall bandwagon! (WAF, f**king hate each new acronym). Amazingly, these dudes have done it all….by chance/coincidence to coincide with PSS DSS requirement 6.6! Where were they before this???? All heroes now! Put your hands up! Driving business….that is it….oh wow….I discovered a vendor that does this!
If your favourite blogger per chance is all of the sudden lately a fan of a WAF and helping push a product, I reckon you need to think about what they are doing! (talking to industry dudes, cred may have already be gone). Were they 12 months ago pushing the same message? Are they now a QSA (not that that matters so much but may ride on PCI DSS 6.6) and using that to drive business?
Has our situation changed that much that previous anti-WAF dudes are now sold on the benefits?
$$$$ vs industry objectives?! Oh yeah!
It’s all BS and I am happy for you to pull me up on it!
We’ve followed the WAF business since day 1! We’ve been there at the start of F5 products for example…BUT…..they’ve never wanted us to test them….we’ve tried and asked many times! (Wonder why?…..) So if anyone wants to promote them, ask the questions?!?! Maybe others did BUT we did not hear about it We just got the impression they were scared of letting us “test” the “system”.
Ooooh Yeah….we love pen testing against WAFs. Not one to this day has saved a site we have tested! While SG helps with product, we always acknowledge that product alone solves little.
Another DD rant you’re probably thinking. As usual, open to flames!
Critical bug fixes are on the agenda for this month's monthly patch update from Microsoft.…
The Kiwis have had this on the table for a while. Computerworld NZ and MIS Australia amongst others have covered it recently with changes being made to the rules governing online banking in New Zealand.
The Computerworld NZ story has a quote that doesn’t seem to make that much sense but in context of the history of this and what could have been, is now a bit more understandable; “The move is expected to boost customer confidence that losses from online fraud will be covered by the banks”.
While the motives are clear, regardless of spin put on the reasons, it does raise more questions than it answers and is something I suppose will be tested eventually in a legal scenario.
Mac and Linux users I suppose need to be worried. Will basic firewalls on those systems constitute “security software”? This will be an interesting one to follow. I am sure banks in other countries that don’t throw liability back as a general rule are also watching this.
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
LinkedIn. STLSec, NYSEC and CHISEC all have LinkedIn groups.
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 ConstantsIf 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:
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”.
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.*
Microsoft has detailed a raft of security improvements due to appear in Internet Explorer 8. The second beta of Redmond's web browser will be packed full of features designed to thwart phishing and drive-by download attacks, Redmond explained on Wednesday.…
Gamers visiting the US Sony PlayStation website risk malware infection after the site was hit by hackers.…
Nearly half (45.2 per cent) of all internet surfers neglect to regularly update their browser software. Slackness in applying updates in a timely fashion leaves an estimated 637 million surfers vulnerable to drive-by download attacks, according to a new survey.…
By straxd
Nobody expects an Australian inquisition….
Most of you have probably heard by now that new regulations have been enacted for World Youth Day in Sydney which allow police to fine up to $5500 and possibly imprison people who “annoy and inconvenience” World Youth Day participants. From the SMH; co-incidentally written by Julian of Chaser fame. One could put forward the argument that this has been setup for the Chaser team and other organised mobs are being discriminated against unfairly. Why should the Chaser team spoil the fun for everyone!
Police are apparently going to “use their discretion” to impose fines or gaol. Now that’s scary.
So what does this have to do with security? Well firstly, haxor dudes will need to check their black t-shirts before they go out to ensure no subtle anti-pope or anti-Christianity messages are printed on them. “If in doubt, don’t go out” should be the motto to all.
Aside from that, why stop there. Lets draw a really long bow here and give System Administrators the power to become Bastard Operators From Hell and manipulate users for fun and profit. All companies obviously have lots of protections against that happening …obviously…
It would be fun and most importantly, profitable to move these regulations into IT. “System Administrators now have the power to dock 10% from the pay of any worker who calls the help desk with an annoying or invalid issue. They should use their discretion to apply this rule only when necessary.”
Let the IT Security dudes become real security dudes and allow for batons and wrestling holds on those that don’t comply with company policies. Send in the special PCI security team with “extra powers” that override any internal policing for organisations that refuse to comply with the PCI DSS. Oh….this is now getting ridiculous…..it’s been a long day.
Does the church allow for pre-sin confessions? Always wondered that. Anyway, packing away my heavy metal t-shirts and donning the hair cream, short back and sides and then 3 Hail Marys for me.
Surely the NSW Government knows that the Chaser dudes are in semi-retirement? Or do they know something we don’t?
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 don’t really know what more to add. Just in case you weren’t aware of spam and its prevelence and intent:
http://www.networkworld.com/news/2008/070108-mcafee-spam-experiment.html?page=1
http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/07/01/MNFH11HHOU.DTL
Probably covered best here by the boys at Zero Day at ZDNET US:
http://blogs.zdnet.com/security/?p=1390
I need to think up some out-there research project that we can undertake through Beast or Buddha. Any suggestions?
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
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.
I was lucky enough to be invited to the first Interdisciplinary Workshop on Security and Human Behavior at MIT this week. Organized by Alessandro Acquisti, Ross Anderson, George Lowenstein, and Bruce Schneier, the workshop brought together an aggressively diverse group of 42 researchers from perspectives across computing, psychology, economics, sociology, philosophy and even photography and skepticism. As someone long interested in security on the human scale [pdf], it was exciting to meet so many like minded people from outside my own field. And judging from the comments on Ross' and Bruce's blogs, there's a lot more interest in this subject than from just the attendees.
There wasn't a single climactic insight or big result from the workshop; the participants mainly gave overviews of their fields or talked about their previously published work. The point was to get people with similar interests but widely different backgrounds talking (and hopefully collaborating) with one another, and it succeeded amazingly well at that. I overheard someone (accurately) comment that many of the kinds of conversations that usually take place in the hallway or the bar at most conferences were taking place in the sessions here.
This was a small and informal event, with no published proceedings or other tangible record, but I made quick-and-dirty sound recordings of most of the sessions, which I'll put up here as I process them.
I apologize for the uneven sound quality (the Frank Gehry sculpture in which the workshop was held was clearly not designed with acoustics in mind, and the speakers weren't always standing near my recorder's microphone on the podium). Audience comments in particular may be inaudible. Keep in mind that these are all big 90 minute MP3 files, about 40MB each, so they are definitely not for the bandwidth-deprived. For concise summaries of the sessions, see Ross Anderson's excellent live-blogged notes here.
Update 7/1/08 8pm: I'm heading back home from the conference now, with all the sound from yesterday already online below. I should have today's files (except the last session) up by late tonight or early tomorrow.
Update 7/1/08 11pm: I've uploaded the rest of the conference audio (except for the final session), all of which is linked from the agenda below. Unfortunately, I had to leave just before the last session (Session 8), so there's no audio for that one; sorry.
The United Kingdom is the most popular destination for 419 scams - emails which promise huge riches in exchange for up-front arrangement fees.…
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.*
A group of software and online payment companies are teaming up to find a better way than passwords to protect, and prove, your identity online.…
Is this a reaction to the monkeynet project? You have to wonder.
We had SAFECode announced last year and now comes ICASI, (Industry Consortium for Advancement of Security on the Internet). Release:
http://www.icasi.org/articles/art_001.htm
How they’re going to; “enhance global IT security by proactively driving excellence and innovation in security response” is something I think we all look forward to hearing more about.
I was just thinking to myself the other day, we’re about due for another consortium!
Recent update on SAFECode.