January 31, 2006

Windows Access Control Demystified

I just came across an interesting paper being published out of Princton in which the authors have constructed a logical model of Windows XP access control, in a declarative but executable format.

They have even built a simple scanner that reads access-control conguration information from the Windows registry, file system, and service control manager database, and feeds raw configuration data to the model. Through this, they believe they can reason about such things as the existence of privilege-escalation attacks, and they believe that they have even found several user-to-administrator vulnerabilities caused by misconfiguration of the access-control lists of commercial software from several major vendors.

It is an interesting approach. I will need to spend a bit more time analyzing what they have done here in an effort to see what it is that they believe they are able to do. It seems that this might be an interesting way to to model and debug the complex interactions of access control on installations under Windows environments.

Their words... not mine. Interesting none the less. Happy reading!

Posted by SilverStr at 05:40 PM | Comments (2) | TrackBack

Preventing Exchange from sending RTF messages (and winmail.dat) to mailing lists

OK, so I had an interesting issue today. Seems I couldn't post to a mailing list because it had an attachment (winmail.dat) that I didn't know about. Apparently when using OWA it always sends it in RTF, which of course appends the winmail.dat file (if you like it or not) to mailing lists. I could NOT find a way in OWA to send to specific addresses in plain text only. And since I don't use Outlook, I was hosed.

Or so I thought.

I found an awesome way to FORCE delivery in plain text to certain addresses. And with no thanks to Exchange which was amazinging difficult and complex. Susan pointed me to KB138053, but I couldn't find ANY of those settings in the Exchange System Manager.

So I was on the hunt for something easier. And low and behold, I came across a small article on Technet which shows how to create a custom SMTP recipient who you can then force to be delivered as plain text. It works like this on SBS:

  1. Open up Server Management Console
  2. Expand "Advanced Management"
  3. Expand "Active Directory Users and Computers"
  4. Expand your domain (ie: foo.local)
  5. Right click on "MyBusiness"
  6. Select New, and then Contact
  7. Fill in the name for the contact (I used the list name)
  8. Click Next
  9. Ensure "Create an Exchange e-mail address" is checked
  10. For the alias, set it to whatever you want (list name for me)
  11. Click "Modify" button
  12. Select "SMTP Address" and hit OK
  13. When prompted enter the email address of the mailing list or person you want to send to plain text
  14. IMPORTANT: Click Advanced Tab
  15. Click the "Override Internet Mail Service settings for this recipient" checkbox
  16. Select how you want it delivered. I selected "Plain Text/UUEncode"
  17. Hit OK

At this point you now have a contact that will ALWAYS deliver in Plain text for you, even if you use OWA.

Microsoft, could you PLEASE add a simple "Send in Plain Text" option in OWA contacts in a future release? PLEASE!?!?

Until then, this configuration will have to do.

Posted by SilverStr at 10:35 AM | Comments (1) | TrackBack

January 30, 2006

How Novell brightened my Monday Morning Mono Blues

I thought it was important that I document the interesting morning that I have had. And to show how I am only human, and just as much a liability as the next person when it comes to responsible disclosure *sigh*. I do hope you will learn from my mistakes. ALWAYS look for the security vulnerability reporting page BEFORE using regular reporting mechanisms.

7:25am: Review security audit findings from work done over the weekend.

7:52am: Talk with developer responsible for a vulnerable web service through Mono. Discuss how I was able to download the web service assembly, decompile it and extract the database password for their Oracle server. Give mitigation recommendation to use <Files> directive in Apache to prevent adversaries from accessing web service assemblies, and discuss WHY it's important to NOT store db passwords in code. Grumble about how I wish DPAPI existed on Linux to restrict access to such data.

8:15am: Contacted by client to confirm vulnerability and show product manager who doesn't believe this is possible, because their threat model said so (*groan*).

8:17am: Receive permission to exploit web service to reproduce problem.

8:19am: Perform attack against client's web service, download assembly and decompile code.

8:20am: Read Oracle password over the phone to stunned product manager.

