('binary' encoding is not supported, stored as-is) In-Reply-To: <1061409854.1743.99.camelat_private> >3. Results of EFC are in front of you all. There have been 2000+ plus >attacks, still system is up and running without a reboot. All >applications are doing what they are supposed to do. All these >security loopholes and attacks have cost money in past. > Ok, hang on a second here. - 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... - 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. - It was not possible via the webshell.cgi to view the contents of numerous directories. Finally some visible signs of security. 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 Plain old don't work. Various people have pointed out why EFC's design can never be 100% secure, which is transparently obvious, really. From what I've seen the implementation is pretty broken as well, and I was trying to be forgiving. 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. 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. Cheers, ~x
This archive was generated by hypermail 2b30 : Tue Aug 19 2003 - 11:02:11 PDT