helping a friend

OK i think I'm going to get flamed for this but i don't care. a buddy of mine wants me to test his site for vulnerabilities. and i noticed something in the url.

it says something like this http://svcs.sf2000.registeredsite.com/svcs/prot.jsp?ppage+id81.html&obpp=blDe2trOWt5azlrm6sTiZGRieGps&ret_url=http://www.example.com/index.html (i'm not giving out the real site of course)

but i was wondering if anyone could tell me if they see any vulnerabilities just from this. just say yes or no don't say what it is.

i tried everything else i know without messing with the url. i just want to tell him if its secure or not from my understanding.

any help would be appreciated.

Realy hard to find any exploits without knowing the source….

&ret_url=http://www.example.com/index.html

This right here appears to be a RFI vuln. But idk you should post the site or pm me with it I'd be more than glad to test it. If you couldn't spot that you really have no business testing ;) :D

slpctrl wrote: RFI??????????? Gimme the site I want to test :)

thats what i thought but i don't know because its not using php and theres nothing of interst in the source code and all the directories are locked.

fallingmidget wrote: [quote]slpctrl wrote: RFI??????????? Gimme the site I want to test :)

thats what i thought but i don't know because its not using php and theres nothing of interst in the source code and all the directories are locked.[/quote]

Well if it's not using PHP then it won't work. Shells are in text format, and work on the fact that if PHP is echoed within a php page, it will execute the code not echo it. So, but if there's no PHP and it's not really dynamic, there's probably little that can be done.

i sent you the site

there are some sites around that check vulnerability, I dont remember them at the moment, but most were free

@fallingmidget, it really depends on the code not the structure of the site.

there is a possibility of an rfi/lfi exploit, however you would need to test it to find out. you never know until you play around with it.

also, its jsp (java server page) so that is going to change things

is that a server side scripting or not. if it's not then i guess he doesn't have any server side scripting

it is not server side scripting. but that doesnt mean there are not any vulnerabilities, either.

slpctrl wrote: If you couldn't spot that you really have no business testing

Can't help but agree with this. GET variables are the easiest possible vulnerabilities to locate.

You may want to try more of the challenges to get acquainted with basic terminology and concepts. In particular, complete the Basics and Reals.

Ah but zephyr its not a php rfi, its jsp. vulnerabilities are going to be confined to maybe cookie stealing/ ip logging or whatnot. ive never done any thinking about jsp rfi so im not even sure if there are going to be that many weaknesses. if there are they are going to be far above fallingmidgets head. <<haha, i made a joke :happy:

Zephyr_Pure wrote: Can't help but agree with this. GET variables are the easiest possible vulnerabilities to locate.

DigitalFire wrote: Ah but zephyr its not a php rfi, its jsp. vulnerabilities are going to be confined to maybe cookie stealing/ ip logging or whatnot. ive never done any thinking about jsp rfi so im not even sure if there are going to be that many weaknesses.

I didn't assume it was PHP RFI or anything else. GET variables, by their very nature, should be limited in use and sanitized heavily. It doesn't matter what language uses them, as they still serve the same purpose.

JSP aren't special… they're just different. And RFI is not the only GET weakness that can be exploited; GET variables are used as values in the code itself. If you can get the code to start breaking through invalid GET variables, then you can figure out how to "exploit the weakness".

if there are they are going to be far above fallingmidgets head.

This much was obvious by the fact that this thread even exists.

Zephyr_Pure wrote: I didn't assume it was PHP RFI or anything else. GET variables, by their very nature, should be limited in use and sanitized heavily. It doesn't matter what language uses them, as they still serve the same purpose.

JSP aren't special… they're just different. And RFI is not the only GET weakness that can be exploited; GET variables are used as values in the code itself. If you can get the code to start breaking through invalid GET variables, then you can figure out how to "exploit the weakness".

I am well aware. But the "exploiting the weakness" is going to be exploiting a java app, which is client side, and run in a virutal machine. I was just saying you are not going to be getting root of a server by exploiting java.

Zephyr_Pure wrote: This much was obvious by the fact that this thread even exists.

very true

actually, i just did a bit of research. turns out JSP is server side :right:

my bad.

scratch the last like 3 things i said.

DigitalFire wrote: actually, i just did a bit of research. turns out JSP is server side :right:

my bad.

scratch the last like 3 things i said.

It's cool. You did the research, so I can say nothing bad about your comments. Anyways, you brought up a valid point… JSP pages will require a slightly different mentality than PHP pages would. In the end, everything is exploitable: you just have to attack in a way similar to that way in which you would implement. :)

OK i just got back.

1.if it were php i would have tried RFI. 2. when i do the basics some of them i don't know were to even begin and when i ask for some help with the challenge people suddenly want to bitch and its not the way i ask them its that they tell me to go learn on my own but sometimes i can't find anything. 3. i just tried the things i already knew how to do. when nothing worked i decided to see if someone noticed anything in the URL (i was thinking RFI because of the way it looked i just wanted someone to confirm it). 4. how do you get the GET variables.

fallingmidget wrote: 1.if it were php i would have tried RFI.

2. when i do the basics some of them i don't know were to even begin and when i ask for some help with the challenge people suddenly want to bitch and its not the way i ask them its that they tell me to go learn on my own but sometimes i can't find anything.

3. i just tried the things i already knew how to do. when nothing worked i decided to see if someone noticed anything in the URL (i was thinking RFI because of the way it looked i just wanted someone to confirm it).

4. how do you get the GET variables.

5. I doubt that. You have to know how to recognize GET variables before you can exploit an RFI vuln.

6. Read the previous threads about the challenges in the forums, as well as the articles on those challenges. Only when you're stuck, though; there should be any need to start a new thread with all of the information that's already there.

7. There's plenty in the URL… you have to learn about GET variables to figure out how to use it, though.

8. Read.

lesserlightsofheaven wrote: Fuck. Zephyr beat me. ;D

Nice to see you, too. :P Seems as if we say the same things at times here, doesn't it? ;)

fallingmidget wrote: 1.if it were php i would have tried RFI.

Okay.

2. when i do the basics some of them i don't know were to even begin and when i ask for some help with the challenge people suddenly want to bitch and its not the way i ask them its that they tell me to go learn on my own but sometimes i can't find anything.

That's because you're not looking hard enough.

3. i just tried the things i already knew how to do. when nothing worked i decided to see if someone noticed anything in the URL (i was thinking RFI because of the way it looked i just wanted someone to confirm it).

Read: "I tried everything I knew how to do, and then I gave up and shoved it on someone else."

4. how do you get the GET variables.

You're looking at them.

blah.php?ohlookimavariable=ohlookimanassignedvalue

Fuck. Zephyr beat me. ;D

1. i read in wikipedia what it is so i know at least how to spot the vulnerability just not to carry it out (thats what i am about to start looking for).

2. it's not that i'm not looking hard enough it's that i lack some basic things while knowing some intermediate things. (there should be like a hackerpedia or some refeance to go to to teach the exploits) please don't say google. and i do look hard. i do look in the past threads and articles but sometimes i don't understand them so i ask someone to help describe it to me.

3. i didn't want to dump it on someone else i just wanted to know if there was something there or not. (i was just looking for a yes or no)

4. huh