Web data BLEEDOUT: Users to feel the pain as Heartbleed bug revealed All over the world, systems administrators are scrambling to fix the OpenSSL “Heartbleed” bug. At the same time, certificate sellers are preparing rub currency all over their bodies as Web admins virtually swipe the corporate Amex to revoke and renew their certs. OpenSSL's history reaches back to Eric Young's SSLeay. While it …
Nice to see they've added Heartbleed testing - it didn't check for it yesterday as that site was my first port of call and flagged up all the servers I needed to test as green, but at least has flagged up the one I know has an issue with a big fat red F.
However, it does state that the Heartbleed check is experimental, so it may report a pass even if the server actually is vulnerable. Might be worth using a few different tests, including use openssl itself on a box local to the servers being tested to cut out any intermediate termination points that might be disguising the issue.
Although they do only list like the last 10 worst, and so many people use it, this list changes every second, so it isn't likely to become a lightening rod for attacks in about a second.
Not to mention the check box, which you can tick to not have your info displayed on the boards, right under the input box.
Telcobox = unsecure
mybox = secure
Use the telcobox for transport only and triple-play, then get LAN/WLAN and security from mybox only.
Of course, mybox must not be remotely managed, must not trust anything coming from telcobox and it should run one of the popular freewares (dd-wrt, openwrt, tomato).
Et voila.
Ask yourself:
•Can I easily find out if my router is running OpenSSL, and if so what version? (Answer: probably no)
- With OpenWRT this is pretty easy
•Can I easily upgrade to a secure version? (Answer: only if my vendor or the ISP that provided the hardware ships a firmware upgrade)
- With OpenWRT this is pretty easy
•Will old devices get upgraded? (Answer: probably not in a hurry and almost certainly not automatically)
- With OpenWRT this is pretty easy
•What can I do? (Answer: turn off remote management, if you can).
- Keep using open source router firmware? :)
it was open source that caused this problem in the first place.[Citation Needed]
You sure it wasn't someone making buggy code that caused this problem in the first place?
And the open source development model that made the bug more likely to be discovered and fixed?
...and the closed off, black box nature of shitty SoHo routers that prevents a lot of people from easily applying the fix?
Yes, yes and yes.
"But have they issued a patch yet?"
Uh, yes... Patched on the 8th of April, but compiling from source is not difficult either.
Confirming whether you're safe or not is as simple as:
# opkg list | grep openssl
Updating to the latest version is as easy as
# wget http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/libopenssl_1.0.1g-1_ar71xx.ipk
# wget http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/openssl-util_1.0.1g-1_ar71xx.ipk
# opkg install libopenssl_1.0.1g-1_ar71xx.ipk
# opkg install openssl-util_1.0.1g-1_ar71xx.ipk
# reboot
As far as "It was open source that caused the problem in the first case" - I don't even know whether to bother explaining the errors in logic. How does publishing the source code of a program cause it to be insecure? Either it's secure or it's not.
Oh, wait..........
Well, someone had to say it :-)
I've just bought an old Cisco router to try and get away from the bulk Soho consumer routers because Virgin Media won't fix bugs in their supplied product.
Now I have to go back to school to learn how to configure the blasted thing.
Oh, and given that it runs IOS how come Apple haven't sued Cisco yet?
Mine's the one with the infinite pockets to hold all the CLI manuals.
A Cisco 837 ADLS router, which copes with "Up to 8Mbps" just fine, may only cost £30 off the web. Cisco's web site has plenty of examples of how to configure various routers. You may have to get your head round Access Control Lists when locking the thing down or, worse, allowing some external access. You may not legitimately be able to maintain IOS – if that is of concern. But probably are much more secure option than whatever the ISP supplies.
Cheers
I have that router.
Its not really Cisco and it doesn't run IOS - it was badge engineered linksys I think. Whatever. Cisco bought a company to get into low end, and then sold it again.
http://en.wikipedia.org/wiki/Linksys
It is however a decent router with nearly all the features a geek needs and most importantly, they actually do work.
And it runs hotter than hell.
If it's old you might be fine. From what I can see the issue only affects the newer versions of openssl, older versions like 0.9.8 and below don't have the vulnerability, so some older kit will likely be fine. For instance Watchguard report some of their older firewalls are unaffected, and I believe CentOS 5.x is also fine as it doesn't support OpenSSL newer than 0.9.8, unlike any of the CentOS 6.x versions which have the newer one and therefore need looking at.
so: "it's nearly impossible for the average end user to work out what version of software a consumer broadband router is running."
Hmm. If the router is running linux, surely all I have to do is check the source code handily supplied to me by the manufacturer ... (ROFL)
wait, wait ... wasn't my ROFL big enough for you? Am I not allowed to chuckle at both (a) the idea of average users checking src code, and (b) manufacturers (not) supplying source code?
So you are admitting to performing a security probe without authorisation from the server owner? Congratulations on becoming a criminal.
Under what law? The special Internet law that doesn't exist?
Unless of course you know in which jurisdiction the OP resides, and can quote the relevant passages from the relevant acts verbatim.
I've always wondered *why* anyone would need to remotely manage their home router?
The only scenario I can think of is that the router is locked down super tight (static addresses for every device on the LAN) and the person adminning it is out of town for a couple of weeks when a family member buys a new device and wants to connect it to the LAN.
I suspect that remote management may include your ISP updating firmware on your router.
May also include remote management to fix finger trouble by unskilled users.
When routers are provided as part of a turnkey solution then remote support capability is more or less a given.
Store and access files on router connected storage.
Bittorrent
Music and movie streaming
Bandwidth and data management (caps)
Clueless family
DYN DNS type service
Whitelist or blacklist sites
Change traffic priority rules
Restart a consumer grade router that ran out of memory
See if your house is there after a disaster
There's probably a better way to do many of these things, but remote management through a simpler than setting a box up yourself webpage makes them so simple. I can remotely access my router, just in case. (Turned off atm until I can call support tomorrow)
I wonder how often the remote management is on by default in these devices? The ADSL+WLAN router I bough several years ago had it disabled, and after some thinking I left it that way, not seeing any good reasons to enable it, just lots of risks. But I could imagine some manufacturers having a different policy, in which case those devices are probably pwned by now.
While this vulnerability is rather catastrophic, you're looking for demons in additional places where they do not lie. To the extent that any of these home routers and access points bother with SSL _at all_, they are using self-signed certificates which are already insecure and worthless. Being able to steal the private key from a device using a self-signed certificate to begin with isn't much further of a vulnerability.
No I think you misunderstand. The vulnerability allows _all_ the memory on the device to be leaked (albeit in 64kb chunks). There could be _anything_ in there - I guess any web traffic sent in plain text will be visible (presumably anything encrypted in the browser would be fine)
Isn't the scope of the compromise limited to the type of hardware? For firmware devices with a simple process and memory model, I can see the compromise extending to _all_ the memory.
But for other devices, including the webservers at companies, it seems the access would be more limited. How can _all_ the memory be compromised when the OpenSSL library would be loaded inside a process context with memory protection that prevents you seeing the memory of other processes? It seems you should only get it for the particular process(es) using OpenSSL in support of each IP ports communications.
Why do you consider a self signed certificate worthless? I don't see how paying a 3rd party to sign your cert with their trusted root certificate makes things anymore secure, it just means browsers trust them by default.
If you add the self signed cert to your trusted certificates you'll know if someones trying to spoof your host or something funny is going on.
That's because the definition of self-signed certificates includes two types of certificates:
1) certificates created by a device/software during its installation process
2) certificates signed by a non-global CA
#1 above can, depending on the author of the installation script, create identical certificates on every device.
#2 is what you get when you build your own, internal, CA. Either using openssl and a handful of scripts or a package like ejbca. You can create certificates equal to, or better than, certificates issued by any global root CA. At nearly zero cost.
Have been using Mikrotik for my home routers for a couple of years now. Not only are they cheaper than your 'generic' consumer routers, but they are much better specified, and more configurable. I have no problems recommending them.
Add the fact that they're not susceptible to the current SSL issue, and it's all good.
I thought this vulnerability only related to 1.0.1 and later? Older OSes and routers etc may well be running 0.9.x or possibly earlier. RHEL5/Centos5 was on 0.9.8 the last time I looked, for example. Yes, I know RH backports some stuff so version numbers aren't always indicative, and maybe you rolled your own rather than using an rpm or .deb or whatever.
+1 insightful
It is pretty unlikely that SOHO gear is actually running 1.0.1. They are generally MIPS or ARM things that run some sort of ancient cut down *BSD. However, I would look at your NASs closely - QNAPs run Linux of some sort for starters. These quite often offer themselves up to the outside world for file sharing n cloudy cobblers.
pfSense 2.1.1 is not vulnerable and was released especially for this - it has 1.0.1g on it as well as a 0.9.x series for other stuff (don't ask!)
Cheers
Jon
In short, yes.
I'd recommend finding the IP of your router, most commonly 192.168.1.1 or 192.168.1.100 or 192.168.1.101 or 192.168.2.200 or 192.168.1.201 you already seem to know it's IP so you're a step ahead there. Type the addresses in one at a time and see if you get a webpage requesting a username and password, or a message about could not connect.
Once you've found the IP for the router you need to login, most commonly this will be Username: admin password: admin , Username: admin password: blank, do not type blank here leave password blank, username: administrator password: password If that gets you in, look on the router itself, if you're lucky/unlucky you'll find the username on the router. If so try that, if not, find the model number on the router and search in Google model number manual pdf , read that and you should find it.
Once you're logged in, there will be pages of settings arrayed either across the top of the page or the side go through those one by one, looking for options that say something along the lines of update router or check for firmware update. If you do click that and see what happens. pay attention to the date on the update, if it's before the 8th of April 2014 chances are it fixes other things and should be installed, but it doesn't fix the SSL issue if there is one with that device. If you don't find a firmware update from the 8th or later then you should logon to your router each week and do another check, for a month and then after that check for updates once a month. Alternatively if there is an auto update option select that. The second thing to look for is remote management or remote administration. If you see such an option make sure to deselect, or uncheck, or disable it.
Know that on many routers after you change settings on a page you must click update, confirm, or save at the bottom of the page. Otherwise the router will forget you made any changes. After you click the save button most routers will reboot, taking anywhere from 15-90 seconds or more. The router will usually inform you what to do.
Some would say it's best to disable UPNP (Universal Plug and play) while you're at it as that is often poorly done and has security issues, but UPNP makes games and file transfers to the internet work, in short so I wouldn't mess with that setting.
Or get the brand, and model number off your router and call support, but usually support is pretty worthless.
In general I'd recommend to anyone who doesn't already know the above to buy a copy of Windows For Dummies. I mean no insult by this suggestion. I've used a lot of computer books, and by far the for Dummies series is the clearest easiest, and most logical resource you'll find. It will take a person from not knowing where they saved a file on the computer to an advanced intermediate level of skill.
Good luck.
I'd recommend finding the IP of your router, most commonly 192.168.1.1 or 192.168.1.100 or 192.168.1.101 or 192.168.2.200 or 192.168.1.201
Or open a command line (hit the Windows start button and type 'cmd' then the return key). Then type 'ipconfig' and hit return. Amongst all the blergh, you'll have your active network interface. This will have a "default gateway" address. That'll be your router. Tap that address into your web browser.
Wireless LAN adapter Wireless Network Connection 2:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::1414:2f7d:2def:4e1d%18
IPv4 Address. . . . . . . . . . . : 192.168.43.92
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.43.1
Something like that!
Thanks for that. I "knew" that, but didn't think of it. That's a better solution, but mine doesn't involve the command line and in most cases that's exactly where you'll find consumer equipment. If fact I've never personally seen a consumer router out side of those default ips except where a user changed it.
Some consumer routers use 10.x.y.z addresses too.
I was going to suggest using the Javascript function myIpAddress() that can be used in Proxy Auto Config files to define which proxy server should be used depending on which subnet a user is on, but it doesn't seem to be accessible when used in a script embedded in a page - no doubt allowing a webpage to have access to that sort of information would be used for nusiance value far more often than it would be used to create helpful tools like pointing the user at their routers home page.
Having said all that, for most non-technical users, looking at the label on their router for a name and model number and then searching for "name model default IP address" is probably going to be the simplest approach.
They might even end up at http://www.routeripaddress.com/routers/ which seems to have already gathered much of this information, and the default username and passwords for a lot of consumer hardware.
"Ty Miller of Threat Intelligence agrees, telling The Register the end user would either have to work out how to retrieve the information from a command line connection to the device"
Command line? Sure if you have a 10 year old DSL modem. My first ADSL modem used telnet, but it was also plain text no SSL.
Any router or current modem has had a web interface where you could check the version, update software...
Biggest problem is when it's owned by the ISP and they lock it down and don't let you have the password.
"All over the world, systems administrators are scrambling to fix the OpenSSL “Heartbleed” bug."
07-Apr-2014: "OpenSSL 1.0.1g is now available, including bug and security fixes"
Unless OpenSSL plans to magically install the update for me and test, update and replace any potentially compromised devices and or certificates, (and write the reports for managements explaining the how and the why of the problem, and what was done about it), the mere existence of a fix doesn't mean that system administrators aren't scrambling to react to this issue.
•Can I easily find out if my router is running OpenSSL, and if so what version? (Answer: probably no)
Yes of course you can ......... simply ask the makers help desk, it is that simple.
All this talk of every router being affected is plain fiction. Ask your manufacturer if you could be affected.
I know my routers are safe,I asked the maker and got the answer in minutes.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
