ネットエージェント株式会社 オフィシャルブログ

技術

Anonymousの攻撃は成功するのか?

ネットエージェント株式会社、代表取締役社長の杉浦です。今回は、「Anonymousがインターネットのルートサーバをダウンさせると予告してきた」ことに関連する内容といたしました。

-----

Anonymousがインターネットのルートサーバをダウンさせると予告してきた。
ルートサーバは、インターネットの名前解決における一番の元となるサーバである。一般の人が直接利用する事はほとんどないが、もし仮にここが長時間使えなくなった場合、インターネットもメールも使えなくなると思って良い。
<参考URL>
http://www.itmedia.co.jp/news/articles/1202/21/news033.html

■本当にルートサーバはダウンするのか?
DoSアタックは基本的に数対数の戦いになるので、圧倒的に物量で優位に立てれば勝つという単純な図式が成り立つ。
攻撃側が大量のクエリー(要求)を送信しても、相手側が捌ける量を超えなければ、そもそも攻撃は成功しない。また、もし特定の相手側サーバ1台に攻撃が成功するだけの送信量だったとしても、ルートサーバによっては複数のホストのクラスタとして実装されており、攻撃対象となる到達先の機器が分散される仕組み(Anycastによる負荷分散)等もあるので、サーバクラスタそのものに対する目的(=ダウン)は達成されない。
最近の一般的なサーバ1台の応答性能は50,000~100,000クエリー/秒程度である。では、果たして攻撃側のDoSアタックではどの程度まで送出可能なのであろうか?かつて社内の製品試験で過去に数多くのDNSクエリーを発行する実験を行ったところ、社内のテスト環境でも1,000,000クエリー/秒ぐらいのリクエストが送信可能だった。
実験と違い、DDoS用途として扱う場合はリアルなDNSクエリーにする必要があるので、若干手を加えることになる。しかし、ほぼ同等の速度でクエリーを送出することはそう難しくないだろう。攻撃側は想像より少ないDoSアタック用端末数でも攻撃を成功させることが可能なのかもしれない。

■実際の影響は?
仮にルートサーバが全部ダウンしたとしても、直後であれば大半のページは閲覧可能だろう。ルートサーバがダウンした場合に生じる現象としては、Webサイト閲覧やメールの送受信が出来なったりするわけだが、ルートサーバが攻撃されている間、クライアントとの中間に存在するDNSキャッシュサーバがキャッシュを保持し続けている間は、こうした名前解決のトラブルは発生しにくい。従って、もし本当に3月31日に攻撃が始まったなら、DNSのキャッシュ内容をフラッシュするのは止めておいたほうが良い。ルートサーバのレコードのTTL(Time To Live=寿命)は比較的長いので、うまく行けば攻撃が終わるまで、ルートサーバのキャッシュ寿命が切れる前に攻撃が終わる。
ちなみにrootサーバによってレコードの寿命は異なる。中には800秒や3600秒といった短い寿命のTLDもあり、攻撃による影響が出やすいため見られないサイトが出てくる可能性がある。ちなみに日本にあるm.root-servers.netは3600000秒、およそ41日程度だ。恐らくはその辺の事情もあって、Anonymous側は攻撃が数日続く可能性も示唆しているのだろう。

■誰が守ればいいのか?
まずルートサーバを管理運営している組織、関係者がこれを守るのは当然だが、時間的余裕があればそれだけ対策は立てやすくなる。Anonymousの攻撃予告は3月31日で、それまでまだ40日近くある。当日までに世界中の多くの関係者が知恵を絞ってきちんと対策するはずで、恐らく大きな問題は生じないと思われる。
だがもし仮に万が一攻撃が成功してルートサーバがダウンしてしまった場合に備えて事前に何が出来るか。名前解決ができなくなるであろうと予測される期間に備え、レコードを事前にキャッシュしておくことで一定の効果は見込まれる。要は予めルートサーバのコピーを作っておいて、いざというときには使えるような備えをしておくような運用が出来ればよい。

トップレベルドメイン一覧にあるデータを前もって全部引いておき、キャッシュ。

以下のコマンドを叩くと全TLD(Top Level Domain)を引いてくれる。

perl -e '$a="arpa,aero,asia,biz,cat,com,coop,info,int,jobs,mobi,museum,name,net,org,pro,tel,travel,xxx,edu,gov,mil,ac,ad,ae,af,ag,ai,al,am,an,ao,aq,ar,as,at,au,aw,ax,az,ba,bb,bd,be,bf,bg,bh,bi,bj,bm,bn,bo,br,bs,bt,bv,bw,by,bz,ca,cc,cd,cf,cg,ch,ci,ck,cl,cm,cn,co,cr,cs,cu,cv,cx,cy,cz,dd,de,dj,dk,dm,do,dz,ec,ee,eg,eh,er,es,et,eu,fi,fj,fk,fm,fo,fr,ga,gb,gd,ge,gf,gg,gh,gi,gl,gm,gn,gp,gq,gr,gs,gt,gu,gw,gy,hk,hm,hn,hr,ht,hu,id,ie,il,im,in,io,iq,ir,is,it,je,jm,jo,jp,ke,kg,kh,ki,km,kn,kp,kr,kw,ky,kz,la,lb,lc,li,lk,lr,ls,lt,lu,lv,ly,ma,mc,md,me,mg,mh,mk,ml,mm,mn,mo,mp,mq,mr,ms,mt,mu,mv,mw,mx,my,mz,na,nc,ne,nf,ng,ni,nl,no,np,nr,nu,nz,om,pa,pe,pf,pg,ph,pk,pl,pm,pn,pr,ps,pt,pw,py,qa,re,ro,rs,ru,rw,sa,sb,sc,sd,se,sg,sh,si,sj,sk,sl,sm,sn,so,sr,ss,st,su,sv,sy,sz,tc,td,tf,tg,th,tj,tk,tl,tm,tn,to,tp,tr,tt,tv,tw,tz,ua,ug,uk,us,uy,uz,va,vc,ve,vg,vi,vn,vu,wf,ws,ye,yt,yu,za,zm,zw,xn--lgbbat1ad8j,xn--54b7fta0cc,xn--fiqs8s,xn--fiqz9s,xn--wgbh1c,xn--node,xn--j6w193g,xn--h2brj9c,xn--mgbbh1a71e,xn--fpcrj9c3d,xn--gecrj9c,xn--s9brj9c,xn--xkc2dl3a5ee0h,xn--45brj9c,xn--mgba3a4f16a,xn--mgbayh7gpa,xn--80ao21a,xn--mgbx4cd0ab,xn--mgbc0a9azcg,xn--mgb9awbf,xn--mgbai9azgqp6j,xn--ygbi2ammx,xn--wgbl6a,xn--p1ai,xn--mgberp4a5d4ar,xn--90a3ac,xn--yfro4i67o,xn--clchc0ea0b2g2a9gcd,xn--3e0b707e,xn--fzc2c9e2c,xn--xkc2al3hye2a,xn--mgbtf8fl,xn--kprw13d,xn--kpry57d,xn--o3cw4h,xn--pgbs0dh,xn--j1amh,xn--mgbaam7a8h,xn--mgb2ddes";@b=split(",",$a);for(@b){system("dig $_ ns");}'

たまにはハードウェア工作を楽しもう!

 こんにちは。ネットエージェント株式会社、研究開発部の長谷川です。今日は少し低レイヤの話ということで簡単なハードウェア工作を楽しもうと思います。

-----

■ ディスプレイを回転させたい!
 デュアルディスプレイの便利さはみなさんご存じのとおりだと思いますが、PDFやWordなどでA4サイズの文書を表示させているときなどに「ディスプレイを縦向きに表示させたい!」と思うことはありませんか? 私は普段からそう感じており、一時期、サブで使用しているディスプレイを縦向きに使用(表示)して使っていたのですが、日常的な作業では、やはり縦よりも横のほうが向いていることもあり、なかなか思ったほど気持ちよく作業できる環境ではありませんでした。
 というわけで、もう少し気軽に縦横を変えられる仕組みを実現しようと思い、ディスプレイ回転ツールを自作しました。

■ 材料
 今回使用した材料は以下になります。
  1. 液晶ディスプレイ用アーム(ARM-41C)
  2. スイッチ(5Aマイクロスイッチ)
  3. USB-シリアル変換ケーブル(USB-シリアル変換ケーブルUC-SGT)
  4. シリアルケーブル
  5. みんな大好きフリスクケース
 まず必要なのは液晶ディスプレイ用のアームです。一般的な液晶ディスプレイ用アームは、視野に対する角度などは細かく調整できますが、ディスプレイそのものの縦横を回転できるものは少ないです。それでも、丹念に探すと液晶の縦横回転機構を備えたものもそれなりの価格で見つかります。今回調達したものは、ライブクリエータ社のARM-41Cというもので、ヨドバシカメラで7000円を切る価格で手に入りました。
 次にスイッチですが、これはディスプレイの縦横を検出するために使用します。どのようなものでも構いませんが、今回はおもちゃ売り場で売っていたタミヤの5Aマイクロスイッチを使用しました。
 また、スイッチのON/OFFをPCに取り込むために、シリアル通信(いわゆるRS-232C)を利用することにし、今時のPCだとCOMポートがついていないため、USB経由でCOMポートを利用可能にするために、エレコムのUSB-シリアル変換ケーブルUC-SGTを使いました。
 あとは、クロスでもストレートでも構いませんので、スイッチに接続するために使用するシリアルケーブル。そして、スイッチを固定する台座として、みんな大好きフリスクケース。それ以外にもネジや両面テープなど適宜用意しておくと便利です。

