SECCON 2016 online "PNG over Telegraph"

SECCON 2016 online CTFに参加された皆様、お疲れさまでした。
今回は初めて問題を作る側に参加させてもらい、たくさんの高評価を頂いてとても嬉しいです！

https://www.youtube.com/watch?v=Y6voaURtKlM

さて、このSECCON TOWERこと腕木通信の塔について、少しだけ解説をしようと思います。
(解き方については、解けたチームがWrite Upなどを公開してくれる...と思いますので)

腕木通信(Semaphore Line)は、18世紀末から19世紀にかけてフランスで考案されて使われた、世界で最初の大規模通信網です。 考案したのはクロード・シャップというフランス人で、フランスに存在する腕木通信の塔のことを「シャップの塔」と呼ぶこともあるようです。
そもそも「セマフォ(Semaphore)」や「テレグラフ(Telegraph)」という用語は、このシャップさんが考案しました。
この辺りの詳しい話は、各言語版Wikipedia(日本語, 英語, フランス語)あたりを参照してください。

https://ja.wikipedia.org/wiki/%E8%85%95%E6%9C%A8%E9%80%9A%E4%BF%A1
https://en.wikipedia.org/wiki/Semaphore_line
https://fr.wikipedia.org/wiki/S%C3%A9maphore_(communication)

この腕木通信を再現したのが、今回のSECCON TOWERです。

素材は割り箸と秋月電子で800円で売っているサーボモーター3個、制御はArduinoで行なっています。

背景には、私が撮影した桜島の写真をネットプリントでA3サイズに印刷して使っています。
DSC_4693 | 鹿児島大学教育学部より桜島を望む | Kei Yoshimura | Flickr

ちなみに土台の部分にはセ○ンカフェの紙コップを使用し、塔の質感を演出しています。

Arduinoのコードはこちら
9SQ/SECCON_TOWER: Semaphore tower (Chappe tower) made by Arduino

Serialで待ち受けるArduinoに対して、1文字ずつ文字を送ることで動作します。
送られた文字に対応する腕木の形は、基本的に フランス語版 Wikipediaに記載されているChappe Code表を基準にしています。

https://fr.wikipedia.org/wiki/S%C3%A9maphore_(communication)#/media/File:Chappe.svg

しかし、このコード表には J が存在しません。使われている腕木のパターンは 36通りしかないため、使用頻度の低い J は文献によっては I で代替されていたりしました。
とはいえ J と I が混同されると何かと不便なので、今回の SECCON TOWER では & を J として扱っています。
このことは、問題動画の冒頭で紙に書き写している文章の一部から、補完可能です。

WELCOME TO SECCON CTF.
WE HOPE YOU WILL ENJOY THE GAME.
GOOD LUCK.

これに、flagの入っている PNG 画像をBASE32エンコードして流しました。

なぜ、BASE32なのか... 前述の通り Chappe Code では、36通りの組み合わせが使われています。素直に考えると BASE36 という選択肢もあります。
しかし今回は様々な理由で BASE32 を使った方が都合が良いことが多かったので、そうしています。
(特に、冒頭の8文字をデコードするだけで PNG のシグネチャを得られるのが最重要でした)
参考: RFC 4648 - The Base16, Base32, and Base64 Data Encodings


というわけで、作問者側が想定していた正攻法な解き方としては...

1. 腕木通信であることを認識し、Semaphore、Chappe towerなどのワードからChappe Code表にたどり着く
2. 50分の動画から、対応表を元に文字に戻す。(この手段は問わない)
3. BASE32デコードする
4. PNGファイルが出てくるので、開く
5. flagをget

そう。この腕木から文字を復元する作業について、手段は全く問わないのです。
画像処理が得意な人は画像処理で解くもよし、機械学習で解くもよし、人力で解くもよし。

この点について、発案者のきくちゃん先生からの熱いメッセージがあります。