8:22am: Point product manager to XenoCode and explain how obfuscation would be appropriate here to protect business logic that they are worried about.

8:31am: Finished explaining why buying Writing Secure Code, Second Edition for their entire dev team would be a good idea. Understanding how to learn from this incident is just as important as they reflect on how their threat model failed to catch the password problem.

8:35am: Think to myself... maybe I should get into the business of consulting on threat modeling. Then realizing I have a mortgage to pay, and not enough time in the day to educate clients on why threat modeling properly matters, get back to work.

8:45am: Client calls back happy. They took my advice and applied the <Files> directive into the Apache config on their production server.

9:14am: Finished contacting two other clients who have the same problem.

9:24am: Went to Mono site to report vulnerability. Cannot find any information on reporting security bugs. Report bug using Bugzilla, believing unconfirmed bugs are private. WRONG.

9:25am: Quick panic sets in. I realize my bug report (Case 77406) is public for the world to see. Not good. The last thing I want is some script kiddie who is watching Bugzilla for new bugs to prey on such information.

9:36am: Email mono@novell.com to inform them of the bug report in an effort to get a resolution, or the bug pulled from Bugzilla until someone can look into it.

9:40am: Realize Mono is supported by Novell and hunt for their security vulnerability report form. Report incident to Novell directly.

9:54am: Receive response from Platform Security & Mono Team, escalating this to the appropriate people.

10:15am: Bug report RESOLVED by Mono team as a known vulnerability fixed only a few days prior. Talk about good karma. Please see the end of this post on how to fix this issue.

10:17am: Received response from WSS Security Alerts team that they will get in contact with the right department.

10:18am: Respond to WSS Security Alerts team and inform them that the Mono guys have resolved this already, and everything is ok now.

10:32am: Email Mono team asking if I can blog about this, or if I should wait until the fix is more readily available.

10:34am: Realize that now that the vulnerability is in public (thanks to me DOH) that I should consider telling at least the Mono lists.

10:54am: Receive go ahead from Mono team. Given the option to blog about the fix, or wait until the upcoming release which fixes this.

11:00am: Decide its more important to mitigate against this issue NOW, rather than wait until the next release.

11:01am: Blog, blah blah blah.

As you can see, its been an eventful morning. I was extremely satisified with how quickly everyone was in responding to this. I had one low "level one" support person at Novell who couldn't get what I was trying to do when I gave them a quick call (wanting me to pay to talk to an engineer), but I found the email went around much faster anyways. I found the Mono team and Novell to not only be responsive, but quite responsible while I ran around yelling the sky is falling. That's how responsible disclosure is SUPPOSED to work.

So on to the information for the vulnerability that I found.

Vulnerability: The default configuration for Mono and Apache allows an adversary to download the web service assemblies directly. This allows for a potential information disclosure vulnerability as in most cases, these assemblies are NOT obfuscated, giving you complete access to the source code with tools like Reflector. What SHOULD occur is that a "403 Forbidden" message be sent, as it is in Microsoft's .NET implementation on IIS.

Resolution: The official fix for this is to modify the machine.config (typically stored in /etc/mono/1.0/machine.config) and add the following line inside the <httpHandlers> section:

<add verb="*" path="*.dll" type="System.Web.HttpForbiddenHandler, System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

This fix has been added to the master sources (HEAD) of mono and backported to 1.1.3. It should be available in an upcoming release of mono.

Many thanks to the Mono team for being so quick to respond. I apologize for using Bugzilla when I REALLY should have used Novell's security report form. Perhaps I could recommend you put a link to it on your website?

Damn those Monday mornings. *sigh*

Posted by SilverStr at 10:54 AM | Comments (1) | TrackBack

January 29, 2006

Sunday Chuckle - I've actually been here!

Posted by SilverStr at 07:40 AM | Comments (1) | TrackBack

January 27, 2006

Code Scanning Tools Do Not Make Software Secure

Michael Howard has an excellent post on how code Scanning tools do not make software secure. I think he had an interesting formula that sums it up:

"Not-so-knowledgeable-developer" + great tools == marginally more secure code