■ ハードウェア工作
 fig1まずは、フリスクケース2個を振り子になるようネジで固定し、回転したときにスイッチが押されるようにスイッチも固定します。振り子側は、きちんとスイッチを押さえられるように中にコインを重りとして入れています(左図)。
 fig2シリアルケーブルのDTR、DSRをスイッチにハンダ付けします。また、ケーブルの自重でスイッチやハンダ付け部分が痛まないようにケースにケーブルを固定しておきます(右図)。
 fig3スイッチ部分ができあがれば、液晶ディスプレイ背面に両面テープでスイッチ機能付きフリスクケースを取り付けます。しっかりとスイッチが押されるように少し斜めに取り付けるのがコツです。縦、横とディスプレイの向きを変えたときにきちんとスイッチがON/OFFされるか確認します(左図-横、右図-縦)。
 fig4これで、ハードウェアの準備は完了です。あまりお金をかけない簡単な工作で、ディスプレイの向きに応じてシリアルポートのDTR-DSRがON/OFFされる装置が出来上がりました。

■ ソフトウェアの準備
 ハードウェアを作成したので、次はソフトウェアを組みます。
 ディスプレイの向きはシリアルポートのDSR信号を監視することで把握でき、監視するコードは、概ね以下のようになります(監視コードはサービスとして動作させています)。

HANDLE hComm;
OVERLAPPED ov;
DWORD dwCommState;

/* 略 */

EscapeCommFunction( hComm, SETDTR ); // DTR信号をON
SetCommMask( hComm, EV_DSR ); // DSR信号の変化を監視
ResetEvent( ov.hEvent ); // 非同期I/Oのためイベントをリセット

WaitCommEvent( hComm, &dwCommState, &ov ); // DSRの監視スタート
WaitForSingleObject( ov.hEvent, 30000 ); // イベント発生まで待機

 ディスプレイ表示の向きを変えるには、以下のようなコードで実現できます(エラー処理等は省略)。

int iDevNum = 1; // Display No.2
DISPLAY_DEVICE d;
DEVMODE dm;
int w;

ZeroMemory( &d, sizeof( d ) );
d.cb = sizeof( d );

EnumDisplayDevices( NULL, iDevNum, &d, 0 ) );
EnumDisplaySettings( d.DeviceName, ENUM_CURRENT_SETTINGS, &dm ) );

w = dm.dmPelsHeight;
dm.dmPelsHeight = dm.dmPelsWidth;
dm.dmPelsWidth = w;
dm.dmDisplayOrientation = DMDO_90; // 90度回転

ChangeDisplaySettingsEx( d.DeviceName, &dm, NULL, CDS_UPDATEREGISTRY, NULL );

 全ソースコードはGitHub上に置いてあります。興味がある方は参照してください。
 サービスとしてシリアルポートを監視していると、ユーザのディスプレイ(デスクトップ)とは直接対話できないため、シリアルポートからの信号を受け取った時点でログオンしているユーザのトークンを用いてCreateProcessAsUserを使ってディスプレイ表示の向きを変えるためのプログラムを起動しています。

■ さいごに
fig5 このように、ディスプレイの向きを検出するスイッチと、それに応じて表示の向きを変えるプログラムを作成することによって、ディスプレイの向きを物理的に変えることで表示も連動して変わり、非常に快適になりました(左図:縦表示)。
 ソフトウェアエンジニアにとって、ハードウェア工作は若干敷居が高そうに思えるかもしれませんが、ソフトウェアと同じくらい面白く、また出来ることの幅、可能性も広がると思います。興味があればぜひとも挑戦してみてください。
 それにしてもフリスクケースはちょっとした工作にはとても便利ですね。Enjoy!

バイナリファイルの可視化ツール BinVis の紹介

 はじめまして、ネットエージェント株式会社の村中と申します。今回はバイナリファイルの可視化ツール BinVis を紹介したいと思います。

