Research

Macworld Expo may no longer be good enough for Apple, but it’s still one of my conference highlights of the year. I’ll be out there today through Thursday while Adrian manages the fort in Phoenix (I’ve managed to convince him that cleaning the cat litter while my wife is at work is a formal job responsibility, please don’t tell him that’s illegal and stuff). Most of my writing this week will be over at TidBITS, but I’ll pop some of my informal thoughts (and anything security related) over here at Securosis and on Twitter. And if any of you are over at the Expo, drop me a line and let’s try to meet up. For the record- I don’t expect any earth shattering new announcements this week, but some nice incremental upgrades. To be honest, I’d rather have better stability and functionality with what I already own than some new device I’ll get in trouble for buying. P.S. Dear Apple, if you do announce anything insanely new and cool, please make it small enough to fit in my carry-on luggage. That is all. Share:

Update: Verisign already closed the hole. This morning (in the US- afternoon in Europe), a team of security researchers revealed that they are in possession of a forged Certificate Authority digital certificate that pretty much breaks the whole idea of a trusted website. It allows them to create a fake SSL certificate that your browser will accept for any website. The short summary is that this isn’t something you need to worry about as an individual, there isn’t anything you can do about it, and the odds are extremely high that the hole will be closed before any bad guys can take advantage of it. Now for some details and analysis, based on the information they’ve published. Before digging in, if you know what an MD5 hash collision is you really don’t need to be reading this post and should go look at the original research yourself. Seriously, we’re not half as smart as the guys who figured this out. Hell, we probably aren’t smart enough to scrape poop off their shoes (okay, maybe Adrian is, since he has an engineering degree, but all I have is a history one with a smidgen of molecular bio). This seriously impressive research was released today at the Chaos Computer Congress conference. The team, consisting of Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Anne Osvik, and Berne de Weger took advantages of known flaws in the MD5 hash algorithm and combined it with new research (and an array of 200 Sony Playstation 3s) to create a forged certificate all web browsers would trust. Here are the important things you need to know (and seriously, read their paper): All digital certificates use a cryptographic technique known as a hash function as part of the signature to validate the certificate. Most certificates just ‘prove’ a website is who they say they are. Some special certificates are used to sign those regular certificates and prove they are valid (known as a Certificate Authority, or CA). There is a small group of CAs which are trusted by web browsers, and any certificate they issue is in turn trusted. That’s why when you go to your bank, the little lock icon appears in your browser and you don’t get any alerts. Other CAs can issue certificates (heck, we do it), but they aren’t “trusted”, and your browser will alert you that something fishy might be going on. One of the algorithms used for this hash function is called MD5, and it’s been broken since 2004. The role of a hash function is to take a block of information, then produce a shorter string characters (bits) that identifies the original block. We use this to prove that the original wasn’t modified- if we have the text, and we have the MD5 results, we can recalculate the MD5 from the original and it should produce exactly the same result, which must match the hash we got. If someone changes even a single character in the original, the hash we calculate will be completely different from the one we got to check against. Without going into detail, we rely on these hash functions in digital certificates to prove that the text we read in them (particularly the website address and company name) hasn’t been changed and can be trusted. That way a bad guy can’t take a good certificate and just change a few fields to say whatever they want. But MD5 has some problems that we’ve known about for a while, and it’s possible to create “collisions”. A collision is when two sources have the exact same MD5 hash. All hash algorithms can have collisions (if they were really 1:1, they would be as long as the original and have no purpose), but it’s the job of cryptographers to make collisions very rare, and ideally make it effectively impossible to force a collision. If a bad guy could force an MD5 hash collision between a real cert and their a fake, we would have no way to tell the real from the forgery. Research from 2004 and then in 2007 showed this is possible with MD5, and everyone was advised to stop using MD5 as a result. Even with that research, forging an MD5-based digital certificate for a CA hadn’t ever been done, and was considered very complex, if not impossible. Until now. The research team developed new techniques and actually forged a certificate for RapidSSL, which is owned by Verisign. They took advantage of a series of mistakes by RapidSSL/Verisign and can now fake a trusted certificate for any website on the planet, by signing it with their rogue CA certificate (which carries an assurance of trustworthiness from RapidSSL, and thus indirectly from Verisign). RapidSSL is one of 6 root CAs that the research team identified as still using MD5. RapidSSL also uses an automatic system with predictable serial numbers and timing, two fields the researchers needed to control for their method to work. Without these three elements (MD5, serial number, and timing) they wouldn’t be able to create their certificate. They managed to purchase a legitimate certificate from RapidSSL/Verisign with exactly the information they needed to use the contents to create their own, fake, trusted Certificate Authority certificate they can then use to create forged certificates for any website. They used some serious math, new techniques, and a special array of 200 Sony PS3s to create their rogue certificate. Since browsers will trust any certificate signed by a trusted CA, this means the researchers can create fake certificates for any site, no matter who originally issued the certificate for that site. But don’t worry- the researchers took a series of safety precautions, one being that they set their certificate to expire in 2004- meaning that unless you set the clock back on your computer, you’ll still get a security alert for any certificate they sign (and they are keeping it secret in the first place). All the Certificate Authorities and web browser companies are

We’ve been covering a heck of a lot of territory in our series on Building a Web Application Security Program (see Part 1, Part 2, Part 3, Part 4, Part 5, and Part 6). So far we’ve covered secure development and secure deployment, now it’s time to move on to secure operations. This is the point where the application moves out of development and testing and into production. Keep in mind that much of what we’ve talked about until now is still in full effect- just because you have a production system doesn’t mean you throw away all your other tools and processes. Updates still need to go through secure development, systems and applications are still subject to vulnerability assessments and penetration testing (although you need to use a different process when testing live applications vs. staging), and configuration management and ongoing secure management are more important than ever before. In the secure operations phase we add two new technology categories to support two additional processes- Web Application Firewalls (WAF) for shielding from certain types of attacks, and monitoring at the application and database levels to support auditing and security alerting. Before we dig in, we also want to thank everyone who has been commenting on this series as we post it- the feedback is invaluable, and we’re going to make sure everyone is credited once we put it into whitepaper format. Web Application Firewalls (WAF) The role of a web application firewall is to sit in front of or next to a web application, monitoring application activity, and alerting or blocking on policy violations. Thus it potentially serves two functions- as a detective control for monitoring web activity, and as a preventative control for blocking activity. A web application firewall is a firewall specifically built to watch HTTP requests and block those that are malicious or don’t comply with specific rules. The intention is to catch SQL injection, Cross Site Scripting (XSS), directory traversal, and various HTTP abuses, as well as authorization, request forgeries, and other attempts to alter web application behavior. The WAF rules and policies are effectively consistency checks, for both the HTTP protocol and application functionality. WAFs can alert or block activity based on general attack signatures (such as a known SQL injection attack for a particular database), or application-specific signatures for the web application being protected. WAF products examine inbound and outbound HTTP requests, compare these with the firewall rules, and create alerts for conditions of concern. Finally, the WAF selects a disposition for the traffic: 1) let it pass, 2) let it pass but audit, 3) block the transaction, or 4) reset the connection. WAFs typically network appliances. They are normally placed in-line as a filter for the application (proxy mode); or ‘out-of-band’, receiving traffic from a mirror or SPAN port. In the former scenario, all inbound and outbound requests are intercepted and inspected prior to the web server receiving the request or user receiving the response, reducing load on the web application. For SSL traffic, inline WAFs also need to proxy the SSL connection from the browser so it can decrypt and inspect traffic before it reaches the web server, or after it leaves the web server for responses. In out-of-band mode, there are additional techniques to monitor the encrypted connections by placing a copy of the server certificate on the WAF, or positioning it behind an SSL concentrator. Some vendors also provide WAF capabilities via plug-ins for specific platforms, rather than through external devices. The effectiveness of any WAF is limited by the quality of the policies it is configured to enforce. Policies are important not merely to ability to recognize and stop known/specific attacks, but also for flexibly dealing with ambiguous and unknown threat types, while keeping false positives manageable and without preventing normal transaction processing. The complexity of the web application, combined with the need for continuous policy updates, and the wide variety of deployment options to accommodate, pose a complex set of challenges for any WAF vendor. Simply dropping a WAF in front of your application and turning on all the default rules in blocking mode is a recipe for disaster. There is no way for black box to effectively understand all the intricacies of a custom application, and customization and tuning are essential for keeping false positives and negatives under control. When deployed in monitoring mode, the WAF is used in a manner similar to an intrusion detection system (IDS). It’s set to monitor activity and generate alerts based on policy violations. This is how you’ll typically want to initially deploy the WAF, even if you plan on blocking activity later. It gives you an opportunity to tune the system and better understand application activity before you start trying to block connections. An advantage of monitoring mode is that you can watch for a wider range of potential attacks without worrying that false positives will result in inappropriate blocking. The disadvantages are 1) your incident handlers will spend more time dealing with these incidents and false positives, and 2) bad activity won’t be blocked immediately. In blocking/enforcement mode, the WAF will break connections by dropping them (proxy mode) or sending TCP reset packets (out of band mode) to reset the connection. The WAF can then ban the originating IP, permanently or temporarily, to stop additional attacks from that origin. Blocking mode is most effective when deployed as part of a “shield then patch” strategy to block known vulnerabilities in your application. When a vulnerability is discovered in your application, you build a specific signature to block attacks on it and deploy that to the WAF (the “shield”). This protects your application as you go back and fix the vulnerable code, or wait for an update from your software provider (the “patch”). The shield then patch strategy greatly reduces potential false positives that interfere with application use and improves performance, but is only possible when you have adequate processes to detect and evaluate these vulnerabilities. You can combine both

