SANS Internet Storm Center, InfoCON: green

According ot various reports, many users of Belkin routers are havingproblems connecting to the internet as of last night. It appears that the router will occasionally ping">heartbeat.belkin.com to detect network connectivity, but the heartbeat host is not reachable for some (all?) users. Currently, the host responds to ICMP">As a workaround, you can add an entry to the routers host file pointing heartbeat.belkin.com to 127.0.0.1. This appears to remove the block. The block only affects the DNS server on the device. It will route just fine. You can still get hosts on your network to work as long as you set a DNS server manually, for example using Googles DNS server at 8.8.8.8. .
For a statement from Belkin, seehttps://belkininternationalinc.statuspage.io
In a tweet, Belkin also pointed to this page on its community forum:http://community.belkin.com/t5/Wireless/Belkin-Routers-Internet-Outage/m-p/5796#M1466
---
Johannes B. Ullrich, Ph.D.STI|Twitter|LinkedIn
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Ever done a quick vulnerability check only to discover that someone found that vulnerability before you did and already had the system compromised?
During the early stages of a vulnerability scan, nmap is your friend just to quickly confirm what you got. In this case, the big surprise was that the firewall responded on port 4444. Anybody whoever dabbled with pentestingmay be familiar with this port: Metasploit uses port 4444 by default for its remote shell. Other then that, it is typically not used by any well known service.
So at this point, with a possible compromised network firewall, there isnt much point in going much further. A quick connect with netcat oddly enough let to an HTTP error. Upon furhter investigation, it tuns out the Sophosfirewalls use port 4444 for https remote administration. Typically, ports like 8000,8080 or 8443are used, but then again, maybe Sophos wanted to hide their port, or just be different.
---
Johannes B. Ullrich, Ph.D.STI|Twitter|LinkedIn
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Yesterday and today, a post on reddit.org caused quite a bit of uncertainty about the security of 1024 bit RSA keys if used with OpenSSL. The past referred to a presentation given at a cryptography conference, stating that 1024 Bit SSL keys can be factored with moderate resources (20 minutes on a Laptop). It was suggested that this is at least in part due to a bug in OpenSSL, which according to the post doesnt pick the random keys from the entire space available.
It looks more and more like the assertions made in the presentation are not true, or at least not as wide spread as claimed.
However, this doesnt mean you should go back to using 1024 bit keys. 1024 bit keys are considered weak, and it is estimated that 1024 keys will be broken easily in the near future due to advances in computer technology, even if no major weakness in the RSA algorithm or its implementation are found. NIST recommended phasing out 1024 bit keys at the end of last year.
So what should you do?
- Stop creating new 1024 bit RSA keys. Browsers will start to consider them invalid and many other software components already do so or will soon follow the browsers lead (I dont think any major CA will sign 1024 bit keys at this point)
- Inventory existing 1024 bit keys that you have, and consider replacing them.
There may be some holdouts. Embedded systems (again) sometimes cant create keys larger then 1024 bits. In this case, you may need to look into other controls.
With cryptograph in general, use the largest key size you can afford, for SSL, your options for RSA keys are typically 2048 and 4096 bits. If you can, got with 4096 bits.
[1]https://www.reddit.com/r/crypto/comments/2i9qke/openssl_bug_allows_rsa_1024_key_factorization_in/
---
Johannes B. Ullrich, Ph.D.STI|Twitter|LinkedIn
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.