Running static analysis tools won't alone make your code secure. But its a great asset in your arsenal of tools to use alongside of secure programming principles and practices.

I think he hit it out of the ball park with this comment:

Creating secure software requires having an executive mandated, end-to-end process requiring on-going education, secure design based on threats, secure coding policy and testing policy, penetration and fuzz testing focused on new and old code, a credible response process and finally a feedback loop to learn from mistakes.

Yep. That's exactly it. Security is a process that has to have buy in from the top down, all the way from the CEO to the junior programmer. It has to be part of your software development lifecycle and has to accepted by all.

But great tools don't hurt!

Posted by SilverStr at 12:41 PM | Comments (2) | TrackBack

January 25, 2006

New blog worm in the wild


Blog.Worm

Posted by SilverStr at 12:13 PM | Comments (5) | TrackBack

January 20, 2006

How to get more out of your Windows Firewall

So have you ever wondered how to tell if your Windows firewall is working? Ever notice that there is no information really telling you what is going on? Why not turn on the logging facilities for the firewall so you can see dropped packets and allowed connections?

To enable logging of dropped packets:

netsh firewall set logging droppedpackets=enable

To enable logging of connections:

netsh firewall set logging connections=enable

If you want to see the firewall configuration for logging:

netsh firewall show logging

There you have it. Turn it on and you will now be able to look at the log (default %windir%\pfirewall.log) and do your bidding.

Update: Fixed type in cmd line option for logging. Thanks Tom!

Posted by SilverStr at 12:25 PM | Comments (4) | TrackBack

January 19, 2006

Mark debunks Steven Gibson's claims that WMF issue is a backdoor

Over at SysInternals, Mark has debunked Steve Gibson's theory that Microsoft intentiionally placed a backdoor in WMF. His results conclude:

In my opinion the backdoor is one caused by a security flaw and not one made for subterfuge.

You can read Mark's analysis here. He goes into great depth into analyzing Steve's theories and providing detailed information on what is really going on.

Good work Mark. Steve.... where is your retraction?

Posted by SilverStr at 08:46 AM | Comments (1) | TrackBack

January 18, 2006

Kewl... Microsoft's User Account Control (UAC) people are blogging

I fumbled over something interesting today. Apparently the User Account Control (UAC) people (the guys doing the neat LUA/UAP in Vista) are now blogging. You can check them out over at http://blogs.msdn.com/uac/.

There isn't a lot of content up there yet, but I am hoping to see some interesting stuff out of that group. With talk about LUA today, I thought maybe some of you would be interested in subscribing to their rss feed. You can do that here.

One thing I did find interesting is that they are working on some guidance for "Developer Best Practices and Guidelines for Applications in a Least Privileged Environment" on Vista. Interesting read.

Enjoy!

Posted by SilverStr at 05:01 PM | Comments (0) | TrackBack

Microsoft releases new LUA whitepaper

A couple of months ago I was asked to be part of a team that was reviewing a new whitepaper from the Microsoft Solutions for Security and Compliance group (MSSC) on "Applying the Principle of Least Privilege to User Accounts on Windows XP". Microsoft has released it today and you can download a copy of the paper here.

If you want to read it online, you can read it here.

If you ever wanted to better understand how to run with least privilege on Windows XP, this is a great introduction. Furthermore, there are some good links to more technical articles which can go even deeper if you like.

Happy reading!

Posted by SilverStr at 02:31 PM | Comments (0) | TrackBack

January 15, 2006

Is the NSA snooping your email? Wanna find out?

Have you ever wanted to know if the NSA is spying on your email? How about a co-worker? I learned an interesting technique from Richard M. Smith on how you can easily find out.

If you have access to a website server logs, and can create new content, then it is rather simple to do.

  • Create a UNIQUE URL that is not linked from ANYWHERE that only you know. Or better yet, DON'T create it and let a 404 be generated. (Thats what I do)
  • Place it in an email, making it interesting enough that a person may go look at it.
  • Write a quick script or filter that will search the access and/or error logs for this unique URL and schedule it to run every hour/day etc. In a worst case scenario just do a grep against the log for the URL.
  • Have the script email you if it ever finds a match, including the SourceIP of the connection so you can backtrace it to see WHO is snooping YOU.