時間内に効率よく文字に戻すにはどうしたらよいか、という命題に対し、各々が持てるリソースをどのように配分して投入するか。手段は問わない。
それこそが CTF における問題解決能力の腕の見せ所だと思います。
もし何らかのプログラム的な手法で解くことだけを狙うなら、動画の長さは50分程度ではなく5時間くらいにしちゃいます。
むしろ画像処理や機械学習を使わないと解けない、と思いこませることこそがミスリードでした。
人力で読むにしても、ある程度コンピュータに手助けしてもらったり、様々な工夫や手法があると思います。

私が解くとしたら... 動画から各形のフレームを取り出して、同じ形状をしているものは同じ文字として... やはり人力でやると思います。
プログラムで解くと思わせて、実は人力が最短？(かもしれない)問題なのです。

ちなみに... こんな裏話もあったり。

直前まで「PNG over Telegraph」ではなく「Semaphore」という問題名だったけど、これだとすぐに腕木通信と分かってしまい、対応表を見つけて簡単に解けるのでは？ということでTelegraphに変更されたという経緯があります

— けーいち (@9SQ) 2016年12月11日

三脚が無かったのでiPhoneをビニールテープで工具箱に貼り付けて撮影してたら、テープが緩んで少しずつ上に向いちゃったという経緯がありまして、決してわざと動くように撮ったのではありません（てへっ

— けーいち (@9SQ) 2016年12月11日

それから、今年はQRコードがなかった！！というあなた...

SECCON から QR が消えたとお嘆きのあなた。ちゃんと塔の中に隠してありますよ！

— きくちゃん (@kikuchan98) 2016年12月11日

今年のSECCONはQRコードが無かったなどと言われてますが「PNG over Telegraph」でQRコードのPNG画像を伝送しているので...😎 #SECCON

— けーいち (@9SQ) 2016年12月11日

flag の PNG画像 は QRコードなので、半分ぐらい入力すれば、それっぽい画像が得られます。
読み取りに失敗してQRコードが壊れてた？ QRコードの復元は、みなさんお手の物、ですよね！

解けた方は、ぜひWrite upを書いてくださいね！


追記：この問題について記述されているWrite upを貼っていきます。

SECCON 2016 Online CTF に参加しました (Write-up) | monolog
http://blog.monora.me/2016/12/seccon-2016-online-ctf-write-up/

SECCON 2016 予選 - /home/cympfh/
http://cympfh.hatenablog.jp/entry/2016/12/11/215023

PNG over Teregraph - TomoriNao SECCON 2016 Online
https://hackmd.io/s/SJVWBNtXx

SECCON TOWER 参加記のようなもの - Unpronounceable Name
http://tatarhy.hatenablog.jp/entry/2016/12/16/014821

SECCON 2016 Online CTF Write up PNG over Telegraph - Qiita
http://qiita.com/Liesegang/items/f6ac10b18064906a3808

ESP8266のSSL clientについて

ESP-WROOM-02でhttpsなAPIを叩こうとしたらハマったので、まとめておきます。

SDKは1.3.0 (Release date: Aug 08, 2015)を使用しています。
ドキュメントも、これ(esp_iot_sdk_v1.3.0_15_08_08.zip)に含まれている2C-ESP8266__SDK__Programming Guide__EN_v1.3.0.pdfを参照しました。

現状

8/28現在、Arduino core for ESP8266はSSL(TLS)でのclientに対応していない。
対応して欲しいという要望＆対応したいねという話は出ている。

ESP8266のSDKとしては、SSLに対応している。
※ただし、制約あり(この下に書きます)

処理の流れ

公式によるサンプルコードがEspressifのフォーラムにあるので、それを見るとだいたい分かります。

以下も非常に参考になります。
DSAS開発者の部屋:ESP8266 モジュールの AT コマンドに SSL クライアント機能を追加する
ESP-WROOM-02で、IFTTTをhttps(SSL/TLS)で呼び出す例 - Qiita

大雑把な流れとしては...

//証明書ストアを用意
unsigned char *default_certificate;
unsigned int default_certificate_len = 0;
unsigned char *default_private_key;
unsigned int default_private_key_len = 0;

//espconn, _esp_tcpを定義

LOCAL struct espconn user_tcp_conn;
LOCAL struct _esp_tcp user_tcp;

//接続先のIPアドレスとポートを設定
user_tcp.remote_ip[0] = 192;
user_tcp.remote_ip[1] = 168;
user_tcp.remote_ip[2] = 1;
user_tcp.remote_ip[3] = 128;
user_tcp.remote_port = 443;

//自分のポートを設定
user_tcp.local_port = espconn_port();

//type, state等を設定
user_tcp_conn.proto.tcp = &user_tcp;
user_tcp_conn.type = ESPCONN_TCP;
user_tcp_conn.state = ESPCONN_NONE;

//接続時、再接続時、接続断時のコールバックを設定
espconn_regist_connectcb(&user_tcp_conn, user_tcp_connect_cb);
espconn_regist_reconcb(&user_tcp_conn, user_tcp_recon_cb);
espconn_regist_disconcb(&user_tcp_conn, user_tcp_discon_cb);

//SSLバッファサイズを設定
espconn_secure_set_size(ESPCONN_CLIENT,5120);

//接続する
espconn_secure_connect(&user_tcp_conn);

みたいな感じ？

user_tcp_connect_cb()関数の中でデータ送受信時のコールバックを設定してあげれば良いみたい。

void user_tcp_connect_cb() {
    espconn_regist_recvcb(pespconn, user_tcp_recv_cb);
    espconn_regist_sentcb(pespconn, user_tcp_sent_cb);
}

サーバからの応答は
void user_tcp_recv_cb(void *arg, char *pusrdata, unsigned short length)
のpusrdataに入ってくるので、これを出力するなり判定するなりすると良い。

SSLバッファサイズはデフォルト(espconn_secure_set_sizeを呼ばない場合)で2048バイトになっているので、SSLパケットが2048バイトを超えそうな時は適宜増やしてね、ということらしい。
最大8192バイトらしいけど、8192を設定したらメモリに乗り切れないっぽくて(確保できない？)、espconn_secure_connectの段階でこけました。
公式サンプルコードにあるように5120くらいが限界かな...？

使用できるプロトコル(バージョン)と暗号

たぶん、ここが一番重要で、メモリ周りとかは全然大丈夫だけどespconn_secure_connectした直後にuser_tcp_discon_cbが呼ばれる(接続断される)ような、とあるサービスのAPIサーバがあって、Wiresharkでパケットキャプチャしたら原因が分かりました。

こちらがESP8266からサーバに送信されたClient Hello。

バージョンはTLS 1.1で、Cipher Suitesは以下の4種。

• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_RC4_128_MD5

TLS 1.1を拒否ってたり、上記暗号種での接続を拒否ってると

「お前の指定したバージョン、暗号種ではうちに繋げねーぞ」とHandshake Failureが返ってきてServer Helloしてくれない訳です。

HeartbleedとかPOODLEとか色々あった関係で、厳しめなところは繋がらないという感じかなぁ。

このマイコンの性能上、強度の高い暗号アルゴリズムは載せられないのでしょうが、IoT向けを前面に押し出してるからには、もうちょっと頑張ってほしい...

追記：その後、Arduino core for ESP8266でWiFiClientSecureが追加され、httpsが叩けるようになりました。

セキュリティさくら#05

8月25日開催の熊本情報セキュリティ勉強会「セキュリティさくら」#05について、参加記録と今後の為のメモ。

今回で参加5回目、皆勤賞更新中。

今回の装備は、MacBook Pro Retina、iPad3、iPhone4S、HTC EVO 3Dという感じ。
残念ながらネタ不足＆準備検証の為に時間が割けないため、LTはしませんでした。

本会
・場所は前回と同じく、桜の馬場 城彩苑 2F 多目的交流室
→やはり、この会場のアクセス・利用料・許容人数が一番安定だと思われる。

・辻さん「WHAT IS ANONYMOUS」
→Nanorymousの辻さんによるAnonymousについての講演。
→今までのオペレーションやAnonymousという団体の変遷などを解説されました。

・新井さん「俺ってそんなにシェルコードばっかり見てるイメージある？それどこ情報？どこ情報よー？」
→前回もマルウェアについて講演された新井さんによるシェルコードの読み方(≒目grep)
→PDFに仕組まれているコードの解析をDEMOを交えて解説されました。
→IDA Pro、FileInsight、scSigsなどなど。

