By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,082 Members | 2,108 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,082 IT Pros & Developers. It's quick & easy.

Qustion on viewing code

P: n/a
Is there a way i can look at the php code that is runnig a site, without any
ind of admin access to the server?


Feb 23 '07 #1
Share this Question
Share on Google+
34 Replies


P: n/a
Alan Larsson wrote:
Is there a way i can look at the php code that is runnig a site, without any
ind of admin access to the server?
Unless there is a horrible server misconfiguration or the site has a
serious scripting vulnerability, no.

--
Curtis, http://dyersweb.com
Feb 23 '07 #2

P: n/a
On 23 Feb, 01:12, Curtis <zer0d...@verizon.netwrote:
Alan Larsson wrote:
Is there a way i can look at the php code that is runnig a site, without any
ind of admin access to the server?

Unless there is a horrible server misconfiguration or the site has a
serious scripting vulnerability, no.

--
Curtis,http://dyersweb.com
yes, probably but not for someone who provides no specifics and at
least attempts to justify it.
do no evil.
and you have to pay school fees by learning more about things before
you ask this kind of question, or you wont be respected enough to get
given the answers

Feb 23 '07 #3

P: n/a
Message-ID: <45**********************@roadrunner.comfrom Alan Larsson
contained the following:
>Is there a way i can look at the php code that is runnig a site, without any
ind of admin access to the server?
No.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
Feb 23 '07 #4

P: n/a

"shimmyshack" <ma********@gmail.comwrote in message
news:11**********************@v33g2000cwv.googlegr oups.com...
On 23 Feb, 01:12, Curtis <zer0d...@verizon.netwrote:
>Alan Larsson wrote:
Is there a way i can look at the php code that is runnig a site,
without any
ind of admin access to the server?

Unless there is a horrible server misconfiguration or the site has a
serious scripting vulnerability, no.

--
Curtis,http://dyersweb.com

yes, probably but not for someone who provides no specifics and at
least attempts to justify it.
do no evil.
and you have to pay school fees by learning more about things before
you ask this kind of question, or you wont be respected enough to get
given the answers
actually, I am being accused of stealing PHP code from a site.. and I did
not think it was possible, so I asked the experts here.
Feb 23 '07 #5

P: n/a
On 23 Feb, 02:23, "Alan Larsson" <newsgr...@alstown.comwrote:
"shimmyshack" <matt.fa...@gmail.comwrote in message

news:11**********************@v33g2000cwv.googlegr oups.com...
On 23 Feb, 01:12, Curtis <zer0d...@verizon.netwrote:
Alan Larsson wrote:
Is there a way i can look at the php code that is runnig a site,
without any
ind of admin access to the server?
Unless there is a horrible server misconfiguration or the site has a
serious scripting vulnerability, no.
--
Curtis,http://dyersweb.com
yes, probably but not for someone who provides no specifics and at
least attempts to justify it.
do no evil.
and you have to pay school fees by learning more about things before
you ask this kind of question, or you wont be respected enough to get
given the answers

actually, I am being accused of stealing PHP code from a site.. and I did
not think it was possible, so I asked the experts here.
Ah I see, well it didn't sound to me that you knew enough to do it, so
that's your strongest card.
Don't start getting interested in this area just for the sake of
showing you can't because it's a huge area and the answer to this
question is always YES probably. (even the ones with "hacker safe"
symbols.
Basically PHP code is designed never to be released to the end user,
any file on the server should be executed and only the results of the
php code sent to your browser, however there are times when people
make mistakes and the code can be downloaded. The only way you could
have accidentally stolen code via a browser is by accidentally finding
a publically available piece of code, which is NOT your fault. Even if
you did find this, it would be quite improbable that the site in
question could tell if you had. (Unless they use some kind of complex
outgoing filter that records but does not stop outgoing code release -
whereas filters of this kind are usually set up to stop code release)

I would say you are on balance very unlikely to be accused for very
long,
a) it shows a lack of professionalism on their part to be releasing
code which they later regret.
b) whereas however they are saying "they know" you did it, which shows
a degree of skill they probably don't have as (a) shows

Just ask for evidence. But don't claim it "isn't possible" because it
usually is possible to launch an attack, there are so may ways to do
it. For more advice and info ask "OWASP or web app sec" they have to
deal with these kinds of complaints and threats on a regular basis
when they reveal vulnerabilities on sites. In general if you see
something wrong the advice is don't report it, unless you have reason
to believe you will escape subsequent action.

Feb 23 '07 #6

P: n/a

"shimmyshack" <ma********@gmail.comwrote in message
news:11*********************@s48g2000cws.googlegro ups.com...
| On 23 Feb, 02:23, "Alan Larsson" <newsgr...@alstown.comwrote:
| "shimmyshack" <matt.fa...@gmail.comwrote in message
| >
| news:11**********************@v33g2000cwv.googlegr oups.com...
| >
| >
| >
| On 23 Feb, 01:12, Curtis <zer0d...@verizon.netwrote:
| Alan Larsson wrote:
| Is there a way i can look at the php code that is runnig a site,
| without any
| ind of admin access to the server?
| >
| Unless there is a horrible server misconfiguration or the site has a
| serious scripting vulnerability, no.
| >
| --
| Curtis,http://dyersweb.com
| >
| yes, probably but not for someone who provides no specifics and at
| least attempts to justify it.
| do no evil.
| and you have to pay school fees by learning more about things before
| you ask this kind of question, or you wont be respected enough to get
| given the answers
| >
| actually, I am being accused of stealing PHP code from a site.. and I
did
| not think it was possible, so I asked the experts here.
|
| Ah I see, well it didn't sound to me that you knew enough to do it, so
| that's your strongest card.
| Don't start getting interested in this area just for the sake of
| showing you can't because it's a huge area and the answer to this
| question is always YES probably. (even the ones with "hacker safe"
| symbols.
| Basically PHP code is designed never to be released to the end user,
| any file on the server should be executed and only the results of the
| php code sent to your browser, however there are times when people
| make mistakes and the code can be downloaded. The only way you could
| have accidentally stolen code via a browser is by accidentally finding
| a publically available piece of code, which is NOT your fault. Even if
| you did find this, it would be quite improbable that the site in
| question could tell if you had. (Unless they use some kind of complex
| outgoing filter that records but does not stop outgoing code release -
| whereas filters of this kind are usually set up to stop code release)
|
| I would say you are on balance very unlikely to be accused for very
| long,
| a) it shows a lack of professionalism on their part to be releasing
| code which they later regret.
| b) whereas however they are saying "they know" you did it, which shows
| a degree of skill they probably don't have as (a) shows
|
| Just ask for evidence. But don't claim it "isn't possible" because it
| usually is possible to launch an attack, there are so may ways to do
| it. For more advice and info ask "OWASP or web app sec" they have to
| deal with these kinds of complaints and threats on a regular basis
| when they reveal vulnerabilities on sites. In general if you see
| something wrong the advice is don't report it, unless you have reason
| to believe you will escape subsequent action.

which is odd that he'd be asking how to do it...thus giving him the
knowlege/means and taking away his best defense.

find a server that parses all documents via php instead of by extension, and
one that allows uploads. embed php code in an image and upload it. in that
code, you should find the document root and then recurse for all dirs from
the doc root. output the paths into a file your script creates. access that
script. look for interesting names...especially header, security, and config
file names. the embedded php code should also output the product of
php_info(). any file you want, you can access via this method whether it is
in the www root or in some other system directory - which most people here
think gives a measure of security.

it's not hard to hack any site...it just takes a bit of knowledge and some
desire.
Feb 23 '07 #7

P: n/a

"Geoff Berrow" <bl******@ckdog.co.ukwrote in message
news:68********************************@4ax.com...
| Message-ID: <45**********************@roadrunner.comfrom Alan Larsson
| contained the following:
|
| >Is there a way i can look at the php code that is runnig a site, without
any
| >ind of admin access to the server?
|
| No.

are you trying to be funny, geof? that's about the most uninformed and
unimaginatively wrong answer as i've ever seen. i am horrified that it was
made by you of all people!
Feb 23 '07 #8

P: n/a
Rik
Steve <no****@example.comwrote:
find a server that parses all documents via php instead of by extension,
....

it's not hard to hack any site...it just takes a bit of knowledge and
some desire.
And in this case, both an insane webserver setting and a either no or a
bogus check on files after upload... Usually it would be much, much harder.

--
Rik Wasmus
Feb 23 '07 #9

P: n/a

"Rik" <lu************@hotmail.comwrote in message
news:op.tn6pvcviqnv3q9@misant...
| Steve <no****@example.comwrote:
| find a server that parses all documents via php instead of by extension,
| ....
| >
| it's not hard to hack any site...it just takes a bit of knowledge and
| some desire.
|
| And in this case, both an insane webserver setting and a either no or a
| bogus check on files after upload... Usually it would be much, much
harder.

true. however sadly, *most* web servers (apache anyway) out there at least
parse all documents through php even if the extension is different...things
like .css or .jpg, or what have you. this is the critical part. as long as
this is the configuration, you can find *many* ways to get your script onto
their server. and you will have enough authorization to access any system
directory that php has access to...even those not in the web root.

