フロムスクラッチ開発者ブログ

from scratch Engineers' Blog

CTFのパケット解析から学ぶセキュリティとハッキング vol.2

 こんにちは!フロムスクラッチ新人エンジニアのおんじです!
 今回のブログでは、前回の記事「CTFのパケット解析から学ぶセキュリティとハッキング」の実践編として、Wiresharkを使ったHTTPプロトコルのパケット解析による画像オブジェクトの抽出やFTPプロトコルのパケットによるファイル抽出に取り組んでいこうと思います。
 尚、今回の記事のきっかけとなっている社内勉強会は『セキュリティコンテストチャレンジブック CTFで学ぼう情報を守るための戦い方』の内容を参考にしています。より深く気になられた方は、そちらも御覧頂ければと思います!

1.HTTPプロトコルのパケット解析によるオブジェクトの抽出

 Wiresharkは、前回の記事でも紹介したGUIのネットワークパケット・プロトコル解析ツールです。これを活用すると、HTTPプロトコルの通信をキャプチャして、そこに流れているHTMLファイルや画像、CSS、 JSON や XML などのオブジェクトを抽出することができます。そこで今回は、Wiresharkを使ってフロムスクラッチの子会社であるTechJINのホームページから、会社ロゴの画像オブジェクトを抽出してみたいと思います。
 f:id:kota-onji:20180512140605p:plain
 まずは、抽出したいオブジェクトが流れる通信をキャプチャしてきます。前回も確認した通りパケットキャプチャを開始すると、大量のパケットが記録されていきます。このままだと表示件数が多すぎるので、キャプチャしたパケットの中からHTTPプロトコルのものだけを表示できるようにしたいと思います。
 Wiresharkには、条件にあったパケットのみを表示するDisplay Filterと呼ばれるフィルタリング機能があります。この機能を使い、必要なパケットのみを表示します。今回の場合は、HTTPプロトコルが使われているパケットのみを表示したいので、下記画像のように入力欄に"HTTP"と入力します。
f:id:kota-onji:20180511160430p:plain
すると、、、
f:id:kota-onji:20180512140838p:plain
 このように、HTTPプロトコルを使用したパケットのみが抽出して表示されるようになりました。
 今回は検索ページに直接プロトコル名を打ち込みましたが、他にも直接条件式を打ち込むことでプロトコルのフィールド名まで指定したより詳細なフィルタリングも、このDisplay Filterで実現することが出来ます。

 さて本題に戻りますが、問題のオブジェクトを抽出するために、WiresharkのExport Objects機能を利用していきたいと思います。以下の画像のように、File > Export Objects > HTTP Objects を開きます。
f:id:kota-onji:20180509133956p:plain
 すると、以下の画像のようにHTTPオブジェクトが一覧として表示されます。
f:id:kota-onji:20180512142853p:plain
 先程のページをデベロッパツールで確認すると、該当する画像はmark_i.pngというファイル名であることがわかります。
f:id:kota-onji:20180512143953p:plain
よってExport Objectsの画面で該当するファイルをダウンロードしてくると、、、
f:id:kota-onji:20180512144117p:plain
 上記の通り、画像オブジェクトの抽出とダウンロードに成功しました!
今回は画像のケースを取り上げましたが、他のオブジェクトであってもいとも簡単に、抽出してくることができてしまうのです。

2.FTPプロトコルのパケット解析による転送ファイルの抽出

 さて、ここまではHTTPプロトコルについて見てきました。今度は、FTPプロトコルについて見ていきます。FTPサーバをローカルに構築し、そのサーバにb→dashアイコンのpng画像を転送して、転送した画像データをパケット解析によって抽出してみたいと思います(尚、今回はパケット解析にフォーカスするために、サーバの構築~データの転送の部分については省略致します)。

 その前に、前提となるFTPプロトコルの通信の流れについて確認していきます。
f:id:kota-onji:20180511155144p:plain
 上の図のように、FTPプロトコルは「データコネクション」と「コントロールコネクション」とを組み合わせて転送を行います。データコネクションは、実際にデータを転送するためのコネクションになります。それに対して、コントロールコネクションは、FTPサーバにログインする際の利用者認証やFTPコマンドの送受信など、データコネクションを制御するためのコネクションとなっています。
 
 では、実際にデータを転送した際のパケット情報を見てみます。
f:id:kota-onji:20180511154211p:plain
まず、Aの部分はコントロールコネクションに該当します。ユーザーログインのリクエストとレスポンス、データ転送のリクエストとレスポンスが行われています。次に、Bの部分、ここがデータコネクションに該当します。先程のデータ転送のレスポンスを受けて、クライアントからサーバにデータ転送が行われています。そして最後のCで、またコントロールコネクションに帰ってきて、データ転送成功のレスポンスと、通信の終了が行われています。
 
 さて、抽出するデータがやり取りされているパケットがわかった所で、実際にファイルの抽出に入っていきたいと思います。そこで、今回はTCPストリームという機能で、直接データコネクションの通信内容を参照して、そこからファイル抽出を行います。
 まずは、Wireshark上で先程のデータコネクションに該当するパケットを指定して右クリックを押下し、Fllow > TCP Streamを開きます。
すると、以下のようなデータコネクションのFTPの送信データに遷移します。
f:id:kota-onji:20180510163027p:plain
 この中で、png画像のデータを抽出して保存するため、表示形式をRowに変更した上で下部のテキストボックスでpngと入力して()、絞り込みを行います。そして保存すると、f:id:kota-onji:20180510170607p:plain
このように、画像のダウンロードに成功しました!

3.おわりに

 2週間に渡って、普段の業務とは一味違ったパケット解析というものを行い、非常に楽しかったと同時に、
今週はGUI上で全てが完結したように、本当にあっさりと通信の中身を取ってこれることに怖さも感じました。
 お客様のデータを扱う会社として、今後もこのような社内勉強会を積極的に実施し、記事を掲載していきます。
 この度は、お読み頂きありがとうございました!

AWS Summit Tokyo 2018について改めてまとめてみた。

こんにちは。新卒2年目でインフラエンジニアをやっているtakasuです。

5月の終わり~6月の初めにかけて、開催されたAWS Summit Tokyo 2018が開催されました。
www.awssummit.tokyo

大阪開催については、6 月 18 日に発生しました大阪地震の関係で中止になったと聞きましたので、
改めてその内容についてまとめたいと思い、筆を取りました。
(被害にあわれた皆様へ心よりお見舞い申し上げます。)

さて、本題ですが、
インフラエンジニアである身としては行かねばなるまいということで、最終日の午後、滑り込みで参加してきました。

AWS Summitについて

そもそもAWS Summitとは何なのかというと、公式HPによると、
「AWS Summit はクラウドコンピューティングコミュニティーが一堂に会して、アマゾン ウェブ サービス(AWS)に関する情報交換、コラボレーション、学習を行うことができる日本最大級のクラウドコンピューティングカンファレンス」で「世界 23 ヵ国以上 33 か所以上の都市で開催」されているそうです...!!!

AWS Summit Tokyoは、品川のグランドプリンスホテル新高輪で行われたのですが、会場が大きく講演スペースと商談スペースとの2つの構成になっていました。
講演スペースでは、AWS社員・パートナー企業・AWS利用企業による講演があり、商談スペースではクラウドの導入や運用などをサポートする企業が商談ブースを出展していました。
特に講演では、クラウドの最大級カンファレンスだけあって、AWSを利用し成果を出すまでの苦労やクラウド活用の秘訣など様々なお話を聞くことができました。
ここからは、特に印象的だった講演の中身について触れていきたいと思います。

面白かった講演たち

ここからはAWSサミットで聞いてきた講演内容についてまとめてみたいと思います。自分が面白いなと思ったポイントに絞ってお伝えします。

株式会社gumiさん、インフラエンジニアがたった5人で運用を回すその秘訣

【講演題目】
【 gumi 様ご登壇事例】gumi が目指す「 Less DevOps, More Code」~運用を削減して, もっとコードを書こう!~
【講演企業】
株式会社gumi

題目にもある通り、インフラ構築・保守を題材として運用削減をメインテーマに掲げた内容でした。インフラエンジニアが5人しかいない状況の中で、多種多様なゲームのインフラ構築・保守を行うために取り組んできたことをお話していただきました。

よくインフラの構成管理において問題となるのは以下の二点かと思います。

  • 様々な調整やカスタマイズを行うことで、構成が管理されず不明な設定が存在する
  • 環境構築する際は、構成管理表をもとに手動インストールを行うため工数がかかる

これら問題に対してコード化を進めることで、冪等性の担保と自動化を同時に進めたという話でした。この話自体は、よく聞く話ではあると思います。(詳細はInfrastructure as codeについて調べてみてください。)
ただ、ここでポイントだったのは、コード化・自動化のためのツール選定などの手間を惜しまず積極的に行うことです。まずは実験を行うようにテストを行いながら、そして少しずつ適用していくことでツール導入のハードルを下げ実施していきます。このように自動化を進めることで時間が空き、その空いた時間を使ってさらに自動化を進めることで、日に日に業務が効率化されていくという夢のようなお話でした。

ここまで徹底的にコード化を推し進められたからこそ、高品質かつ大量のインフラを管理できているのだと感じました。

株式会社ウフルさん、高い開発力を実現するジャイロ型組織とは...

【講演題目】
ゼネコン型開発の破綻とジャイロ型組織AWSの革新によるプロジェクト開発組織の変革
【講演企業】
株式会社ウフル

技術要素の講演だけではなく、組織論的な講演もありました。題目からはイメージしづらいですが、プロジェクト開発組織とはどうあるべきかをメインテーマとした講演でした。

結論としては、開発組織はナレッジ蓄積の文化を持つことが必要であり、そのためにはプロジェクトではなく組織ドリブンとするべきという話でした。

メンバーは限られているので、優秀なメンバーをあるプロジェクトに固定してしまうと、それ以外のプロジェクトがうまくいかない可能性が出てしまいます。このように限られたメンバーで複数のプロジェクトを成功させるためには、ナレッジを蓄積させ活用していくことが必要です。しかし、プロジェクト単位で進めた場合、そのプロジェクト内ではナレッジが共有されますが、プロジェクトが終わってしまうと共有されなくなってしまい別のプロジェクトに活かすことができなかったそうです。そのためナレッジはプロジェクト単位で管理するのではなく、組織として管理を行いプロジェクトと分離するようにしたところ、ナレッジが蓄積されるようになり組織的に改善をしやすくなったというお話でした。

ちなみに題目の”ジャイロ型組織”というネーミングは、プロジェクト以外にナレッジなど、複数の軸を持つことで安定した組織になるという意を込めたネーミングだそうです。

アーキテクチャコンテストも開催!!

【講演題目】
【スタートアップ向け】Startup Architecture of the Year 2018ファイナルラウンド~アーキテクチャにフォーカスしたコンテストを初開催~
【講演企業】
AWS 他8社

スタートアップ企業が手がけるプロダクトのアーキテクチャの斬新さを競うコンテストです。AWSとしても新しい試みらしいですね。このコンテストにおける評価項目は、「セキュリティ」「信頼性」「パフォーマンス」「コスト効率」「運用上の優秀さ」の5つだそうです。

様々な特色が企業ごとにありましたが、どの企業にも共通して言えることは「運用をいかに楽にするか」というポイントだったかなと思います。環境差分によって苦しめられた経験をした身としては、非常に共感できる内容でした。その中でも株式会社MESON様の「リソース管理を徹底的に排除する」という思想が参考になったのですが、なんでも「一人でサービスのバックエンドを全て構築しきるために」とその思想になったそうです。フルマネージドとサーバーレスサービスをフル活用することで、リソース管理をAWS側に任せるというアーキテクチャにはそんな考え方もあったかと刺激になりました。

このようにサービスを支えている裏側のアーキテクチャを知る機会、しかも比較しながら知ることができる機会はそうないのではないでしょうか?
ただの感想に過ぎませんが、このコンテストの面白いところはこのようにサービスの裏側を知ることができることだったと思っています。あの機能やこの機能をどのような構成で実現しているのか、まだ新米なインフラエンジニアとしてはとてもいい勉強をさせてもらえました。

【閑話】
実はこのコンテストに弊社も参加しました。
弊社のCTO井戸端が発表し、なんとこのコンテストの最優秀賞である、Startup of the Year 2018を頂くことができました!!!!

商談スペースも見てきたよ

ついでに商談スペースも見てきました。企業がブースを出展していたのですが、そのうち多かったのは導入や運用の代行などを行う企業でした。

クラウドが広まってきたとはいえ、まだまだIT投資を行えているところは数少なく、オンプレからクラウドに移行するのも一苦労なのだという現状を垣間見ました。弊社では自社で直接AWSを利用しており、構築から運用まで自社で行っています。なので、運用面でもし何かアウトソースしたいことがあればこのような企業に相談してみるのがいいのかなと感じました。

ちなみに商談ブースを見て回ったときに色々なノベルティを頂きました。中には商店街に出てきそうなガラガラ(ちなみに正式名称は新井式回転抽選器と言うそうです)や、ipadを使ったくじ引きなどを用意しているノベルティに凝った企業もありました。参加者としては一種のお祭りのような気分なので、こういうものがあるとテンション上がりますよね。

おわりに

AWSサミットは初参加だったのですが、ネットだけではなかなか知ることのできない情報に触れることができ、非常に勉強になりました。仕事だけに打ち込んでいると視野が狭くなるので、こういった機会はすごい貴重だと思います。しかも、企業ブースのガラガラで3000円分のアマゾンカードまで当たったので財布にも優しいカンファレンスでした。
f:id:kota-onji:20180622142908p:plain

毎年開催しているようなので、ぜひ来年も参加してみたいと思います。

CTFのパケット解析から学ぶセキュリティとハッキング vol.1

 こんにちは!この春フロムスクラッチに入社した新人エンジニアのおんじです!

 今回のフロムスクラッチ開発ブログでは「CTFのバイナリ解析から学ぶセキュリティとハッキング」に続いて、パケット解析編の勉強会について書きたいと思います。
また、勉強会の内容自体が書籍の『セキュリティコンテストチャレンジブック CTFで学ぼう情報を守るための戦い方』を参考にしているので、より深く気になる方は手にとってみてはいかがでしょうか。
 ※CTFバイナリ解析編のバックナンバーは、こちらからどうぞ!

1.CTFとは?

 CTFとは情報技術に関する問題に対して適切な形で対処することで、「フラグ(Flag)」と呼ばれる得点対象の文字列を取得することによって、得られた得点で勝敗を決める大会です。”Capture The Flag”の頭文字をとってCTFといいます。国内ではSECCON CTFが有名です。(CTFについては、こちらの記事で詳しく触れています。)

2.ネットワークプロトコルとパケット

 パケット解析では、ネットワークを流れる通信を分析して、どのようなプロトコルでどのような要素を扱った通信を行っているのかを解明します。そのため、まずは前提のネットワークプロトコルの知識を確認していきます。

 ネットワークプロトコルとは、ネットワーク上での通信に関する規約を定めたものです。TCP/IPのモデルによると、これは以下のような階層構造になっています。

  f:id:kota-onji:20180507212545p:plain

これは、階層間の依存を無くし、プロトコルの開発やメンテナンスを容易に行えるようにすることを目的とした構造になっています。
 何らかのデータを送信する際には、上記のそれぞれの階層で、そのプロトコルに必要な情報を渡されたデータの先頭に付与し、次の階層に渡します。この付与した情報をヘッダと呼び、このヘッダを付与する動作をカプセル化と呼びます。
 逆に、データを受信した際には、それぞれの階層でこのヘッダを解釈し、削除した後に次の階層に渡していきます。
                                            
 今回扱うパケットは、一般的には、インターネット層のデータのことを指します。しかし、パケット解析を行う際には、ネットワークインターフェース層のヘッダとデータも解析します。この部分は一般的にはフレームと呼ばれますが、便宜上この記事では上図の太枠で囲われた部分をパケットとして扱っていきます。

3.pcapファイル

 ではパケットに関する前提を確認した所で、実際にパケットの解析に進んでいきたいと思います。ここではWiresharkと呼ばれるGUIのネットワークパケット・プロトコル解析ツールを使用していきます。
 ※OSはUbuntu 16.04.4 、Wiresharkのバージョンは2.2.6で実行しています。
 『セキュリティコンテストチャレンジブック CTFで学ぼう情報を守るための戦い方』によると、Wiresharkには、主に以下の3つの機能が実装されています。

 (1)ネットワークを流れるパケットをキャプチャ する
 (2)キャプチャしたパケットを表示する
 (3)表示したパケットを解析する

 まず、パケット解析をするために、パケット情報をキャプチャしていきます。Wiresharkを起動すると、以下のような画面が表示されます。
f:id:kota-onji:20180505205250p:plain

ここで、パケット情報を取得したい接続を選択します。すると、以下のようにパケット情報が記録されていきます。

f:id:kota-onji:20180505205257p:plain

