dslreports logo
    All Forums Hot Topics Gallery


how-to block ads

Search Topic:
share rss forum feed



1 recommendation

Heartbleed- Noob asks how does the avg home user identify problem devices

I'm still waiting for someone to post a plain-English, non-technical set of directions for the home user to determine which of their gizmos might be a problem?

Techy folks can say "server", but that doesn't mean much to the avg home user. Take me for instance, my service comes in to a VOIP cable modem (Motorola SBV5220), and from there to a wireless LAN (Netgear WGT624v3).

Then between us and visitors we have the usual suite of doodads that connect to the LAN.... Ipad, kindle, laptop & desktop PCs, tablets, etc. Various external devices like USB memory readers (and cards), drives, cameras, scanners, printers.

When will someone put out a picture (i.e., a table) with lay-person names of gizmos with a simple green, yellow, and red coding? "Green" (can't be vulnerable) "Red" (definitely need to check) "Yellow" (uncertain)

Meanwhile if you folks that know can offer advice on my Motorola modem or Netgear router, I would be especially grateful.

OH... yes.... sure I can go here

and put in various urls. But then I don't really know what the syntax means when it asks for command line this-and-that. Some examples for us know-nothings would be really helpful.

Newtown, PA

I'm in IT, but I am not an expert in the security field, so the following is how I understand it:

There is nothing a user can do to any of his devices to prevent the problem. It's as if a site you are using was hacked, and maybe your user id and password for that site were stolen, or could be stolen if the site hasn't patched the problem.

That being said, the odds of your information being stolen is small. Many sites were not affected at all, as they were using software that is not affected by this bug. See »mashable.com/2014/04/09/heartble···6&ctst=1 for a partial list showing affected and unaffected sites.

To take advantage of the bug, the baddies would need to constantly monitor the site (this requires additional hacking to accomplish, and is not easy) and try to grab the encryption key information needed to decrypt communications. If they get that, they would need to continue to monitor to try to intercept a user id and password being sent. It's not like they can use the key to get onto the site and download everyone's user id and password. The return on the effort for them just isn't there. Additionally, as far as anyone has determined, this bug, though existing for some time, was just discovered, and sites are patching the problem quickly.

In my opinion, this is much ado about very little. That being said, if you are worried, change your passwords on sites you are worried about. If you use the same password on more than one site, change them now, as that is a horribly bad thing to do anyway.


Melbourne, FL
reply to SAtLan

The devices that Heartbleed affects are not in your home, they are the machines out on the net that provide the websites.

What heartbleed does is let bad people get snapshors of random data out of the web server computer that has the bad OpenSSL software. That data isn't organized, but one can mine it, looking for valuable data. And there is no limit to the number of snapshots the can grab.

There is a XKCD cartoon that simply explains it here:




The word "server" is sort of ambiguous to us noobs. For example, my cable modem can function as DHCP "server". My router too, plus the router has various encryption/firewall bells/whistles.

Should us noobie home users assume (((((((( none )))))))))) of these "server" functions of those appliances use SSL? And what if I configured my home network with a central PC acting as an ethernet "server"?


Atlanta, GA
reply to SAtLan

Sort of on topic; what about those who have streaming devices such as Roku, Sony, etc. Not sure what their connection protocol is via the internet? Home security web cams, Nest devices, etc.



You bet that's on topic. We need a no brainer red/yellow/green checklist of the potentiality on all this crap. And when the next bug comes along, voila! We have a template for early rumor control.


Melbourne, FL
reply to SAtLan

There are a few home gizmos that use SSL. For instance you could have your gateway router (often a 802.11 access point) set up for remote HTTPS management (i.e. from the internet, not just the local network). Not something I'd recommend, but devices have that as an option. If its only enabled inside your local net then you'd only have to worry about people in your local net.

If you are running a HTTPS server on your PC, and have it exposed to the internet, then that might be an issue.

Probably the largest risk would be if you had a VPN running that used OpenSSL as the secure pipe. I understand that there are some aftermarket router firmware, like WRT54, that may have that. But for someone to exploit heartbleed, you'd have to accept a connection from the malefactor. More likely, the vulnerability would be at the other end of the pipe. If the malefactor bought a VPN account on the same remote endpoint you use, they could theoretically snapshot your data by chance at the remote endpoint, because it passed through that endpoint.

Hopefully even then it'd be a HTTPS session traversing the VPN, and therefore still be encrypted.

Most of this seems like sort of advanced network usage, so I am guessing it is unlikely you need to worry about someone on the internet exploiting heartbleed through your internet gateway.

But it is theoretically possible

Guruguy's post does raise an interesting idea about the webcam though. I do think some of those incorporate a HTTPS server. But besides the images, what data does the webcam contain? If its not in memory, its not something that can be peaked at. A password might be exposed I guess, if you used the same password on the webcam that you used somewhere important