this is not just a php issue, asp and others have the same problem. people
are not ever as aware as they should be when it comes to security. myself
included.
Feb 23 '07 #10

P: n/a
On 23 Feb, 04:45, "Steve" <no....@example.comwrote:
"Rik" <luiheidsgoe...@hotmail.comwrote in message

news:op.tn6pvcviqnv3q9@misant...| Steve <no....@example.comwrote:

| find a server that parses all documents via php instead of by extension,
| ....
| >
| it's not hard to hack any site...it just takes a bit of knowledge and
| some desire.
|
| And in this case, both an insane webserver setting and a either no or a
| bogus check on files after upload... Usually it would be much, much
harder.

true. however sadly, *most* web servers (apache anyway) out there at least
parse all documents through php even if the extension is different...things
like .css or .jpg, or what have you. this is the critical part. as long as
this is the configuration, you can find *many* ways to get your script onto
their server. and you will have enough authorization to access any system
directory that php has access to...even those not in the web root.

this is not just a php issue, asp and others have the same problem. people
are not ever as aware as they should be when it comes to security. myself
included.
the embedding image technique gets passed antivirus, alot of incoming
filters, mimetype checking, most types of "is this an image" checking
(thumbnails/height/width etc...) - cos it still is, and just about the
only reliable way on windows to counter this is to use forcetype, and
store all images so they arent callable by URL. Removehandler wont
work unless your using cgi, its a very damaging attack. As for the
server settings, its default on windows, even on a good admin who has
security always on his mind might let this one passed. The same attack
works locally too, embedding javascript instead of php, and calling
the image in a frame, if you know your victim has a server on his
machine, you can even email him the offending picture asking him to
save it to his desktop, and using one of IEs many local file insertion
vulnerabilities included it in the window and grab his crendentials,
so to speak. Nasty

Feb 23 '07 #11

P: n/a
Steve wrote:
true. however sadly, *most* web servers (apache anyway) out there at least
parse all documents through php even if the extension is different...things
like .css or .jpg, or what have you. this is the critical part. as long as
this is the configuration, you can find *many* ways to get your script onto
their server. and you will have enough authorization to access any system
directory that php has access to...even those not in the web root.
Um, excuse me, but I've never seen/used a server that was set up like
that (then again, you can usually trust professional web hosts to set up
their servers properly). On one or two occasions, I've seen someone in
here ask if you *can* set up the server to parse everything through PHP,
and the general answer was "don't, because it's horribly insecure". It's
useful for single directories (containing dynamic images or feeds), but
as long as those directories are separated from the ones where files can
be uploaded, it should be safe.

--cb
Feb 23 '07 #12

P: n/a
Steve wrote:
"Rik" <lu************@hotmail.comwrote in message
news:op.tn6pvcviqnv3q9@misant...
| Steve <no****@example.comwrote:
| find a server that parses all documents via php instead of by extension,
| ....
| >
| it's not hard to hack any site...it just takes a bit of knowledge and
| some desire.
|
| And in this case, both an insane webserver setting and a either no or a
| bogus check on files after upload... Usually it would be much, much
harder.

true. however sadly, *most* web servers (apache anyway) out there at least
parse all documents through php even if the extension is different...things
like .css or .jpg, or what have you.
<snip>
I haven't seen Apache set up like that (on the document root and
below) ever. Most people don't do this. Apache doesn't force any
configuration, the server admin has control over how PHP is configured.

--
Curtis, http://dyersweb.com
Feb 23 '07 #13

P: n/a
Message-ID: <77***************@newsfe03.lgafrom Steve contained the
following:
>| >Is there a way i can look at the php code that is runnig a site, without
any
| >ind of admin access to the server?
|
| No.

are you trying to be funny, geof? that's about the most uninformed and
unimaginatively wrong answer as i've ever seen.
Well I don't really agree, but I see where you are coming from.
You could argue that any form of hacking is an attempt to get some kind
of admin access. In the normal course of events, barring a hacking
attempt or misconfigured server there is no way to 'look' at the php
code running the site.

Besides that, if you genuinely don't know the answer to the question the
answer of 'no' is probably quite reasonable.

Nevertheless, I apologise for not qualifying my answer more fully.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
Feb 23 '07 #14

P: n/a
On Feb 22, 8:45 pm, "Steve" <no....@example.comwrote:
"Rik" <luiheidsgoe...@hotmail.comwrote in message

news:op.tn6pvcviqnv3q9@misant...| Steve <no....@example.comwrote:

| find a server that parses all documents via php instead of by extension,
| ....
| >
| it's not hard to hack any site...it just takes a bit of knowledge and
| some desire.
|
| And in this case, both an insane webserver setting and a either no or a
| bogus check on files after upload... Usually it would be much, much
harder.

