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
Current thread:
- Re: Need help. Proof of concept 100% security., (continued)
- Re: Need help. Proof of concept 100% security. Balwinder Singh (Aug 18)
- Re: Need help. Proof of concept 100% security. Kyle Roger Hofmann (Aug 19)
- Re: Need help. Proof of concept 100% security. Balwinder Singh (Aug 18)
- Re: Need help. Proof of concept 100% security. Crispin Cowan (Aug 15)
- Re: Need help. Proof of concept 100% security. Alaric B Snell (Aug 18)
- Re: Need help. Proof of concept 100% security. Anil Madhavapeddy (Aug 18)
- Re: Need help. Proof of concept 100% security. ari (Aug 20)
- Re: Need help. Proof of concept 100% security. Anil Madhavapeddy (Aug 18)
- Re: Need help. Proof of concept 100% security. Stefano Zanero (Aug 18)
- RE: Need help. Proof of concept 100% security. Joyce, MP (Matthew) (Aug 18)
- Re: Need help. Proof of concept 100% security. Evan Teran (Aug 18)
- Re: Need help. Proof of concept 100% security. xenophi1e (Aug 19)
- Re: Need help. Proof of concept 100% security. Balwinder Singh (Aug 21)