-----

 BinVis はバイナリファイルを解析、可視化し、特徴ある部分を探したり、特定のパターンや(場合によっては)暗号データを調べたり、といった用途で使用される高機能なファイル可視化ツールです。とは言っても、最終的には目視による解析は必須なのですが、それらを可能な限り支援してくれるツールとして、主にリバースエンジニアリングやフォレンジックの分野で利用できます。
binvis_annotated3_prob では、早速使ってみます。BinVis を用いて、wav ファイルを開いた時の表示を右図に示します。各ウィンドウは、それぞれ以下の形式でバイナリデータを解析、表示します。
  1. Text
  2. Byte Plot
  3. RGB Plot
  4. Bit Plot
  5. Dot Plot
  6. Byte Presence
  7. Strings
  8. Byte Cloud
  9. Byte Frequency
 まず 1. の Text ですが、これは 16 進ダンプと ASCII でデータ列を表示します。ヘキサエディタによくある表示ですね。この Text ウィンドウには 336 バイトしか表示されませんが、後述の Byte Plot から表示オフセットを変更できます。
 2. の Byte Plot は、1 バイトを 1 ピクセルに、つまり「値」を「色」に対応させて表示します。色づけは Color Coding ウィンドウから変更でき、Normal、ASCII、Frequency、Invert の4つから選択できます。ボタンの効果は順に、0~255 の値をそのまま緑色の明るさに、ASCII 文字だけ青色で表示、低頻度の値は青で高頻度の値は赤で表示、色の反転となっているようです。また、Byte Plot の任意の位置をクリックすると、クリックした位置に対応した部分が Text 表示に反映されます。
 続いて 3. の RGB Plot ですが、これは 3 バイトを 1 ピクセルに、つまり 1 バイトごとの値にそれぞれ三原色の赤・緑・青を対応させて表示します。このウィンドウでは折り返しする幅を 1~640 の値で設定でき (地味なバグで、一度スライドバーを動かすと 631 までしか設定できないが…)、これをうまく使うとベタに保存された画像を簡単に確認できます。
 4. の Bit Plot は 1 ビットを 1 ピクセルに対応させて表示、つまりは ON/OFF での表示です。
 以上の 4 つが、もっとも基本的な可視化機能となります。これらに加えて、さらに解析をやりやすくするための機能が以降の 5 つになります。
 5. Dot Plot は、縦軸と横軸をファイルのオフセットとして、その交差する部分の値が同じなら色をつけます。値によって明るさが変わるようです。6. Byte Presence は、ある一定の範囲に 0~255 の値がそれぞれあるかどうかを調べ、あれば色をつけます。横軸が 0~255 の値、縦軸がブロックとなっています。7. Strings は、ASCII 文字が 5 文字以上続いたデータを文字列と見なし、一覧で表示するもので、いわゆる strings コマンドと同等の機能です。8. Byte Cloud は 0~255 の値がそれぞれファイル内にどれくらいあるかによって文字の大きさを変えて表示するものです。4~5 年ほど前に登場したタグクラウドのバイナリ版と思えばよいでしょう。そして最後の 9. Byte Frequency は、ある範囲内で、それぞれの値が出現する頻度をヒストグラムで表示するもので、頻度解析などでよく利用されます。
 以上、各ウィンドウを簡単に解説しましたが、より詳しい説明は、Visual Forensic Analysis and Reverse Engineering of Binary Data がご参考になると思いますので、興味がある方はぜひ参照ください。

 さて、以上で機能解説は終わりですが、個人的な感想としては、紹介した表示のほとんどは Navigator ウィンドウから表示位置を変更でき、Plot 系や Byte Presence や Byte Frequency の表示は同期するため、かなり「分かりやすい」目視が可能だと感じました。また、Navigator ウィンドウにある Play/Stop ボタンを使うと自動的にスクロールする機能もあるため、流し読みもできます。
 特に気に入った機能は Dot Plot と Byte Presence で、これらの表示はファイル内に出てくるデータの特徴をかなりはっきり表示できており、特に Dot Plot は値の周期や繰り返しがあった場合の表示が特徴的で、wav ファイルを見るとかなり興味深い絵が見られます。また、Byte Presence は値に偏りがあるときの表示が特徴的で、Byte Plot の横に並べるとより効果的にデータの特徴を確認できます。
 逆に、Bit Plot や Normal 色づけの Byte Plot は、BMP 形式くらいでないと違いがわかりにくく、これらは少し使いにくく、利用頻度に欠けると感じました(対象データによるとは思いますが…)。

