Suspicious files in /tmp
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
Suspicious files in /tmp
by kladizkov.thehome
::
Rate this Message:
Hi,
My firewall LFD, pulled out three perl scripts from /tmp. It was found to be executing in my server. I have attached the scripts along with this mail. Is this issue familiar to anyone? How can a script uploaded to /tmp be executed when it has noexec privilege? ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Matt D. Harris
::
Rate this Message:
They're being executed despite filesystem mount options because the
script isn't being executed, the perl interpretter is. The script is being read and interpretted by the perl interpretter. Interesting - I hadn't thought of this before. Some logic to check the underlying filesystem of a script before reading it would be a very cool addition to perl from a security standpoint. Wouldn't be a big performance hit at all just to check once every require, etc as well. It'd need to be somewhat platform specific. Anyways, it would be neat for someone to bring this up within the Perl community as a possible idea, and maybe consider python, ruby, and others as well. Then there're various shells... I tested bash and FreeBSD's /bin/sh, and neither of them respect the noexec mount flag on FreeBSD either. It seems like this should be a relatively easy problem to correct, at least for the most common platforms. It's a thought that I'm going to bring up with the FreeBSD guys and see what their reaction is. Thanks for bringing this up here. Take care, Matt kladizkov.thehome wrote: > Hi, > > My firewall LFD, pulled out three perl scripts from /tmp. It was found > to be executing in my server. I have attached the scripts along with > this mail. Is this issue familiar to anyone? > > How can a script uploaded to /tmp be executed when it has noexec privilege? > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This list sponsored by: SPI Dynamics > > ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper > It's as simple as placing additional SQL commands into a Web Form input box > giving hackers complete access to all your backend systems! Firewalls and IDS > will not stop such attacks because SQL Injections are NOT seen as intruders. > Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! > > https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E > -------------------------------------------------------------------------- ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Jamie Riden
::
Rate this Message:
Hi there,
It looks like the bot exploits a remote file include in mosConfig_absolute_path - I think this would be Mambo or a component of Mambo. It looks a lot like a compromise attempt I saw a year or so back - http://infosecwriters.com/texts.php?op=display&id=416 [pdf, sorry]. In the one I saw, initially, the mosConfig_absolute_path vulnerability was exploited to drop and execute a connect-back shell. (Cb.pl and cback seem to be connect back shells of the same type as I saw.) In mine, the connect back shell immediately downloaded a perl bot which had similar spreading code in it to your 'bot' file. (ie. search google for potentially vulnerable Mambo installs and attempt to exploit them.) Have you ever had Mambo on this box? Try grepping your apache logs for 'mosConfig_absolute_path=http' If it's any consolation, in the one I saw, they didn't bother to make the bot persistent after reboot, nor to install a rootkit. cheers, Jamie On 16/06/07, kladizkov.thehome <kladizkov.thehome@...> wrote: > Hi, > > My firewall LFD, pulled out three perl scripts from /tmp. It was found > to be executing in my server. I have attached the scripts along with > this mail. Is this issue familiar to anyone? > > How can a script uploaded to /tmp be executed when it has noexec privilege? > > > ------------------------------------------------------------------------- > This list sponsored by: SPI Dynamics > > ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper > It's as simple as placing additional SQL commands into a Web Form input box > giving hackers complete access to all your backend systems! Firewalls and IDS > will not stop such attacks because SQL Injections are NOT seen as intruders. > Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! -- Jamie Riden, CISSP / jamesr@... / jamie@... UK Honeynet Project: http://www.ukhoneynet.org/ ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Jamie Riden
::
Rate this Message:
On 16/06/07, kladizkov.thehome <kladizkov.thehome@...> wrote:
> Hi, > > My firewall LFD, pulled out three perl scripts from /tmp. It was found > to be executing in my server. I have attached the scripts along with > this mail. Is this issue familiar to anyone? Sorry, a bit more. See also this thread, where Daniel Cid noticed something similar: http://www.securityfocus.com/archive/75/433959/30/240/threaded > How can a script uploaded to /tmp be executed when it has noexec privilege? The initial shell was probably run with 'perl foo.pl', so execute permission wouldn't matter. jamie@pokey:~/test$ chmod a-x foo.pl jamie@pokey:~/test$ ls -l foo.pl -rw-r--r-- 1 jamie jamie 28 2007-06-18 18:11 foo.pl jamie@pokey:~/test$ perl foo.pl foo! cheers, Jamie -- Jamie Riden, CISSP / jamesr@... / jamie@... UK Honeynet Project: http://www.ukhoneynet.org/ ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Michal Zalewski
::
Rate this Message:
On Mon, 18 Jun 2007, Matt D. Harris wrote:
> Some logic to check the underlying filesystem of a script before reading > it would be a very cool addition to perl from a security standpoint. This is not necessarily a great idea: not only Perl is in no way special, but like most interpreters, it can be invoked to read scripts from stdin or any other "volatile" source, without the necessity to store them in a file. Most interpreters also accept include file search paths and various command-line switches that would make such restrictions pointless anyway. But, say we implement heavily-handed restricted mode for Perl. Should bash refuse to read from stdin and implement the same check? Gdb? Awk? Sed? Where do you draw the line? If you don't want your users to use interpreters, make these programs not executable by that user; there's really no other way without a major ovehaul of how un*xes are built. And even then, interpreters aside, "noexec" flag is *not* an effective method to stop the user from running custom code, and never was: - /lib/ld-linux.so.2 /tmp/myexec - LD_PRELOAD=/tmp/foo.so ls - etc, etc. /mz ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
|
|
|
Re: Suspicious files in /tmp
by Rainer Duffner
::
Rate this Message:
Am 18.06.2007 um 18:47 schrieb Matt D. Harris: > They're being executed despite filesystem mount options because the > script isn't being executed, the perl interpretter is. The script > is being read and interpretted by the perl interpretter. > Interesting - I hadn't thought of this before. Some logic to check > the underlying filesystem of a script before reading it would be a > very cool addition to perl from a security standpoint. Wouldn't be > a big performance hit at all just to check once every require, etc > as well. It'd need to be somewhat platform specific. Anyways, it > would be neat for someone to bring this up within the Perl > community as a possible idea, and maybe consider python, ruby, and > others as well. Then there're various shells... I tested bash and > FreeBSD's /bin/sh, and neither of them respect the noexec mount > flag on FreeBSD either. It seems like this should be a relatively > easy problem to correct, at least for the most common platforms. > It's a thought that I'm going to bring up with the FreeBSD guys and > see what their reaction is. Thanks for bringing this up here. > Take care, Matt > A quick google search turned up the hint to disallow access to perl (chmod 700 /usr/local/bin/perl, probably) and/or to write a wrapper for it. If you don't need CGI-scripts, you can chmod 700 it. If cronjobs etc. (not running as root) still need it, maybe use sudo. It's really a nuisance, all in all. If you've got a big installation, there might be literally hundrets of old pre-joomla mambos, old coppermines, galleries, phpBBs etc. waiting for exploitation. Not to forget the BCC-injection susceptible mail-forms and the "index.php?page=bla.html"-allow-furl-open=yes morons... cheers, Rainer -- Rainer Duffner CISSP, LPI, MCSE rainer@... ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Rainer Duffner
::
Rate this Message:
Am 18.06.2007 um 18:47 schrieb Matt D. Harris: > They're being executed despite filesystem mount options because the > script isn't being executed, the perl interpretter is. The script > is being I forgot: mod_security seems to be able to block it, too. But it needs some configuration - and it draws a bit performance. cheers, Rainer -- Rainer Duffner CISSP, LPI, MCSE rainer@... ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Matt D. Harris
::
Rate this Message:
A lot of times in an exploit scenario, you don't have access to stdin.
While the script could still be feasibly passed on the command line, this is a much greater restriction and would shut down a number of existing exploits. If you read further in my post, I do address that there're plenty of other interpretters around that would need to adhere as well. I don't see the ld_preload issue as being difficult to modify either, and furthermore not all exploit scenarios involve access to the env. Of course, I'm talking about mitigation here, it's far from a perfect solution, but for a web server environment where the "dump a file in /tmp and then execute it" vector is fairly common, it seems like a logical step for command interpretters to take. I don't think any of us see it as a perfect be-all-end-all solution to prevent web server compromises, but it's probably better than how it is now (the performance hit is negligible, and I don't see any other real down sides). If it even stops 5 out of 50 compromise attempts that get this far due to things like bad cgi or web server-interpretted code (php, asp, et al), then that's progress, and that's a good thing. I might be missing something though in terms of down sides... Take care, Matt Michal Zalewski wrote: > On Mon, 18 Jun 2007, Matt D. Harris wrote: > >> Some logic to check the underlying filesystem of a script before reading >> it would be a very cool addition to perl from a security standpoint. > > This is not necessarily a great idea: not only Perl is in no way special, > but like most interpreters, it can be invoked to read scripts from stdin > or any other "volatile" source, without the necessity to store them in a > file. Most interpreters also accept include file search paths and > various command-line switches that would make such restrictions > pointless anyway. > > But, say we implement heavily-handed restricted mode for Perl. Should bash > refuse to read from stdin and implement the same check? Gdb? Awk? Sed? > Where do you draw the line? > > If you don't want your users to use interpreters, make these programs not > executable by that user; there's really no other way without a major > ovehaul of how un*xes are built. > > And even then, interpreters aside, "noexec" flag is *not* an effective > method to stop the user from running custom code, and never was: > > - /lib/ld-linux.so.2 /tmp/myexec > - LD_PRELOAD=/tmp/foo.so ls > - etc, etc. > > /mz > ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Robin Sheat
::
Rate this Message:
On Tuesday 19 June 2007 04:47:13 Matt D. Harris wrote:
> They're being executed despite filesystem mount options because the > script isn't being executed, the perl interpretter is. Â The script is > being read and interpretted by the perl interpretter. I think it's also the case (I don't have a noexec partition handy to test on) that you can get around this by doing something like: /lib/ld-linux.so.2 /tmp/mybadbinary e.g.: /lib/ld-linux.so.2 /bin/ls noexec is at best an annoyance to an attacker rather than a real security measure. Of course, it would be nice to see a check in interpreters just to make things that much trickier. -- Robin <robin@...> JabberID: <eythian@...> Hostes alienigeni me abduxerunt. Qui annus est? PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D |
|
|
Re: Suspicious files in /tmp
by Michal Zalewski
::
Rate this Message:
On Mon, 18 Jun 2007, Matt D. Harris wrote:
> A lot of times in an exploit scenario, you don't have access to stdin. Why not? If you can call execve, you can go for sh -c 'echo "foo()" | perl -' instead of calling perl interpreter directly. Or use pipe() + fork(). > While the script could still be feasibly passed on the command line, > this is a much greater restriction and would shut down a number of > existing exploits. *Existing* exploits usually have little to do with invoking perl - and unless you're fearing local account attacks (unlikely on a firewall?), little to do with creating executable files in /tmp. All it takes to stop most of common exploits is to disallow /bin/sh invoked with stream socket stdin or *id/e*id discrepancies. If you want to defend yourself against off-the-shelf attacks, perl restrictions and noexec are of probably of least use; and if you want to defend yourself against clever, targeted attacks - very much the same... /mz ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
|
|
|
Re: Suspicious files in /tmp
by Valdis.Kletnieks
::
Rate this Message:
On Tue, 19 Jun 2007 13:33:21 +1200, Robin Sheat said:
> I think it's also the case (I don't have a noexec partition handy to test on) > that you can get around this by doing something like: > /lib/ld-linux.so.2 /tmp/mybadbinary > e.g.: > /lib/ld-linux.so.2 /bin/ls This particular trick was closed in the 2.6.0 kernel. I am *not* sure whether the fix was backported to the 2.4 kernel or not. |
|
|
RE: Suspicious files in /tmp
by Thyago Braga da Silva
::
Rate this Message:
A binary which you have NOT permission to execute but only to read, it can
be executed. Follows an example note: [dx@foobar ~]$ ./prog checking... [dx@foobar ~]$ su Password: [root@foobar dx]# chmod 754 prog [root@foobar dx]# chown root:root prog [root@foobar dx]# exit [dx@foobar ~]$ ./prog -bash: ./prog: Permission denied [dx@foobar ~]$ ls -l prog -rwxr-xr-- 1 root root 4690 May 24 18:47 prog [dx@foobar ~]$ /lib/ld-linux.so.2 ./prog checking... [dx@foobar ~]$ Taking a look at strace's output we can note this: [dx@foobar ~]$ strace -fiv /lib/ld-linux.so.2 ./prog [ffffe405] execve("/lib/ld-linux.so.2", ["/lib/ld-linux.so.2", "./prog"], ["HOSTNAME=foobar", "TERM=xterm", "SHELL=/bin/bash", "HISTSIZE=1000", "SSH_CLIENT=localhost 1573 6"..., "SSH_TTY=/dev/pts/4", "USER=dx", "LS_COLORS=no=00:fi=00:di=00;34:l"..., "MAIL=/var/spool/mail/dx", "PATH=/usr/kerberos/bin:/usr/loca"..., "INPUTRC=/etc/inputrc", "PWD=/home/dx", "SHLVL=1", "HOME=/home/dx", "LOGNAME=dx", "SSH_CONNECTION=201.51.165.190 15"..., "LESSOPEN=|/usr/bin/lesspipe.sh %"..., "G_BROKEN_FILENAMES=1", "_=/usr/bin/strace"]) = 0 [56568deb] brk(0) = 0x56570000 [56569814] open("./prog", O_RDONLY) = 3 [56569894] read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\340\202"..., 512) = 512 [565697d6] fstat64(3, {st_dev=makedev(9, 1), st_ino=16453004, st_mode=S_IFREG|0754, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=16, st_size=4690, st_atime=2007/05/24-18:54:19, st_mtime=2007/05/24-18:47:51, st_ctime=2007/05/24-18:48:42}) = 0 [565699e6] getcwd("/home/dx", 128) = 9 [56569a43] mmap2(0x8048000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x8048000 [56569a43] mmap2(0x8049000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x8049000 [5656984d] close(3) = 0 [56569a43] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f29000 The programs ld.so and ld-linux.so* find and load the shared libraries needed by a program, prepare the program to run, and then run it. If an application opens a file for reading and 'maps' it content into it's own pages (copy+resetting permissions), then it's would be legal (kernel-wise) to execute the page. The kernel won't allow to execute the binary straight off, because it doesn't have an 'x' on its pages. It would be possible to run it, even though it doesn't explicity have eXecutable flag. -----Mensagem original----- De: Valdis.Kletnieks@... [mailto:Valdis.Kletnieks@...] Enviada em: Wednesday, June 20, 2007 1:47 PM Para: Robin Sheat Cc: incidents@... Assunto: Re: Suspicious files in /tmp On Tue, 19 Jun 2007 13:33:21 +1200, Robin Sheat said: > I think it's also the case (I don't have a noexec partition handy to > test on) that you can get around this by doing something like: > /lib/ld-linux.so.2 /tmp/mybadbinary > e.g.: > /lib/ld-linux.so.2 /bin/ls This particular trick was closed in the 2.6.0 kernel. I am *not* sure whether the fix was backported to the 2.4 kernel or not. ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Remko Lodder-2
::
Rate this Message:
Hello Matt,
Indeed FreeBSD doesn't respect the cases where a shell script is on a noexec mounted device; but where /bin/sh is still executable (/bin/sh /tmp/script for example). From the Manual page this should be clear that it is not designed as a security measure but to aid other activities; it is unlikely that we (see the archives for more information, this had been discussed a couple of times) will change this behaviour (since the design isn't for security): mount(8): noexec Do not allow execution of any binaries on the mounted file system. This option is useful for a server that has file systems containing binaries for architectures other than its own. Note: This option was not designed as a security feature and no guarantee is made that it will prevent malicious code execution; for example, it is still possible to execute scripts which reside on a noexec mounted partition. Hope this helps aiding you a bit with the information we can deliver. Regards, Remko On Mon, June 18, 2007 6:47 pm, Matt D. Harris wrote: > They're being executed despite filesystem mount options because the > script isn't being executed, the perl interpretter is. The script is > being read and interpretted by the perl interpretter. Interesting - I > hadn't thought of this before. Some logic to check the underlying > filesystem of a script before reading it would be a very cool addition > to perl from a security standpoint. Wouldn't be a big performance hit > at all just to check once every require, etc as well. It'd need to be > somewhat platform specific. Anyways, it would be neat for someone to > bring this up within the Perl community as a possible idea, and maybe > consider python, ruby, and others as well. Then there're various > shells... I tested bash and FreeBSD's /bin/sh, and neither of them > respect the noexec mount flag on FreeBSD either. It seems like this > should be a relatively easy problem to correct, at least for the most > common platforms. It's a thought that I'm going to bring up with the > FreeBSD guys and see what their reaction is. Thanks for bringing this > up here. Take care, Matt > > kladizkov.thehome wrote: >> Hi, >> >> My firewall LFD, pulled out three perl scripts from /tmp. It was found >> to be executing in my server. I have attached the scripts along with >> this mail. Is this issue familiar to anyone? >> >> How can a script uploaded to /tmp be executed when it has noexec >> privilege? >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> This list sponsored by: SPI Dynamics >> >> ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper >> It's as simple as placing additional SQL commands into a Web Form input >> box >> giving hackers complete access to all your backend systems! Firewalls >> and IDS >> will not stop such attacks because SQL Injections are NOT seen as >> intruders. >> Download this *FREE* white paper from SPI Dynamics for a complete guide >> to protection! >> >> https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E >> -------------------------------------------------------------------------- > > ------------------------------------------------------------------------- > This list sponsored by: SPI Dynamics > > ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper > It's as simple as placing additional SQL commands into a Web Form input > box > giving hackers complete access to all your backend systems! Firewalls and > IDS > will not stop such attacks because SQL Injections are NOT seen as > intruders. > Download this *FREE* white paper from SPI Dynamics for a complete guide to > protection! > > https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E > -------------------------------------------------------------------------- > > -- Kind regards, Remko Lodder ** remko@... FreeBSD ** remko@... /* Quis custodiet ipsos custodes */ ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
RE: Suspicious files in /tmp
by Kanedaaa Bohater
::
Rate this Message:
On Wed, 20 Jun 2007, Thyago Braga da Silva wrote:
:] A binary which you have NOT permission to execute but only to read, it can :] be executed. Morning... On 2.6 kernel its not possible JUST run directly from noexec partition: [@ogoreczek ~]$ /lib/ld-linux.so.2 /tmp/ls /tmp/ls: error while loading shared libraries: /tmp/ls: failed to map segment from shared object: Operation not permitted /dev/hda2 on /tmp type ext3 (rw,noexec) but of course You can still use other interpreter: [@ogoreczek /tmp]$ /usr/bin/perl /tmp/a.pl lpr [@ogoreczek /tmp]$ /lib/ld-linux.so.2 /usr/bin/perl /tmp/a.pl lpr [@ogoreczek /tmp]$ cat a.pl #!/usr/bin/perl print "lpr\n"; Kanedaaa :] :] On Tue, 19 Jun 2007 13:33:21 +1200, Robin Sheat said: :] > I think it's also the case (I don't have a noexec partition handy to :] > test on) that you can get around this by doing something like: :] > /lib/ld-linux.so.2 /tmp/mybadbinary :] > e.g.: :] > /lib/ld-linux.so.2 /bin/ls :] :] This particular trick was closed in the 2.6.0 kernel. I am *not* sure :] whether the fix was backported to the 2.4 kernel or not. :] -- [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][].. [+] You can take our lives,but you will never take our Freedom - W.Wallace [+] Peace on earth depends on the peace in the peoples hearts - Dalai Lama [+] Revolution the only solution - System of a down... [+] Dalej idac dalej dojdziesz dalej siedzac dalej siedzisz - etoe aka ok0 [-] Kanedaaa... Bohateur... Cucumber Team Member... kaneda@... ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Cy Schubert-3
::
Rate this Message:
In message <46277.194.74.82.3.1182425927.squirrel@...>,
"Remko Lodder" writes: > Hello Matt, > > Indeed FreeBSD doesn't respect the cases where a shell script is on a > noexec mounted device; but where /bin/sh is still executable (/bin/sh > /tmp/script for example). From the Manual page this should be clear that > it is not designed as a security measure but to aid other activities; it > is unlikely that we (see the archives for more information, this had been > discussed a couple of times) will change this behaviour (since the design > isn't for > security): > > mount(8): > > noexec Do not allow execution of any binaries on the mounted > file system. This option is useful for a server that > has > file systems containing binaries for architectures other > than its own. Note: This option was not designed as a > security feature and no guarantee is made that it will > prevent malicious code execution; for example, it is > still possible to execute scripts which reside on a > noexec mounted partition. > > > Hope this helps aiding you a bit with the information we can deliver. All that is needed to execute a shell script is read access. -- Cheers, Cy Schubert <Cy.Schubert@...> FreeBSD UNIX: <cy@...> Web: http://www.FreeBSD.org e**(i*pi)+1=0 ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
|
|
Re: Suspicious files in /tmp
by Eduardo Tongson
::
Rate this Message:
On 6/22/07, kaneda@... <kaneda@...> wrote:
> On Wed, 20 Jun 2007, Thyago Braga da Silva wrote: > > :] A binary which you have NOT permission to execute but only to read, it can > :] be executed. > > Morning... > > On 2.6 kernel its not possible JUST run directly from noexec partition: <...> Don't be misinformed. Vanilla 2.6.xx is not completely protected. On 2.6.20 you can still run files on noexec mounts with ld-linux. You only need read access. Get http://rootshell.be/~tongson/hello.bin. Save to a noexec mount. $ /lib/ld-linux.so.2 /dev/shm/hello.bin Hello world! Regards, E ------------------------------------------------------------------------- This list sponsored by: SPI Dynamics ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection! https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E -------------------------------------------------------------------------- |
suspicious.tar (68K) 
| Free embeddable forum powered by Nabble | Forum Help |
