Monthly Archives: October 2014

Panda Security

Six tips to make sure your personal photos don’t end up on the Web like those of Jennifer Lawrence

girl-with-computer

Increasingly, personal and private information is ending up on public view on the Internet. You may not have posted it yourself, you might have just stored it in the cloud, yet some ill-intentioned individual can access and publish it. Photos, videos and other personal data can easily fall into the wrong hands without your permission.

Since last September, more than 100 celebrities have been victims of this type of invasion of privacy. After having uploaded compromising photos to the Apple iCloud, they discovered these images posted on the Web. Someone had accessed and leaked the pictures.

All eyes then turned to Apple. The attack was caused by a security flaw on its mobile devices. A cyber-criminal claimed to have hacked the company’s services to get hold of the images, although the company has rejected this claim on several occasions.

Nevertheless, here we offer six tips to help protect your photos… just in case!

IMAGEN 1C

1. Be careful about what you store in the cloud

If these actresses and models hadn’t uploaded compromising images, it would have been considerably harder for the hackers to get hold of them. Even if you are not a public figure, it’s always a good idea to think about what kind of things you want to store on your phone.

2. Don’t share your account user names or passwords with others

Even though a friend or colleague may have your complete trust, the fewer people who know your credentials, the less chance there is of others finding out. Most online platforms (Facebook, Apple, Google and Yahoo) allow you to boost security with two-factor authentication. If available, it is always a good idea to use it. It basically involves another step in the verification of the user’s identity. This could involve generating a code that the page sends to your phone or another means of contact to verify your identity.

3. Strengthen your passwords to make sure they can’t be guessed by cyber-criminals

One useful tip is for them to contain a mix of numbers, special characters and upper and lower case letters, i.e. make them has complex and varied as possible. The same goes for your Wi-Fi password. It’s also a good idea to change them frequently.

apple-id

4.  With email, it’s wise to have different addresses for different purposes

Use different accounts for professional, personal or financial affairs. If somebody manages to gain access to one, at least all your data won’t be at risk.

5. Take care with your profile on social networks

Check the privacy options from time to time as sometimes they can be changed or the default settings are re-established without notice. And be careful with what you post online.

6. Use a good antivirus

It will not only keep your computer virus-free but will also identity and help keep Internet fraudsters at bay when, for example, you’re shopping online. Find the antivirus that best meets your needs from out 2015 product lineup.

The post Six tips to make sure your personal photos don’t end up on the Web like those of Jennifer Lawrence appeared first on MediaCenter Panda Security.

Redhat

Can SSL 3.0 be fixed? An analysis of the POODLE attack.

SSL and TLS are cryptographic protocols which allow users to securely communicate over the Internet. Their development history is no different from other standards on the Internet. Security flaws were found with older versions and other improvements were required as technology progressed (for example elliptic curve cryptography or ECC), which led to the creation of newer versions of the protocol.

It is easier to write newer standards, and maybe even implement them in code, than to adapt existing ones while maintaining backward compatibility. The widespread use of SSL/TLS to secure traffic on the Internet makes a uniform update difficult. This is especially true for hardware and embedded devices such as routers and consumer electronics which may receive infrequent updates from their vendors.

The fact that legacy systems and protocols need to be supported, even though more secure options are available, has lead to the inclusion of a version negotiation mechanism in SSL/TLS protocols. This mechanism allows a client and a server to communicate even if the highest SSL/TLS version they support is not identical. The client indicates the highest version it supports in its ClientHello handshake message, then the server picks the highest version supported by both the client and the server, then communicates this version back to the client in its ServerHello handshake message. The SSL/TLS protocols implement protections to prevent a man-in-the-middle (MITM) attacker from being able to tamper with handshake messages that force the use of a protocol version lower than the highest version supported by both the client and the server.

Most popular browsers implement a different out-of-band mechanism for fallback to earlier protocol versions. Some SSL/TLS implementations do not correctly handle cases when a connecting client supports a newer TLS protocol version than supported by the server, or when certain TLS extensions are used. Instead of negotiating the highest TLS version supported by the server the connection attempt may fail. As a workaround, the web browser may attempt to re-connect with certain protocol versions disabled. For example, the browser may initially connect claiming TLS 1.2 as the highest supported version, and subsequently reconnect claiming only TLS 1.1, TLS 1.0, or eventually SSL 3.0 as the highest supported version until the connection attempt succeeds. This can trivially allow a MITM attacker to cause a protocol downgrade and make the client/server use SSL 3.0. This fallback behavior is not seen in non HTTPS clients.

The issue related to the POODLE flaw is an attack against the “authenticate-then-encrypt” constructions used by block ciphers in their cipher block chaining (CBC) mode, as used in SSL and TLS. By using SSL 3.0, at most 256 connections are required to reliably decrypt one byte of ciphertext. Known flaws already affect RC4 and non block-ciphers and their use is discouraged.