Now that you know your wife is reading your email, you can worry about black helicopters and the supression of freedoms in your country. The NSA has billions of dollars of computers searching through transmissions looking for key words, patterns etc through their old Echelon systems. If you want to see if you can trigger it, take the above steps but add a few before that:

  • Create a web account with Microsoft Hotmail or Google gmail. (Or some other US based server)
  • Set up a second account with an email server with a non-USA provider. Richard recommended Rediffmail.com
  • Have your email include some various terrorist triggers (keywords) or content that may seem harmful the the USA. You can google for "NSA Echelon keywords" for some examples of keywords the NSA has used in the past. Use your imagination to think about what would interest the NSA these days. You know... phrases like "Bin Laden wants to kill the imperialist pig-dog George W. Bush with a dirty bomb of VX gas". (p.s. Hello NSA op who has been forced to read my blog entry today. Nice to see you too.)

Now, in case you don't realize this, you may be playing with fire. I HIGHLY suggest you don't use your own production servers for these tests, unless you would like men in black suits with sunglasses and Glock specials knocking on your door. But you can have some fun with this. A few of us have been running a little contest since the beginning of the New Year. I am currently in second place with 3 hits so far. I have an unfair advantage though. The NSA servers have spiders that have been going through my blog, rss feeds and personal servers for years :)

YMMV. Have fun with it.

Posted by SilverStr at 07:57 AM | Comments (3) | TrackBack

January 10, 2006

Eric has an update on Brett'sforay into blogging

Eric was so kind to give us an update on Brett's foray in to the blogging world.....

Posted by SilverStr at 09:12 AM | Comments (0) | TrackBack

January 05, 2006

WMF Issue to be fixed today with release of GDI patch early

It seems Microsoft is ready to release to patch early. Instead of next Tuesday, the patch will be available for download TODAY sometime after 2 pm.

The security bulletin (MS06-001) is already published and available here.

Congratulations to Microsoft for releasing the patch when it was ready. Like most people I was expecting it next Tuesday. The fact that QA gave it a thumbs up and you are pushing it out sooner is a good decision. Many security professionals were warning and hoping that the patch would be deployed before any major attack was introduced to the Net. Seems like this early release may thwart some of the PoC code in the underground that was building up to be that next major attack.

Make sure you test and deploy these patches soonest.

Posted by SilverStr at 12:10 PM | Comments (0) | TrackBack

January 04, 2006

Hold on to your hats. The sky is falling. Guess who is a Microsoft Windows Security MVP?

With the bad weather outside already thundering and lightening, I must admit that the freakish storm outside was a precursor to what just hit my email.

Guess who just became a Microsoft Windows Security MVP? Thats right. (*Lightening flash with loud thunder abound*) Apparently I am a Security MVP.

RUN. RUN NOW. NO ONE IS SAFE.

OK, ok. Fun is over. So I heard something about this last year, but I didn't believe it. Who would have thought that Microsoft would award me with an MVP. I need to thank people like Robert and Susan, who I am sure had something to do with this. I think this is Robert and Susan's secret way to take over the world, but I am not quite sure yet. I am too scared to pop my head outside to see if the storm has stopped, so I can get off this ride.

So what does this mean for me and this blog? Absolutely nothing. Nothing is going to change. I made it clear that my opinions won't be swayed because of this. And the response I got from Microsoft and other MVPs was awesome. They agreed. And said its outside parties like me that keeps them honest. And keeps them working. Now the only difference is... I can email them privately and chase them down at the MVP Summit.

God help us all.

Posted by SilverStr at 04:09 PM | Comments (9) | TrackBack

Give Microsoft a break already! The WMF patch SHOULD be out next week.

OK, this is nuts. I am quite saddened by the state of this latest WMF problem. Actually, I am more vexed at how irresponsible some security professionals seem to be in rushing to make recommendations that just don't make sense.

