Posted on 08/26/2005 6:31:03 PM PDT by Bush2000
Firefox's 'retreat' ensures Microsoft excels
Open source web browser Firefox has lost the momentum it has steadily gained since it was unleashed last year, according to Web analysts at Net Applications.
The online portal’s unique Hit List service reveals a slump in the Mozilla browser’s market share, falling from 8.7% to 8.1 % in July.
Coinciding with its demise, was the advance of Microsoft's IE that has gained some of the ground surrendered in June, climbing back from 86.6 % to 87.2% last month.
The revival for the dominant browser comes on the back of average monthly losses of between .5 to 1% for Redmond, as Firefox started to gain acceptance among a wider audience than just tech-savvy users.
When asked by Contractor UK whether Microsoft’s sudden gains were from the unveiling of a new IE, Net Applications said a re-launch tends revive industry interest, and could have bolstered Microsoft’s market share of the browser market.
When a company launches a new product, there is always renewed interest in what the company has produced and it would also be fair to say that this may have had an effect, said a member of the Hit List team.
Although, there have been browser issues with Windows 2000 in the news, so it is possible that again you may see a dip [in Microsoft’s market share]. Right now, people are looking for security and whenever there are issues with the security of one's system, they will use what they feel will be the most secure.”
Besides Net Applications, web developer site W3 Schools, confirms that adoption of Firefox is falling, just as IE is reaching its highest share of the market in 2005.
According to W3's data on specialist users, Microsoft IE (6) enjoyed a 67.9% share in July, improving to 68.1% in August matched against Firefox’s top share of 21% in May, which has now dropped to 19.8% for the last two months.
Observers noted that both sets of analysis concur that Microsoft’s loss, up until now, has been Firefox’s gain, but over the last month roles have reversed.
Security fears concerning Mozilla and its browser product have recently emerged, coinciding with Microsoft’s high-profile trumpeting of its new safer browser product (IE 7), complete with glossy logo.
Experts at Net Applications said they were surprised at Firefox’s sudden retreat, saying they expected a slow down before any decline.
Yet they told CUK: “Whenever there may be problems with security, there always is a decline with users changing browsers.”
Data from the Web analytics company is based on 40,000 users, gleaned from their global internet operations, prompting some commentators to question the so-called ‘global decline’ in the Firefox market share.
The Counter.com reportedly finds that between June and July, Firefox actually increased its share by two points, and overtook IE5 for the first time ever.
The Web Standard Project suggests webmasters should treat data from web analysis providers with caution, before rushing to make service changes.
So what can we conclude?” asks the WSP, a grass roots project fighting for open access to web technologies.
“Not much: Mozilla-based browsers are probably used by just under 10% of the web audience and their share is growing slowly. IE5.x is probably used by somewhat less than that and its share is declining slowly. IE6 is roughly holding steady.”
Meanwhile, Spread Firefox, which measures actual download rates of the browser, reports that it took just one month for the Mozilla Foundation’s showpiece to reach 80 million downloads in August – from its July total of 70 million.
At the time of writing, Firefox had been downloaded 80701444 times, meaning adoption rates of over 10m occurred one month after Net Applications says Firefox bolted in light of the dominant IE.
Maybe Linux is doing a different type of salting then I'm familiar with. I thought salting was like this: SALT + Password = hash All you do is you put the salt unique id with the password (beginning, end, middle...wherevever). Then you make a hash out of it. You don't need to know the salt. as the entire salt+password is hashed. once you break the hash you now have the salt+password.
I understand. I'm also not trying to say that Linux is invulnerable (heck, with physical access, I can get into almost any Linux system inside of ten minutes). But with salting, I don't believe that Rainbow can be used to crack its passwords.
I said... There's also buffer overflows, sql injections, and input validation errors which can get you to run code on a box.
"Really? So on a fully patched box you can execute these types of attacks. Impressive indeed. So Impressive, I don't believe it."
SQL injections are most often present in web applications, though i've also found them in binary client/server apps. I've been able to do things liks steal the user/password database table for an app through the "lost password" dialog box... on a fully patched system without compromising the system. This was entirely through an input validation failure in the web app.
I've done similar things with client/server apps. While the binary client might validate user input, the server did not - it relied on the client. Using an ethernet sniffer like tcpdump or ethereal to understand the application protocol in use and a command line tool like ngrep, i could intercept and modify the client/server communications stream, inserting stuff that the client would not normally allow you to do. This bypasses client side input validation, and lets you submit arbitrary strings to the server. Again, input validation issues that might include things like remote command execution or sql injection.
The level of privilige you have for sql injection is dependent on the user context that the query runs as. You'd be surprised how often web apps in internal environments use the SA account out of laziness.
"Explain to me one buffer overlow you can exploit on a fully patched box? If you can't my bet is GE was right about you."
OOOOOOh. If he was, it would be the first technical thing he was ever right about.
Buffer overflows on a fully patched box? That would be the exploit that the vendor doesn't know about, or one that they haven't patched.
Even in environments with "fully patched boxes," it's hard to keep everything up to date. One time I did a pentest and every box was patched... except for a kiosk in the lobby that had been plugged in for patches months ago, never unplugged, and was not part of the normal patching routine. They just didn't know it was still plugged in. It was a somain member, I compromised it, and used it to take over the rest of the domain.
Right now I'm doing an assessment for a fortune 100 company. They have excellent patching procedures, strong policies, strong controls.... and still, there's always a way in, because their network is so big. They have to be perfect every time... I have to get it right once.
My understanding of Rainbow is that it uses the entire string as the password. It assumes there is no salt. It will then find a string that hashes into the hash it is given. It will then return this as a password. The key to this is that it assumes no salt is given. Also, you, as a breaker, would not know how long the salt string is. Rainbow is producing a password based on a 12-char password, rather than a 4-cahr salt+8-char password. It doesn't know to look at only the portion of the given hash to produce a portion of a password.
Aren't you the same guy that hit the abuse button for GE calling you an idiot and twisting what you say? And you say that would be the first thing he was right about.
You're very immature and need to learn not to where your feelings on your sleeves. How does putting GE down and saying something false like that make you feel good about yourself?
It adds an extra dimension of difficulty in cracking the hash. If all the salts on a system were the same, then a general lookup table would just have to be that much bigger. Probably still possible with a really big hard drive.
But each salt for each user is usually different, so now you have to up your table size exponentially yet again (2.8*10^14 times each hash entry already there), and your storage requirement is probably into the petabyte range or beyond. Basically, now Rainbow Crack would be trying to crack a 22-character password.
Salts don't protect against brute-force calculation attacks (as opposed to lookup attacks) where the cracker has the password file. In that case he knows the salt and can concentrate computer time on cracking a specific password. But that still takes a while.
Or just listen to the wire and get the hash and then crack? According to antiRepublicrat it's nearly fool proof. Also since you get paid for this, you can charge the $500 for the hash table to the client.
I prefer John the Ripper. Used to use crack, but I gave it up. ;)
It's a classic dictionary brute force.
You encrypt the dictionary one word at a time, and compare the hashes. The chance of collision is so small that when you match hashes, you can be sure you've found your password.
Rainbow supports a precomputed has database, which can speed this up immensely... no need to re-encrypt on the fly, you just compare to the DB.
Windows hashes of short passwords (6 chars or less) are especially vulnerable, because the LM Hash is stored in 2 pieces of 8 bytes each (pretty sure it's 8, not worth looking up for the point of this convo). If you use a short password, someone only has to crack half as many bytes. (A 7 byte password is strong, because there are 2 bytes of padding added, making the total stored length 9 bytes.)
Oops!
Where's your 1? Your virus wasn't a virus, and not even in the wild. It was just a possible exploit that could not travel beyond the LAN even if it could replicate itself to other computers (and what would be the point, you're already capturing all the updates on that LAN).
It salts the hash; therefore, Rainbow Crack won't work on it.
But this is what you said. And it was in a discussion around windows with strong passwords. As I said salting does make the password stronger, but so does increasing the password length. So saying windows is more at risk is bogus. Salting allows admins and users to be lazy with passwords because it makes them stronger without user intervention.
My review of Rainbow Crack looks like it's a brute force method to crack. Not a dictionary attack; therefore, Linux hash is at as much risk as a Windows hash.
"Aren't you the same guy that hit the abuse button for GE calling you an idiot and twisting what you say? And you say that would be the first thing he was right about."
Thats not an insult, it's an observation.
GE has a long history of making incorrect technical statements. That's what I was referring to.
Besides, I took that challenge as stated in that post, no parsing of words, you did not state the challenge was conditioned on the content of previous posts. I also did not commit myself to an undefined challenge of yours, only attemted to define one before anyone should take it.
So I'll give you 0, me 1/2. I'll be nice and still give up half since you did not correctly state the challenge you intended to give. Although I won a challenge as clearly written, I did not win one as intended, so it is a somewhat shallow victory.
Actually a collision is also a match. It doesn't matter what the password is just that the hash needs to match. So if you hit a collision you in essence have a working password.
My 1 is that you can't point to on buffer overflow today that can be exploited remotely on a fully patched windows box.
"Why waste your time trying various clients? Why not just take the server's hard drive out and get the hashes and then attack them with Rainbow Crack?"
It's in the context of doing an enterprise security assessment, which also takes policies and procedures into account, or in the context of a pentest, which is to get an idea of the networks security posture at a point in time, compare against their standards and best practice to find the gap, and give them a roadmap to fix the delta.
"Or just listen to the wire and get the hash and then crack?"
Done that. Most networks are switched which can make it a little more difficult, but not impossible using various ARP spoofing techniques.
"According to antiRepublicrat it's nearly fool proof. Also since you get paid for this, you can charge the $500 for the hash table to the client."
Rainbow is pretty fool proof.
Other thing that makes Windows LM passwords easy to crack is that you only have to crack half the password at a time, since it's stored as 2 discrete 8 byte hashes...
Actually I'm taking back the 1/2 point because I clearly did discuss physical security on the box. And you never asked for full details of the challenge. So you lose having accepted the challenge (even though you didn't know the full scope) and you can't provide a buffer overflow that can be exploited remotely.
"Actually a collision is also a match. It doesn't matter what the password is just that the hash needs to match. So if you hit a collision you in essence have a working password."
True, but the chance of finding a collision where the password is NOT the actual cleartext password is miniscule. It's even smaller if you limit the number of non-matching collisions to dictionary words and variations.
I always thought it was the more eyes on the code allows the black hats to exploit your system.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.