true. however sadly, *most* web servers (apache anyway) out there at least
parse all documents through php even if the extension is different...things
like .css or .jpg, or what have you. this is the critical part. as long as
this is the configuration, you can find *many* ways to get your script onto
their server. and you will have enough authorization to access any system
directory that php has access to...even those not in the web root.

this is not just a php issue, asp and others have the same problem. people
are not ever as aware as they should be when it comes to security. myself
included.
I personally always run uploaded images through a resize operation -
that would defeat your embedded php code, wouldn't it?

Feb 23 '07 #15

P: n/a
Steve wrote:
"Rik" <lu************@hotmail.comwrote in message
news:op.tn6pvcviqnv3q9@misant...
| Steve <no****@example.comwrote:
| find a server that parses all documents via php instead of by extension,
| ....
| >
| it's not hard to hack any site...it just takes a bit of knowledge and
| some desire.
|
| And in this case, both an insane webserver setting and a either no or a
| bogus check on files after upload... Usually it would be much, much
harder.

true. however sadly, *most* web servers (apache anyway) out there at least
parse all documents through php even if the extension is different...things
Do you have proof of this statement? I find just the opposite - very
few servers parse non-html files through PHP - and most of those who do
change when told about the security implications.
like .css or .jpg, or what have you. this is the critical part. as long as
this is the configuration, you can find *many* ways to get your script onto
their server. and you will have enough authorization to access any system
directory that php has access to...even those not in the web root.

this is not just a php issue, asp and others have the same problem. people
are not ever as aware as they should be when it comes to security. myself
included.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 23 '07 #16

P: n/a
On 23 Feb, 11:15, Jerry Stuckle <jstuck...@attglobal.netwrote:
Steve wrote:
"Rik" <luiheidsgoe...@hotmail.comwrote in message
news:op.tn6pvcviqnv3q9@misant...
| Steve <no....@example.comwrote:
| find a server that parses all documents via php instead of by extension,
| ....
| >
| it's not hard to hack any site...it just takes a bit of knowledge and
| some desire.
|
| And in this case, both an insane webserver setting and a either no or a
| bogus check on files after upload... Usually it would be much, much
harder.
true. however sadly, *most* web servers (apache anyway) out there at least
parse all documents through php even if the extension is different...things

Do you have proof of this statement? I find just the opposite - very
few servers parse non-html files through PHP - and most of those who do
change when told about the security implications.
like .css or .jpg, or what have you. this is the critical part. as long as
this is the configuration, you can find *many* ways to get your script onto
their server. and you will have enough authorization to access any system
directory that php has access to...even those not in the web root.
this is not just a php issue, asp and others have the same problem. people
are not ever as aware as they should be when it comes to security. myself
included.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
This is the only statement in my httpd.conf:

AddType application/x-httpd-php .php

and yet the attack works.
The server doesnt have to be set up to parse every doc for php, that
was an assumption.
Has anyone here tried it on their server?

Feb 23 '07 #17

P: n/a
I personally always run uploaded images through a resize operation -
that would defeat your embedded php code, wouldn't it?
yes it might well do depending on how you do it,
I just tried it using the DB library and it replaced the embedded php
code with:

CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 75

which is nice, but also a little bit rude.

Feb 23 '07 #18

P: n/a
On 23 Feb, 13:34, "shimmyshack" <matt.fa...@gmail.comwrote:
I personally always run uploaded images through a resize operation -
that would defeat your embedded php code, wouldn't it?
sorry to come back immediately but if you use imagemagick
convert <filenameresize geometry
and I guess therefore any other software that doesn't advertise itself
in the way GD does, then resizing doesnt work.

Feb 23 '07 #19

P: n/a

"shimmyshack" <ma********@gmail.comwrote in message
news:11*********************@k78g2000cwa.googlegro ups.com...
| On 23 Feb, 11:15, Jerry Stuckle <jstuck...@attglobal.netwrote:
| Steve wrote:
| "Rik" <luiheidsgoe...@hotmail.comwrote in message
| news:op.tn6pvcviqnv3q9@misant...
| | Steve <no....@example.comwrote:
| | find a server that parses all documents via php instead of by
extension,
| | ....
| | >
| | it's not hard to hack any site...it just takes a bit of knowledge
and
| | some desire.
| |
| | And in this case, both an insane webserver setting and a either no
or a
| | bogus check on files after upload... Usually it would be much, much
| harder.
| >
| true. however sadly, *most* web servers (apache anyway) out there at
least
| parse all documents through php even if the extension is
different...things
| >
| Do you have proof of this statement? I find just the opposite - very
| few servers parse non-html files through PHP - and most of those who do
| change when told about the security implications.
| >
| like .css or .jpg, or what have you. this is the critical part. as
long as
| this is the configuration, you can find *many* ways to get your script
onto
| their server. and you will have enough authorization to access any
system
| directory that php has access to...even those not in the web root.
| >
| this is not just a php issue, asp and others have the same problem.
people
| are not ever as aware as they should be when it comes to security.
myself
| included.
| >
| --
| ==================
| Remove the "x" from my email address
| Jerry Stuckle
| JDS Computer Training Corp.
| jstuck...@attglobal.net
| ==================
|
| This is the only statement in my httpd.conf:
|
| AddType application/x-httpd-php .php
|
| and yet the attack works.
| The server doesnt have to be set up to parse every doc for php, that
| was an assumption.