Several cryptographic library vendors have issued patches which introduce the TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV) support to their libraries. This is essentially a fallback mechanism in which clients indicate to the server that they can speak a newer SSL/TLS versions than the one they are proposing. If TLS_FALLBACK_SCSV was included in the ClientHello and the highest protocol version supported by the server is higher than the version indicated by the client, the server aborts the connection, because it means that the client is trying to fallback to a older version even though it can speak the newer version.

Before applying this fix, there are several things that need to be understood:

  • As discussed before, only web browsers perform an out-of-band protocol fallback. Not all web browsers currently support TLS_FALLBACK_SCSV in their released version. Even if the patch is applied on the server, the connection may still be unsafe if the browser is able to negotiate SSL 3.0
  • Clients which do not implement out-of-protocol TLS version downgrades (generally anything which does not speak HTTPS) do not need to be changed. Adding TLS_FALLBACK_SCSV is unnecessary (and even impossible) if there is no downgrade logic in the client application.
  • The TLS/SSL server needs to be patched to support the SCSV extension – though, as opposed to the client, the server does not have to be rebuilt with source changes applied. Just installing an upgrade TLS library is sufficient. Due to the current lack of browser support, this server-side change does not have any positive security impact as of this writing. It only prepares for a future where a significant share of browsers implement TLS_FALLBACK_SCSV.
  • If both the server and the client are patched and one of them only supports SSL 3.0, SSL 3.0 will be used directly, which results in a connection with reduced security (compared to currently recommended practices). However, the alternative is a total connection failure or, in some situations, an unencrypted connection which does nothing to protect from an MITM attack. SSL 3.0 is still better than an unencrypted connection.
  • As a stop-gap measure against attacks based on SSL 3.0, disabling support for this aging protocol can be performed on the server and the client. Advice on disabling SSL 3.0 in various Red Hat products and components is available on the Knowledge Base.

Information about (the lack of ongoing) attacks may help with a decision. Protocol downgrades are not covert attacks, in particular in this case. It is possible to log SSL/TLS protocol versions negotiated with clients and compare these versions with expected version numbers (as derived from user profiles or the HTTP user agent header). Even after a forced downgrade to SSL 3.0, HTTPS protects against tampering. The plaintext recovery attack described in the POODLE paper (Bodo Möller, Thai Duong, Krzysztof Kotowicz, This POODLE Bites: Exploiting The SSL 3.0 Fallback, September 2014) can be detected by the server and just the number of requests generated by it could be noticeable.

Red Hat has done additional research regarding the downgrade attack in question. We have not found any clients that can be forcibly downgraded by an attacker other than clients that speak HTTPS. Due to this fact, disabling SSL 3.0 on services which are not used by HTTPS clients does not affect the level of security offered. A client that supports a higher protocol version and cannot be downgraded is not at issue as it will always use the higher protocol version.

SSL 3.0 cannot be repaired at this point because what constitutes the SSL 3.0 protocol is set in stone by its specification. However, starting in 1999, successor protocols to SSL 3.0 were developed called TLS 1.0, 1.1, and 1.2 (which is currently the most recent version). Because of the built-in protocol upgrade mechanisms, these successor protocols will be used whenever possible. In this sense, SSL 3.0 has indeed been fixed – an update to SSL 3.0 should be seen as being TLS 1.0, 1.1, and 1.2. Implementing TLS_FALLBACK_SCSV handling in servers makes sure that attackers cannot circumvent the fixes in later protocol versions.

Security

HP Security Bulletin HPSBST03131

HP Security Bulletin HPSBST03131 – A potential security vulnerability has been identified with certain HP StoreOnce Backup systems running Bash Shell. This is the Bash Shell vulnerability known as “Shellshock” which could be exploited remotely to allow execution of code. NOTE: Versions of HP StoreOnce Backup software prior to 3.11.4 contain the vulnerable version of Bash. However, HP is unaware of any method that would allow this vulnerability to be exploited on HP StoreOnce Backup systems but is providing an updated version of Bash Shell as a precaution. Revision 1 of this advisory.

NVD

CVE-2014-7551

The Noticias Bebes Beybies (aka com.beybies) application 1.0 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

NVD

CVE-2014-7552

The Zombie Diary (aka com.ezjoy.feelingtouch.zombiediary) application 1.2.2 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

NVD

CVE-2014-7563

The Tactical Force LLC (aka com.conduit.app_69f61a8852b046f2846054b30c4032a7.app) application 1.9.23.276 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

NVD

CVE-2014-7562

The Health Advocate SmartHelp (aka com.healthadvocate.ui) application 3.6 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.