CSAM: Scary ports and firewall remote administration
Have you 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 who ever dabbled with pentesting may 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".
At this point, with a possible compromised network firewall, there isn't much point in going much further. A quick connect with netcat oddly enough let to an HTTP error. Upon further investigation, it tuns out that Sophos firewalls use port 4444 for https remote administration. Typically, ports like 8000, 8080 or 8443 are used, but then again, maybe Sophos wanted to "hide" their port, or just be different.
Belkin Router Apocalypse: heartbeat.belkin.com outage taking routers down
According ot various reports, many users of Belkin routers are having problems 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 echo requests, but apparently, many Belkin routers are still down.
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 Google's DNS server at 8.8.8.8. .
For a statement from Belkin, see https://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
Confusion over SSL and 1024 bit keys
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 doesn't 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 doesn't 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 browser's lead (I don't 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 can't 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/
Comments