full-disclosure - Re: Sony: No firewall and no patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <947004.42875.qm@web162012.mail.bf1.yahoo.com>
Date: Tue, 10 May 2011 10:52:48 -0700 (PDT)
From: Bruno Cesar Moreira de Souza <bcmsouza@...oo.com.br>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	RolandDobbins <rdobbins@...or.net>
Subject: Re: Sony: No firewall and no patches

--- On May 10, 2011, Dobbins, Roland <rdobbins@...or.net> escreveu:

> On May 10, 2011, at 10:56 PM, Bruno
> Cesar Moreira de Souza wrote:
> 
> > If the compromised server is not behind a stateful
> firewall, it will be easier to create a tunnel to access
> unauthorised ports (such as database network services) and
> attack other servers. 
> 
> 
> That's untrue if even the most basic BCPs for crafting and
> enforcing network access policies have been followed. 
> Plus, the moment the httpd stops working, that should ring
> alarm bells via even the most basic NMS/OSS monitoring.

How would you block an ACK tunnel using only a packet filter? (http://ntsecurity.nu/papers/acktunneling/) You don't need to stop the httpd service to create this kind of tunnel, as the packets from the attacker would just be ignored by the httpd service, but could be intercepted by the malicious code executed on the compromised server (using the same approach employed by network sniffers). 

> 
> > Even if the exploited vulnerability is fixed in a
> short time, the attacker will still be able to easily
> control the compromised server.
> 
> Not if it's taken offline and scrubbed down to the bare
> metal, as should be routine after a compromise.
> 

This is true IF the compromise was detected. I'm talking about the common case when the compromise is not detected, but after some time the vulnerability is fixed (for example, through patching).  If the attacker installed a backdoor in the compromised server, which uses a convert channel through your packet filter, then you may not detect the problem for a long time.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/