From: sockz loves you To: full-disclosure@lists.netsys.com Subject: Security Industry Under Scrutiny: Part One Date: Thu, 07 Nov 2002 05:12:33 -0500 Hello Full-Disclosure. It has been some time since I last posted here. Please forgive my neglect. I see that in my absense this whitehat shit has grown, those few of you who had seen the errors of your ways have been replaced by morons who still don't understand what is wrong with the security industry. In a way this is bad, in that this list is being used for evil again. But in a round-about way, I also see this as being a good opportunity to enlighten the masses some more. Thus, I give you today's post. It is the first in a series of posts I have chosen to title "Security Industry Under Scrutiny". I have no intended life span for this series. It will go on as long as it has to. Today I write about the misconception that whitehats do good for the community. I do this by breaking down a recent post to the full-disclosure mailing list from a K.K Mookhey (cool name dude where'd you get it?). At the end I make some suggestions and throw about some ideas as to how the future of the security industry can be saved if we change our ways now. ----- Original Message ----- From: "K. K. Mookhey" Date: Sat, 2 Nov 2002 13:08:33 +0530 To: , , , , Subject: [Full-Disclosure] Weak Password Encryption Scheme in MS SQL Server > ================================================= > Advisory: Weak Password Encryption Scheme (Modified) in MS SQL Server > Software: SQL Server, All Versions > Severity: Low > Vendor: Microsoft, http://www.microsoft.com > Type of Vulnerability: Weak Password Encryption > Author: K. K. Mookhey (cto@nii.co.in) > Company: Network Intelligence India Pvt. Ltd. http://www.nii.co.in > Date: 2nd November 2002 > > Original Discovery: David Litchfield http://www.nextgenss.com > Original Paper: http://www.nextgenss.com/papers/tp-SQL2000.pdf > ================================================= We start off with a short analysis of the basic details of the bug. The date it was released. The kind of system it affects. Take note of the last two lines, and see that this bug is not an original concept. Few vulnerabilities that are disclosed to the security industry are entirely original. In fact, a lot of the "tools" produced by whitehats are built upon concepts that were found by others. Of course each post often goes in a different direction to the original version, but for the sake of today's post, let's just say that without other whitehats many whitehats couldn't come up with their own stuff. > Description: > ========= > MS SQL Server has two means of authenticating users. One uses Windows > Authentication, and the other is the built-in SQL Authentication (which > includes the 'sa' account). The passwords for the SQL Authentication are > sent over the network using a very weak password encryption method. This was > first mentioned in David Litchfield's paper "Threat Profiling Microsoft SQL > Server". > > Details: > ====== > In his paper, Mr. Litchfield states that the password is encrypted by > first converting it into UNICODE and then performing a simple XOR operation. > I quote directly from there: *snip* blah blah blah I could have read this in a book if I wanted to know about it. Thankyou for encouraging me to be lazy. *snap* > However, there is a slight inaccuracy in this description which we detail > below. We have determined that the actual XORing method involves an > additional step. > Step 1: Password is converted into UNICODE > Additional Step 2: For each byte of the password, the four Most Significant > Bits (MSB) > are swapped with the four Least Significant Bits (LSB) > Step 3. This modified byte is then XORed with 0xA5. > > In the case of the alternating UNICODE 0x00, swapping the 4 MSB with the 4 > LSB does > not make a difference. But for the rest of the bytes, it does. This is the main part of the advisory, the part where the whitehat tells everyone what they've found. Note the easy to follow steps/instructions that could be followed by a four year old (well, one who understands unicode). I should point out that between snip and snap there were 13 lines of text. If you compare the actual advisory to the amount of noise around it you see a line ratio (crap : useful stuff) of 81:12. Astonishing huh. I plan to do more work with this ratio, and see if this kind of number holds true for other advisories. If it does then we can assume that roughly 80-90% of the security industry is pure noise. Which makes sense if you see all whitehats as loud mouthed scene whores, "Oooh! Look what I did! Everyone look! Aren't I so great!!" Trust me folks, the security industry is pretty much useless. > Vendor Response: > ============= > We did not contact the vendor, Microsoft as this is not exactly something > new. However, we did contact Mr. Litchfield informing him about the slight > modification to his original statement in his whitepaper. We did not receive > any response from him. > > Suggested Workarounds: > ================== > There is nothing new to be done here, other than that which ought to be done > when hardening an MS SQL Server. Do NOT use the SQL Server Authentication. > This is strongly recommended by Microsoft. Why didn't the whitehat contact the software vendor? Isn't the software vendor the only one who can actually update the product's code? Yes? Yes. Did the whitehat simply assume that the vendor would eventually find out, maybe via vuln-dev or maybe a programmer for Microsoft will find out over a casual lunch with a friend. If this vulnerability is nothing new then why bother posting it? For scene status? The recognition that the security company can tear apart the work of others and act in a destructive manner towards the vendor? The last two lines of this section hint at a hatred for Microsoft's products. Is this justified? No. How can Microsoft produce a secure SQL Server Authentication system if they are not informed of the problems with it? I'm sure the company would love to hear about how they could improve their products. It would be a damned sight more considerate than going around seeing how the product could be destroyed. I think this section speaks for itself in many ways. > > Note: > ==== > This is more of an FYI Advisory. Just to keep things a bit more accurate. > > > Other Information: > ============== > This advisory is available online at http://www.nii.co.in/vuln/sqlpass.html > We have used this method in our free tool 'forceSQL' which guess SQL Server > Passwords using both Dictionary and Brute Force attacks. This is available > for free download at http://www.nii.co.in/tools.html > You may read our Vulnerability Disclosure Policy at > http://www.nii.co.in/vdp.html > Other advisories are at http://www.nii.co.in/research.html > *snip* This part of the advisory was what disgusted me the most. Not only did these security "experts" not bother to inform the software vendor, they also offer a password cracking tool for those ppl who don't know shit about computer security. In doing this they've said, "Hey, script kiddies, we realise you are dumb and won't be able to write anything yourself to compromise the security of another system. So we have written something for you." Why would a security organisation write a program that allows systems to be compromised? Is this not the very anti-thesis of security (the idea of a safer society)? Yes. Yes it is. This organisation offers tools for script kiddies to hack systems so that admins around the cyber-planet will be forced to patch. Forced to invest more money in the security industry or be punished. And you know what, those admins won't be any more secure for all the money they spend. Hell no. With the rate at which bugs are disclosed to the greater community and the rate at which organisations like Network Intelligence India release hacking tools for script kiddies, no system is EVER going to be truely secure. If it were, then companies like NII would go out of business... I guess its good business-sense to be destructive. Sickening thought isn't it. That the security industry seeks to destroy that which it is supposed to heal. So what can we do to change this? Well for starters, don't post your bugs to public forums. Contact the vendor directly. If the vendor is serious enough about their product then they will address the issue by the next patch. If not then their product is probably not worth the investment. Secondly, stop producing cracks in the guise of "network assessment tools". Its bullshit. Those 'tools' are 'toolz' which will only be used by script kiddies to attack those systems that are not quick enough to be secured. In this case, anyone who uses SQL authentication is at potential risk. You KNOW that this is the case. You KNOW that script kiddies troll through these posts like fossikers looking for gold. And you KNOW that even if _one_ script kiddy finds this information before _all_ admins have patched their systems, then there is a greater security risk than when the bug was unknown. You KNOW this is the truth. Do not kid yourselves. Lastly, if you can't do the above two without losing your job then you know that you're not working for the greater good of security. You're working for the capitalist machine, and that as a drone for this system you are contractually obligated to be sneaky, underhanded, deceitful, and misleading when it comes to dealing with your clients and with society in general. People like this are the scum of the earth. They're like the ppl who spit in your burger at McDonalds, or the ppl who change the expiry date on meat products in supermarkets so they can still be sold. The security industry, as it stands, cares more about money and keeping its high level of importance to the commercial world. This needs to change. If security is ever going to be the central focus then we need to stop worrying about job security and start worrying about computer security. Don't support the public disclosure of vulnerabilities. It is a misconception. Don't support whitehats. They are liars. Stop being a whitehat and convert to black. <3 sockz