-----

 BinVis は、全体的にグラフィカルに表示する機能が充実しているので、シグネチャや値を見て解析するような用途にはあまり向かないかもしれませんが、データを大雑把に見る、眺めるといった用途にはかなり適していると感じました。
 今回は BinVis 自体の紹介をさせていただきましたが、Visual Reverse Engineering of Binary and Data Files では、利用する際のケーススタディが 4 つほど紹介されており、BinVis の非常に有用な使い方が載っています。また、BinVis のソースコードも公開されていますので、その気があれば自分で改良もできます。
 BinVis自体は今のところ Attractor が動かなかったり、最後までスクロールした時や Byte Plot 表示でファイルの終端以降をクリックした時に例外が発生したり、Color Coding を変更しても Navigator を操作するまで変更が反映されなかったりと、まだ完璧とは言い難い品質ですが、ファイル解析のアプローチを増やしてくれる点ではかなり面白いツールです。興味があれば、ぜひとも触ってみてください。

PCTF 2011 参戦記

 こんにちは、愛甲です。今回は、先週末に行われた PCTF 2011 も含めた、セキュリティコンテスト全般について書かせていただこうと思います。とはいっても、最近 CTF 参戦記ばかり書いている気がしますので(汗)、今回は少し違った視点でセキュリティコンテストについて考えてみたいと思います。「そもそも CTF って何?」という方は、前回の記事をご参照ください。

-----

■ PCTF 2011
blog2 PCTF とは、アメリカの PPP_CMU というチームが主催するセキュリティコンテストです。彼らは今年の CODEGATE 2011 CTF の優勝チームでもあり、この度、ロッキードマーティン社をスポンサーとして、CTF を開催することになりました。
 PCTF はオンラインで、日本時間の 4月23日(土)6:30 ~ 4月25日(月)6:30 までの 48 時間で行われました。それで、いきなりなのですが、sutegoma2 は 5 位という結果に終わりました。実は競技終了の 3 時間ほど前に一時暫定 1 位となったのですが、その後は得点が伸びずに…、といった具合で、結局は 5 位で終了となりました。まぁ結果は結果で仕方がないので、より勉強していこう、頑張っていこう、という新たな決意で再スタートしたいと思います。
 さて、前回の記事で問題の傾向や雰囲気について書きましたので、今回はまた別の角度から CTF について紹介したいと思います。

■競技時間
 実は CTF は主催国によって若干の時間的な有利不利が存在します。例えば、前回の CODEGATE 2011 CTF は韓国のチーム主催ですので、韓国の時間で実施しやすい 48 時間が競技時間として選ばれます。韓国と日本の時差はほとんどないので、日本時間にしても 3月4日(金)21:00 ~ 3月6日(日)21:00 までの 48 時間という、日本に住んでいる人にとって(というよりも韓国に住んでいる人にとって)有利な時間となりました。
 しかし、PCTF は開催国がアメリカですので、日本時間にすると 4月23日(土)6:30 ~ 4月25日(月)6:30 までの 48 時間という、月曜日の予定に大きく影響の出る時間帯となります。ほとんどの社会人は月曜日の朝から仕事がありますし、学生であっても月曜日の予定が確実に空くとは限りません。つまり、日本にとっては終盤に進むにつれて確実に不利になっていきます(逆に韓国主催の CODEGATE では、序盤がアメリカ不利となります)。
 よって、CODEGATE で予選 1 位になれたのは、時間的な優位性も少なからずあったのかもしれません。また逆に、次回 6 月に行われる DEFCON CTF では、アメリカ開催であるため、時間的に不利な立場になることが予想できます。

■出題される問題
 CTF にはセキュリティに関する全般的な問題が出題されます。@IT にて辻伸弘氏が「第1回 プレイ・ザ・ゲーム! CTFが問いかけるハックの意味」と題して、CTF の問題について紹介、解説をされていますので、興味がある方はぜひご参照ください。
 さて、前回の記事で、CTF には主に 6 つの分野から問題が出題されると書きました。それらは「暗号」「フォレンジック」「リバースエンジニアリング」「脆弱性」「パケット解析」「トリビア」の 6 つですが、今回は、これらとは別の角度で出題される問題を分類したいと思います。

