CSRF test
Add system_meltdown to your friends list.
View this thread.
See if he is still on your friends list.
CSRF 2:
Much More Dangerous.
This one uses php on my t35 sub domain to remove richohealy from your friends list.
Add RichoHealey to your friends list, and then look at this thread. See if the php on my server was executed by your browser to delete him from your friends list.
This has been reported to the admins a few times.
You can force users to execute arbitrary php/html on your server by bypassing the avatar filter. You can bypass the filter for the avatar with a url like the following: yourwebsite.com/script%2e%70%68%70?hey=yes.jpg
This works by encoding .php and ending the url with .jpg . The .php must be encoded because if the filter see's this it will not allow you to use the "photo" even if it ends with .jpg
I have figured out how to use this to change a users password. The user needs to have refspoof, or you can use a cURL script to send a POST request and spoof the referer.
Test this theory by getting a t35.com subdomain and adding this php code to your server :
header( 'Location: http://www.hellboundhackers.org/fusion_infusions/buddy_panel/buddy_delete.php?id=7540' ) ;
$hey=yes.jpg
?>```
name it script.php and add this as your avatar, yoursubdomain.t35.com/script%2e%70%68%70?hey=yes.jpg
This will bypass the filter and everytime your avatar loads it will execute the code from the script. See if you can keep richohealy on your friends list.
This should prove that the php is in fact being executed by a person viewing the avatar and not escaped as being executed by php and passed to apache
Infam0us wrote: I have figured out how to use this to change a users password. The user needs to have refspoof, or you can use a cURL script to send a POST request and spoof the referer. This could be patched so easily - by just forcing all users to enter their current password in order to update their profile/set new passwords etc.
This works very well on many other sites, so I've actually been wondering why we don't use that technique here… :right:
Ooohh here we go again… Alright, first off! 50% of the admins has Coding related jobs so after getting home from work at 5-6PM do you really think they gonna place their asses infront of the computer to have a coding session again? Rest of the admins goes to school so there's a bit lack of time there you see.
We work as hard as we can, WHEN we can! There are tons of ideas and tons and tons of more stuff to fix aswell so have patience!
About the CSRF we have already fixed the major bugs that can be achieved with it so it's not top priority! Thanks for you critics though fallingmidget, to bad no one gives a shit!
root_op wrote: to bad no one gives a shit!
I think she said that was the problem. And she's kinda right, and despite the fact that 'no one gives a shit' your community is only going to be as good as you make it. I remember it taking months and months and months to get the code bank working. That should have been a very high priority and yet nobody could submit anything for quite some time. I'm not bitching, your site is only going to be as good as the standards you set for it. :\
Besides, you guys have recruited a few admins here recently. Is it really smart to recruit admins that have no time to really do shit for the community?? :right:
I'm interested in how you got this thing to send a POST request. Your page was grabbed via GET, which means that yes, the header() function would work.
How did you get it to submit information to create a POST?
Also, how did you bypass the user_hash variable? Or is that not needed for user submission?
slpctrl wrote: There are some pretty fun/annoying applications that can be used with this. You could just make a huge array of numbers from like 1-20,000 and then do a header for each one to remove every person off of one's buddy list whenever they view the image :D.
How are you planning on using Location 20,000 times using one page?
nights_shadow wrote: [quote]slpctrl wrote: There are some pretty fun/annoying applications that can be used with this. You could just make a huge array of numbers from like 1-20,000 and then do a header for each one to remove every person off of one's buddy list whenever they view the image :D.
How are you planning on using Location 20,000 times using one page?[/quote]
If I understand this correctly, it doesn't actually redirect your browser just does the action where the location is. I could be wrong but I doubt it :ninja:
I mean, does this thread redirect your browser when you view it? The CSRF image is on the OPs avatar after all, and I'm not redirecting anywhere.
nights_shadow wrote: But you are, just because your window doesn't change, doesn't mean his location doesn't.
Avatar loads and GET's page. Page uses Location: to tell browser 302 302 = location of resource changed temporarily Redirect to new resource
I mean, try it yourself to be sure.
It works, my avatar removes 2 members from your buddy list: system_meltdown and Futility ;) I'm right; what's new. HAHAHAAHHAHAHAHA. HAHAHAHAHAHAHAHAHAHAHAA. J/k :ninja:
It's possible with cURL I'm sure, but I guess it's not possible with the header('location'). Who woulda thought?? B) I'm just curious as to why it takes the 2nd value and not the value of my first header('location'). If it processed teh first line and went to the 2nd and removed him, why didn't it do the first? I donno but obviously it doesn't work with multiple ones, which confused me because it's not actually affecting the browser. I don't know :ninja: HJAAHAHAHAHAHAHAHAHAHAHA
nights_shadow wrote: I'm interested in how you got this thing to send a POST request. Your page was grabbed via GET, which means that yes, the header() function would work.
How did you get it to submit information to create a POST?
Also, how did you bypass the user_hash variable? Or is that not needed for user submission?
Your right I didnt think about the user hash, I didnt actualy try this on anyone but myself :angry:. But im sure it wouldnt take much to make it a cURL script to use the users cookie to get the user hash, put it in a variable and use that variable as the value for that part of the form.
As for the POST, It doesnt matter what http method was used to access the page, just what that page does once its accessed. What happens when you make a GET request to a page that uses <body onload=' document.user_input.submit'> and auto submits a form in the page? Say The form is the same form held in the edit profile page of hbh. when submitted It will redirect to http://hellboundhackers.org/edit_profile.php with all the POST data that was submitted with the form wouldnt it? I dont know for sure if that would work, exactly like that, through an avatar because I havent actually tested that theory..
I havent actually got down and dirty staying up late night trying to perfect it. I was just trying to help patch another dangerous hole.
Not to mention what other requests could be made with this.
Picture this: Mr.cheese is messing arround with the host for hbh and comes on hbh to read some threads and see how things are doing.
He reads a thread with a "poisoned" avatar, in this avatar code points to the webhost hosting hbh. This GET request forces him to change the email address on his account on the host for hbh. This user sends a forgot password request and gets all the credentials he needs to get onto hbh's host and look / do anything he wants.
Believe it or not this has been done before..
Dangerous? I think so.
and @slpctrl you cant have .php in the url, just encode it as %2e%70%68%70 ;)
apescanfly223 wrote: nice find. just 1 questions why does it matter if they have refspoof?
If they have ref spoof you dont need to spoof the referer because you could make the form auto submit to spoof://hellboundhackers.org/editinfo.php;ref://www.hellboundhackers.org
Which will spoof the referer so you dont have to change any header information with php.
Uber0n wrote: [quote]Infam0us wrote: I have figured out how to use this to change a users password. The user needs to have refspoof, or you can use a cURL script to send a POST request and spoof the referer. This could be patched so easily - by just forcing all users to enter their current password in order to update their profile/set new passwords etc.
This works very well on many other sites, so I've actually been wondering why we don't use that technique here… :right:[/quote]
Very true. And the csrf could also be easily fixed by verifying it is indeed an image by the contents of the file and by un-encoding anything in the url for the avatar after http:// and after un-encoding repeat any filter checks recursively until all is not encoded and a final check has been made on the url, similar to some xss filters. The first one could be fixed by not allowing a reference to hellboundhackers.org in the [img] tag, the avatar etc. And verifying it is indeed an image by the content of the file.
Infam0us wrote: [quote]nights_shadow wrote: I'm interested in how you got this thing to send a POST request. Your page was grabbed via GET, which means that yes, the header() function would work.
How did you get it to submit information to create a POST?
Also, how did you bypass the user_hash variable? Or is that not needed for user submission?
Your right I didnt think about the user hash, I didnt actualy try this on anyone but myself :angry:. But im sure it wouldnt take much to make it a cURL script to use the users cookie to get the user hash, put it in a variable and use that variable as the value for that part of the form.
As for the POST, It doesnt matter what http method was used to access the page, just what that page does once its accessed. What happens when you make a GET request to a page that uses <body onload=' document.user_input.submit'> and auto submits a form in the page? The form is the same form held in the edit profile page of hbh. when submitted It will redirect to http://hellboundhackers.org/edit_profile.php with all the POST data that was submitted with the form wouldnt it? I dont know for sure if that would work, exactly like that, through an avatar because I havent actually tested that theory..
I havent actually got down and dirty staying up late night trying to perfect it. I was just trying to help patch another dangerous hole.
Not to mention what other requests could be made with this.
Picture this: Mr.cheese is messing arround with the host for hbh and comes on hbh to read some threads and see how things are doing.
He reads a thread with a "poisoned" avatar, in this avatar code points to the webhost hosting hbh. This GET request forces him to change the email address on his account on the host for hbh. This user sends a forgot password request and gets all the credentials he needs to get onto hbh's host and look / do anything he wants.
Believe it or not this has been done before..
Dangerous? I think so.
and @slpctrl you cant have .php in the url, just encode it as %2e%70%68%70[/quote]
Yeah I did, that wasn't the issue though, I thought something would work that didn't; Now I'm gonna go cry myself to sleep :ninja:
slpctrl wrote: It's possible with cURL I'm sure, but I guess it's not possible with the header('location'). Who woulda thought?? B) I'm just curious as to why it takes the 2nd value and not the value of my first header('location'). If it processed teh first line and went to the 2nd and removed him, why didn't it do the first? I donno but obviously it doesn't work with multiple ones, which confused me because it's not actually affecting the browser. I don't know :ninja: HJAAHAHAHAHAHAHAHAHAHAHA
Hmm, thanks for doing that experiment. Processing the second line over the first is something I wouldn't have guessed it to do, but I guess it makes sense. Let me theoretisize (damn, that would be a cool word, say it out loud…it sounds awesome) for a second here. Please someone let me know if I'm wrong here.
It has to read the entire script before taking any action. It doesn't just say, oh hey modified header information here, ignore rest of code. In which case, when you set the second one, it's newer than your first line. So it takes that action instead.
Edit — reading OP's new post
nights_shadow wrote: [quote]slpctrl wrote: It's possible with cURL I'm sure, but I guess it's not possible with the header('location'). Who woulda thought?? B) I'm just curious as to why it takes the 2nd value and not the value of my first header('location'). If it processed teh first line and went to the 2nd and removed him, why didn't it do the first? I donno but obviously it doesn't work with multiple ones, which confused me because it's not actually affecting the browser. I don't know :ninja: HJAAHAHAHAHAHAHAHAHAHAHA
Hmm, thanks for doing that experiment. Processing the second line over the first is something I wouldn't have guessed it to do, but I guess it makes sense. Let me theoretisize (damn, that would be a cool word, say it out loud…it sounds awesome) for a second here. Please someone let me know if I'm wrong here.
It has to read the entire script before taking any action. It doesn't just say, oh hey modified header information here, ignore rest of code. In which case, when you set the second one, it's newer than your first line. So it takes that action instead.
Edit — reading OP's new post[/quote]
I do believe that is the case; I've seen scripts with a header('location') at the top of the line and I had always thought…wtf? You're redirecting it before it has the chance to process the rest of the code, and yet the whole script worked. It seems quite inefficient to me, I donno but that's the best answer I can think of. I always thought that PHP just executed from the top line down.
Infam0us wrote: [quote]nights_shadow wrote: I'm interested in how you got this thing to send a POST request. Your page was grabbed via GET, which means that yes, the header() function would work.
How did you get it to submit information to create a POST?
Also, how did you bypass the user_hash variable? Or is that not needed for user submission?
Your right I didnt think about the user hash, I didnt actualy try this on anyone but myself :angry:. But im sure it wouldnt take much to make it a cURL script to use the users cookie to get the user hash, put it in a variable and use that variable as the value for that part of the form.
As for the POST, It doesnt matter what http method was used to access the page, just what that page does once its accessed. What happens when you make a GET request to a page that uses <body onload=' document.user_input.submit'> and auto submits a form in the page? The form is the same form held in the edit profile page of hbh. when submitted It will redirect to http://hellboundhackers.org/edit_profile.php with all the POST data that was submitted with the form wouldnt it? I dont know for sure if that would work, exactly like that, through an avatar because I havent actually tested that theory..
I havent actually got down and dirty staying up late night trying to perfect it. I was just trying to help patch another dangerous hole.
Not to mention what other requests could be made with this.
Picture this: Mr.cheese is messing arround with the host for hbh and comes on hbh to read some threads and see how things are doing.
He reads a thread with a "poisoned" avatar, in this avatar code points to the webhost hosting hbh. This GET request forces him to change the email address on his account on the host for hbh. This user sends a forgot password request and gets all the credentials he needs to get onto hbh's host and look / do anything he wants.
Believe it or not this has been done before..
Dangerous? I think so.
and @slpctrl you cant have .php in the url, just encode it as %2e%70%68%70[/quote]
Yes, but with your exploit, your POST will not submit. There's also no way for you to use this exploit to steal my cookies and grab the user_hash…that I know of o.0.
If you use the exploit as your example, than it's not exactly something HBH can fix. Also, if webhost uses GET for change email with no form of authentication to verify account is his, kill admin.
nights_shadow wrote: [quote]Infam0us wrote: [quote]nights_shadow wrote: I'm interested in how you got this thing to send a POST request. Your page was grabbed via GET, which means that yes, the header() function would work.
How did you get it to submit information to create a POST?
Also, how did you bypass the user_hash variable? Or is that not needed for user submission?
Your right I didnt think about the user hash, I didnt actualy try this on anyone but myself :angry:. But im sure it wouldnt take much to make it a cURL script to use the users cookie to get the user hash, put it in a variable and use that variable as the value for that part of the form.
As for the POST, It doesnt matter what http method was used to access the page, just what that page does once its accessed. What happens when you make a GET request to a page that uses <body onload=' document.user_input.submit'> and auto submits a form in the page? The form is the same form held in the edit profile page of hbh. when submitted It will redirect to http://hellboundhackers.org/edit_profile.php with all the POST data that was submitted with the form wouldnt it? I dont know for sure if that would work, exactly like that, through an avatar because I havent actually tested that theory..
I havent actually got down and dirty staying up late night trying to perfect it. I was just trying to help patch another dangerous hole.
Not to mention what other requests could be made with this.
Picture this: Mr.cheese is messing arround with the host for hbh and comes on hbh to read some threads and see how things are doing.
He reads a thread with a "poisoned" avatar, in this avatar code points to the webhost hosting hbh. This GET request forces him to change the email address on his account on the host for hbh. This user sends a forgot password request and gets all the credentials he needs to get onto hbh's host and look / do anything he wants.
Believe it or not this has been done before..
Dangerous? I think so.
and @slpctrl you cant have .php in the url, just encode it as %2e%70%68%70[/quote]
Yes, but with your exploit, your POST will not submit. There's also no way for you to use this exploit to steal my cookies and grab the user_hash…that I know of o.0.
If you use the exploit as your example, than it's not exactly something HBH can fix. Also, if webhost uses GET for change email, kill admin.[/quote]
It wouldn't really matter if anyone stole your cookies as one cookie that's required to login to the site is IP based…you change your IP, you will log out anyways. You can't really inject anyone else's cookies into your own like that here :p.
Basically I thought you could use some sort of code like so:
<?php
$num = range('1', '20000');
foreach($num as $nums) {
header('Location: http://www.hellboundhackers.org/fusion_infusions/buddy_panel/buddy_delete.php?id=' . $nums);
}
$hey=yes.jpg
?>
To completely kill everyone on one's buddy list. It can't be done though I guess :\.
nights_shadow wrote: [quote]Infam0us wrote: [quote]nights_shadow wrote: I'm interested in how you got this thing to send a POST request. Your page was grabbed via GET, which means that yes, the header() function would work.
How did you get it to submit information to create a POST?
Also, how did you bypass the user_hash variable? Or is that not needed for user submission?
Your right I didnt think about the user hash, I didnt actualy try this on anyone but myself :angry:. But im sure it wouldnt take much to make it a cURL script to use the users cookie to get the user hash, put it in a variable and use that variable as the value for that part of the form.
As for the POST, It doesnt matter what http method was used to access the page, just what that page does once its accessed. What happens when you make a GET request to a page that uses <body onload=' document.user_input.submit'> and auto submits a form in the page? The form is the same form held in the edit profile page of hbh. when submitted It will redirect to http://hellboundhackers.org/edit_profile.php with all the POST data that was submitted with the form wouldnt it? I dont know for sure if that would work, exactly like that, through an avatar because I havent actually tested that theory..
I havent actually got down and dirty staying up late night trying to perfect it. I was just trying to help patch another dangerous hole.
Not to mention what other requests could be made with this.
Picture this: Mr.cheese is messing arround with the host for hbh and comes on hbh to read some threads and see how things are doing.
He reads a thread with a "poisoned" avatar, in this avatar code points to the webhost hosting hbh. This GET request forces him to change the email address on his account on the host for hbh. This user sends a forgot password request and gets all the credentials he needs to get onto hbh's host and look / do anything he wants.
Believe it or not this has been done before..
Dangerous? I think so.
and @slpctrl you cant have .php in the url, just encode it as %2e%70%68%70[/quote]
Yes, but with your exploit, your POST will not submit. There's also no way for you to use this exploit to steal my cookies and grab the user_hash…that I know of o.0.
If you use the exploit as your example, than it's not exactly something HBH can fix. Also, if webhost uses GET for change email with no form of authentication to verify account is his, kill admin.[/quote]
No I would not steal your cookie, I would have you execute the script, using your own cookie to get it for me. I dont know, Im getting confuesed now :whoa:
I dont understand why it wouldnt submit a POST though? Even if the page you go to autosubmits a form with set values? Or uses php to send the request with set headers etc. ?
nights_shadow wrote: Well, we're talking about jacking user_hash and then modifying the CSRF on the fly to change account information. Not using the cookies to hijack user's session.
I know from experience (an experiment myself and a member who used to post here a lot, zvirx) that you can't really do much of anything including a CSRF I don't believe (I tried to do all that shit in cURL using his cookie info to change value), I don't really see where you're coming from with that either, but hey go for it and try to do something with it B).
Infam0us wrote: [quote]nights_shadow wrote: [quote]Infam0us wrote: [quote]nights_shadow wrote: I'm interested in how you got this thing to send a POST request. Your page was grabbed via GET, which means that yes, the header() function would work.
How did you get it to submit information to create a POST?
Also, how did you bypass the user_hash variable? Or is that not needed for user submission?
Your right I didnt think about the user hash, I didnt actualy try this on anyone but myself :angry:. But im sure it wouldnt take much to make it a cURL script to use the users cookie to get the user hash, put it in a variable and use that variable as the value for that part of the form.
As for the POST, It doesnt matter what http method was used to access the page, just what that page does once its accessed. What happens when you make a GET request to a page that uses <body onload=' document.user_input.submit'> and auto submits a form in the page? The form is the same form held in the edit profile page of hbh. when submitted It will redirect to http://hellboundhackers.org/edit_profile.php with all the POST data that was submitted with the form wouldnt it? I dont know for sure if that would work, exactly like that, through an avatar because I havent actually tested that theory..
I havent actually got down and dirty staying up late night trying to perfect it. I was just trying to help patch another dangerous hole.
Not to mention what other requests could be made with this.
Picture this: Mr.cheese is messing arround with the host for hbh and comes on hbh to read some threads and see how things are doing.
He reads a thread with a "poisoned" avatar, in this avatar code points to the webhost hosting hbh. This GET request forces him to change the email address on his account on the host for hbh. This user sends a forgot password request and gets all the credentials he needs to get onto hbh's host and look / do anything he wants.
Believe it or not this has been done before..
Dangerous? I think so.
and @slpctrl you cant have .php in the url, just encode it as %2e%70%68%70[/quote]
Yes, but with your exploit, your POST will not submit. There's also no way for you to use this exploit to steal my cookies and grab the user_hash…that I know of o.0.
If you use the exploit as your example, than it's not exactly something HBH can fix. Also, if webhost uses GET for change email with no form of authentication to verify account is his, kill admin.[/quote]
No I would not steal your cookie, I would have you execute the script, using your own cookie to get it for me. I dont know, Im getting confuesed now :whoa:
I dont understand why it wouldnt submit a POST though? Even if the page you go to autosubmits a form with set values? Or uses php to send the request with set headers etc. ?[/quote]
Nope, even if the page autosubmits a form with set values, it shouldn't work.
Test it, if it does…well….then fuck.
As for creating headers to send information to create a POST, I'm not sure if that will work either. In all honesty, the more I think about it, the more I think it's possible, but have no experiments to go back on saying if it'll work or not. I'm leaning towards yes as you proved you could create headers with your Location:. You'll have to get back to me on that one.
Even if you can, you still have the problem of user_hash blocking you from doing anything dangerous. Issuing a POST is just the first hurdle.
But yeah, definitely try to simulate a POST request with headers and see what works.
slpctrl wrote: [quote]nights_shadow wrote: Well, we're talking about jacking user_hash and then modifying the CSRF on the fly to change account information. Not using the cookies to hijack user's session.
I know from experience (an experiment myself and a member who used to post here a lot, zvirx) that you can't really do much of anything including a CSRF I don't believe (I tried to do all that shit in cURL using his cookie info to change value), I don't really see where you're coming from with that either, but hey go for it and try to do something with it B).[/quote]
For some reason I forgot user_hash was dynamic. I, for some reason, was thinking fusion_user was user_hash.
nights_shadow wrote: [quote]Infam0us wrote: [quote]nights_shadow wrote: [quote]Infam0us wrote: [quote]nights_shadow wrote: I'm interested in how you got this thing to send a POST request. Your page was grabbed via GET, which means that yes, the header() function would work.
How did you get it to submit information to create a POST?
Also, how did you bypass the user_hash variable? Or is that not needed for user submission?
Your right I didnt think about the user hash, I didnt actualy try this on anyone but myself :angry:. But im sure it wouldnt take much to make it a cURL script to use the users cookie to get the user hash, put it in a variable and use that variable as the value for that part of the form.
As for the POST, It doesnt matter what http method was used to access the page, just what that page does once its accessed. What happens when you make a GET request to a page that uses <body onload=' document.user_input.submit'> and auto submits a form in the page? The form is the same form held in the edit profile page of hbh. when submitted It will redirect to http://hellboundhackers.org/edit_profile.php with all the POST data that was submitted with the form wouldnt it? I dont know for sure if that would work, exactly like that, through an avatar because I havent actually tested that theory..
I havent actually got down and dirty staying up late night trying to perfect it. I was just trying to help patch another dangerous hole.
Not to mention what other requests could be made with this.
Picture this: Mr.cheese is messing arround with the host for hbh and comes on hbh to read some threads and see how things are doing.
He reads a thread with a "poisoned" avatar, in this avatar code points to the webhost hosting hbh. This GET request forces him to change the email address on his account on the host for hbh. This user sends a forgot password request and gets all the credentials he needs to get onto hbh's host and look / do anything he wants.
Believe it or not this has been done before..
Dangerous? I think so.
and @slpctrl you cant have .php in the url, just encode it as %2e%70%68%70[/quote]
Yes, but with your exploit, your POST will not submit. There's also no way for you to use this exploit to steal my cookies and grab the user_hash…that I know of o.0.
If you use the exploit as your example, than it's not exactly something HBH can fix. Also, if webhost uses GET for change email with no form of authentication to verify account is his, kill admin.[/quote]
No I would not steal your cookie, I would have you execute the script, using your own cookie to get it for me. I dont know, Im getting confuesed now :whoa:
I dont understand why it wouldnt submit a POST though? Even if the page you go to autosubmits a form with set values? Or uses php to send the request with set headers etc. ?[/quote]
Well, you would still have to somehow read my cookie information to be able to modify your script to edit my account information. That's what I was getting at.
Nope, even if the page autosubmits a form with set values, it shouldn't work.
Test it, if it does…well….then fuck.
As for creating headers to send information to create a POST, I'm not sure if that will work either. In all honesty, the more I think about it, the more I think it's possible, but have no experiments to go back on saying if it'll work or not. I'm leaning towards yes as you proved you could create headers with your Location:. You'll have to get back to me on that one.
Even if you can, you still have the problem of user_hash blocking you from doing anything dangerous. Issuing a POST is just the first hurdle.
But yeah, definitely try to simulate a POST request with headers and see what works.[/quote]
Well I figured since every request you send to hbh (after your session has started by logging in) sends your cookie information along with the request I could just use that to my advantage to edit your info, or gather your hash from a page only you can access. That was my theory, but now I see what your saying :happy:
And I also started thinking that ***if ***the hash is generated from something public like your username you could find what encryption is being used to encrypt it and possibly figure out a users hash that way :ninja: EDIT: Scratch that. I didnt realize it was dynamic, for somereason I thought it was static form your username or something :happy:
This hash is a pain.
@Admins: Can you remove the user_hash from the edit profile page so I can try something please? jp :D
Thanks for help and comments :D