Listen up. Security is about risk mitigation. NOT risk avoidance. That means that technical safeguards being deployed in an organization should mitigate against risks to get within acceptable tolerance levels WITHOUT exposing the business to new risk, or lost productivity. Now, combine that with the fact that every organization's risk tolerance levels will be different, its quite clear that blanket statements simply don't make sense. And now we are seeing security professionals back pedal their statements as they start to see the repercussions of their recommendations.

If ANY security professional recommends that you install an unsupported and untested security patch on your system, RUN. RUN AWAY. And don't look back. You don't want them near you. It is INSANE to blindly put security patches on a system without them being thoroughly tested first. No matter HOW GOOD the programmer is. Even if he is a kernel god (Which Ilfak Guilfanov is. I am a big fan of IDA).

Look, let me let you in on a little secret that Steve Gibson is now sharing with the world. Microsoft has had a working patch to the REAL vulnerability (the one in GDI32.DLL) since back on December 28th. This means they were on TOP of the problem and had a fix almost immediately. The question you are probably asking yourself is WHY then wasn't it deployed. And the answer is... they wanted to test it first. And god bless them for making that decision.

Why do I say that? Well, people are now seeing that the UNOFFICIAL patch from Ilfak is actually causing printing problems for some users. It seems some postscript drivers use the very code that the patch turns off. On the Full Disclosure list, there is a good explaination of how this could very well be happening. And without ANY testing of the patch, now people are finding they can't print. Whoops.

Its funny that people are screaming at Microsoft for not being faster to fix this. In my post on The Cost in Fixing Bugs and How Irresponsible Disclosure doesn't Help the Matter, I brought to your attention the fact that a single change has a tonne of test cases that have to be checked against. And it has to be tested against every version of Windows in every language. Quite frankly I am rather impressed that they were able to get it into the regular patch Tuesday as quickly as they did.

So in the end, wait for the official patch. And when it is available TEST IT on your own test systems before deploying it to your production systems. VMWare/Virtual PC are perfect tools for that. Ensure it works on your business systems BEFORE you go and deploy it. And that should be for any patch. Direct from the vendor or not.

Posted by SilverStr at 11:32 AM | Comments (9) | TrackBack

January 02, 2006

Book Review - .NET Web Services: Architecture and Implementation with .NET

So over the holidays I had a chance to read .NET Web Services: Architecture and Implementation with .NET. For someone still relatively new to web services, this was a great book. It brought me up to speed on life, the universe and everything SOAP. At one point I almost wanted to go and make a SOAP system using SNAIL mail as the transport. (You could actually do that! Why you would want to is another matter... and requires a bit of history and humour which requires more beer then I have in my house right now. Jeff will know what I am talking about)

Anyways, I liked the book. It really brought me up to speed on the topic, and I was able to write my first web service immediately after that. It was an extremely easy read, and I was done it in less than two days. However with that said, I have to point out an amazingly glaring problem with the book.

It needs an entirely NEW book for the errata for all the bloody botched code samples! Quite frankly, I have to wonder if there was a technical review of the code at all in respect to the content it was supposed to show. Confusion abound when code samples don't actually match the screenshots, or worse yet, actual WRONG code. And the discussion about getting the errata on keithba.net is kinda useless when the domain isn't even in use anymore. A domain dying in 2 years after publishing isn't very good.

I was hoping for a lot more in the WS-Security arena. Although it is covered, I found it was quite lacking in useful samples on how we can secure our content. Can't blame the author for this though, as it really is a topic that needs its own book. I will have to find such a book on WS-Security as that is what interests me the most out of the potentials with SOAP envelopes.

All in all, still a great book. Even with the botched code samples, its easy to pick up what is being said, and what the intent is. And I finally now understand XML serialization the way it is intended. In no time I was consuming web services in Microsoft Sharepoint through ASP.NET and writing web services in Mono on Linux.

Good book, worth the read. If you know of any good books to recommend on WS-Security, could you please email me or leave a comment here? Thanks.

Happy reading!

Posted by SilverStr at 05:54 PM | Comments (1) | TrackBack