●タイプ 1 :問題ファイルを解析するタイプ
 代表的なものはフォレンジックとパケット解析系の問題です。問題として与えられるファイルの中にパスワードがあるタイプで、例えば「 pkt ファイルを解析して、サーバからダウンロードされている実行ファイルの MD5 ハッシュ値を求めよ」といったものや、「 NTFS を解析して削除されたパスワードファイルを復元せよ」といった問題になります。
 サイズの大きな問題ファイルに対してのアプローチ方法、いかに巨大なファイルから欲しいデータを取りだすか、といった技術力が問われます。

●タイプ 2 :問題ファイルを復号するタイプ
 代表的なものは暗号問題ですが、バイナリ系の一部もこちらに属します。問題ファイルの中や問題文自体にパスワードが隠されているという点ではタイプ 1 と同じですが、こちらは探すことではなく、それらを「復号すること」がメインとなります。EXE ファイルの実行中にメモリ内を参照するとパスワードが見つかる、といったリバースエンジニアリング系の問題や、謎のデータ列が渡され、それを解読してパスワードを得る暗号系の問題をこのタイプに分類します。
 今年の CODEGATE では、予選と決勝の両方で、以下のような問題が出題されました。

 解読せよ:SCMPKBOUPDPHYTIAVIVRBTMVORUDNBDFNETDOIVTXRO
      UNDKOBFWBPVOEQLTGKKARACYCGDNAECBXIZIKPTLEER
      ZTYCYKIVXCPKPTPOVCAQRHRVKJUWMTWCMSXKADYHRVN
      AHCBRVSVSSCQCZQYDJXGSNRVSWCESTTBHIFCIASXRTA
      HKRRTUMVOKWITZPFZDISXZVVLGETPPLKSELDPGKELSH
      CBJBWXBIFCPEZYNBWXCDYMGAOVWNDKAKKKWBBQKPTIO
      DKMGGHRVVNHINFCQESDYMLACVVBWBBQROPBBDFOXOSK
      DIGZWXFNTKFYIICWHRVVNHIYILTKHRVXPISB

 これはコンピュータ技術に関するものではなく、純粋な暗号の問題になります。答えはヴィジュネル暗号なのですが、このような問題を解くためには実用的に使われる現代暗号のみではなく、古典暗号も含む、全般的な暗号に関する知識が必要になります。

●タイプ3 :リモート環境にあるパスワードを取得するタイプ
 代表的なものは Exploit と Web 系の問題です。Exploit 系の問題は、脆弱性を探し出し、権限を奪うことで Key ファイルへのアクセス権を獲得し、その Key ファイルの中に書かれてあるパスワードを取得します。Web 系の問題もほぼ同じですが、こちらは SQL インジェクションを始めとした Web に関するテクニックを用いて、例えばデータベースの中にあるパスワード等を得るタイプです。
 タイプ 1 やタイプ 2 とは明確に異なり、問題ファイルや問題文の中にはパスワードはなく、実際に外部のサーバや Web サイトを攻撃してパスワードを得る必要があります。リモート環境の権限を得る、データベースにアクセスする、といった分かりやすい目的であるため、ある意味もっともシンプルなタイプと言えます。
 問題文においても、サーバのIPアドレスとポートのみが書かれてあったり、問題となる Web ページの URL のみが書かれてある、といったシンプル具合です。

●タイプ4 :パスワードを推測するタイプ
 代表的なものはトリビア問題で、クイズのような問題がこのタイプに当てはまります。検索しなければ分からない問題や、業界の歴史やイベントなどを知ってないと解けないものも多いです。
 今回の PCTF では、トリビアとして以下の問題が出題されました。

 Figure out what the corrupted value is.
 1.3337 ~= XXXXXXX/3145727

 XXXXXXXに入る文字列が解答となるのですが、いかがでしょうか? ちなみにこの答えは「4195835」で、解説については Pentium FDIV bug を参照してください。個人的にはまさにトリビアらしく、かつ、なかなか興味深く、面白い問題だったと思います。

 CTF の問題は以上の 4 タイプに分けられますが、逆に考えれば、上記の 4 タイプのいずれにも当てはめ難いならば、それは CTF には使われ難い問題と言えます。またタイプ 4 はほとんどトリビア問題でしか扱われないため、実質、上記の 1~3 のタイプが考察対象となります。
 では、例えば、XSS を考えましょう。サーバ内にあるパスワードを XSS で取得するといった問題は作れませんので、タイプ 3 はありません。またタイプ 1 やタイプ 2 のような、htmlファイル内を探索、あるいは解読してパスワードを得るといったものも XSS の問題とは言えませんので無理でしょう。よって、XSS は CTF では扱いにくい問題と言えます。CSRF も同じ理由で難しいです。
 逆に、SQLインジェクション、またセッション管理系の成りすまし(Cookie関連)などはタイプ 3 に分類できますし、JavaScript の暗号化や難読化といった分野はタイプ 2 に分けられます。あと、バッファオーバーランを利用した Exploit や Pack された実行ファイルのリバースエンジニアリングなどは、比較的出題しやすい問題だと思います。
 出題し難い問題は、他に ARP スプーフィングのような TCP/IP 以下のレイヤーを扱うもの、また、ターゲットサーバのカーネルを対象とした問題なども出題が難しいです。そもそもカーネルを扱う問題自体、CTF ではほとんど出ません。
 このように考えていくと、CTF がどのような技術を競うもので、どういった分野を学んでおくことが重要であるかが分かってきます。このような「傾向」を考えてみるのも面白いかと思います。

■運用システムの問題
 CTF はセキュリティに関する様々な問題を扱いますが、分野は違えど、最終的に「解答となるパスワードを探す」という点においては同じです。これは極論すると、すべての問題が「与えられたファイルや情報からパスワードを探せ」というスタンスでしかなく、そのパスワードを submit したかどうかでのみ正解、不正解が決められます。
 これはシステムとして運用しやすく、オンラインでの開催が容易である反面、パスワードさえ分かってしまえば問題そのものを解く必要がないとも言えます。つまり、カンニングやチーム間での教え合いが容易に可能であり、またそれを制限できません。よって、その気になれば、1 位が確定したチームは 2 位以下のチームに解答パスワードを教えることで、そのランキングを自由に操作できますし、同じ国同士のチームで解答を共有し、ランキングを占有、なんてこともやろうと思えば可能です。
 そのような不正を防ぐために、CODEGATE CTF では決勝戦へ進むチームに対して、解答レポートの提出を義務付けています。これは、「どのようにして解答パスワードを得るに至ったか?」を書くレポートであり、予選終了後、3~4 日までに提出する必要があります。
 このレポート提出により、極端な不正は防止できると思いますが、ランキングの上位では数百点の差に 2~3 チームがひしめき合うなんてことは普通に起こり得ます。そして、それらのチームが予選通過の条件である 8 位以内に入るために 1~2 問程度を仲の良いチームと交換する、といったことが起こらないとは限らず、またそれを防ぐことは難しいです。これは、運営や不正を行うチームが悪いと言っているわけではなく(まぁ不正は良くないですが…)、現状の CTF のシステム的な限界だと思います。それも踏まえて、決勝戦へ進むためには、予選においてある程度「余裕勝ち」しておく必要があるのかもしれません。

■その他のセキュリティコンテスト
 セキュリティコンテストは CTF 以外にもたくさんあります。例えば、韓国のセキュリティカンファレンス Power of Community 2010(以下、POC)で、Hacker's Dream という CTF と同じオンライン型のセキュリティコンテストが開かれました。ただ、ルールは CTF とは大きく異なり、解答をレポートにまとめて submit するという、また少し違った形式のコンテストだったようです。ちなみに、2010 年は日本人が優勝しており、優勝者である大居氏のブログからコンテストの詳細が確認できます。
 他にも、詳しくは知らないのですが、F-Secureリバースエンジニアリングチャレンジ、Panda Challengeといった、カンファレンスではなく企業が実施しているセキュリティコンテストも多くあります。
 CTF もそうなのですが、ここ 2~3 年でセキュリティ系のコンテストは数多く実施されるようになりました。参加資格が国内在住者限定のものも多いですが、オンライン上で、誰でも参加できるものもあるため、力試しに参加してみても面白いかもしれません。

第1回 Win32 API 探検隊

 こんにちは。ネットエージェント株式会社、研究開発部の長谷川です。
 今回は、ちょっと軽めのネタということで、MSDN Library を眺めていて見つけた、少し変わった Windows API 関数を紹介したいと思います。

■ 使い道がありそうで見つからない PathIsExe
 Shell32.dll に含まれる PathIsExe 関数は、引数で指定したファイルが実行可能なファイルかどうかを、ファイル名の拡張子を見て判断します。例えば、"*.exe" や "*.cmd" といった拡張子であれば TRUE が返ります。
 Shell32 に含まれるということで、Explorer のようなシェルやシェル拡張などを書いている場合には(もしかすると)利用するかも知れませんが、一般のアプリケーションを開発する場合にはあまりお世話になる機会はなさそうです。
 同じ Shell32.dll には、PathIsSlow という面白い関数もあります。これは、指定したパスが遅延の大きなネットワークドライブなどであった場合に TRUE を返すようです。
 また、Shlwapi.dll にはこれらとよく似た名前で、PathIsURL という関数もあります。引数で指定された文字列がURLの書式に合致すれば TRUE を返すようですが、"http:" や "ftp:" だけでなく、"+-:" や "..:" などでも TRUE が返ってくるというおもしろ仕様なので、大抵の場合は自分で似たような関数を用意しなければなりません。