not an assumption...just a high-level, objective scenario that others may be
able to understand.

| Has anyone here tried it on their server?

probably not. :(
Feb 23 '07 #20

P: n/a

"Geoff Berrow" <bl******@ckdog.co.ukwrote in message
news:3p********************************@4ax.com...
| Message-ID: <77***************@newsfe03.lgafrom Steve contained the
| following:
|
| >| >Is there a way i can look at the php code that is runnig a site,
without
| >any
| >| >ind of admin access to the server?
| >|
| >| No.
| >
| >are you trying to be funny, geof? that's about the most uninformed and
| >unimaginatively wrong answer as i've ever seen.
|
| Well I don't really agree, but I see where you are coming from.
| You could argue that any form of hacking is an attempt to get some kind
| of admin access. In the normal course of events, barring a hacking
| attempt or misconfigured server there is no way to 'look' at the php
| code running the site.
|
| Besides that, if you genuinely don't know the answer to the question the
| answer of 'no' is probably quite reasonable.
|
| Nevertheless, I apologise for not qualifying my answer more fully.

geoff, it's not a big deal really. i was just surprised to hear that answer
from you. i'm also quite puzzled at your 'besides' answer now. if one
genuinely doesn't know the answer to a question, a response of 'i genuinely
don't know the answer' is the only logical one to make. you only have a one
in three chance of being correct by answering 'no'...and that's an illogical
modus apparandi anyway. the choices are generally 'yes', 'no', 'it depends'.
while 'i don't know' is a response, it is not an answer but much more
appropriate than just throwing 'no' out there.

cheers.
Feb 23 '07 #21

P: n/a
Message-ID: <oI***********@newsfe06.lgafrom Steve contained the
following:
>| Besides that, if you genuinely don't know the answer to the question the
| answer of 'no' is probably quite reasonable.
|
| Nevertheless, I apologise for not qualifying my answer more fully.

geoff, it's not a big deal really. i was just surprised to hear that answer
from you. i'm also quite puzzled at your 'besides' answer now.
I meant if the OP genuinely didn't know the answer. The fact that the
OP asked at all is a good indication that they would have little chance
of viewing php source code IYSWIM

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
Feb 23 '07 #22

P: n/a

"Geoff Berrow" <bl******@ckdog.co.ukwrote in message
news:7l********************************@4ax.com...
| Message-ID: <oI***********@newsfe06.lgafrom Steve contained the
| following:
|
| >| Besides that, if you genuinely don't know the answer to the question
the
| >| answer of 'no' is probably quite reasonable.
| >|
| >| Nevertheless, I apologise for not qualifying my answer more fully.
| >
| >geoff, it's not a big deal really. i was just surprised to hear that
answer
| >from you. i'm also quite puzzled at your 'besides' answer now.
|
| I meant if the OP genuinely didn't know the answer. The fact that the
| OP asked at all is a good indication that they would have little chance
| of viewing php source code IYSWIM

gotcha.

cheers.
Feb 23 '07 #23

P: n/a
Rik
shimmyshack <ma********@gmail.comwrote:
This is the only statement in my httpd.conf:

AddType application/x-httpd-php .php

and yet the attack works.
The server doesnt have to be set up to parse every doc for php, that
was an assumption.
Has anyone here tried it on their server?
Attack does not work here on the local server....
--
Rik Wasmus
Feb 23 '07 #24

P: n/a
shimmy,

would you be interested in working on a prototyped site tester called, say,
phpRaper? i can get all the information related to a site such as all the
path mapping for any file used by a site, the database being used, the db
user/pass to access the db, all the tables of the db, php_info-ed config,
etc.. your creativity in ways get that script to run on presumably secure
servers would be valued (the embedded code is one way but all exploits
should be exercised...and i become less and less familiar with the subject
the further down the chain i go). i'd post my code here with the intent of
people running it on their own site(s) so they can actually secure their
systems.

just a thought.
Feb 23 '07 #25

P: n/a
Rik
Rik <lu************@hotmail.comwrote:
shimmyshack <ma********@gmail.comwrote:
>This is the only statement in my httpd.conf:

AddType application/x-httpd-php .php

and yet the attack works.
The server doesnt have to be set up to parse every doc for php, that
was an assumption.
Has anyone here tried it on their server?

Attack does not work here on the local server....
And the live server is also safe :-)
--
Rik Wasmus
Feb 23 '07 #26

