How might this source be exploited?

How might this source be exploited? - Printable Version

+- Sinisterly (https://sinister.li)
+-- Forum: Hacking (https://sinister.li/Forum-Hacking)
+--- Forum: Website & Server Hacking (https://sinister.li/Forum-Website-Server-Hacking)
+--- Thread: How might this source be exploited? (/Thread-How-might-this-source-be-exploited)

Pages: 1 2

RE: How might this source be exploited? - Equinox - 03-19-2015

(03-19-2015, 01:04 AM)Dyme Wrote: Yeah when I first needed to browse the web I made my own web browser; it totally wasn't a waste of time. It's not like teams of professionals at google or mozilla could do it better anyway...

10/10 sides in orbit.

I wasn't really considering browsers, but I suppose you're right. Inspect element suffices, I seemed to have overlooked it.

RE: How might this source be exploited? - Dyme - 03-19-2015

(03-19-2015, 01:10 AM)Equinox Wrote: 10/10 sides in orbit.

I wasn't really considering browsers, but I suppose you're right. Inspect element suffices, I seemed to have overlooked it.

Lmao I was just using web browsers as a hyperbolic example. What I was trying to get across was that there is no need to re-invent already highly sufficient tools that have been worked upon for years by experts; whether it be for browsing the web, or intercepting HTTP traffic (e.x. Burp Suite or ZAP). Unless you think you can do a better job than PortSwigger or OWASP, making your own knock off tool is really nothing more than a giant waste of time.

RE: How might this source be exploited? - Brawler - 03-19-2015

(03-19-2015, 01:04 AM)Dyme Wrote: Why? All the data being sent to the backend is presented in the client side source code pasted in the OP. While perhaps it may be easier to view for certain people, you will not find anything that is not already visible in the OP while intercepting traffic.

Why? Because then you can tamper with things on submission, you can more easily see what is submitted with each form.

You are right though, you don't need a proxy for this... I guess I just prefer it.

(03-19-2015, 01:04 AM)Dyme Wrote: All of these "note worthy things" are irrelevant. Yeah sure, the password is hashed before being sent to the backend... but why is that a bad thing? If anything it's better than sending the password in plain text as anyone trying to preform a MITM attack will only see the hashed pass.

As for the lack of salt, yes, we get it. He is using MD5 alone to store user passwords. Read my reply to Equinox.

It matters because it gives me questions about the application:

He is using client side code for something that is typically done on the server side.... Is he concerned about the load on the server? Is he new?
He doesn't use a framework for the hash... What other things has he hacked together?

They may not be relevant to you... But I'm a big fan paying attention to the small details.

(03-19-2015, 01:04 AM)Dyme Wrote: Now that I'm done addressing the replies in this thread:
@OP, a closer look at your backend code (Particularly 'index.php') is really needed in order to gauge whether or not you have any serious vulnerabilities. With the information given, the WORST someone can do is brute force the login as described above. If you really care to fix it, simply implement some sort of login throttling in your backend; it would only take a few lines of code.

I get the feeling that you think we are going to bruteforce logins through the application. This is not what we are saying.... What we would do in this situation is crack them offline.... At least that's what I would do.

Also... Why the hell would you throttle your "backend"? CAPCHA.... Account lockout.... These are much better options without implementing some janky workarounds.

RE: How might this source be exploited? - Dyme - 03-19-2015

(03-19-2015, 04:02 AM)Brawler Wrote: It matters because it gives me questions about the application:

He is using client side code for something that is typically done on the server side.... Is he concerned about the load on the server? Is he new?

But the check is done via index.php as specified in the form (If not, feel free to prove me otherwise). Why does the fact that he hashes the password before sending it to index.php make it any more vulnerable as opposed to if he didn't? Typically passwords are sent in plain text, hashed via php functions, and then compared to values in a database. So why does hashing the user given password on the clients end make it any less secure? The answer is no, it doesn't make a difference at all.

(03-19-2015, 04:02 AM)Brawler Wrote: They may not be relevant to you... But I'm a big fan paying attention to the small details.

I get the feeling that you think we are going to bruteforce logins through the application. This is not what we are saying.... What we would do in this situation is crack them offline.... At least that's what I would do.

Crack what offline? What the actual fuck do you plan to crack? You realize the "password" that is hashed is nothing more than user supplied input via the form, right? It's not the real password stored in the database, just the one you supply.

Code:
<input type="password" id="t3-password" name="p_field" value="" class="t3-password" tabindex="2" /> // this is where we get user supplied pass


function doChallengeResponse(superchallenged) {    //
     password = document.loginform.p_field.value; // user supplied pass is taken in this func and hashed


<form action="index.php" method="post" name="loginform" onsubmit="doChallengeResponse(1);"><input type="hidden" name="challenge" value="0a632b550ce0fa1191167179c9df10e2" /><input type="hidden" name="login_status" value="login" /><input type="hidden" name="userident" value="" /><input type="hidden" name="redirect_url" value="backend.php" /><input type="hidden" name="loginRefresh" value="" />
// from takes hashed user supplied password and sends it as a post request to index.php backend

"0a632b550ce0fa1191167179c9df10e2" was the hash value generated from the password input form, which is THEN sent to the PHP backend to VALIDATE whether or not the password is valid or not. What are you not getting here? I could submit "Brawler is a fucking idiot" as a password and all it would do is send the md5 value of that to the php backend to be checked against a database value. What "offline cracking" do you plan on doing related to that? Are you gonna crack the hash of a value you submitted yourself?

(03-19-2015, 04:02 AM)Brawler Wrote: Also... Why the hell would you throttle your "backend"? CAPCHA.... Account lockout.... These are much better options without implementing some janky workarounds.

Please read the code in the OP/learn javascript before replying to me again. You obviously don't understand what the fuck is going on.

And "throttling user logins" is a synonym for what you call "Account lockout", moron.

RE: How might this source be exploited? - whatever - 03-19-2015

Brawler just got cooked by Dyme, sorry Brawler.

RE: How might this source be exploited? - Brawler - 03-19-2015

(03-19-2015, 05:27 AM)Dyme Wrote: Why does the fact that he hashes the password before sending it to index.php make it any more vulnerable as opposed to if he didn't? Typically passwords are sent in plain text, hashed via php functions, and then compared to values in a database. So why does hashing the user given password on the clients end make it any less secure? The answer is no, it doesn't make a difference at all.

I am referring to the hashing itself... It's not something that is typically done on the client's machine. And I was eluding to the idea that a seasoned developer would not do something like that unless he had a good reason.... However, a noob might do something like that because he didn't know any better.

My response was not trying to prove that it was insecure... If you spent a bit less time trying to "big internet tough-guy" me you might realize I was saying that you can gain information about the developer by seeing little quarks like this.

(03-19-2015, 05:27 AM)Dyme Wrote: Crack what offline? What the actual fuck do you plan to crack? You realize the "password" that is hashed is nothing more than user supplied input via the form, right? It's not the real password stored in the database, just the one you supply.

...

"0a632b550ce0fa1191167179c9df10e2" was the hash value generated from the password input form, which is THEN sent to the PHP backend to VALIDATE whether or not the password is valid or not. What are you not getting here? I could submit "Brawler is a fucking idiot" as a password and all it would do is send the md5 value of that to the php backend to be checked against a database value. What "offline cracking" do you plan on doing related to that? Are you gonna crack the hash of a value you submitted yourself?

Sigh..... Two things here.

First:
Yes I realize the MD5 hash is the user supplied input and that I have provided it. However, you can't prove that it ISN'T the password that is being stored in the database anymore then I can prove it is. We both made assumptions... Lets just agree to disagree on this point

Second:
I'm not telling you to crack your own password, never even hinted at it.... My original statement was more or less eluding to the idea that you could crack these values offline in the event of a DB breach.... You were the one that brought up bruteforcing accounts through the application... Not me.

(03-19-2015, 05:27 AM)Dyme Wrote: And "throttling user logins" is a synonym for what you call "Account lockout", moron.

True... However you said "throttling the backend".

I wouldn't interpret this as the same thing.

(03-19-2015, 05:27 AM)Dyme Wrote: The answer is no, it doesn't make a difference at all.
Crack what offline? What the actual fuck do you plan to crack?
What are you not getting here? I could submit "Brawler is a fucking idiot" as a password a
Are you gonna crack the hash of a value you submitted yourself?
Please read the code in the OP/learn javascript before replying to me again.
You obviously don't understand what the fuck is going on.
moron.

I'm trying really hard not to let this turn into some "Who has the bigger dick"/"Internet tough-guy" forum bullshit, but your not making it easy for me.

I don't think any of my points were as far off as you are claiming them to be, but I am willing to concede that several of your points make sense. You seem like someone I could have some decent discussions with... But if this is how you act all the time, I severely doubt we could have any meaningful conversations.

RE: How might this source be exploited? - Dyme - 03-19-2015

(03-19-2015, 07:15 AM)Brawler Wrote: I am referring to the hashing itself... It's not something that is typically done on the client's machine. And I was eluding to the idea that a seasoned developer would not do something like that unless he had a good reason.... However, a noob might do something like that because he didn't know any better.

But the thing is, a well seasoned developer WOULD do something like this, as it's actually more secure than sending user login information in plain text. I get frustrated because I keep repeating this but you still refuse to admit your wrong:

(03-19-2015, 01:04 AM)Dyme Wrote: If anything it's better than sending the password in plain text as anyone trying to preform a MITM attack will only see the hashed pass.

It's also worth noting that if you took three seconds to actually read the code, you could see that this is actually the login form used for TYPO3, an extremely popular CMS with over 8 million downloads:

Code:
<!-- TYPO3 Script ID: typo3/index.php -->
<title>TYPO3 Login: qeep</title>
<meta name="generator" content="TYPO3 4.5, http://typo3.com/, © Kasper Skårhøj 1998-2009, extensions are copyright of their respective owners." />

So no, this isn't a "noob" programmer who probably has other flaws in his code. This is a team of professionals who run and maintain one of the largest CMSs used on the net today. Your whole point in invalid.

(03-19-2015, 07:15 AM)Brawler Wrote: However, you can't prove that it ISN'T the password that is being stored in the database anymore then I can prove it is.

But why does this "proof" even matter what so ever? The only time the user supplied password will equal the one stored in the DB is if the user logging in knows it... otherwise passwords supplied by attackers (which is what we're discussing) will NOT equal the one stored in the db, as they simply don't know it. I don't understand what you're trying to get at here.

(03-19-2015, 07:15 AM)Brawler Wrote: True... However you said "throttling the backend".

I wouldn't interpret this as the same thing.

No, I did not say that. Why quote me wrongly when you could have just went back a page? Oh, because it's clear that I didn't say that and you're trying to warp my words to make yourself seem correct.

(03-19-2015, 01:04 AM)Dyme Wrote: simply implement some sort of login throttling in your backend

I never said to throttle the backend, I said to throttle logins IN your backend (which is PHP). Just admit you misread my reply and get over it.

(03-19-2015, 07:15 AM)Brawler Wrote: I'm trying really hard not to let this turn into some "Who has the bigger dick"/"Internet tough-guy" forum bullshit, but your not making it easy for me.
If you spent a bit less time trying to "big internet tough-guy"

Yeah and you're not doing the same thing you're accusing me of doing here, right? I responded to you in that manner because I get frustrated when I have to correct people over and over again yet they still insist they're right... and I hate to say it to you, but you're not right here.

Ending this convo now as if you still decide to disagree with me it's clear you're just doing so for the sake of arguing. Feel free to respond and make yourself look like an even bigger moron, though.

RE: How might this source be exploited? - Brawler - 03-19-2015

(03-19-2015, 01:06 PM)Dyme Wrote: But the thing is, a well seasoned developer WOULD do something like this, as it's actually more secure than sending user login information in plain text. I get frustrated because I keep repeating this but you still refuse to admit your wrong:

It doesn't add security... It only adds obscurity... There is a very clear difference.

(03-19-2015, 01:06 PM)Dyme Wrote: It's also worth noting that if you took three seconds to actually read the code, you could see that this is actually the login form used for TYPO3, an extremely popular CMS with over 8 million downloads:

So no, this isn't a "noob" programmer who probably has other flaws in his code. This is a team of professionals who run and maintain one of the largest CMSs used on the net today. Your whole point in invalid.

Relatively speaking, its actually quite small.... And are you trying to say, that CMS's are inherently secure?

It would be a mistake to assume things are done correctly just because a large number of people are contributing..... I mean, the autocomplete isn't even turned off for the password field....

(Also... you keep assuming that I don't/didn't read the code.... I simply don't mention things like this because they are irrelevant)

(03-19-2015, 01:06 PM)Dyme Wrote: But why does this "proof" even matter what so ever? The only time the user supplied password will equal the one stored in the DB is if the user logging in knows it... otherwise passwords supplied by attackers (which is what we're discussing) will NOT equal the one stored in the db, as they simply don't know it. I don't understand what you're trying to get at here.

You keep repeating that.... I'm not even arguing it.

All I'm saying is that we both made assumptions... And that neither of our assumptions are provable....

(03-19-2015, 01:06 PM)Dyme Wrote: No, I did not say that. Why quote me wrongly when you could have just went back a page? Oh, because it's clear that I didn't say that and you're trying to warp my words to make yourself seem correct.

I never said to throttle the backend, I said to throttle logins IN your backend (which is PHP). Just admit you misread my reply and get over it.

Alright then, I misread it... It was pretty late at night where I live.

(03-19-2015, 01:06 PM)Dyme Wrote: Yeah and you're not doing the same thing you're accusing me of doing here, right? I responded to you in that manner because I get frustrated when I have to correct people over and over again yet they still insist they're right... and I hate to say it to you, but you're not right here.

Ending this convo now as if you still decide to disagree with me it's clear you're just doing so for the sake of arguing. Feel free to respond and make yourself look like an even bigger moron, though.

If I'm going to be labeled a moron for attempting to defend my arguments then so be it.

I will wear the moron tag proudly!

RE: How might this source be exploited? - roger_smith - 03-19-2015

@Dyme and @Brawler the conversation was rather interesting but I think it's starting to derail the thread. Let's try and get back on track a bit. If you guys wanted to make a new thread referencing this one to continue the side convo that's totally fine.

RE: How might this source be exploited? - azRAel_ - 03-23-2015

(03-19-2015, 12:11 AM)whatever Wrote: Why's that? If your argument is that "it can be bruteforced" or "cracked by a dictionary attack" then yes, that's true. But unless you're calling all hashing algorithms bad, MD5 is no different from any other hashing algorithm, as any password or hash can be bruteforced. As long as someone is using a complex password, the chances of it getting cracked is low (just as it is with any other algorithm) and there will be no need for a salt.

If you use a GPU based decrypter or you can thread it to a cloud server, you can bruteforce MD5 and SHA-1 with 1-15 length passwords in less than a few hours (or even less...).