■ ちょっと便利な StrFormatByteSize
 Shlwapi.dll に含まれる StrFormatByteSize 関数一族は、数値を KB や MB といった単位付きのサイズ文字列に変換する関数です。
 例えば、23506 という数値を StrFormatByteSize64 に渡すと、"22.9KB" という、人間に読みやすい形に単位を変換して書式化した文字列を得られます。ファイルやメモリのサイズを表示する場合に、自分で書いてもたいしたコード量にはなりませんが、覚えておくとちょっとだけ便利です。
 さて、MSDN Library には、以下の5種類の関数の説明が掲載されています。
  1. StrFormatByteSize64
  2. StrFormatByteSizeA
  3. StrFormatByteSizeEx
  4. StrFormatByteSizeW
  5. StrFormatByteKBSize
 ぱっと見て気がつくのは、ANSI バージョンである StrFormatByteSizeA と Unicodeバージョンである StrFormatByteSizeW がそれぞれ別々に定義されている点です。実は、StrFormatByteSizeA と StrFormatByteSizeW は、単純に ANSI 版と Unicode 版という関係ではなく、ANSI 版が DWORD で 32 ビットまでのサイズにしか対応していないのに対して、Unicode 版は LONGLONG で 64 ビットのサイズに対応しています。また、StrFormatByteSize64 という関数は、ANSI 版である StrFormatByteSize64A しか定義されておらず、Unicode 環境では StrFormatByteSizeW が呼び出されます。
 使いそうであまり使わず、それでいて自分で作ってもたいしたコードでもないような関数が用意されていて、にも関わらずチグハグ感が満載というあたり、いかにも Windows らしいですね(編注:そんなWindowsが大好きなんです!)。

■ 末尾の Ex が 2 段重ねの関数
 Windows API で、あとから機能が拡張されたために名前の末尾に Ex のつく関数はたくさんありますが、EnumCalendarInfoExExEnumDateFormatsExExLogOnUserExExW は、末尾の Ex が 2 個重ねられた名前となっています。あと 3 年くらいしたら、ExExEx などになるのでしょうか。
 ちなみに、Win32 API で現存するもっとも長い関数名は、おそらく ConvertSecurityDescriptorToStringSecurityDescriptor あるいは ConvertStringSecurityDescriptorToSecurityDescriptor の 51 文字だそうです。IDE やエディタの入力支援がなければ、何度も打つのはうんざりしてしまいそうです。

■ APIとしては高機能すぎる SendARP
 Iphlpapi.dll に含まれる SendARP 関数は、その名前の通りコマンドラインの arp コマンドのように、ARP リクエストを送信します。なかなかアプリケーションから ARP を送ることは少ないと思いますし、ARP 自体が小さいとはいえ単一のプログラムとして成り立つくらいのものであり、それを API関数 として用意しているというのはちょっとビックリです。

■ 指定したアドレスのメモリの読み書き権限を調べる IsBadReadPtr / IsBadWritePtr
 Kernel32.dllに含まれる IsBadReadPtr 関数や IsBadWritePtr 関数は、引数として指定されたアドレスのメモリが読み書きできるかを調べる関数です(Vista以降ではサポートされていません)。サードパーティ DLL において渡されたパラメータが適切なものかどうかを判断するといった利用が想定されていたようですが、普通に考えると SEH を利用してコード全体を保護するほうが効率が良さそうです。

■ さいごに
 最後にちょっとしたTIPSを。MSDN Libraryは、表示の設定を "Classic"、"Lightweight"、"ScriptFree" から選択できますが、URLにおいて ( ) 内に "classic"、"lightweight"、"loband" などを指定することでも表示を切り替えられます。例えば http://msdn.microsoft.com/en-us/library/aa363858(VS.85,classic).aspx にアクセスすると classic 表示に、http://msdn.microsoft.com/en-us/library/aa363858(VS.85,loband).aspx にアクセスすると ScriptFree の表示に切り替わります。覚えておくとちょっと便利ですね。
記事検索
月別アーカイブ
QRコード
QRコード