Qustion on viewing code

"Geoff Berrow" <blthecat@ckdog.co.uk> wrote in message
news:3p6tt2hsla80302qpae50v9lr5ruo8gf1p@4ax.com...
| Message-ID: <77uDh.506$f%2.460@newsfe03.lga> from 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.

Message-ID: <oICDh.3$yh6.0@newsfe06.lga> from 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

"Geoff Berrow" <blthecat@ckdog.co.uk> wrote in message
news:7lutt2hmnqb2t0c19639kldvrpvqrban7m@4ax.com...
| Message-ID: <oICDh.3$yh6.0@newsfe06.lga> from 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.

shimmyshack <matt.farey@gmail.com> wrote:
> 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

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.

Rik <luiheidsgoeroe@hotmail.com> wrote:
> shimmyshack <matt.farey@gmail.com> wrote:
>> 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

On 23 Feb, 15:47, Rik <luiheidsgoe...@hotmail.com> wrote:
> Rik <luiheidsgoe...@hotmail.com> wrote:
> > shimmyshack <matt.fa...@gmail.com> wrote:
> >> 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.

shimmyshack <matt.farey@gmail.com> wrote:
Rik <luiheidsgoe...@hotmail.com> wrote:
>> Rik <luiheidsgoe...@hotmail.com> wrote:
>> > shimmyshack <matt.fa...@gmail.com> wrote:
>> >> 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

On 23 Feb, 18:02, Rik <luiheidsgoe...@hotmail.com> wrote:
> shimmyshack <matt.fa...@gmail.com> wrote:
> Rik <luiheidsgoe...@hotmail.com> wrote:
> >> Rik <luiheidsgoe...@hotmail.com> wrote:
> >> > shimmyshack <matt.fa...@gmail.com> wrote:
> >> >> 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

"Rik" <luiheidsgoeroe@hotmail.com> wrote in message
news:op.tn7q1znlqnv3q9@misant...
| shimmyshack <matt.farey@gmail.com> wrote:
| Rik <luiheidsgoe...@hotmail.com> wrote:
| >> Rik <luiheidsgoe...@hotmail.com> wrote:
| >> > shimmyshack <matt.fa...@gmail.com> wrote:
| >> >> 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. ;^)