Research

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

Just ran across this ‘new’ SQL Server vulnerability in my news feed. This should not be an issue because you should not be using this set of functions. If you are using external stored procedures on a production database, stop. In fact, you want to stop using them altogether by either locking them down or removing them entirely. Not just because of this reported instance. External stored procedures exploits are favorites of database hackers, and have been used to alter database functionality and to run arbitrary code, both externally and internally launched attacks! SQL Server has historically had issues with buffer overflow attacks (See Microsoft Technical Bulletin MS02-020) against the pre-built procedures, and while known issued have been cleared up, XP’s are a complex and powerful extension ripe for exploits. The database vendors in general recommend as a security best practice the restriction of these to administrative use at a minimum. Even then it violates the best practice of segregation of the OS / database functionality required by compliance and operational security. Use of external stored procedures is flagged by all of the database vulnerability assessment tools, as both a security and a compliance issue. And in case you think that I am picking on SQL Server, many similar problems have been reported on Oracle ExtProc as well. The DBA in me loves the ability to run native platform utilities to support database admin efforts. It’s a really handy extension, and I know it is tempting to leave these on the database so you can make admin easier, but you will be relying upon security through obscurity. It is a really big risk in a production environment and one that every database hacker will have scripts to find and exploit. Share:

Tomorrow I’ll be giving the first webcast in a three part series I’m presenting for Oracle. It’s actually a cool concept (the series) and I’m having a bit more fun than usual putting it together. The first session is Database Security for Security Professionals. If you are a security professional and want to learn more about databases, this is targeted right between your eyes. Rather than rehashing the same old issues, we’re going to start with an overview of some database principles and how they mess up our usual approaches to security. Then we’ll dig into those things that the security team can control and influence, and how to work with DBAs. Although we are focusing on Oracle, all the core principles will apply to any database management system. And I swear to keep the relational calculus to myself. The next webcast flips the story and we’ll be talking about security principles for DBAs. Yes, you DBAs will finally learn why those security types are so neurotic and paranoid. The final webcast in the series will be a “build your own”. We’ll be soliciting questions and requests ahead of time, and then I’ll crawl into a cave throw it all together into a complete presentation. The webcast tomorrow (December 17th) will be at 11 am PT and you can sign up here. Share:

Just a quick note that I’ll be out in San Francisco for Macworld on January 5-8. While most of my time is dedicated to the conference, I will be able to take some meetings in the SF area. You can drop me a line at rmogull@securosis.com. I’m under strict orders to not come home with any new shiny Apple devices. We’ll have to see how that goes. (Last year I came home with an iPhone, totally against orders.) Share: