Tag Archives: Website Security Solutions

How to Manage the SHA-1 Deprecation in SSL Encryption

For many website owners and network security admins 2013 was the final push to move older websites and servers off of 1024-bit RSA SSL certificates to 2048-bit RSA certificates. This was an industry wide effort and one that was essential to safeguard the future of SSL/TLS. For us here at Symantec it was a year of education, communication, and mobilization.  Although many people were comfortable with SSL certificate administration and the base functions of the technology, many did not understand the core aspects of SSL encryption.  Our webinars, blogs and other publications on the subjects of algorithms and encryption levels became highly popular; and still are.

Now that 2013 has come to a close and the migration from 1024-bit SSL certificates are becoming a distant memory it is time to switch your mind to hash algorithms (e.g. SHA-1) as we embark on another migration to higher cryptographic standards before 2017. Once again this is an industry wide push to ensure that we are at the forefront of technology to meet a multitude of future demands.

What is a Hash Algorithm?

A hash algorithm reduces and maps the entire contents of the SSL certificate into a small, fixed-size value. The Certification Authority’s (CA) private key is used to encrypt the hashed value, and that is included in the certificate as the signature.  The main purpose is to reduce data of any size to a small fixed-size fingerprint that effectively represents the initial file which is signed by a CA.

The Issue

sha-blog.jpg

On 12 November 2013, Microsoft published a security advisory on “Deprecation of SHA-1 Hashing Algorithm for Microsoft Root Certificate Program”.  In summary, Microsoft is requesting that Certificate Authorities stop issuing new SHA-1 SSL and code signing certificates by 1 January 2016. With regards to SSL certificates, Windows (Internet Explorer) will no longer recognize or accept SHA-1 certificates from 1 January 2017. All SHA-1 SSL certificates issued before or after this announcement must be replaced with a SHA-256 (SHA-2) equivalent by 1 January 2017 to continue working with Microsoft platforms.  In regards to code-signing certificates, your code must be time stamped before 1 January 2016.

At the time of writing, the Certification Authority/Browser Forum (CA/BF) has not endorsed Microsoft’s schedule to depreciate the SHA-1 hash algorithm.  It is also worth noting that certificates chained to a private root, such as Symantec Private Certification Authority (CA) or any self-signed CA are not affected by these migrations and other regulations associated with certificates chained to public roots.

What You Need To Do/Know

Much like the recent migration from 1024 to 2048-bit RSA or ECC certificates there will be a little bit of pain but the methodologies will thankfully be the same, which should be some comfort to those of you licensing SSL certificates to multiple servers. To simplify things let me give you a check list of actions to take:

  1. Locate all of your SHA-1 certificates.  Tools such as Symantec Certificate Intelligence Center can discover all of the certificates on your network regardless of who issues them.
  2. Create a migration plan.

    1. SHA-1 SSL certificates expiring before 1 January 2017 will need to be replaced with a SHA-2 equivalent certificate.
    2. SHA-1 SSL certificates expiring after 1 January 2017 should be replaced with a SHA-2 certificate at your earliest convenience. 
    3. Any SHA-2 certificate chained to a SHA-1 intermediate certificate should be replaced with another one chained to a SHA-2 intermediate. 
  3. Execute. Plan to do this sooner rather than later. Although many people tend to wait until the deadline, the last thing you need to handle on a New Year’s Eve is SSL certificate installation and testing.  Since any unused validity will be credited back to you, there are few benefits in waiting.
  4. Test.  Upon installation please check your configuration using our set of SSL tools.  Although SSL installation may like simple muscle memory after a while, there may be hardware or software conflicts you may not have caught and a belt and suspenders approach makes sense here.

SHA-2 Ubiquity and Hardware/Software Conflicts

One thing that some owners of webservers learned in 2013 is that some older servers are not configured to handle advanced SSL encryption.  In our recent webcast on the subject only 18% of attendees who responded to the poll said they were confident that all of their servers can handle the SHA-2 hash algorithm.  If a server can’t handle SHA-2 what will you do?

If retiring them is not an option (and we know that this is often not an option you can consider), the main course of action is to move it to the backend (intranet usage) and encrypt it with a SHA-1 SSL certificate chained to a private root.  Symantec can provide an organization with a custom private SSL hierarchy to overcome hardware/software conflicts in legacy devices.  Talk to us today to help complete your cost/benefit analysis when considering this option.  It is also worth noting that in the event you encounter a hardware/software conflict please access our SSL Support Pages or contact Symantec Technical Support (available 24/7/365 days a year) using the contact information provided to you (based on region) or located in your SSL control center.

At Symantec we are committed to supporting you through this next transition in encryption standards.  In summary please plan, prepare, execute and test your move to SHA-2 before 1 January 2017 for SSL and 1 January 2016 for code-signing certificates.  If you would like to learn more view our aforementioned webinar How to Navigate the Future Changes in SSL Encryption (select “View” at the bottom of the text for the recording).

Code signing 101: Why developers need digital certificates for applications

Code signing 101

Code signing does two things extremely well: it confirms who the author of the software is and proves that the code has not been altered or tampered with after it was signed. Bot…

Apache Struts2??????????????S2-016(CVE-2013-2251)????

このブログではウェブサイトやその上で動作しているウェブアプリケーションの脆弱性について紹介すると共に注意喚起をする目的でまとめられています。

今回は2013年に公表されたApache Strus2の脆弱性(S2-016)の概要、影響、対策について解説をしています。

※なお、内容に関しましてはHASHコンサルティング株式会社の徳丸 浩様に監修いただいています。

 

+++++++++++++++++++++++++++++++++++++++++++++++

 

Apache Struts2の任意コード実行可能な脆弱性S2-016(CVE-2013-2251)

 

■概要

Apache Struts2(2.0.0-2.3.15)には、外部から指定した任意のプログラムを許してしまう脆弱性S2-016(CVE-2013-2251)があります。これはすなわち、インターネット経由で、攻撃者がサーバー上で勝手にプログラムを実行できるという意味です。その結果、情報漏洩、データやページの改ざん、他のサーバーへの攻撃、サービスの停止などさまざまな影響を受ける可能性があります。

 Struts2には、OGNL(Object-Graph Navigation Language)というJavaに似た言語がサポートされ、Web開発をサポートしています。OGNLはStruts2の様々な場所で使えますが、外部からOGNLが指定できてしまうとセキュリティ上問題なので、外部から指定できないように制限されています。

しかし、一部に制限漏れがあり、細工したURLを閲覧することで、外部からOGNL式を指定できる箇所が見つかりました。式には「プログラム実行」を指定することもできるため、この脆弱性は、前述のような大きな影響があります。

 

■攻撃のイメージと影響

 Struts2のサンプルアプリblankに対して、サーバー上で3 * 4の計算をするには下記のURLを実行します。

 

http://example.jp/struts2-blank/example/X.action?action:%25{3*4} 

 

 3 * 4のかけ算をサーバー上で計算しても実害はありませんが、同様の手順によりサーバー側で「任意のプログラム」を実行することができます。

 

■脆弱性による影響

 この脆弱性による影響の例として下記がありますが、これらに限りません。

 

  • Webコンテンツの改ざん
  • 情報漏えい
  • コンテンツ削除等によるサービスの停止
  • 他サーバーへの攻撃(踏み台)

 

■脆弱性の有無の確認方法

 S2-016は外部からの診断で見つけることは難しいとされており、Struts2が設置されているサーバー上で下記のコマンドを実行する方法が確実です。

# find / -name ‘struts2-core*.jar’

/var/lib/tomcat7/webapps/struts2-blank/WEB-INF/lib/struts2-core-2.3.15.jar

上記の太字の部分がStruts2のバージョンです。上記の実行例では、2.3.15となります。2.3.15以下の数字であれば当該脆弱性があります。2.3.15.1以降であれば対策されたバージョンです。

 

■対策

Struts2をバージョンアップすることで対策となります。前述のように2.3.15.1以降で対策されていますが、特別な事情がなければ最新版のStruts2(本稿執筆時点では2.3.16)の導入を推奨します。

Struts2のバージョンアップ自体はjarファイルの入れ替えのみであり短時間で終わりますが、バージョンアップによるアプリケーションの影響の検証が必要であり、検証には時間を要する場合があります。すぐに検証が終わらない場合や、検証の結果アプリケーションに不具合が生じてアプリケーションの改修が必要な場合は、回避策を導入する必要があります。回避策の1つとして、WAF(Web Application Firewall)の導入があります。S2-016による攻撃は特徴的であるため、WAFによる防御は有効です。

 

なお、「シマンテック クラウド型WAF」では、S2-016の脆弱性をからウェブサイトが攻撃を受けるのを防ぐことができます。

 

■参考文献

Apache Struts の脆弱性 (S2-016) に関する注意喚起(JPCERT/CC)

How customers really react to web browser security warnings

The University of California, together with Google, recently undertook a study to track real-world clickthrough rates from browser security warnings in two of the most popular web browsers Google Chrome and Mozilla Firefox. The results reveal a much mo…

Dangers of domain-validated certificates

      No Comments on Dangers of domain-validated certificates

SSL certificates do more than encrypt data, they also authenticate websites. This is an important and fundamental function because it builds trust. Website visitors see the SSL padlock or HTTPS and they believe that the site is genuine.

In the fight against fake sites, phishing and fraud, trustworthy SSL certificates are essential.

This is why domain-validated certificates can be dangerous.

What is domain validation?

Certificate Authorities (CAs) will issue a domain-validated certificate to anyone who is listed as the domain admin contact in the WHOIS record of a domain name. They just send an email to the contact email address and that’s it.

It is the lowest level of authentication used to validate SSL certificates. Higher levels include organisationally-validated and extended validation certificates which require more detailed checks.

Why can they be dangerous?

The problem with domain validation is that internet criminals can easily get SSL certificates for phishing sites with misspellings of a legitimate domain name. For example, if they were targeting BankOne.com they could register bank1.com and, using a free webmail account, get a domain validated SSL certificate for that site.

When a regular visitor is tricked into visiting the phishing site, they see the comforting https, SSL padlock and don’t necessarily spot the misspelled address.

How to spot a domain-validated certificate

It is actually very difficult to tell if a certificate is domain validated. Therefore users are equally likely to trust your site as the cloned phishing site, and when they find their details have been stolen, may well blame you.

Practices vary from CA to CA on how exactly they verify website owners, but Extended Validation certificates are certain to have higher levels of authentication, and this is shown to your visitors by turning their address bar green (see examples from the most popular browsers below).

dangers-of-domain-blog.png

The trusted alternative

With fake sites using easily-obtained SSL certificates becoming so common, website owners can’t afford to take a risk with domain-validated certificates. Especially if the site asks for particularly sensitive or personal user information, where users will be more likely to look for extra reassurance.

Choosing a certificate from a reputable CA, such as Symantec, and selecting a high-assurance validation method, such as Extended Validation, delivers a more trustworthy alternative. And certainly that can be better for your business than the alternative.

For more information about SSL, from how it works to how to set up on your servers, download our interactive resource, SSL Explained, now.

Staying CyberStreetWise

      No Comments on Staying CyberStreetWise

A UK Government public awareness campaign Cyberstreetwise.com launched this week, aiming to help educate UK consumers and small businesses about online security. The campaign, running for three months via radio, outdoor and online advertising, offers tips to help people improve their performance online, and help keep important and personal information safe.

120px_cyberstreet_partners.jpg

We know that most of the UK population are not doing enough to protect themselves, leaving themselves open for cybercriminals to access their data and abuse their personal info, tricking them into downloading malware.

Cyberstreetwise is advising people in the UK to adopt a few simple online behaviours to make them and their families safer, such as:

  1. Using strong, memorable passwords
  2. Installing internet security software on new devices
  3. Checking privacy settings on social media
  4. Shopping safely online – always ensuring to check online retail sites are secure
  5. Downloading software and the application of patches when prompted

Have a look at the site – and your own personal devices – and please spread the word. Be Cyberstreetwise! 

Important changes to SSL certificates on intranets: what you need to know

If you use SSL certificates on intranet sites with internal server names, they may not work from 1 November 2015. For companies with complex infrastructures, the change may be challenging but now is the time to start getting ready.

EASTERN EUROPE, CYBERCRIME – AND WHY CODE SIGNING IS VITAL

More and more software developers in the UK and US are looking to Eastern Europe to get their code written. After all, it can be done far more cheaply there, as well as offering an abundance of choice. Indeed, code writing ‘houses’ in Eastern Europe are proliferating in response to this demand – from one-man bands to sizeable operations. So any developer intent on keeping their costs down, and often along with the promise of a quick turnaround, has the perfect scenario for having their software code written there, right?

Not necessarily. Because cheap is not good if the code that’s written becomes compromised in any way. And when you, the developer, are possibly thousands of miles away from whoever is writing your code, you need to be even more sure of those into whose hands you are entrusting this process.

Certainly, there are many highly reputable enterprises in Eastern Europe that provide this service and deliver to the highest standards. But this is also a region where, not unlike other areas of the world, cybercrime has soared with the rapid growth of ecommerce and emergence of a more stable, faster Internet. Software that has not been adequately protected is an irresistible target for them, as indeed it is wherever cybercrime rears its head.

