Duqu 2.0: ?????????????????
Duqu ワームの新しいバージョンを使う攻撃者が、電気通信事業者、電子機器メーカー、さらにはセキュリティ企業まで狙って活動しています。
Read More
Duqu ワームの新しいバージョンを使う攻撃者が、電気通信事業者、電子機器メーカー、さらにはセキュリティ企業まで狙って活動しています。
Read More
Attackers use new version of Duqu worm in ambitious attacks against telecoms, electronics and even information security sectorsRead More
공격자들, 새로운 Duqu 웜 버전으로 통신, 전자, 정보 보안 부문에 대한 고강도 공격 감행
Read More
cibercriminosos Sofisticados do Equation levam Malware para outro patamar.Read More
Today, Kim Zetter released her book, “Countdown to Zero Day”. The book recounts the story of Stuxnet’s attempt to sabotage Iran’s uranium enrichment program. The work that Eric Chien, Nicolas Falliere, and I carried out is featured in the book. During the process of writing the book, Kim interviewed us on many occasions and we were lucky enough to be able to review an advanced copy.
Figure 1. Kim Zetter’s new book, “Countdown to Zero Day”
In the chapter 17 of the book, “The Mystery of the Centrifuges”, Kim talks about how Stuxnet infections began in Iran, identifying several companies where she believes the infections originated.
“To get their weapon into the plant, the attackers launched an offensive against four companies. All of the companies were involved in industrial control processing of some sort, either manufacturing products or assembling components or installing industrial control systems. They were likely chosen because they had some connection to Natanz as contractors and provided a gateway through which to pass Stuxnet to Natanz through infected employees”
This is a different story from the one that David Sanger’s sources painted in his New York Times article and in his book “Confront and Conceal”. Sanger states:
“. . . an element of the program accidentally became public in the summer of 2010 because of a programming error that allowed [Stuxnet] to escape Iran’s Natanz plant and sent it around the world on the Internet.”
So which is right? Did Stuxnet originate outside of Natanz and spread all over the world with the hopes of eventually entering Natanz? Or did Stuxnet start inside of Natanz and accidentally escape due to a programming error?
Tracing the spread of Stuxnet
We actually covered how Stuxnet originated in a blog post in February 2011. Let’s start with whether it is possible to track Stuxnet’s origin back to specific companies in Iran.
Normally, it would not be possible to state with 100 percent accuracy where an infection started. However, in the case of Stuxnet version 1.x, the attackers left a trail behind which allows analysts to trace the specific genealogy of each sample. This is possible because every time Stuxnet executes, it records some information about the computer it is executing on and stores that within the executable file itself, creating a new unique executable in the process. As a result, every unique executable contains an embedded and ordered list showing the computers it has previously infected. As Stuxnet spreads from computer to computer, the list grows and grows. By examining this list, we can trace back from one entry to the next, extracting computer information from each entry. These are the breadcrumbs we can follow to get back to the original compromised computers.
What do the breadcrumbs look like?
Each entry in the list looks like the data shown in the following image. Although this may not make sense at first, by analyzing the code within Stuxnet, we can find out what each number represents.
Figure 2. List entry of compromised computers
Among other information, the computer name, domain name, date, and IP address are stored in each entry. We can extract information from previous data, which is shown in the following image.
Figure 3. Details stored in each entry
By looking at each entry in the list embedded in any sample, we can see how the threat moved from one computer to the next. The real computer names and domains have been anonymized.
Figure 4. List of compromised computers from one sample shows how Stuxnet spread
In the previous image, we can see Stuxnet’s path through the first six compromised computers. This information was extracted from one sample. When we look at the first six infections from a different sample, we get the following path.
Figure 5. List of compromised computers from another sample shows different movement pattern
The two samples’ first four entries are the same but after that, the samples moved in two different directions. At the fifth step, one sample compromised a computer on the WORKGROUP domain while the other sample compromised a computer on the MSHOME network.
Using this data, we graphed the spread of Stuxnet infections. See pages eight to ten of our Stuxnet whitepaper for more details.
Figure 6. Spread of Stuxnet infections
Many computers and domains used generic names that do not provide much insight into the targets. For example, WORKGROUP and MSHOME—two default workgroup names—appear very frequently in the breadcrumb logs. However, we were able to identify all of the places where Stuxnet infections originated, and they were all in Iran.
The verdict
So did Stuxnet spread into Natanz as Zetter says or escape out of Natanz as Sanger reported?
Based on the analysis of the breadcrumb log files, every Stuxnet sample we have ever seen originated outside of Natanz. In fact, as Kim Zetter states, every sample can be traced back to specific companies involved in industrial control systems-type work.
This technical proof shows that Stuxnet did not escape from Natanz to infect outside companies but instead spread into Natanz.
Unfortunately, these breadcrumbs are only available for Stuxnet version 1.x. There was at least one previous version of Stuxnet released, version 0.5 (which we analyzed in our whitepaper), for which this infection path information is not available.
While version 0.5, which did not spread as aggressively as version 1.x, could have been planted inside Natanz and then spread outwards, this version was no longer operational during the conversation timeframe (the summer of 2010) outlined in the Sanger article. As a result, it is unlikely the 0.5 version is the subject of his article.
To make up your own mind, you should read Kim Zetter’s “Countdown to Zero Day”, which is out today.
よく知られた格言として、こんな話があります。
樽いっぱいの汚水に、きれいな水を 1 パイント注いでも、残るのは樽いっぱいの汚水だ。では、樽いっぱいのきれいな水に、汚水を 1 パイント注いでみたらどうなるかといえば、そう、できあがるのはやっぱり樽いっぱいの汚水だ。
この話に出てくる、きれいな水を「論理的に真である文」に、汚水を「論理的に偽である文」に置き換えてみれば、この格言が論理学で使われるおなじみの原理を表すことがわかります。
AND 演算子(&)を使って、いくつか連鎖した偽の文(樽いっぱいの汚水)に真である文(1 パイントのきれいな水)を 1 つ追加すると、結果として全体の文は偽になります。いくつか連鎖した真の文に偽である文を 1 つ追加しても同じようになり、全体の文は偽になります。
この格言と論理学の原理は、シマンテックのセキュリティレスポンスエンジニア(SRE)にとっても有益です。SRE の大きな責務のひとつは、特定のファイルが配備先の環境にとって脅威となるかどうかを判定し、その脅威が現実のものとならないように必要な措置を講じることです。そのために SRE は、配備先の環境で望ましくない処理や、悪質な処理を実行しうる特定のコードシーケンスあるいはコマンドがないかどうかファイルを調べる必要があります。
前述の格言や論理学の原理と同じように、解析対象となる潜在的に悪質なファイルは、以下のような(長い)論理シーケンスとして表されます。
S = P1 & P2 & P3 & … & Pi & … & Pn
ここで、各 Pi はファイルの基本ブロック(1 単位の処理を実行する)を表し、論理学で言えば 1 つの文に当たります。実際には、この式に「IF/THEN」など他の論理演算子が含まれることもあります。いずれにしても、ファイル全体を評価するためには、Pi を 1 つずつ評価しなければなりません。
ここでは、一般形としてのファイルブロックを前提に話を進めています。現実的には、ファイルはタイプによって大きく異なるからです。ファイルタイプが異なれば、ファイルブロックの意味も異なります。たとえば、スクリプトファイルにおけるファイルブロックは、スクリプトのインタープリタによって 1 ステップで実行されるコマンドの 1 単位です。それに対して、ネーティブ実行可能ファイルにおけるファイルブロックは基本的なコードブロックと見なされます。つまり、複数のエントリまたは複数のエグジットを持つ命令のブロックです。
リストに 1 つでも偽の文があれば全体の文が偽となるように、いずれか 1 つのファイルブロックが脅威の原因と特定されれば、直ちにそのファイル全体が脅威と見なされます。ファイルが脅威と判定されれば解析はそこで停止し、その脅威に対する検出シグネチャが追加されます。
ファイル全体が悪質な意図で作成された場合(ほとんどのトロイの木馬が当てはまります)、脅威は簡単に特定できます。脅威の要素がいたるところで見つかるのに加えて、不明瞭化やポリモーフィズムも、ファイルに何か問題があることを示す格好の手掛かりになるからです。現在、シマンテックが解析対象として受け取るファイルのうち 4 つに 3 つ(75%)は脅威であると見なされ、検出のためのシグネチャが追加されています。
この作業の労力がいかに大きいかを感覚的にわかっていただくために、メモ帳のように単純なアプリケーションを考えてみましょう。メモ帳でさえ、ファイルブロックの数はおよそ 1,500 に及びます。攻撃者が悪質なブロックをいくつかランダムな位置に挿入した場合、1,500 もの正常なファイルブロックの中からそれを見つけ出すのは非常に困難です。まさに、干し草の中から針を 1 本探し出すようなものです。
脅威の動作を文書化するために詳しい情報が必要な場合には、ファイル全体について詳しい解析を実行する必要があります。こうした詳しい解析を実行するには、パズルの全ピースを埋めるために、SRE は正常なブロックから悪質なブロックまでファイルのコードブロックをほぼすべて調査します。たとえば Stuxnet(これまでに確認された最も複雑な脅威のひとつです)の場合には、シマンテックのシニアセキュリティレスポンスエンジニア 3 人によるチームで約 12,000 ものコードブロックを完全に解析するのに 4 カ月以上を要しました。
多くのバイナリで再利用されることが多い既知の正常なライブラリコードの識別を自動化したり、元の正常なファイルを見つけて悪質な可能性のあるファイルとの差分を比較したりすれば、このように膨大な量の情報でも処理時間を短縮することは可能です。しかし、ブロック数が大きくなれば必ず手作業での検査が必要になります。セキュリティに関して判断を下すための労力と時間は、ファイルに含まれる情報の量に正比例します。つまり、解析作業はファイルサイズにほぼ等しいという法則が成り立つのです。
作業の膨大さを考慮して、SRE は詳しい解析に進む前に特殊なツールを利用する場合もあります。たとえば、制御下の環境に配備したファイルが示す挙動に基づいて判断を下すビヘイビア分析などは有効なツールです。こうしたツールについての詳細は別の機会に譲ります。
よく考えてみると、コマンドプロンプト(cmd.exe)や同等の機能を持つツールは、複数のファイルを削除できるコードブロックを少なくとも 1 つ持っており、しかもユーザーの介在なしにそれを実行できます。このような動作は、それだけでも悪質と見なされ、スタンドアロンのアプリケーションに単独で見つかった場合には(たとえば、実行されるとシステム上で見つけたファイルをすべて削除し始める実行可能ファイルなど)、トロイの木馬と見なされます。とは言っても、cmd.exe や類似のツールは実際には正常なファイルです。では、どうやって判断するのでしょうか。
論理学の場合と同様、真/偽の文と正常/不正なファイルとの類似性が、ここでも同じように働きます。破壊的なコードが実行されるのは、cmd.exe に特定のパラメータが渡され、別の外部パラメータによってユーザー操作が抑止される場合だけです。
基本的に、cmd.exe は以下のように動作します。
del コマンドを入力した場合には、指定されたファイルを削除します。サイレントパラメータを渡すと、確認メッセージは表示されません。
この 2 つの文は、以下のように表すことができます。
S = if P then Q
つまり、P が偽のとき S は真である、つまり正常であるということです。del コマンドがコマンドラインで入力されていない(P が偽である)場合には、cmd.exe によってファイルが削除されないのと同じで、つまりこれは正常な動作です。サイレントパラメータを省略した場合には、コマンドごとに確認メッセージが表示されるということでもあります。
P が真の場合には Q が評価され、それが真であれば S もまた真になります。同じように、ファイルの削除を指示されると cmd.exe は正常に動作します。大きい仕組みの一部である場合は別として、単独では正常です。包丁が、台所で使う道具である一方で犯罪行為に使われることもあるのと似ています。このように、SRE はコマンドを発行するファイルが(正常または悪質な)処理を実行する目的を調べ、その意図を解明します。
最近の脅威や攻撃では実際、相互に対話する複数のモジュールが使われています。ほとんどの場合そのモジュールは明らかに悪質な意図を持って作成されており、悪質であると断定することも比較的容易ですが、特定の脅威に実装されているモジュールの一部が、それ自体では正規のツールであるという場合もあります。
その一例が NetCat で、これはネットワーク管理者が高度なネットワーク接続に使うコマンドラインツールです。NetCat 自体は正常なツールですが、ハッキング攻撃にもきわめて有効であり、バックドア接続を開始する目的で多用されています。悪質な利用が広まったため、シマンテックは NetCat をセキュリティ上の脅威でもありセキュリティ評価ツールでもあると分類しています。NetCat が正当な目的で使われている場合、検出されても無視することができます。
個々のファイルを解析する長いプロセスと、日ごとに増え続ける解析対象ファイルの量から、ファイルの発生元と信頼性を特定することが、プロセスで重要な要因になっています。
たとえば、正規の企業は、品質管理の定義に合致する高品質なコンテンツを作り出すのが普通です。デジタル署名やバージョン情報といった整合性データも必ず揃っています。このような情報を使ってファイルを作成者まで追跡すれば、そのファイルの信頼性も判明します。
既知の正規の企業によって作成されたファイルであれば、(既知の副作用がある、動作に疑わしい点があるなど、完全な解析を実行する明白な理由がある場合を除き)完全な解析プロセスを経なくても、一定範囲の確度で正常であると見なすことができます。
ファイルにフラグを設定するときにも、信頼性は適用されます。今日確認されている脅威ファイルのうち 83% は実際のペイロードに重ねて 1 つ以上のパッカーを使っていますが、正常なファイルのほとんどは簡単に解析できる傾向にあります。信頼できる作成元に由来しているように見せかけたファイルでも、不明瞭化の兆候やデジタル署名の不一致がある、あるいはカスタムパッケージを使っている様子がある場合には、95% 以上の確率でセキュリティ上の問題があるでしょう。通常、信頼できる作成元からの正規のファイルであれば、不明瞭化の手法やカスタムパッカーを使ったりはしないものだからです。
論理学が示すように、真理が指し示すのは真理だけです。同じように、正常なファイルはあらゆるレベルで正常でなければなりません。正常なファイルとは、評価の確かな既知の存在によって作成され、正規の明確な目的のために使われるものであり、正常なブロックのみで構成されるものであるべきです。こうした原則は、ファイルの判定に有用なだけではなく、他の分野にも応用できます。
現在使われている解析手法が(比較的)遅く、その一方で処理すべきファイルの数が日々増えている現状を考えれば、セキュリティベンダーは個々のファイルの詳しい解析を減らして脅威を解析できる新しい手法を生み出す必要があります。信頼性と意図の特定に重点を置く傾向は、今後も強くなっていくでしょう。
ミルチャ・チュボタリュ(Mircea Ciubotariu)著「The Clean Theory」(Virus Bulletin、2013 年 8 月)。著作権は Virus Bulletin Ltd が有していますが、Virus Bulletin の許諾により、このサイトでは個人的な使用に限って無償で公開しています。
* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。
Old rules…
A popular proverb goes like this:
When one adds a pint of clean water to a barrel of sewer water one gets a barrel of sewer water, but when one adds a pint of sewer water to a barrel of clean water one gets… well… a new…