あとは左上2番目の停止ボタンを押下し、ファイルを保存したらパケットのキャプチャは完了です(※sample1.pcapというファイル名で保存)。

 ここで保存されたパケットのキャプチャは、WinPcap(Linuxであればlibpcap)ファイルフォーマットというフォーマットで保存されます。このフォーマットはパケットを記録する基本的なフォーマットで、ネットワーク通信を記録するファイルとして、広く使用されています。以下に、そのサンプルを示します。

 f:id:kota-onji:20180508104119p:plain

 pcapファイルは、基本的に次の3段構造になっています。
 f:id:kota-onji:20180507212554p:plain
 Pcap file header(以下pcapheader)は、pcapファイルそのものの情報を格納する部分です。その最大の特徴は、ファイルの先頭の"D4 C3 B2 A1"という先頭の4バイトです。pcapファイルであれば必ずこのような4バイトから始まっており、pcapファイルを判別する部分になっています。また、pcapheadaerには他にも次のような情報が格納されています。
  ●pcapファイルフォーマットのバージョン情報
    - major version:2バイト "02 00"
    - minor version:2バイト "04 00"

  ●タイムゾーン情報
    - timezone:4バイト "00 00 00 00"

  ●タイムスタンプの精度
    - sigfigs:4バイト "00 00 00 00"

  ●キャプチャできるパケット長の最大長
    - snaplen:4バイト "ff ff 00 00"

  ●データリンク層のヘッダタイプ
    - linktype:4バイト "01 00 00 00
pcap headerをまとめると、以下のような構造になっています。
f:id:kota-onji:20180507212751p:plain

 Pcap packet header(以下packet header)は、各パケットに付与されるヘッダで、それぞれのパケットに関する情報が格納されています。具体的には以下の情報が格納されています。
  ●パケットキャプチャしたときのタイムスタンプ
    - 日付を表すUNIXタイムスタンプ:4バイト "72 bb ec 5a"
    - マイクロ秒を表すタイムスタンプ:4バイト "82 6a 04 00"

  ●パケットの長さ
    - caplen:4バイト "54 00 00 00"
    - len:4バイト "8c 16 45 04"

 基本的に、caplenとlenは同じ値ですが、pcap headerのsnaplenよりも大きいパケッ トがパケットキャプチャ中に流れてきた場合、ファイルに記録されるパケット長と実際 のパケット長は異なるので、caplenとlenは異なる値になる可能性があります。
 そしてこのpacket headerの後に、各パケットのpacket dataが格納されているという形式になっています。

4.Rubyを使ったパケット解析

 pcapファイルの構成がわかった所で、実際の解析に移っていきたいと思います。今回はRubyの拡張ライブラリであるruby-pcapを使用して、解析を行いました。
 ※Ruby 2.3.1 、ruby-pcap 0.7.9で実行

 まず、Rubyの環境下にruby-pcapをインストールします。

$ sudo apt-get install libpcap-dev
$ sudo gem install ruby-pcap

 次に、例としてIP パケットのsource addressを抽出してくるコードを作成します(先程キャプチャしたsample1.pcapを使用)。

require 'pcap'

packets = Pcap::Capture.open_offline('sample1.pcap')

packets.each do |packet|
  puts packet.ip_src if packet.ip? == true
end

 これを実行すると、以下のように接続していたIPアドレスが羅列されていきます。

172.217.25.232
10.0.2.15
183.79.250.123
104.244.43.112
10.0.2.15
10.0.2.15
104.244.43.112
104.244.43.112
10.0.2.15
104.244.43.112
...
※以下略

このままだと、無秩序に並んでいるだけなので、タイムスタンプも一緒に出力してIPアドレスごとにソートをかけて出力してみます。

require 'pcap'

array = Array.new

packets = Pcap::Capture.open_offline('sample1.pcap')

packets.each do |packet|
  ip = packet.ip_src if packetl.ip? == true
  time = packet.time

  array.push([ip.to_s,time.to_s,''])

end

sorted = array.sort 
puts sorted

すると、以下のように出力されるようになりました。

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900
...
※以下略

実際の解析ではこのように問題となっている接続を特定していきます。
この続きの解析については、次週記事にしたいと思います。

5.おわりに

 今回は、パケット解析の前提知識と、基本部分についてお話しました。次回は、実際のCTFの問題などを解いていき、より深い部分に踏み込んで行きたいと思います。次回も興味深い内容になる予定ですので、是非読んでみてください。