Online shopping can be risky even if you use world renowned websites such as Amazon. Take a look at our top tips for how to shop safely with the online store.
The post Shopping safely with Amazon appeared first on We Live Security.
Tag Archives: Security
70 Percent of MSPs Must Adapt Services to Capitalize on Internet of Things, AVG Study Reveals
AMSTERDAM and SAN FRANCISCO – October 22, 2014 – Roughly 1-in-4 (26 percent) small- to medium-sized businesses (SMBs) and managed services providers (MSPs) expect the Internet of Things (IoT) including multiple devices, wearables and Cloud-based services in general to generate more money for them than any of the other current big IT trends, according to a new survey announced today by AVG Technologies N.V. (NYSE: AVG), the online security company for devices, data and people. Almost three out of five (57 percent) SMBs agreed that IoT will help boost their revenues, a sentiment that was echoed by around two-thirds (67 percent) of MSP respondents. However just 18 percent of SMB respondents thought their IT provider was ahead of the curve regarding IoT management while 70 per cent of MSPs themselves admitted the need to adapt their services to meet customer expectations in this regard.
“Our MSP partners are telling us that the ‘Internet of Things’ is the one IT trend making an immediate difference to their bottom line and the business customers that they serve. A massive 7 out of 10 stated they need to amend their offerings to enable business growth.† said Mike Foreman, AVG’s general manager, SMB
The study*, which interviewed 1,770 small businesses and MSPs in the U.S., Canada, the UK, Germany and Australia, also revealed more than half (55 percent) of MSP respondents say customers are demanding Internet of Things related services and over three quarters (77 percent) are planning to expand their service/product portfolio. However, they had better adapt quickly. Of those SMBs with an IT provider, 68% feel that their provider could improve their service with regard to Internet of Things offerings and understanding.
“The study shows clearly that as businesses grow to rely more and more on the Internet of Things and Cloud-based services to help generate revenue most MSPs are still some way short of being ready to help customers’ manage this,†continued Mike Foreman. “The research strongly indicates that MSPs need to significantly up their game and demonstrate enhanced levels of protection and control over their customers’ ever changing data and device needs.â€
A summary of the other key findings in the study were:
SMBs
Almost half (46%) of SMBs think that the Internet of Things will be the IT trend that has the greatest impact on their organization over the next five years. An even higher proportion -around seven in ten (71%) – say that due to the Internet of Things their organization will need to take extra steps to secure and protect their data
- Around three fifths (62%) of SMB respondents report that their organization has budget specifically assigned over the next 12 months for the development of Internet of Things solutions. 49% have a moderate or substantial budget assigned for these solutions.
- Only 18% of SMB respondents say that their IT provider is completely ahead of the curve with regard to the Internet of Things and the potential for their business. Of those with an IT provider, 68% feel that their provider could improve their service with regard to Internet of Things offerings and understanding.
- The majority (84%) of SMB respondents say that their organization has purchased mobile devices within the last year, spending an average of over $6,500 on these devices. Of those who have purchased mobile devices within the last 12 months, SMB respondents estimate that their organization spends an average of around $4,500 in hidden costs annually.
MSPs
- Over half (55%) of MSP respondents state that customers are demanding Internet of Things related services and seven in ten (70% but only 56% Germany) say that they will amend their services based on the wants of the customer.
- However, less than two fifths (38%) of MSPs say that their organization currently has an integrated remote monitoring and management platform.
- Around three fifths (58%) of MSP respondents say that they will need to join up with cutting edge partners in order to successfully offer Internet of Things-related services. Currently only 38% of MSP respondents feel that the vendors they work with are cutting edge.
- Furthermore around three in ten MSP respondents feel that their current vendor helps make efficiency savings (31%) or productive gains (25%) for their customers.
* AVG commissioned independent technology market research specialist Vanson Bourne to undertake this research. 1770 interviews were carried out during September 2014 with IT and marketing decision-makers of organizations with of 1 – 500 employees with and 85/15 per cent split between SMBs and MSPs. Interviews were performed across five countries: UK, US, Canada, Germany and Australia. Respondents to this research came from a range of industry sectors, with only the public sector excluded.
For more information, please see our video on the survey findings:
About AVG Technologies (NYSE: AVG)
AVG is the online security company providing leading software and services to secure devices, data and people. AVG has over 182 million active users, as of June 30, 2014, using AVG’s products and services including Internet security, performance optimization, and personal privacy and identity protection. By choosing AVG’s products, users become part of a trusted global community that engages directly with AVG to provide feedback and offer mutual support to other customers.
All trademarks are the property of their respective owners.
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 Mller, 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.
POODLE – An SSL 3.0 Vulnerability (CVE-2014-3566)
Red Hat Product Security has been made aware of a vulnerability in the SSL 3.0 protocol, which has been assigned CVE-2014-3566. All implementations of SSL 3.0 are affected. This vulnerability allows a man-in-the-middle attacker to decrypt ciphertext using a padding oracle side-channel attack.
To mitigate this vulnerability, it is recommended that you explicitly disable SSL 3.0 in favor of TLS 1.1 or later in all affected packages.
A brief history
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communication security over networks. The SSL protocol was originally developed by Netscape. Version 1.0 and was never publicly released; version 2.0 was released in February 1995 but contained a number of security flaws which ultimately led to the design of SSL 3.0. Over the years, several flaws were found in the design of SSL 3.0 as well. This ultimately lead to the development and widespread use of the TLS protocol.
Most TLS implementations remain backward compatible with SSL 3.0 to incorporate legacy systems and provide a smoother user experience. Many SSL clients implement a protocol downgrade “dance” to work around the server side interoperability issues. Once the connection is downgraded to SSL 3.0, RC4 or a block cipher with CBC mode is used; this is where the problem starts!
What is POODLE?
The POODLE vulnerability has two aspects. The first aspect is a weakness in the SSL 3.0 protocol, a padding oracle. An attacker can exploit this vulnerability to recover small amounts of plaintext from an encrypted SSL 3.0 connection, by issuing crafted HTTPS requests created by client-side Javascript code, for example. Multiple HTTPS requests are required for each recovered plaintext byte, and the vulnerability allows attackers to confirm if a particular byte was guessed correctly. This vulnerability is inherent to SSL 3.0 and unavoidable in this protocol version. The fix is to upgrade to newer versions, up to TLS 1.2 if possible.
Normally, a client and a server automatically negotiate the most recent supported protocol version of SSL/TLS. The second aspect of the POODLE vulnerability concerns this negotiation mechanism. For the protocol negotiation mechanism to work, servers must gracefully deal with a more recent protocol version offered by clients. (The connection would just use the older, server-supported version in such a scenario, not benefiting from future protocol enhancements.) However, when newer TLS versions were deployed, it was discovered that some servers just terminated the connection at the TCP layer or responded with a fatal handshake error, preventing a secure connection from being established. Clearly, this server behavior is a violation of the TLS protocol, but there were concerns that this behavior would make it impossible to deploy upgraded clients and widespread interoperability failures were feared. Consequently, browsers first try a recent TLS version, and if that fails, they attempt again with older protocol versions, until they end up at SSL 3.0, which suffers from the padding-related vulnerability described above. This behavior is sometimes called the compatibility dance. It is not part of TLS implementations such as OpenSSL, NSS, or GNUTLS; it is implemented by application code in client applications such as Firefox and Thunderbird.
Both aspects of POODLE require a man in the middle attack at the network layer. The first aspect of this flaw, the SSL 3.0 vulnerability, requires that an attacker can observe the network traffic between a client and a server and somehow trigger crafted network traffic from the client. This does not strictly require active manipulation of the network transmission, passive eavesdropping is sufficient. However, the second aspect, the forced protocol downgrade, requires active manipulation of network traffic. As described in the POODLE paper, both aspects require the attacker to be able to observe and manipulate network traffic while it is in transit.
How are modern browsers affected by the POODLE security flaw?
Browsers are particularly vulnerable because session cookies are short and an ideal target for plain text recovery, and the way HTTPS works allows an attacker to generate many guesses quickly (either through Javascript or by downloading images). Browsers are also most likely to implement the compatibility fallback.
By default, Firefox supports SSL 3.0, and performs the compatibility fallback as described above. SSL 3.0 support can be switched off, but the compatibility fallback cannot be configured separately.
Is this issue fixed?
The first aspect of POODLE, the SSL 3.0 protocol vulnerability, has already been fixed through iterative protocol improvements, leading to the current TLS version, 1.2. It is simply not possible to address this in the context of the SSL 3.0 protocol, a protocol upgrade to one of the successors is needed. Note that TLS versions before 1.1 had similar padding-related vulnerabilities, which is why we recommend to switch to TLS 1.1, at least. (SSL and TLS are still quite similar as protocols, the name change has non-technical reasons.)
The second aspect, caused by browsers which implement the compatibility fallback in an insecure way, has yet to be addressed. Strictly speaking, this is a security vulnerability in browsers due to the way they misuse the TLS protocol. One way to fix this issue would be to remove the compatibility dance, focusing instead on making servers compatible with clients implementing the most recent TLS implementation (as explained, the protocol supports a version negotiation mechanism, but some servers refuse to implement it).
However, there is an industry-wide effort under way to enable browsers to downgrade in a secure fashion, using a new Signaling Cipher Suite Value (SCSV). This will require updates in browsers (such as Firefox) and TLS libraries (such as OpenSSL, NSS and GNUTLS). However, we do not envision changes in TLS client applications which currently do not implement the fallback logic, and neither in TLS server applications as long as they use one of the system TLS libraries. TLS-aware packet filters, firewalls, load balancers, and other infrastructure may need upgrades as well.
Is there going to be another SSL 3.0 issue in the near future? Is there a long term solution?
Disabling SSL 3.0 will obviously prevent exposure to future SSL 3.0-specific issues. The new SCSV-based downgrade mechanism should reliably prevent the use of SSL 3.0 if both parties support a newer protocol version. Once these software updates are widely deployed, the need to disable SSL 3.0 to address this and future vulnerabilities will hopefully be greatly reduced.
SSL 3.0 is typically used in conjunction with the RC4 stream cipher. (The only other secure option in a strict, SSL 3.0-only implementation is Triple DES, which is quite slow even on modern CPUs.) RC4 is already considered very weak, and SSL 3.0 does not even apply some of the recommended countermeasures which prolonged the lifetime of RC4 in other contexts. This is another reason to deploy support for more recent TLS versions.
I have patched my SSL implementation against BEAST and LUCKY-13, am I still vulnerable?
This depends on the type of mitigation you have implemented. If you disabled protocol versions earlier than TLS 1.1 (which includes SSL 3.0), then the POODLE issue does not affect your installation. If you forced clients to use RC4, the first aspect of POODLE does not apply, but you and your users are vulnerable to all of the weaknesses in RC4. If you implemented the n/n-1 split through a software update, or if you deployed TLS 1.1 support without enforcing it, but made no other configuration changes, you are still vulnerable to the POODLE issue.
Is it possible to monitor for exploit attempts?
The protocol downgrade is visible on the server side. Usually, servers can log TLS protocol versions. This information can then be compared with user agents or other information from the profile of a logged-in user, and mismatches could indicate attack attempts.
Attempts to abuse the SSL 3.0 padding oracle part of POODLE, as described in the paper, are visible to the server as well. They result in a fair number of HTTPS requests which follow a pattern not expected during the normal course of execution of a web application. However, it cannot be ruled out that a more sophisticated adaptive chosen plain text attack avoids confirmation of guesses from the server, and this more advanced attack would not be visible to the server, only to the client and the network up to the point at which the attacker performs their traffic manipulation.
What happens when i disable SSL 3.0 on my web server?
Some old browsers may not be able to support a secure connection to your site. Estimates of the number of such browsers in active use vary and depend on the target audience of a web site. SSL protocol version logging (see above) can be used to estimate the impact of disabling SSL 3.0 because it will be used only if no TLS version is available in the client.
Major browser vendors including Mozilla and Google have announced that they are to deactivate the SSL 3.0 in their upcoming versions.
How do I secure my Red Hat-supported software?
Red Hat has put together several articles regarding the removal of SSL 3.0 from its products. Customers should review the recommendations and test changes before making them live in production systems. As always, Red Hat Support is available to answer any questions you may have.
Adobe gathers data from your eBook reader
Image from http://www.quickmeme.com
Security and privacy violations in Adobe’s Digital Editions eBook and PDF reader were discovered last week.
“This is a privacy and security breach so big that I am still trying to wrap my head around the technical aspects, much less the legal aspects,†researcher Nate Hoffelder wrote in The Digital Reader blog post.
If you check out eBooks from your local library and read from a digital reader like a Nook, Kobo, or other non-Amazon eBook reader, then you have probably used Adobe’s free Digital Editions software.
Hoffelder said that Adobe is gathering user data on the eBooks that have been opened, which pages were read, and in what order, as well as metadata such as title and publisher –and all of it is being sent to Adobe’s servers in plain text. That means anyone who is interested and has the means, say, the National Security Agency or your ISP, could be reading over your shoulder. That’s not good. In fact, it’s very bad, as well as illegal.
It is hoped that Adobe’s Tuesday update will include a plug for the Digital Editions leak, but more likely it will be next week. In a statement to the American Library Association, Adobe reports they “expect an update to be available no later than the week of October 20†in terms of transmission of reader data.”
Thank you for using avast! Antivirus and recommending us to your friends and family. For all the latest news, fun and contest information, please follow us on Facebook, Twitter and Google+. Business owners – check out our business products.
What is the Bash bug, and how do I prevent my systems from being Shellshocked?
Shellshock is a newly discovered security flaw that has been around for 22 years, and works by exploiting the very nature of web GUI.
Working in the same way as SQL injection, Shellshock allows users to insert Bash (a Unix-based command processor, or shell) commands into a server via a web form or similar method, and exploits the very nature of environment variable handling, which is that after assigning a function to a variable, any trailing code in the function will be then executed.
Where the SQL injection vulnerability allows a hacker access to the database, Shellshock gives the hacker an authentication-free access to the server, which makes it much more powerful. With this type of access, one with malicious intent could create a worm that could multiply and reproduce the exploit across entire networks to collect or modify data, or open other security holes that would otherwise be closed. Though Bash does not natively run on Microsoft Windows machines, it can be ported, but it is not yet known if the vulnerability will remain present.
Ok, so I get it, it’s dangerous. Am I vulnerable?
Absolutely.
Why?
Because Unix has a much wider grip on our networks than most people can really appreciate. Due to its ubiquity, everything from routers and smartphones, TVs, cars and more could be exploited. Worse, is that many of those devices are very difficult to update. Your home router, for example, has control of all your incoming and outgoing network traffic, and if someone has that, not only do they have the potential to collect your data, but to enable ports, disable the firewall, and further their access into your network infrastructure. With that being said, if you are running any versions of Unix or Mac, and haven’t familiarized yourself with this vulnerability, you’re well overdue.
Luckily, many vendors have now patched for Shellshock by updating Bash, but at this time, Apple users should wait for an update.
I’m running Unix. What do I do now?
First, it’s best to find out if you’re affected. Specifically, are you running Redhat, Ubuntu, Fedora, CentOS (v5-7) CloudLinux, or Debian? If so, then run this command to find out if you’re vulnerable.
$ env x=’() { :;}; echo vulnerable’ bash -c “echo this is a test”
If you see nothing but “this is a test,†you’ve successfully run the exploit, and you’ve got some work to do.
Luckily, most Linux distributions have issued fixes, so you can simply run your update manager. For those who haven’t, you can do so manually by running the following commands:
yum update bash
OR
sudo apt-get update && sudo apt-get install bash
Help, I have a Mac!
Are you infected? Run this command from your shell and find out.
$ env x=’() { :;}; echo vulnerable’ bash -c ‘echo hello’
If you’ve got Mac machines in your environment that can be exploited, you can disable the exploit by temporarily changing the default user shell. For IT administrators that have the know-how, get started right away – but for those that have to ask “how?,†it’s best to keep your eyes peeled and wait for an official update from Apple.
Thank you for using avast! Antivirus and recommending us to your friends and family. For all the latest news, fun and contest information, please follow us on Facebook, Twitter and Google+. Business owners – check out our business products.
How to make your social media accounts (almost) unhackable
Now more than ever, its important to make sure your social media accounts are safe and secure. Here are our 6 top tips to make your social media accounts almost unhackable.
The post How to make your social media accounts (almost) unhackable appeared first on We Live Security.
TLS landscape
Transport Layer Security (TLS) or, as it was known in the beginnings of the Internet, Secure Sockets Layer (SSL) is the technology responsible for securing communications between different devices. It is used everyday by nearly everyone using the globe-spanning network.
Let’s take a closer look at how TLS is used by servers that underpin the World Wide Web and how the promise of security is actually executed.
Adoption
Hyper Text Transfer Protocol (HTTP) in versions 1.1 and older make encryption (thus use of TLS) optional. Given that the upcoming HTTP 2.0 will require use of TLS and that Google now uses the HTTPS in its ranking algorithm, it is expected that many sites will become TLS-enabled.
Surveying the Alexa top 1 million sites, most domains still don’t provide secure communication channel for their users.
Just under 40% of HTTP servers support TLS or SSL and present valid certificates.
Additionally, if we look at the version of the protocol supported by the servers most don’t support the newest (and most secure) version of the protocol TLSv1.2. Of more concern is the number of sites that support the completely insecure SSLv2 protocol.
Only half of HTTPS servers support TLS 1.2
(There are no results for SSLv2 for first 3 months because of error in software that was collecting data.)
One of the newest and most secure ciphers available in TLS is Advanced Encryption Standard (AES) in Galois/Counter Mode (AES-GCM). Those ciphers provide good security, resiliency against known attacks (BEAST and Lucky13), and very good performance for machines with hardware accelerators for them (modern Intel and AMD CPUs, upcoming ARM).
Unfortunately, it is growing a bit slower than TLS adoption in general, which means that some of the newly deployed servers aren’t using new cryptographic libraries or are configured to not use all of their functions.
Only 40% of TLS web servers support AES-GCM ciphersuites.
Bad recommendations
A few years back, a weakness in TLS 1.0 and SSL 3 was shown to be exploitable in the BEAST attack. The recommended workaround for it was to use RC4-based ciphers. Unfortunately, we later learned that the RC4 cipher is much weaker than it was previously estimated. As the vulnerability that allowed BEAST was fixed in TLSv1.1, using RC4 ciphers with new protocol versions was always unnecessary. Additionally, now all major clients have implemented workarounds for this attack, which currently makes using RC4 a bad idea.
Unfortunately, many servers prefer RC4 and some (~1%) actually support only RC4. This makes it impossible to disable this weak cipher on client side to force the rest of servers (nearly 19%) to use different cipher suite.
RC4 is still used with more than 18% of HTTPS servers.
The other common issue, is that many certificates are still signed using the obsolete SHA-1. This is mostly caused by backwards compatibility with clients like Windows XP pre SP2 and old phones.
SHA-256 certificates only recently started growing in numbers
The sudden increase in the SHA-256 between April and May was caused by re-issuance of certificates in the wake of Heartbleed.
Bad configuration
Many servers also support insecure cipher suites. In the latest scan over 3.5% of servers support some cipher suites that uses AECDH key exchange, which is completely insecure against man in the middle attacks. Many servers also support single DES (around 15%) and export grade cipher suites (around 15%). In total, around 20% of servers support some kind of broken cipher suite.
While correctly implemented SSLv3 and later shouldn’t allow negotiation of those weak ciphers if stronger ones are supported by both client and server, at least one commonly used implementation had a vulnerability that did allow for changing the cipher suite to arbitrary one commonly supported by both client and server. That’s why it is important to occasionally clean up list of supported ciphers, both on server and client side.
Forward secrecy
Forward secrecy, also known as perfect forward secrecy (PFS), is a property of a cipher suite that makes it impossible to decrypt communication between client and server when the attacker knows the server’s private key. It also protects old communication in case the private key is leaked or stolen. That’s why it is such a desirable property.
The good news is that most servers (over 60%) not only support, but will actually negotiate cipher suites that provide forward secrecy with clients that support it. The used types are split essentially between 1024 bit DHE and 256 bit ECDHE, scoring respectively 29% and 33% of all servers in latest scan. The amount of servers that do negotiate PFS enabled cipher suites is also steadily growing.
PFS support among TLS-enabled HTTP servers
Summary
Most Internet facing servers are badly configured, sometimes it is caused by lack of functionality in software, like in case of old Apache 2.2.x releases that don’t support ECDHE key exchange, and sometimes because of side effects of using new software with old configuration (many configuration tutorials suggested using !ADH in cipher string to disable anonymous cipher suites, that unfortunately doesn’t disable anonymous Elliptic Curve version of DH – AECDH, for that, use of !aNULL is necessary).
Thankfully, the situation seems to be improving, unfortunately rather slowly.
If you’re an administrator of a server, consider enabling TLS. Performance issues when encryption was slow and taxing on servers are long gone. If you already use TLS, double check your configuration preferably using the Mozilla guide to server configuration as it is regularly updated. Make sure you enable PFS cipher suites and put them above non-PFS ciphers and that you as well as the Certificate Authority you’ve chosen, use modern crypto (SHA-2) and large key sizes (at least 2048 bit RSA).
If you’re a user of a server and you’ve noticed that the server doesn’t use correct configuration, try contacting the administrator – he may have just forgotten about it.
Teaching cyber-security from school age
As the Internet increasingly becomes part of our everyday lives and we use new technologies in all areas of our life, there’s an ever greater need for professionals capable of guaranteeing our security in these areas.
However, in a field as new and complex as cyber-security there is still a lack of people prepared to work in it. As we saw recently, in the United States there is already a plan under way to tackle the situation: training army veterans to become cyber-warriors and consequently, helping them to adjust to civilian life again.
Yet this is only one of the solutions put forward, and there are others that take a longer view. To ensure the future of the profession, the only viable plan for the long term involves educating children in this area and stimulating their interest in computing in general and specifically in IT security.
Along such lines, countries like the USA and the UK have projects that will hopefully provide the cyber-warriors of the future.
The UK’s Cyber-Centurion challenge
In the UK in fact, an initiative called Cyber Centurion has been launched to get thousands of youngsters competing in teams in a cyber-security challenge.
The key to the initiative is that young people will be in direct contact with situations that a real cyber-security expert could encounter. In fact, the challenge, which is to be held in two rounds, involves downloading a virtual computer full of vulnerabilities that could present opportunities for a cyber-criminal. What the teams (comprising 4 to 6 youngsters and one adult) have to do is identify these vulnerabilities and patch them as soon as possible.
As this is the first edition of the challenge, there will first be a practice round in October before the two competition rounds. The top six teams will then battle it out in April 2015 in the Grand Final. The winners will be awarded a scholarship at Northrop Grumman, one of the largest defense contractors in the United States and maker of the B-2 stealth bomber who is funding this initiative with a view to uncovering future talents in IT security.
This however isn’t the only cyber-security initiative in the UK. The Cyber Centurion challenge is supported by Cyber Security Challenge UK , a platform funded by the British government that has organized other educational initiatives such as workshops and other challenges in schools, colleges and universities across the UK.
CyberPatriot
In fact, this exciting British initiative is really an adaptation of the US Cyber Patriot program, the National Youth Cyber Education Program. This program is now in its seventh edition and is also funded by Northrop Grumman, which claims to have already dramatically reduced America’s cyber-security talent shortage.
This search for US Cyber Patriots involves three programs:
- A competition among high school students similar to the one that will begin in a few months in the UK (where the teams have to identify and fix vulnerabilities in an operating system to prevent cyber-criminals from entering),
- A camp organized for the first time this summer and which aims to teach the principles of cyber-security in an entertaining way and
- An initiative that will take basic IT security knowledge to primary schools and teach children how to protect themselves on the Internet.
So why in the US and the UK is there so much interest in students learning firsthand what it takes to be a cyber-security professional and not any other job?
Basically, because the future (and the present) will require IT professionals dedicated to cyber-security. Moreover, international threats and attacks can now come across the Internet, so another profession of the (short-term) future will be cyber-warriors, who even now are being recruited by companies like Northrop Grumman. This will no doubt be the army of the future.
The post Teaching cyber-security from school age appeared first on MediaCenter Panda Security.
Jennifer Lawrence: Victim of a security hole in iCloud?
If you are on Twitter you may have noticed the actress Jennifer Lawrence has been ‘Trending Topic’ since yesterday afternoon.
The reason? The leak of nude photos of the 2013 Academy Award winner on the /b/ forum of 4Chan.
She has confirmed the story, although she is apparently not the only victim.
Other models and actresses such as Kirsten Dunst, Kate Upton or Ariana Grande have also allegedly had pictures leaked, although not all these cases have been confirmed. Meanwhile, Mary E. Winstead has acknowledged the authenticity of the pictures that have been circulated, while Victoria Justice has denied that some photos allegedly of her are authentic.
It is still not clear how ‘Celebgate’ (as some are referring to this massive hacking) was carried out. Some sources have suggested a possible security breach in iCloud, Apple’s virtual data storage platform, though the company has yet to confirm this.
Until it is known how these images were stolen, the best anyone can do is apply common sense and ensure they use strong passwords to access their services. We also recommend that users check their Apple ID account.
The post Jennifer Lawrence: Victim of a security hole in iCloud? appeared first on MediaCenter Panda Security.