A Microsoft Security Advisory for SQL Server (961040) was posted on the 22nd of December. Microsoft has done a commendable job and provided a lot of information on this page, with a cross reference of the CVE number (CVE-2008-4270) so you can find more details if you need it. Any stored procedure that provide remote code execution can be dangerous and is a target for hackers. You want to patch as soon as Microsoft releases a patch. Microsoft states that “… MSDE 2000 or SQL Server 2005 Express are at risk of remote attack if they have modified the default installation to accept remote connections, if they allow untrusted users access to MSDE 2000 or SQL Server 2005 Express …” But I rate the risk higher than they say because of the following: MSDE 2000 and SQL Server Express 2005 are often bundled/embedded into applications and so their presence is not immediately apparent. There may be copies around that IT staff are not fully aware of, and/or these applications may be delivered with open permissions because the developer of the application was not concerned with these functions. Second, replication is an administrative function. sp_replwritetovarbin, along with other stored procedures like sp_resyncexecutesql and sp_resyncexecute, functions run as DBO, or Database Owner, so if they are compromised they expose permissions as well as functions. Finally, as MSDE 2000 and SQL Server Express 2005 get used by web developers who run the database on the same machine with the same OS/DBA credentials, you server could be completely compromised with this one. So follow their advice and run the command: use master deny execute on sp_replwritetovarbin to public” A couple more recommendations, assuming you are a DBA (which is a fair assumption if you are running the suggested workaround) check the master.dbo.sysprotects and master.dbo.sysobjects for public permissions in general. Even if you are patched for this specific vulnerability, or if you are running an unaffected version of the database, you should have this procedure locked down otherwise you remain vulnerable. Over and above patching the known servers, if you have a scanning and discovery tool, run a scan across your network for the default SQL Server port to see if there are other database engines. That should spotlight the majority of undocumented databases. Share:

‘The Microsoft Security Advisory (961040) for SQL Server was posted on the 22nd of December. Microsoft has done a commendable job and provided a lot of information on this page, with the cross reference of the CVE number (CVE-2008-4270) so you can find more details if you need it. Like any of the store procedures that provide remote code execution, they can be dangerous and are targets for hackers. You want to patch as soon as Microsoft releases a patch. Microsoft states that “… MSDE 2000 or SQL Server 2005 Express are at risk of remote attack if they have modified the default installation to accept remote connections, if they allow untrusted users access to MSDE 2000 or SQL Server 2005 Express …”. But I rate the risk higher than what they are saying because of the following: MSDE 2000 and SQL Server Express 2005 are often bundled/embedded into applications and so their presence is not immediately apparent. There may be copies around that most IT staff are not fully aware of, and/or these applications may be delivered with open permissions because the developer of the application was not concerned with these functions. Second, replication is an administrative function. sp_replwritetovarbin, along with other stored procedures like sp_resyncexecutesql and sp_resyncexecute functions run as DBO, or Database Owner, so if they are compromised they expose permissions as well as function. Finally, as MSDE 2000 and SQL Server Express 2005 get used by web developers who run the database on the same machine with the same OS/DBA credentials, you server could be completely compromised with this one. So follow their advice and run the command: “use master  deny execute on sp_replwritetovarbin to public” A couple more recommendations, assuming you are a DBA (which is a fair assumption if you are running the suggested workaround) check the master.dbo.sysprotects and master.dbo.sysobjects for public permissions in general. Even if you are patched for this specific vulnerability, or if you are running an unaffected version of the database, you should have this procedure locked down otherwise you remain vulnerable. Over and above patching the known servers, if you have a scanning and discovery tool, run a scan across your network for the default SQL Server port to see if there are other database engines. That should spotlight the majority of undocumented databases. Share:

The Microsoft Security Advisory (961040) for SQL Server was posted on the 22nd of December. Microsoft has done a commendable job and provided a lot of information on this page, with the cross reference of the CVE number (CVE-2008-4270) so you can find more details if you need it. Like any of the store procedures that provide remote code execution, they can be dangerous and are targets for hackers. You want to patch as soon as Microsoft releases a patch. Microsoft states that “… MSDE 2000 or SQL Server 2005 Express are at risk of remote attack if they have modified the default installation to accept remote connections, if they allow untrusted users access to MSDE 2000 or SQL Server 2005 Express …”. But I rate the risk higher than what they are saying because of the following: MSDE 2000 and SQL Server Express 2005 are often bundled/embedded into applications and so their presence is not immediately apparent. There may be copies around that most IT staff are not fully aware of, and/or these applications may be delivered with open permissions because the developer of the application was not concerned with these functions. Second, replication is an administrative function. sp_replwritetovarbin, along with other stored procedures like sp_resyncexecutesql and sp_resyncexecute functions run as DBO, or Database Owner, so if they are compromised they expose permissions as well as function. Finally, as MSDE 2000 and SQL Server Express 2005 get used by web developers who run the database on the same machine with the same OS/DBA credentials, you server could be completely compromised with this one. So follow their advice and run the command: “use master deny execute on sp_replwritetovarbin to public” A couple more recommendations, assuming you are a DBA (which is a fair assumption if you are running the suggested workaround) check the master.dbo.sysprotects and master.dbo.sysobjects for public permissions in general. Even if you are patched for this specific vulnerability, or if you are running an unaffected version of the database, you should have this procedure locked down otherwise you remain vulnerable. Over and above patching the known servers, if you have a scanning and discovery tool, run a scan across your network for the default SQL Server port to see if there are other database engines. That should spotlight the majority of undocumented databases. Share:

Remember our first post that there are no trusted sites? Followed by our second one? Now I suppose it’s time to start naming names in the post titles, since this seems to be a popular trend. American Express is our latest winner. From Dark Reading: Researchers have been reporting vulnerabilities on the Amex site since April, when the first of several cross-site scripting (XSS) flaws was reported. However, researcher Russell McRee caused a stir again just a week ago when he reported newly discovered XSS vulnerabilities on the Amex site. The vulnerability, which is caused by an input validation deficiency in a get request, can be exploited to harvest session cookies and inject iFrames, exposing Amex site users to a variety of attacks, including identity theft, researchers say. McRee was tipped off to the problem when the Amex site prompted him to shorten his password – an unusual request in today’s security environment, where strong passwords are usually encouraged. … McRee says American Express did not respond to his warnings about the vulnerability. However, in a report issued by The Register on Friday, at least two researchers said they found evidence that American Express had attempted to fix the flaw – and failed. “They did not address the problem,” says Joshua Abraham, a Web security consultant for Rapid7, a security research firm. “They addressed an instance of the problem. You want to look at the whole application and say, ‘Where could similar issues exist?’” No, we don’t intend on posting every one of these we hear about, but some of the bigger ones serve as nice reminders that there really isn’t any such thing as a “safe” website. Share:

Remember our guest post from Jesse Krembs on the MIT students put under a gag order during DefCon this year for hacking the rail system? And I quote: Please grow up; in the connected world there are very few ogres in caves any more, and they don’t let you ride their trains. The difference between black hats and white hats is a line, and it’s a gray one. But occasionally it gets a little contrast. When you treat the person or organization with a security problem like a victim or an enemy, then you’re the bad guy. You’re basically fucking them over, sometimes hard, sometimes gently, but it’s still a screw job. When you treat them like a partner, then everyone wins. Sure, sometimes they don’t want partners, and sometimes you have to go public because they put the rest of the world at risk, but you don’t know that until you try talking to them. Finally I should note that in the end the only people winning in this case are the lawyers; the kids won’t win in the way they want, nor will the MBTA. The lawyers, on the other hand, always get paid Looks like Superman just spun the Earth backwards and turned back time (sort of): The announcement brings to a close a high profile case that pitted the rights of security researchers to freely discuss their findings against the concerns of one of the country’s largest transit systems, which worried that this type of information could lead to widespread ticket fraud. “I’m really glad to have it behind me. I think this is really what should have happened from the start,” said Zack Anderson, one of the students sued by the MBTA. … The settlement ends the matter in an amicable way. “For professional reasons and for public interest reasons, the students wanted to help the MBTA,” said Jennifer Granick, a lawyer with the Electronic Frontier Foundation who represents the students. The case against the three was finally settled on Oct. 7, but this was not publicly announced until Monday, because it took two months for all parties to schedule a public announcement of the settlement, Granick said. The researchers met with MBTA technical staff on Oct. 21 to discuss their findings and are working to improve the transit authority’s fare collection system, she added. And all is good in the world again. Share:

Looks like the RIAA has finally realized that treating customers like criminals isn’t the best strategy in the world. According to the Wall Street Journal (via Slashdot) they are ending their campaign of suing individual file sharers to focus on working with ISPs to reduce illegal sharing. As much as I like to rip the heck out of the RIAA and MPAA for their draconian views on copyright and enforcement, it really is stealing if you snag something off a file sharing network. Like most people in college I was into the Napster thing for a bit, but quickly realized it was wrong, and I stopped using it. Heck, a friend’s dad who was an FBI agent had her download music for him; that’s how new the concept was and how much it snapped our usual social mores. But I will admit, here and now, to downloading digital content I already legally access when DRM restrictions interfere with my use of that content. It’s not something I do very often, but I have no qualms about heading to the Pirate Bay and grabbing an episode of a TV show my TiVo won’t let me transfer to my phone (mostly the hi def stuff), I’ll even rent movies, rip them, watch them once on my iPhone, then delete them. If the media companies interfere with my existing rights, I’m more than happy to circumvent them. I still pay for all my music, movies, and television, and in exchange I use all my technical skills to maintain my rights. Share:

This will be our last Friday Summary for 2008. This afternoon Adrian and I are off to The Office for our Securosis Annual Staff Festivus Party (sorry Chris, but we can drunk dial you if that makes you feel included). 2008 has been an incredibly wild ride. When it started I was just a solo consultant that wasn’t even calling myself an analyst anymore, and wasn’t certain where I wanted to take things. In January I ran a half marathon on a bad knee that mysteriously felt better after the race, but in February I went in for shoulder surgery that I’m still struggling to recover from. Over the summer, Adrian joined Securosis and we moved firmly back into the analyst column. As the year closes we’ve published a ton of free content, multiple vendor-neutral whitepapers, spoken at everything from RSA, to SOURCE Boston, to DefCon, and a few TechTarget and MISTI events (including a show in Moscow), given over a dozen webcasts, and, to be honest, had a heck of a lot of fun in the process. We’ve written articles for everyone from Macworld to Dark Reading, been interviewed by… well, pretty much everyone else, and enjoyed more than a few frothy beverages with our industry friends. For two skinny guys (and a part-time editor/UNIX guru, also skinny) running a small company we really couldn’t have asked for more. We’ve decided to give back, and we’ll announce more on that next week. And 2009 is looking even crazier. In February we’ll be adding a new staff member, the exact date, gender, length, and weight are still undetermined (if he or she is over 8 lbs, my wife might kill me). We’re also completely redesigning our website as we continue to expand things a bit. This site started as just my personal blog, and as we keep pumping out content it isn’t nearly as well suited as it was at the beginning. The blog won’t change, but we’re going to make content more accessible and start loading up new kinds of materials- like videos of our conference presentations. We’re also really going to push forward with the ideas of totally transparent and open research. We’re not idiots, and we don’t intend on competing with Gartner, Forrester, and the other large firms, but we still love what we do and think there’s plenty of room for us little guys (and our combined weight is pretty low, not that that’s relevant). We have more flexibility than they do, and you can expect no bullshit research that’s focused on in-depth, practical advice to help you with specific projects. We already have two programs planned- Pragmatic PCI, and Pragmatic Database Security (we’ll have to charge for those, since we have to keep the dogs, cats, and other little ones fed). Finally, we have some new media, social media, and community stuff in the works. Okay- I realize that all sounded like marketing junk, but I think we’re allowed to be excited about what we’ve done, and what we have planned, from time to time. We are incredibly thankful for the opportunities and support you’ve all given us. And as a preview, here’s the official premier of our new logo (it will look better on the new site template): Have a wonderful holiday season. We’ll be reducing our posting volume a bit over the holidays, but stay tuned for the end of our web application series and a few other treats. Here is the week’s security summary: Webcasts, Podcasts, Outside Writing, and Conferences: The Network Security Podcast is a little shorter this week as we finish off the year. As an aside, Martin and I would like to apologize for our recent audio difficulties. We narrowed it down to a bad sound card on Martin’s side, and are changing our recording process for higher quality (we’ll be moving to double-ended recording). Via NetworkWorld, I gave a webcast for Oracle on Database Security for Security Professionals. It targets security pros who may be new to databases, and the replay is available here. I talked with Forbes about antivirus scanners. I debunked some FUD by Bit9 on automatic software updates in enterprises for LinuxInsider. IT departments can turn them off, so I don’t see what the problem is. Adrian talked database security with eWeek. Adrian on log management for internetnews.com. Someone named Adrian Lane is into otters. It’s the UK, so probably a different guy, but we’ll take all the press we can get. Favorite Securosis Posts: Rich: Part 6 of our Building a Web Application Security Program. We really want to get this series (and the eventual paper) right, so any feedback, comments, and (especially) criticisms are very much appreciated. Adrian: While my practical experience has come to the same set of conclusions, finding meaning is groups of anonymous statistical patterns to justify database security is a black art I don’t care to dabble in. < p>Favorite Outside Posts: {Adrian editorial}- I have been following the series of posts between Alan Shimmel and Andy the IT Guy (links below). They are touching on the very heart of the sales process and common friction between the IT gatekeeper and the salesman. But I thought they both danced around the key point. The sales guy is doing his job by pushing as hard as he can to get the deal done without pissing everyone off to the point the organization gets fed up and will no longer work with you. A good sales guy knows there is always a deal if they can overcome objections (price, support, consultative assistance, etc) because they would not be talking if the need was not there. However buyers buy from people they know, like, and trust, and trampling the gatekeeper is a good way to make enemies. Alan’s comment “Try putting yourself in the other’s shoes to better understand what is involved. Common courtesy and respect would be a good place to start” cuts both ways. Seems to me the sales guy