・前田さん「Stuxnet, Duqu, Flame, Gauss What is next?」(LT#01)
→第3回でも講演して頂いたカスペルスキーのチーフセキュリティエヴァンゲリストの前田さんによるマルウェアのお話。
→頭文字が「SDFG」と来たので次は「H」で確定(キー配列)
→Stuxnet以外は諜報活動が目的のように見える、初期感染・拡散手法が巧妙である。

・吉井さん「スマートフォン・プライバシー・イニシアティブ 〜読むのが面倒な人へ」(LT#02)
→総務省が8月7日に発表した提言についての概要。
→アプリやサービスが収集した情報の扱い方など、個人情報保護法と照らし合わせたお話。

・@parin1213 & @reiji1020「長崎のすゝめ」(LT#03)
→長崎県内でのイベント・勉強会などについてのアピール。

・Sn0wくん「セキュリティキャンプ2012中央大会に参加してきて」(LT#04)
→今年から「プログラミング」が消えて「セキュリティキャンプ」になったにセキュキャンついてのお話。

懇親会
・上通を抜けて並木坂のローソンから右に曲がった先にあるGRILL de GYANというお店(セキュさくら御用達)
→今回は、前回の反省点を踏まえて主菜を多くしてもらったとのことで、10代も満足できたのではないかと思います。
→二次会で大木さんが「幻の焼酎、結局1滴も残って無くて飲めなかった」とか言っておりましたが、大木さん、あなた車で来てるでしょ！！

総評
前回も書いたとおり、この位の規模の勉強会の中では理想形と言えると思います。
約1年前の初回から参加しておりますが、徐々に進化していく様子を見ることができ、とても勉強になっています。
気になる点は、セキュリティに興味が無い人たち(完全に人脈作りの為だけに来ていると思える人)の興味ゼロの態度。
セキュリティさくらは「IT系の人が集まって交流すること」自体が主目的では無いはず。
交流会をやりたい人は、別途、自分の目的を達成出来るイベントに行って欲しいと思う。
日々の激務で疲労がたまっているだろう人たちの居眠りは理解できるが、明らかに興味がないことを示す居眠りというのは失礼である。
1周年を迎え、勉強会の趣旨というものを、もう一度見直す時期に来ているのかもしれません。

告知
ハードウェア(低レイヤ・低レベル)勉強会を9月中にやりたい...やります。 →12月開催で調整中です。
とりあえず、少人数(20以下)で良いので「こういう勉強会やりました！」という実績作りから一歩を踏み出すことが必要かと。
進行状況は、KPF#x07で報告したことから全く進んでおりません。
原因は、あれもこれもそれも...という欲張りがもたらす八方塞がりでしょう。
まずは大成功でなくても良いので、興味のある人が一カ所に集まる勉強会を作ることを目指そうと思います。

セキュリティさくら#04

6月23日開催の熊本情報セキュリティ勉強会「セキュリティさくら」#04について、参加記録と今後の為のメモ。

本会
・場所は桜の馬場 城彩苑 2F 多目的交流室
→交通センターもしくは市電熊本城前電停から少し歩く必要があるが、県外参加者には熊本城が見えるところを歩いてもらえるので良いと思う。

・相戸さん「やってみよう緊急対策訓練」
→さくら開催史上初の彼女同伴講演。
→企業の情報セキュリティの裏側、実際に発生したとき動けるのか？という点、実話を軸にしたお話、凄く良かったです。聞いて良かった。

・新井さん「来ちゃった…リア充の王を追いかけてクマモンの国まで…(仮)」
→マルウェア解析界の聖書「アナライジング・マルウェア」の著者によるお話。
→各種マルウェア検体サイトの紹介は役立ちそう(contagio、KernelMode.info、OpenMalware.org)

・高倉先生「新しい攻撃手法について（追）」
→前回(#03)から4ヶ月、更に高度な標的型攻撃の現状と対策手法についてのお話。
→「入口も出口も内部も固める」「ルータ、スイッチの設定まで監視」というお話は非常に興味深かったです。

・まっちゃさん「IT勉強会カレンダーについて」
→自動かと思いきや全手動で運営中のIT勉強会カレンダーについての説明のお話。
→閲覧しやすいアプリの紹介や、カレンダーに登録する際の裏話など色々。運営お疲れ様です。

・松村君「セキュリティキャンプの紹介」
→つけ麺おんのじの紹介

・自分「ハードウェアセキュリティ（真）」
→今回は真面目すぎて面白くなかったです。反省中。
→プレゼン資料は以下です。


懇親会
・上通を抜けて並木坂のローソンから右に曲がった先にあるGRILL de GYANというお店(前回と同じ)
→今回、60人近い人数にもかかわらず2Fに全員収容出来たのは凄い。
→持ち込みも可能だったので、色々と美味しく頂きました。

総評
勉強会として洗練されてきたイメージ。
ただ、気軽に参加出来る感とのトレードオフであるかもしれないと感じてしまう面もありました。
他県からの参加者にも非常に好評でした。
隣県の勉強会が「利益の出し方」を中心としているなら、さくらは「探求心」を中心としているので良いという意見も。

セキュリティさくら#03

LTちゅう。

いつも通り、参加記録と今後の為のメモ。
※内容的なまとめに関しては公式を参照

本会
・新しく熊本駅前に出来た森都心ビル、6Fの会議室を使用
→前回と違い勉強会らしさが出ていたのでGood。室内の設備、照明の明るさ共に丁度良し。

・名古屋大学の高倉教授によるAPTについてのプレゼン
→実例を交えた分かりやすい内容、非常に時事的でとても興味深かった。
→久々の「聞いて良かったと思えるプレゼン」だったかも。

・カスペルスキーのチーフセキュリティエヴァンゲリスト、前田氏のプレゼン
→Androidのセキュリティ問題について、いくつかの実例を挙げて紹介。
→アンチウイルスをバンドルする方法が最良だが、コスト的に... その辺のもどかしさは良く伝わった。

・LT#1 マルウェア解析を妨害するもの(金丸さん)
→マルウェアが解析されることをマルウェアがどう認識するかという非常に面白い視点。
→最初にして最後のLTとのことでお疲れ様でした。奈良での活躍に期待しています！

・LT#2 地域からのセキュリティUP(七條さん)
→普段、情報セキュリティなどのトラブル相談を受けているだけあって、リアルさが良く伝わっていた。

・LT#3 ハードウェアセキュリティ(仮題) (私)
→久々のLTにしてタイトル偽装LT(という名の徹夜仕上げLT)
→あまりにもオフレコネタ過ぎてtwitterに空白の時間が生まれていたのは後から気づいたお話。
→あと、MacBook Airが予想外のフリーズ。やっぱりプレゼン時はMBPを予備で準備した方が良いことに気づく。

懇親会
・上通から少し外れたところにあるイタリア料理のお店
→2階が割と自由に使えた(プロジェクター使ったりできた)ので、こういった用途には合ってるかも。

その他
・やっぱり会場はアクセスしやすくて、すぐにココだ！と分かるところが一番良い。
→そういう意味では森都心は熊本駅前という抜群の立地条件だと思う。

・次回、時期によっては参加できないかも...

セキュリティさくら#02

参加したという記録と今後の為のメモ。
※内容的なまとめに関しては公式を参照

本会
・非常に人数が多い印象。
→部屋が狭くて縦長だったので休憩時間も他の参加者と交流できなかった。

・発表・LT内容はいかにもセキュリティーな話題という感じで聞き応えあり。
→愛甲さんのDEFCONの話が面白かった。LTは行動認識とネットワークの話がgood。

懇親会
・本会の場所(BAR Party Place)から10分くらい歩いたところ。
→ノーコメント。

・後日、松村がキレてた。
→「第3回はいかない」だそうで。

その他
・#03でLTやる予定
→ソフトウェア系ネタは突っ込みが怖いのでハードウェア系で。

・HTC EVO WiMAX大活躍
→やっぱり俺々WiFiルーターは必須。