Message-ID: <1061385401.1922.82.camel@limit.tm.org>
Date: 20 Aug 2003 18:46:41 +0530
From: Balwinder Singh <balwinder@...stedmachines.com>
To: xenophi1e <oliver.lavery@...patico.ca>
Cc: bugtraq@...urityfocus.com
Subject: Re: Need help. Proof of concept 100% security.


------------------------------------------------------------------------
Note: server 203.197.88.14 has been brought down as contract period with
ISP has expired. Please do not set your exploits for that IP now.
------------------------------------------------------------------------

Webshell was provided to view logs by typing more /var/log/messages, so
that you can find out where your exploit is failing. There are so many
holes in the system, real guys should exploit them. Also on real servers
one may not find webshell kind of applications. 

> 
> - It's already been pointed out on vuln-watch that it is possible to view 
> 
> the contents of /etc/shadow using the webshell.cgi located 
> 
> in /var/www/cgi-bin/. This is just the result of a bad path check, so I 
> 
> thought I would hammer on EFC a bit more...

shadow can be obtained by exploiting ftpd,sshd also. This is a weak
link, which has been pointed out by many guys. My last post talked about
it and a probable solution.


> - It was possible using the webshell.cgi to dump the full contents 
> 
> of /dev/hd* through the web. This bypasses EFCs filesystem restrictions 
> 
> in a obvious way. Again maybe just bad configuration.

Again another creative use of webshell, I had never thought giving 
"more /dev/hda*" in webshell. What all partitions you copied, I hope
bandwidth usage does not go beyond 5GB. 


> Unfortunately it was possible to bypass these restrictions by accessing 
> 
> the same directories via the proc filesystem ( /proc/N/root/whatever-
> 
> directory ). This is clearly a flaw in EFC's checks. I imagine a hard-
> 
> link would have worked as well. This made it possible to obtain a copy of 
> 
> efcm.o, the EFC kernel module, as well as all of the configuration 
> 
> information available in /var/efc/. In fact it was possible to read any 
> 
> file on any filesystem. Good thing there wasn't anything sensitive 
> 
> in /home/bal, although thank you very much for the collection of 
> 
> precompiled exploits... 
> 
> 
> 
> So clearly rules like:
> 
> open /var/www/html/* /usr/sbin/httpd

This is the kind of feedback I was looking for. Thanks for pointing this
out. This flaw will be fixed in next version.


>   Maybe EFC is providing some protection against shellcode, but from what 
> 
> I could tell from /proc/efc/, all of the shellcodes being run against it 
> 
> were failing on a socketcall. I'm guessing the protection is generally as 
> 
> solid as it appears, which is to say not very, and a somewhat cleverly 
> 
> crafted shellcode could get through without much trouble. From what I 
> 
> could tell from /var/efc/db/usr/sbin/sshd, sshd was allowed to 
> 
> access /etc/shadow. So I'm guessing one could read the contents back 
> 
> through the open socket to sshd without much trouble and then crack them 
> 
> offline. Maybe the syscall restrictions are clever and take ordering into 
> 
> account, or maybe they take the value of EIP at the time of the call into 
> 
> account, unless you can point out something novel your doing, common 
> 
> sense dictates that breaking these schemes is just a question of writing 
> 
> a smart shellcode.

Syscall restriction does not take ordering into account. Each syscall has
two flags attached more can be added. One flag is NEED_AUTH and another
is NEED_CHROOT. For programs which require authentication(GATES) NEED_AUTH
bit is set after successful authentication via libpam. So causing sshd,ftpd
to run shell without authentication should not work.
Similarly for programs which call chroot, NEED_CHROOT is set after call to
chroot. This might help for programs like ftpd.

 
> Seriously, you should release the source instead of holding silly h4x0r 
> 
> cockfights, this isn't a bad idea, but breaking it in it's current state 
> 
> isn't worth the trouble. 

I had no other option but to put this server up and I see nothing wrong in it.
Live net experience is different from lab testing.
Let me prepare tar.gz with some READMEs befor releasing the code. May take two days.
Detailed logs will be available describing where exploits failed but again will take
some time as logs are huge, alone messages file has grown to 22Mb during last week.

Little deviation from model: Does someone has some links pointing to the employment
generated by GPL SW distributer companies and layoffs caused by companies which
are loosing to linux? If not now will this be a problem in future? 
Can somebody enlighten me on this?

Thanks

Powered by blists - more mailing lists