P: n/a
On 23 Feb, 15:47, Rik <luiheidsgoe...@hotmail.comwrote:
Rik <luiheidsgoe...@hotmail.comwrote:
shimmyshack <matt.fa...@gmail.comwrote:
This is the only statement in my httpd.conf:
AddType application/x-httpd-php .php
and yet the attack works.
The server doesnt have to be set up to parse every doc for php, that
was an assumption.
Has anyone here tried it on their server?
Attack does not work here on the local server....

And the live server is also safe :-)
--
Rik Wasmus
out of interest what are you running, is php a module, ta.

Feb 23 '07 #27

P: n/a
Rik
shimmyshack <ma********@gmail.comwrote:
Rik <luiheidsgoe...@hotmail.comwrote:
>Rik <luiheidsgoe...@hotmail.comwrote:
shimmyshack <matt.fa...@gmail.comwrote:
This is the only statement in my httpd.conf:
> AddType application/x-httpd-php .php
>and yet the attack works.
The server doesnt have to be set up to parse every doc for php, that
was an assumption.
Has anyone here tried it on their server?
Attack does not work here on the local server....

And the live server is also safe :-)

out of interest what are you running, is php a module, ta.
Homebox:
W2K, Apache 2.2.2, PHP 5.1.4 as a module.

Live server:
FreeBSD 5.3, Apache 2.0.54, PHP 4.4.2 (yes, still, goddamnit) as a module.

But it's all about configuration offcourse :P
--
Rik Wasmus
Feb 23 '07 #28

P: n/a
On 23 Feb, 18:02, Rik <luiheidsgoe...@hotmail.comwrote:
shimmyshack <matt.fa...@gmail.comwrote:
Rik <luiheidsgoe...@hotmail.comwrote:
Rik <luiheidsgoe...@hotmail.comwrote:
shimmyshack <matt.fa...@gmail.comwrote:
This is the only statement in my httpd.conf:
AddType application/x-httpd-php .php
and yet the attack works.
The server doesnt have to be set up to parse every doc for php, that
was an assumption.
Has anyone here tried it on their server?
Attack does not work here on the local server....
And the live server is also safe :-)
out of interest what are you running, is php a module, ta.

Homebox:
W2K, Apache 2.2.2, PHP 5.1.4 as a module.

Live server:
FreeBSD 5.3, Apache 2.0.54, PHP 4.4.2 (yes, still, goddamnit) as a module.

But it's all about configuration offcourse :P
--
Rik Wasmus
Rik,
Ive sent you an email to the hotmail address luihei...
just to help me clear up a few details. Thanks for the above details.

I should make it clear to anyone interested that the type of exploit
we're talking about does NOT involve saving php code with a jpg
extension and then calling it in a browser:

<?php system('echo hello hello.htm'); ?>
saved as hello.jpg, and then called using
htpp://server.com/hello.jpg

now that wouldn't usualy work unless you've asked your server to parse
jpgs looking for php code, which is why its a bad idea in general.

The type of attack that usually DOES work on a windows box is to embed
php code inside the binary header of a jpg, usually using a tool to do
it. Even if the server is set up to only parse .php files, it will
still execute the embedded php code inside a jpg.
more info see:
http://milw0rm.com/video/watch.php?id=57

do no evil

Feb 23 '07 #29

P: n/a

"Rik" <lu************@hotmail.comwrote in message
news:op.tn7q1znlqnv3q9@misant...
| shimmyshack <ma********@gmail.comwrote:
| Rik <luiheidsgoe...@hotmail.comwrote:
| >Rik <luiheidsgoe...@hotmail.comwrote:
| shimmyshack <matt.fa...@gmail.comwrote:
| >This is the only statement in my httpd.conf:
| >>
| > AddType application/x-httpd-php .php
| >>
| >and yet the attack works.
| >The server doesnt have to be set up to parse every doc for php, that
| >was an assumption.
| >Has anyone here tried it on their server?
| >>
| Attack does not work here on the local server....
| >>
| >And the live server is also safe :-)
| >
| out of interest what are you running, is php a module, ta.
|
| Homebox:
| W2K, Apache 2.2.2, PHP 5.1.4 as a module.
|
| Live server:
| FreeBSD 5.3, Apache 2.0.54, PHP 4.4.2 (yes, still, goddamnit) as a module.