No doubt we can all recall incidents where the cybercriminals have struck hard. There was the ‘Zeus’ virus scam, used to steal around £675,000 from the bank accounts of some 3,000 on-line UK customers, while, earlier this year, US federal authorities charged three men with building and disseminating a virus that crippled NASA computers and brought in tens of millions of dollars for the East European-based cybercriminals.

And then there’s Alexsey Belan, for whom the FBI is offering a reward of up to $100,000 for information leading to his arrest. Belan is alleged to have penetrated the computer networks of three major US-based e-commerce companies, stealing their user databases and the encrypted passwords of millions of accounts, and then selling these on. Only look on the FBI’s website listing of ‘Cyber’s Most Wanted’ and you will find many more such examples of cybercriminals active in the region.

“Global cybercrime is arguably the biggest underworld industry of our times,” said Nir Kshetri, in the  report, ‘Cybercrime and Cybersecurity in the Global South’[1]. “Global forces and technologies such as mobile phones, social media and cloud computing are shaping the structure of the global cybercrime industry, estimated at US$1 trillion. Many of the economies in the Former Soviet Union and Central and Eastern Europe (FSU&CEE) have become top cybercrime hotspots.

“Cybercrime rings in these economies have mastered complex tricks and have increased pervasiveness and sophistication of cyberfrauds. Sophisticated frauds, such as cyberextortion, distributed denial-of-service (DDoS) attacks and hijacking users’ searches and clicks, involve a complex fusion of strategy, technology, processes and people,” he states.

“Corruption, the lack of sufficiently high penalties, ineffective, inefficient, inadequate and weak legislation and lax law enforcement have fuelled cybercrime,” Kshetri adds.

So, no matter how compelling your latest application or functionality may be, any vigilant customer will be aware of such dangers and see potential risk in installing your code, fearful that they might be putting malware on their computers, smartphones and other devices. Once unleashed, malicious code can wreak havoc, stealing personal and financial data, damaging files and systems, and compromising confidential information. Malware also poses a serious threat to the mobile environment, slipping into application stores and becoming a threat to anyone who downloads such infected applications.

Fixing the damage can exact a huge toll on those stores – in terms of time, money and disruption. And the damage goes deeper. Because, when application stores lose the trust of their customers, wireless providers and device manufacturers can lose customers, too. The ‘domino’ effect hurts everyone.

So, any developer keen to reap the upsides of Eastern Europe needs to be mindful of the downsides and ensure that the systems to protect their applications are in place. And that brings us to the good news. Software vendors and developers can digitally sign and timestamp the software they distribute over the Internet – known as ‘Code Signing’ – to demonstrate that their applications are safe, secure and trustworthy.

With code signing, everything starts from a position of trust – trust that the apps and downloads that customers install are free from viruses, spyware, or any other alteration or tampering that might compromise or damage their systems. And that isn’t all that’s at stake. Get it wrong and your hard-won brand and reputation could soon be in tatters.

This is where code signing solutions from Symantec come in to play, creating what is essentially a ‘digital shrink wrap’ for secure distribution of code and content over the Internet. Not only does this protect your software, but also it gives customers all the information they need to download and install your software with complete confidence.

Here’s how it works. When you are ready to publish new software and make it available on line, Symantec’s solutions enable you sign and timestamp your code, using a secure private key and digital certificate. The latter includes an encryption hash that allows customers to see all of the information in your digital certificate when they download your application, verifying your identity as the publisher, and confirming the integrity and trustworthiness of your software.

Also, Symantec fully supports multiple computing and mobile platforms, including an EV (Extended Validation) code signing solution that enhances the levels of trust on the latest operating systems, browsers and security software. Another plus for developers is that Symantec has partnered with Microsoft to integrate EV Code Signing certificate status with its SmartScreen reputation services in Internet Explorer and Windows 8. That means programs signed by an EV Code Signing certificate can immediately establish reputation with Microsoft’s SmartScreen, even if no prior reputation exists for that file or publisher; so, potentially there will be fewer warning messages flagged up when a user tries to run your application.

Ensuring that your software has these highest levels of authentication in place protects your brand every time and strengthens the trust relationships that make your business successful.

And with such protections in place, looking to Eastern Europe for the many code writing advantages it promises may well be a move that allows you to sleep that much easier at night.