Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: Need help. Proof of concept 100% security.
From: Balwinder Singh <balwinder () trustedmachines com>
Date: 20 Aug 2003 18:46:41 +0530

------------------------------------------------------------------------
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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]