lol. it feels that way some times don't it. ;^)
Feb 23 '07 #30

P: n/a
On 23 Feb, 18:38, "Steve" <no....@example.comwrote:
"Rik" <luiheidsgoe...@hotmail.comwrote in message

news:op.tn7q1znlqnv3q9@misant...| shimmyshack <matt.fa...@gmail.comwrote:
| Rik <luiheidsgoe...@hotmail.comwrote:

| >Rik <luiheidsgoe...@hotmail.comwrote:
| shimmyshack <matt.fa...@gmail.comwrote:
| >This is the only statement in my httpd.conf:
| >>
| > AddType application/x-httpd-php .php
| >>
| >and yet the attack works.
| >The server doesnt have to be set up to parse every doc for php, that
| >was an assumption.
| >Has anyone here tried it on their server?
| >>
| Attack does not work here on the local server....
| >>
| >And the live server is also safe :-)
| >
| out of interest what are you running, is php a module, ta.
|
| Homebox:
| W2K, Apache 2.2.2, PHP 5.1.4 as a module.
|
| Live server:
| FreeBSD 5.3, Apache 2.0.54, PHP 4.4.2 (yes, still, goddamnit) as a module.

lol. it feels that way some times don't it. ;^)
steve with regards your previous offer, the phrase "i'm not worthy"
flashes into my shrivelled brain. Although of course it would be fun,
have you taken a look at the great CAL9000 stuff from RSnake (http://
http://www.owasp.org/index.php/Categ...9000_Project)? While not
specifically aimed at server side pen testing, it is the vector by
which your code could be introduced.

Feb 23 '07 #31

P: n/a

"shimmyshack" <ma********@gmail.comwrote in message
news:11**********************@z35g2000cwz.googlegr oups.com...
| On 23 Feb, 18:38, "Steve" <no....@example.comwrote:
| "Rik" <luiheidsgoe...@hotmail.comwrote in message
| >
| news:op.tn7q1znlqnv3q9@misant...| shimmyshack <matt.fa...@gmail.com>
wrote:
| | Rik <luiheidsgoe...@hotmail.comwrote:
| >
| | >Rik <luiheidsgoe...@hotmail.comwrote:
| | shimmyshack <matt.fa...@gmail.comwrote:
| | >This is the only statement in my httpd.conf:
| | >>
| | > AddType application/x-httpd-php .php
| | >>
| | >and yet the attack works.
| | >The server doesnt have to be set up to parse every doc for php,
that
| | >was an assumption.
| | >Has anyone here tried it on their server?
| | >>
| | Attack does not work here on the local server....
| | >>
| | >And the live server is also safe :-)
| | >
| | out of interest what are you running, is php a module, ta.
| |
| | Homebox:
| | W2K, Apache 2.2.2, PHP 5.1.4 as a module.
| |
| | Live server:
| | FreeBSD 5.3, Apache 2.0.54, PHP 4.4.2 (yes, still, goddamnit) as a
module.
| >
| lol. it feels that way some times don't it. ;^)
|
| steve with regards your previous offer, the phrase "i'm not worthy"
| flashes into my shrivelled brain. Although of course it would be fun,
| have you taken a look at the great CAL9000 stuff from RSnake (http://
| http://www.owasp.org/index.php/Categ...9000_Project)? While not
| specifically aimed at server side pen testing, it is the vector by
| which your code could be introduced.

i'm pretty clueless with hacking methods not too far into the topic. i do
have script that 'inventories' a site. the information it provides is a good
documentation tool when presenting file dependencies or architecture...it is
also scary to believe that i could execute it on someone else's server.

i'll have a look at the link. the real test is knowing how to introduce the
script so that it can be executed. failing the test would mean that i know
more than enough about the site tested to control it at will. i'll have to
shelve it for a while till i can get to putting it all together.

cheers
Feb 23 '07 #32

P: n/a
On 23 Feb, 19:11, "Steve" <no....@example.comwrote:
"shimmyshack" <matt.fa...@gmail.comwrote in message

news:11**********************@z35g2000cwz.googlegr oups.com...
| On 23 Feb, 18:38, "Steve" <no....@example.comwrote:
| "Rik" <luiheidsgoe...@hotmail.comwrote in message
| >
| >news:op.tn7q1znlqnv3q9@misant...|shimmyshack <matt.fa...@gmail.com>
wrote:
| | Rik <luiheidsgoe...@hotmail.comwrote:
| >
| | >Rik <luiheidsgoe...@hotmail.comwrote:
| | shimmyshack <matt.fa...@gmail.comwrote:
| | >This is the only statement in my httpd.conf:
| | >>
| | > AddType application/x-httpd-php .php
| | >>
| | >and yet the attack works.
| | >The server doesnt have to be set up to parse every doc for php,
that
| | >was an assumption.
| | >Has anyone here tried it on their server?
| | >>
| | Attack does not work here on the local server....
| | >>
| | >And the live server is also safe :-)
| | >
| | out of interest what are you running, is php a module, ta.
| |
| | Homebox:
| | W2K, Apache 2.2.2, PHP 5.1.4 as a module.
| |
| | Live server:
| | FreeBSD 5.3, Apache 2.0.54, PHP 4.4.2 (yes, still, goddamnit) as a
module.
| >
| lol. it feels that way some times don't it. ;^)
|
| steve with regards your previous offer, the phrase "i'm not worthy"
| flashes into my shrivelled brain. Although of course it would be fun,
| have you taken a look at the great CAL9000 stuff from RSnake (http://
|http://www.owasp.org/index.php/Categ...Project)?While not
| specifically aimed at server side pen testing, it is the vector by
| which your code could be introduced.

i'm pretty clueless with hacking methods not too far into the topic. i do
have script that 'inventories' a site. the information it provides is a good
documentation tool when presenting file dependencies or architecture...it is
also scary to believe that i could execute it on someone else's server.

i'll have a look at the link. the real test is knowing how to introduce the
script so that it can be executed. failing the test would mean that i know
more than enough about the site tested to control it at will. i'll have to
shelve it for a while till i can get to putting it all together.

cheers
send me an email when you have time, and I'll do what I can to help in
any way I can, it sounds like a very interesting project, and useful
too. Might be a welcome addon to OWASP who have inttroduced the PHP
top ten and would support the ongoing effort into a project like this.
Not too sure about the name though!

Feb 23 '07 #33

P: n/a
Rik
shimmyshack <ma********@gmail.comwrote:
Rik <luiheidsgoe...@hotmail.comwrote:
Attack does not work here on the local server....
And the live server is also safe :-)
out of interest what are you running, is php a module, ta.

