Synology DSM 5.0-4493 Update 5 Released

Support – Synology – Network Attached Storage (NAS) DSM 5.0-4493 Update 5.

Synology has released another DSM 5 update. Only two fixes listed but one of them is a security fix:

Fixed a vulnerability that could allow servers to accept unauthorized access.

I updated my DS212J and DS1511+ without incident. While I do use encrypted folders I haven’t had a problem so I can’t verify that it fixed anything. I’ll update my DS212+ at the end of the day and post an update if I have any issues. The update of my DS212+ also went fine.

This is What’s Wrong With Security Reporting

Yahoo news picked up this story and it trended to the top (many others also carried it with the same sensationalization . While the meat of the story may have some good information (although not new information), the headline and conclusions are meant to draw clicks.


Your Gmail App Is Shockingly Easy to Hack

In the first paragraph:

..allows them access to mobile Gmail accounts with a 92 percent success rate.

What’s wrong with this? Well, for one the “hack” requires downloading a malicious app to your Android phone. And that 92% success rate? Only among those that download the malicious app.

Yes, it would be nice if shared memory could not me accessed. But that shared memory access also brings benefits (OK, I assume the benefits part. Don’t ask me to list them).

They didn’t test other mobile OS’s but say the hack should work on them too. I’m no developer but I thought on iOS shared memory wasn’t, well, shared by apps. Which resulted in many of the complaints about apps not working together. I’ve also read comments that apps don’t access shared memory on Windows Phone. So this calls into question that assumption by the researchers.

In any event it works on other mobile OS’s, even for Android the headline should be “Installing malicious app will cause security issue!” But I guess that falls into the non-clickworthy “duh” category.

Thoughts on Heartbleed

The Heartbleed vulnerability was made public on April 7th and I found a few things about it, and the reaction to it, interesting.

  • This XKCD comic has a straight-forward explanation of the vulnerability. The vulnerability can be used to collect random bits of information from a server’s memory. The attacker has no idea what they’ll get.
  • Lots of Heartbleed info from Codenomicon (the Finish company that found the vulnerability) is here. (Google also found the vulnerability at about the same time.)
  • I don’t need another reason to like LastPass as my password manager, but they gave me one. They put together a tool to look at the websites I use and determine which ones are vulnerable. Then they look at when the vulnerable sites last updated their SSL certificate and compare it to when it was updated to the non-vulnerable OpenSSL version. If the site is no longer vulnerable and the certificate was updated they then looks at my last password change date. If it was changed before the site was fully fixed I’m told to update my password. If the site isn’t fully fixed I’m told to wait.

LastPass Heartbleed check report

  • The vulnerability was introduced in December 2012 and coincidentally found by two separate researchers in March 2014. It was made public on April 7th. When it was first announced Bruce Schneier, a respected security researcher said “On the scale of 1 to 10, this is an 11.” With more information he’s backed off a bit and posted a nice update with a lot of links to more information. On the This Week In Tech podcast he mentioned that there wasn’t any widespread scanning being done before the public announcement so there probably wasn’t a lot of lost data, But the attacks started quickly after the public announcement.
  • It does appear that the vulnerability wasn’t widely exploited (if at all) until it went public April 7th. Seems true, if hard to believe, that it went unnoticed for over a year and then two independent teams found the vulnerability at the same time. (Codenomicon and Google.)
  • This is the first vulnerability that came with its own marketing campaign and logo.
    Heartbleed logo
    Not a bad idea to get people to take the necessary action.
  • If you haven’t logged into a website between April 7th and when the website was fixed your password wasn’t taken. The problem is knowing when the websites have been fixed. As mentioned, I’m using LastPass to identify vulnerable sites I use and when they were been fixed. The previously mentioned Bruce Schneier posts include some additional links but they’re tough for the average person to go through.  Unfortunately it’s tough to know which scanners can be trusted but this one has been reported as reliable. (But use at your own risk.) I tried a couple scanners and they worked poorly so no other links here.
  • In my case most of my financial websites weren’t vulnerable. I don’t know if that means most financial institutions don’t use OpenSSL or I just got lucky.
  • There are reports that the NSA knew of this and used it rather than reporting it. They’ve denied it. While I wouldn’t want to rely on NSA’s comments (they lied to congress) it makes sense that they didn’t use this. Based on the past disclosures it seems they have more reliable ways of getting the same information.
  • The Canada Revenue Agency reported that over 900 social insurance numbers were taken due to Heartbleed. I was skeptical. Was it Heartbleed or just found when reacting to Heartbleed? But it appears the site was vulnerable for 48 hours after the vulnerability became public. Since the hackers reacted quickly and this would be a high value target it does seem likely. So is the 900 number based on people who accessed the site in that 48 hours. There doesn’t seem to be any way to tell exactly what is taken.
  • Luckily I stopped doing my own hosting via on a virtual private server. This is something that would have had me up late updating software and regenerating certificates/keys since I used OpenSSL. Even though I didn’t maintain user accounts all my access to the server used OpenSSL. I liked running my own server but this is something I don’t miss.

Since there’s no way to know if your password was taken it’s probably time to start updating. It’s probably a good idea to change passwords anyway. I use complex password which are unique for the site so I don’t change them on a regular basis. If you don’t use a password manager it’s time to start so you can make all your passwords complex and unique. I prefer LastPass but there are others worth using. Since I don;t have experience with others I can’t recommend any in particular but 1Password and KeePass are frequently recommended by others.

Field Notes: Google Two-Factor Authentication

the Google Apps Logo

the Google Apps LogoThere’s been a lot of discussion recently about GMail’s two-factor authentication thanks to the Matt Honan hack publicity. I’ve been using it awhile and figured I’d share my thoughts and experiences. I had been using it for an account that I just used for email so it wasn’t much of a hassle. But I recently added it to a second Google account and it’s been more of a hassle. It’s probably needed more on this account, since it’s used for more than just email so I’ve kept it enabled. In the case of Google the two-factors are a password (something I know) and something I have (my phone).

Here are my notes from using Google’s Two Factor Authentication. For the record, I used my own domain with Google Apps accounts in both cases.

There’s plenty of backup available should I lose or break the phone with the authenticator app:

  • I have the Google App on my iPhone so I don’t need a cellular connection to get the code.
  • As backup I have another phone set up to get the code via SMS.
  • As another backup there’s also printable one-time backup codes. The assumption is that Google can keep these codes secure.

If an app or device doesn’t recognize Google Two-Factor authentication there are Application Specific passwords:

  • “Application Specific” is more a description of the intent, rather than a technical requirement.
  • The Application Specific passwords can be used on multiple devices and applications. I’d prefer they be locked to the first app or device they’re used on.
  • If you use the password in a malicious or poorly written app the password can be used my someone else to access your email. So common sense still needs to be used when using the application passwords.
  • While 16 characters is a long password it’s not as complex as it could be, All passwords are 16 characters and there seems to be a limited character set. While this could be more secure, it would still be extremely hard to crack and isn’t a reason not to use them.
  • The application specific passwords only provide limited access to the account, even if compromised, such as accessing email.
  • Application specific passwords are easy to revoke so they can be used to try out a new app and then revoked if the app isn’t used.
  • I’ve had some issues where my iPhone email (for example) decides it needs a new app password and I have to re-enter it. This is a pain as I have to go to the website and generate a new one then type it into the iPhone.
  • While I can see the last time the application password was used, I can’t tell where it is used, so if the password is taken I wouldn’t notice, unless I stopped using it.

Misc Notes:

  • The initial setup is a bit of a pain. When two-factor authentication is turned on all the existing logons will break and have to be redone.
  • PCs can be made “trusted” and then for the next 30 days it won’t be necessary to enter the code when logging on.
  • If Google Sync is used (in Google Chrome) it’s necessary to use a encryption passphrase specific to Google Sync, the account password can’t be used since an application specific password is required. Well actually, an app specific password can be used, but it would have to be remembered and used as the app password for all Google Chrome logons, which goes against the design of the application passwords.

Anyone else using Google two-factor authentication? What’s been your experience?