Last Updated: 2006-08-03 23:22:47 UTC
by Johannes Ullrich (Version: 1)
- This is less of an OS problem, but a firmware/driver issue. While the demo was done on a Mac, it would have worked on other OS's as well.
- Various wireless cards have problems, not just the once demoed at Blackhat.
- You do not have to be associated with a wireless network in order to be exposed.
- A firewall will not protect you.
- Turn off the wireless card (and bluetooth while you are at it).
- Watch for patches.
- To prepare for any patches, learn what type of wireless card you have.
Washington Post "Securityfix" blog (Brian Krebs)
Last Updated: 2006-08-03 02:52:10 UTC
by Jim Clausing (Version: 2)
Update 20:27 UTC: If Bugzilla can be belived, all this update does is fix an issue with "mms://" and related multi-media URLs that have been broken in 22.214.171.124. Apparently, not all updates rushed out while a Blackhat conference is going on have a sinister reason :-).
Update 03:48 UTC: Firefox 126.96.36.199 is formally released. The release notes confirm it fixes an issue with Windows Media.
Last Updated: 2006-08-02 18:41:18 UTC
by Daniel Wesemann (Version: 1)
server named: dispatch 0x8face08: shutting down due to TCP receive error: [IP REMOVED]#53: connection reset.
named: dispatch 0x81eb2b0: shutting down due to TCP receive error: <unknown address, family 48830>: connection reset
Update 18:30 UTC: It looks like we got the solution, or at least parts of it:
- Some DNS servers of "secureserver.net" are apparently broken and sometimes return incomplete records. Two DNS servers in particular, 188.8.131.52 and 184.108.40.206, are implicated in the majority of the "TCP receive error" packet traces that we have received.
- What happens is that "named" sends a UDP DNS query to one of the broken servers and receives a truncated UDP response. By nature of the DNS protocol, "named" re-tries the same query in TCP, which is answered by the broken servers with a rude "tcp reset" packet, which in turn again triggers "named" to write the above log line. This behaviour can be reproduced with "dig" as shown below:
daniel@debian:$ dig whatever.net @220.127.116.11
;; Truncated, retrying in TCP mode.
;; communications error to 18.104.22.168#53: connection reset
- Lookups against ISIPP's IADB spam / sender database seem to have ended up on the broken servers listed above from time to time, causing the "link" between receiving email and seeing the named log entries as reported by some readers
- The IP address in the named log does not seem to have anything to do with the IP that causes the problem. I have no idea where this logged IP comes from, but seeing that some versions are printing "address unknown" instead of an IP, I suspect that this error print statement is broken in several (older?) Bind releases
Last Updated: 2006-08-02 13:38:46 UTC
by Daniel Wesemann (Version: 1)
Not having a default route in the router network is a great way to minimise the impact of malware on the corporate environment. This practice enforces that gateways are used for all external communications.
- Enforces the use of proxy gateways for external communications.
- Malicious packets can be dropped or sent to a centralised server for analysis.
- Reduces the potential impact of misconfigured software through enforcing no internet connectivity.
- Makes malware infection easy to spot (if analysing all dropped packets).
Note that the above tip does not ask you to remove the default route off your end systems (user workstations) - chances are that many services needed in a corporate environment (like financial news feeds) will need to have a default route on the workstation. But if, in your network core, you can get away with only advertising and routing those external networks that are actually needed, you have made a huge step to secure your network. As indicated above, the newly un-used "default route" should then be made to point to a "darknet" where you have nothing except logging and packet collection capability.
Please choose a specific diary above to comment