Homebox:
W2K, Apache 2.2.2, PHP 5.1.4 as a module.

Live server:
FreeBSD 5.3, Apache 2.0.54, PHP 4.4.2 (yes, still, goddamnit) as a
module.
Ive sent you an email to the hotmail address luihei...
just to help me clear up a few details. Thanks for the above details.
To answer publically: followed the little tutorial to the letter (well,
system('ls'); should be system('dir'); here), and no banana: clean output
of the php script in the image, and not my dir contents.

To tell you the truth: I haven't go the foggiest idea _why_ it works, so I
couldn't say which setting it is. I could mail you the main portions of my
apache config, but as it is apparantly a Windows vulnerability, any of
numerous windows settings could be the one that does it. Mind you, I do
have a very nlited version of W2K (google nlite, great for stripping down
unwanted bullshit from Windows), so I won't have you typical Windows
installation. Tomorrow I'll put XAMPP on a WXP64 box here, let's see what
that full installation does.

--
Rik Wasmus
Feb 23 '07 #34

P: n/a
shimmyshack wrote:
On 23 Feb, 11:15, Jerry Stuckle <jstuck...@attglobal.netwrote:
>Steve wrote:
>>"Rik" <luiheidsgoe...@hotmail.comwrote in message
news:op.tn6pvcviqnv3q9@misant...
| Steve <no....@example.comwrote:
| find a server that parses all documents via php instead of by extension,
| ....
| >
| it's not hard to hack any site...it just takes a bit of knowledge and
| some desire.
|
| And in this case, both an insane webserver setting and a either no or a
| bogus check on files after upload... Usually it would be much, much
harder.
true. however sadly, *most* web servers (apache anyway) out there at least
parse all documents through php even if the extension is different...things
Do you have proof of this statement? I find just the opposite - very
few servers parse non-html files through PHP - and most of those who do
change when told about the security implications.
>>like .css or .jpg, or what have you. this is the critical part. as long as
this is the configuration, you can find *many* ways to get your script onto
their server. and you will have enough authorization to access any system
directory that php has access to...even those not in the web root.
this is not just a php issue, asp and others have the same problem. people
are not ever as aware as they should be when it comes to security. myself
included.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

This is the only statement in my httpd.conf:

AddType application/x-httpd-php .php

and yet the attack works.
The server doesnt have to be set up to parse every doc for php, that
was an assumption.
Has anyone here tried it on their server?
The attack doesn't work either on my test system or any of my live
systems, either. Files containing PHP code which do not have the .php
extension are not parsed.

And where uploads are possible, files with a .php extension are not
allowed. So they're safe.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 23 '07 #35

This discussion thread is closed

Replies have been disabled for this discussion.