There is a lack of sanity

Hamilton, ON
reply to SAtLan

The Original Post has legitimate concern here.

Cisco, Juniper and like vendors have various embedded equipment that also have been deemed effected by this vulnerability.


Thus it can be assumed that embedded devices that offer cryptography may be effected. For instance, some Linksys routers offer » for their web control panel. This requires there to be a cryptography library installed on that device — the fact many of these devices are propretary and their firmware is inaccessable

Likewise for devices with dd-wrt which apparently do contain the vulnerable libraries:


The fact all of the testing tools require the target of the test to be Internet-accessable does nothing to allow users to see if their devices can be effected. In the case of routers and like devices, this vulnerability could permit an adversary that has network access to probe the device's memory for an administrator password for that device. The adversary may be a guest to a family who's being allowed Internet access or a tenant at a rooming house where Internet use is centralized. In the latter, it'd be easy to use this attack to eventually re-route the other tenants' DNS requests to log what websites they visit and whatnot or to launch further attacks.

This has concequences for small business too where small business equipment isn't unlike the home situation and owners may not have the budget to secure their network using a consultation service. All it would take would be for one internet cafe user or employee with the know-how of this bug to acquire administration access to that device to potentially leverage that access to pursue further attacks.

Further, consider small businesses that have VPN terminators for employees to work from home, an internet-facing device but not really a "server" in the traditional sense. Many of the testing tools demand port 443 and will not permit people to use them on alternate ports or for non-HTTPS protocols that are secured by OpenSSL implementations.

While everyone's scrambling about the public-facing web servers in the world, it's difficult for people to secure their local networks or SSL-secured non-web services and to ensure they're secured against adversaries and the individual home user, small landlord, or small business owner isn't currently readily able to know if they are effected without receiving political run-around from the vendor of "we're dedicated to the security of our customers" that means nothing.

It may be at this point prudent for a developer to develop a standalone tool that can run locally that isn't just the POC (Proof of Concept) code, that can provide heads of households or IT administrators who do not have resources to call in expensive consultants to be able to test their networks.
--Kradorex Xeron
[an error occurred while processing this signature]

reply to SAtLan


The bottom line is there is nothing you can do on your end. This bug affects the servers you connect to (websites, etc.). Basically you have to "trust" them to update their OpenSLL stack.

This is the real issue with computer security nowadays -- a lot of the trouble is on the webserver's end (credit card breaches, password theft, etc.). Most of the time there is nothing the end user can do -- it's all up to the company or website to fix their shit.
Getting people to stop using windows is more or less the same as trying to get people to stop smoking tobacco products. They dont want to change; they are happy with slowly dying inside. -- munky99999

Bill In Michigan
Royal Oak, MI
·WOW Internet and..
reply to SAtLan

You got me searching for a good analogy to use with non-techies. Here's a quick one but someone else could do better ...

It's like bridges on the road have a flaw and can hurt people if not fixed. BUT... there's really no such thing as a list of cars that are safe to drive in this situation.



2 edits
reply to SAtLan

said by SAtLan:

I'm still waiting for someone to post a plain-English, non-technical set of directions for the home user to determine which of their gizmos might be a problem?

Heartbleed is an exploit that affects this specific implementation of SSL:

On 7 April the OpenSSL developers posted a fixed version (1.0.1g).

In your device maker's licensing credits they should list who's implementation of SSL they've employed. Usually it's in the TOU (aka "User Agreement" or "Licensing") document.

------- Commentary --------

Put yourself in a criminal's shoes. Would you bother trying to locate and infect Bob's home router when the same vulnerability exists on tens of thousands of commercial servers each of which has hundreds of thousands to millions of users who visit at a rates of thousands of times per hour?

As I understand it, Heartbleed is an imperfect tool for gathering complete info. At any one instance it can only grab a very small snippet of data held in memory (client or server) in the hope of eventually piecing together the criteria a server uses to generate keys. This is hugely scary to operators of high volume commercial server farms thus the dust-up. The rest of us need to change our website passwords but, as far as I can see, do not need to rush about worrying over our SoHo equipment. More like we might want to make a note to check into it in our spare time on some upcoming rainy weekend.

In the case of the average home LAN all you care about is turning off remote access (web logins) to the gateway router that sits between your LAN and the rest of the world. While you're at it disable wireless access to the router's control panel too: force use of an ethernet cable attachment to access the Control Panel.


Trenton, NJ
reply to SAtLan

I have used this to check. »filippo.io/Heartbleed/

Honor Our Heros, Our Armed Forces
Kokomo, IN

1 recommendation

reply to SAtLan

Additional info. Client side + embedded devices.

DD-WRT & Heartbleed OpenSSL bug
»DD-WRT & Heartbleed OpenSSL bug

The Other Side of Heartbleed - Client Vulnerabilities
*** Never Forget 9/11 ***