> From: J. Tozo > Sent: Friday, January 23, 2015 1:52 PM > > So you saying if I bruteforce a CAS server with a common password list and > achieve an authentication within the user h*. that is not a authentication > bypass?
Yes, that is exactly what I'm saying. > nice, in your world maybe. Actually, I believe any competent security researcher or analyst would agree with me. Please feel free to find one who does not and reference them. So from your perspective, if I go bruteforce gmail with your address [email protected] and a password list, and eventually determine your password, then access your mail with your password that I have discovered, I have "bypassed authentication"? That is ridiculous. When you bruteforce an account, and then access it using the credentials you have discovered, you are actually performing authentication with those credentials, not bypassing it. Bypassing, if you would bother to read the definition I provided, inherently involves something not occurring, being routed around, or avoided. You're not avoiding authentication, authentication is certainly not occurring. You are *performing* authentication with valid credentials, regardless of how you obtained them. And the chances of you being able to exploit this issue using the username "h*" are infinitesimally small, as there would have to be one and exactly one account that starts with an h, as if the wildcard matches multiple accounts authentication fails. So yes, this issue does allow you to potentially specify less than an exact username in an attempted authentication. But given the limitation that the wildcard must match one and only one account, you need to know so much about how the usernames of the entity being attacked are distributed it provides minimal excess leverage over a plain jane brute force attack using actual usernames. > You can cry, kicking around, panic, call me incompetent or whatever ad > hominem you want Actually, I am writing clear, grammatically correct, and well presented logical arguments and analysis making my case. It is rather you who are projecting the image of a child in a tantrum beating their hands and feet on the ground because someone has the audacity not to agree with them. > this still is an authentication bypass. No, it is not. And if you want to make anybody believe it is, you're going to need to do more than just keep crying "Yes it is! Yes it is! Yes it is!", you are going to need to present an actual analysis and logical argument demonstrating how this vulnerability meets the security industry standard understanding of bypassing authentication. You haven't done that, and you won't be able to do that, because it does not. > If you dont agree, > ask the dev team to rollback the update That would be silly. I've never once claimed this was not a bug, nor that it did not deserve to be fixed. It absolutely is a bug, and I wouldn't even argue it is not a security bug. However, it is a minimal issue with minimal exposure and little vulnerability in practice. It did not deserve being treated like a critical issue requiring immediate attention. > and ask mitre to revoke the CVE. I suppose I wouldn't even argue it doesn't deserve a CVE, at least if the description were accurate and actually contained an analysis of the underlying issue. But a CVE attached to your drivel? That probably should be revoked. > And last, this flame will lead us to nowhere, haters gonna hate and i will > not feed > this troll anymore. Nothing will make me more happy than if you stop beating this dead horse and wasting my time. You wrote a poorly constructed inaccurate CVE with minimal analysis and an artificially inflammatory title that resulted in a rushed security announcement mischaracterizing the vulnerability. Deal with it. Try to do better next time. Also, I'd have to care about you to hate you ;), so drop the persecution attitude. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | [email protected] California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
