SECON2013 全国大会 結果と課題のメモ
korin
見当つかず・・・WriteUp待ち
課題：WriteUp待ち
2.kaku
シェルコードを実行できる箱庭環境。
ステージ0 制限なし。 クリア
ステージ1 isalnumを通過することが条件。 死亡
ステージ2 不明
ステージ3 不明（フォルダ構造探った限りここがラスト）
フラグ：シェルコードで設置できないか試すが権限的に無理そうだった。
きっと別の脆弱性があるはず。あるいは権限昇格？
課題：つぶしの効くアセンブリング力
hanoi
1つ目のキーワード入手。
2つ目で詰む。
DNSの問い合わせクエリが画像に隠蔽されていたが、そこから着想を得られなかった。
実際はターゲットサーバーが３つあったらしい。
→ 192.168.1.1と1.3があった時点で、2もあると想像すべき？？
課題：総合的な分析力？
バベル
format String脆弱性があることまでは気づいたが、突破できず。
やった人たちの話
/tmpにbusyboxを投下して呼び出し
さらにsetuid。
自分が置いたらパーミッション変えて封鎖
ドルアーガ
組み込み系のROMを展開
ン万枚の画像を文字認識→アセンブラとして実行→結果を評価 っていうのを早々にする必要があった。
ピサ
XSS脆弱性
他チームの妨害が死ぬほどってか死んだ
CPAPCHAを解析する必要があったらしい？？
課題：HTML、Javascript
アセンブラかるた
チャレンジせず。
課題：目Grep力。バイナリアン
宿題
・unicode-proof (a-z,A-Z,0-9のみ）でshellcode書く
・formatStrings脆弱性を叩ける解析力
・armの実行環境
・任意のビット列を任意のポートから任意の宛先に送れるツール
・具体的な攻撃、防御手段をテンプレ化する
個人的、セキュコンの意義
うまくまとめられない気がするけど、今のうちに書いておきたい。
主にスタッフとスポンサーの方に伝えたいこと。
あと、俺個人の思いと決意。
まず、結論から言うと、我々のチームは最下位でした。
正直、手も足も出ませんでした。
でも、自信を持って言えるのは SECCON全国大会に出場できてよかったということです。
正直に言うと、最近の俺は現状に甘んじて、鍛錬を怠り始めた、ありがちな中だるみエンジニアでした。
会社ではそこそこなんとか仕事をこなせて、とりあえずスキルレベルも下の方ではない（と思っている）。
日常生活レベルでは、そこまで必死で勉強したりしなくても、なんとかなってしまう。
SECCONに出ていなかったら、きっとそれで向上心を失って、数年後に後悔していたパターンだったと思います。
でも今回、「俺、それなりにできる方じゃね？」という過信を粉々に打ち砕かれ、危機感を得られました。
これから行動しなかったら同じなんだけど、とりあえずきっかけを得られたことは、
俺の人生においてすごく大きな収穫だったんじゃないかという気がしています。
出来る人達（＝上位チームの人達）にとってのSECCONの意義は正直わからない。
楽勝だったのか、勉強になったのか、あるいは俺に想像もつかないような意義を見出しているのか。
ただ、できなかったチームなりに感じたこととして、自信を持って断言できることがあります。
「昔燃えていたのに、いま現状に甘んじてくすぶっている、アラサーエンジニア。
そういう連中を再び燃え上がらせるためには、SECCONはすごくいい。」
実際俺は社会人になってから一番燃えたし、悔しくてこれから取り戻そうと思った。
あと、後輩に同じような轍を踏ませないように、育て方教え方を考えなおすことにした。
今具体的にはうまくまとめられないけれど、必ずやる。
実はこれって、SECCONの意義、日本のICT技術力の向上って意味ではすごく意味あることな気がしました。
すごく失礼な言い方だけれど、今は飛ぶ鳥を落とす勢いで成長している上位チームの学生さんたち、
社会人になって、いろいろあってからも、今のモチベーションを維持できるのだろうか。
（もちろん、俺とはレベルが違うから、できるのかもしれない。でも、俺みたくくすぶってしまう奴もいると思う）
もし、そういう連中すべてを再び燃え上がらせたら、（あるいは、燃え上がらせ続けられたら）
今よりもっとすごい世界が拓けるんじゃないだろうか。
それなりの素地があって、その素地を活かして後輩をそれなりに指導して育成している、中堅なりかけエンジニア層。
ここがレベルアップしたら、育て方もレベルアップして、後輩もレベルアップする。
それってすごい世界だと思います。
・・・
もう一つ別の角度で話す。
今思い返すと、自分は学生時代も中途半端だった。
でもその理由の一つとして、トップレベルを見られなかったことがあると思う。
すごく言い訳の責任転嫁ですが、 私は、ぎりぎりセキュリティ・キャンプに参加できなかった世代です。
だからってアンテナ立てれば情報はいくらでも入ってくるし、実際そうやってのし上がった同世代もちゃんといると思う。
だからこれは言い訳でしか無いんだけれど、そういう、アンテナを立てきれなかった奴らに燃料を投下できたら、
きっと、投下しないよりもいい結果が生まれると思う。
何がきっかけで変わるかはわからない。なら、きっかけは多いほうがいい。
そのきっかけの一つは、「こいつらやべえ。でも追い付きたい」と思える目標を見せることだと思う。
SECCONに出るような連中にとっては、上位チームこそ、その目標になり得る。
でも、俺が学生時代の頃は、SECCONはなかった（あるいは、俺の耳に届かなかった）し、目標も見つけられなかった。
たらればでしか無いけど、昨日今日の経験を20歳でしていたら・・・という思いは（不毛だし無意味だけど）少なからずある。
将来性のあるエンジニアの卵達が、ちゃんと孵化するためのプロセス、目標を見つけられる、そんな環境づくりとしても、
SECCONは有意義だと思った。
１ミリもWriteUPになってないけれど、今じゃないと書けなそうな思いがあったので、
残しておくことにしました。
スポンサー、スタッフ、後援の皆さんにぜひとも伝えたい思いです。
長くなって、うまくまとまってない気がするので、最後に一番言いたいことだけ。
「SECCON すごくいいっす。 俺たちエンジニア一丸となって、来年と言わず、来世紀まで続くイベントにしましょう。」
まずはスタッフか、参加者か、参加者集める側か、どんな形かわからないけど、できることから協力します。
そして将来、攻殻機動隊みたく、電脳ハックが現実化する時代になったら、俺、喜んで課題人間（？）に志願します。
んで、俺に侵入できなくて凹んでる最下位チームに向かって、「いいぞ。その悔しさをバネに来年帰って来い」なんてエールを贈る老後を過ごしたいです。
すげー妄想ですけど、30近くにもなった男を、ここまで熱くしてくれた。
そんだけ、SECCONには力があったってことです。
最後になりましたが、 ここまですごい経験をくださった大会関係者の皆様。
ありがとうございました。
あと、直接も言いたいけど、きっと色々思うことあっただろうに、
笑顔で俺たち4人を送り出してくれた5人目のチームメイト。
ほんとありがとう。
明日朝起きて忘れてしまうこともありそうなので、以上 自分への覚書。
SEC CON2013 オンライン予選 Write-up
忘れないうちにメモー。
自分が担当したところだけ。
network 100 Repeat After Me （未完）
問題文はただのpcapファイル。
中身を見ると、telnetのキャプチャログだとわかるので、何をしているのか調べる。
echoが煩いので、 telnet && tcp.dstport==23 でフィルタ。
中を見ると
- nslookup
- ssh
- ログイン処理
- （ログイン後）ls
を行っているのがわかる。
あとはキーストロークを読み取って同じことを実行すればOK。
楽勝！
・・・とおもいきや、コントロールシーケンス（バックスペースとか、Ctrl-Uとか）の扱いで手こずり、回答できずじまい。
どうも、Ctrl-Wの挙動を勘違いしているようなのだが、まだよくわからず。
network 200 Find the Key
icmp echo/reply のデータ部分にHTTPのメッセージが乗っているので、こいつを切りだす。
最初は プログラム書いてやろうとしたのだが、実質数パケットだったので、デバッグする手間を考えて手作業で実施。
つまり目Grep、手コピペ
ICMPのヘッダまでは問題なく排除。
HTTPのBODY部からファイルを切り出す手段については、以下の2アプローチ。
ファイル全体が落ちてきている場合
2OO OK でレスポンスが来ているので、Content-Lengthを参考に、
それ以降のパケット（MTUの関係で分割されているっぽい）を切りだす。
また content-type が png だったので、マジックバイトとIENDフィールドがあることも合わせて確認した。
ファイルの一部が落ちてきている場合
Get時にbytesオプショを使い、ファイルの途中からDLしているリクエストもあった。
こいつらは、206 Partial Content で落ちてきている。
まずは同様に、 Content-length、IEND を参考に切り出し。
切り出したら、 Content-range を参考にして、前者のファイルに結合（というか開始ビット以降を上書き）する。
ちなみに全体としては、200OK 2つ、 206 3つがやりとりされていたが、
200OK 1つと、206 1つ扱えればKEYは手に入った。
HTTPヘッダとBODYの境目を見極めるのにちょっと苦労した。
network 300 Hidden Message
pngファイル（やるお）が問題。
Hexdumpで中を見ると、末尾にDNSの逆引きクエリが見える。
また、JPGの終端バイトを探すと、その直後にPCAPファイルのヘッダがある。
この2点から、 バイナリエディタで切り出して、Wiresharkへ。
DNSのクエリを投げていたので、 当該のIPアドレスに当該のクエリを投げたらキーが帰ってきた。
この問題が一番楽だったｗｗｗ
network 400 SECCON競馬 （未完）
WEBSOCKETでリアルタイム更新される競馬ページ。
レースの結果を予想して答えるのが問題。
きっと何かの脆弱性とかで結果を不正取得できるのだろう、と想像。
Wiresharkでキャプチャしながら操作したり、javascriptを直接実行したりして、
更新時に実施されるコマンドとレスポンスを調査、列挙。
（ここは主にチームメイトの先輩に助けてもらいました）
その後、パラメータを変えて試行錯誤。
KIAIで2時間ぐらいぐらいやったところ、 get_result という、競馬の結果を手に入れるコマンドがSQLエラーを返してくることを発見。
コマンドの性質的にもこいつが狙い所だろうと判断して的を絞る。
・・・が、エスケープ処理が強固で結局突破できず。。
あとは細々HELPに入ったりしたが、メインはNETWORK問題のみ。
チーム全体の成績は 3300点（12位タイ）
6人チームで、独力で500点、協力して800点。まあ、役にはたったかな？
所感
NETWORK以外の知識がなさすぎるのが反省点。
できる問題終えたあと（手詰まり含む）は、ほとんど役立たずだった。
せめてもうひとつぐらい得意分野を作っておくことにする。
でも久々に徹夜でPC打ち込んで楽しかった。
Inspiron 700m に Kali Linuxをインストール
備忘録。
とりあえずインストールして起動するまでは問題なし。
起動後、無線LANカードを認識しない。
Inspiron 700mの無線LANカードは Intel PRO/Wireless 2100
dmesgを見ると
[ 10.604219] ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, git-1.2.2
[ 10.604220] ipw2100: Copyright(c) 2003-2006 Intel Corporation
[ 10.605179] ipw2100: Detected Intel PRO/Wireless 2100 Network Connection
[ 10.621238] ipw2100 0000:02:01.0: firmware: failed to load ipw2100-1.3.fw (-2)
[ 10.927717] ipw2100: eth%d: ipw2100_get_firmware failed: -2
[ 10.927718] ipw2100: eth%d: Failed to power on the adapter.
[ 10.927719] ipw2100: eth%d: Failed to start the firmware.
どうもファームウェア周りの問題の模様。
で、
debian ipw2100 firmware
とかでググルト
https://wiki.debian.org/ipw2200
こんなサイトにヒット。
ここを読んで以下の作業を実施
apt-get install firmware-ipw2x00
modprobe -r ipw2100; modprobe ipw2100
これで 無線LANカードを eth1 として認識した。
dmesg
[ 1836.482282] ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, git-1.2.2
[ 1836.482288] ipw2100: Copyright(c) 2003-2006 Intel Corporation
[ 1836.483041] ipw2100: Detected Intel PRO/Wireless 2100 Network Connection
[ 1836.483389] ipw2100 0000:02:01.0: firmware: direct-loading firmware ipw2100-1.3.fw
■
[PC]すげー久しぶり
別に日記ではないToDo
- scapy
- netcat
クライアントとサーバ
ずいぶん偉そうな言い方だが、違う人達に３回ほど同じことを指摘したので４回目以降のためにまとめることにした。
俺にこのURLはられた人へ
よくあるミスだから、気にしないでおｋ。
たくさんの人が間違えることだからブログに書いたのです。
でも大事なことだからちゃんと覚えてね。
本文
ソフトウェア設計で気を付けないといけないことの一つ。
「クライアントはリクエストなしにサーバからパケットを受けることはできない」
これは大原則。気をつけることというか、「してはいけないこと」かな。
一応言葉の定義をしておくと
- サーバ：常駐し、リクエストを受信して応答を返送するプロセス
- クライアント：リクエストを送信し応答を受信するプロセス
NW的な言い回しに言い換えると、パケットをlistenするのがサーバ。
そのlistenしている相手にパケットを送るのがクライアント。
クライアントのプロセスは常駐しないし、ポートの監視も行っていないので、いつ来るかわからないパケットを待つことはできない。（リクエストを送ったときのみ、応答を受信するまでポートの監視を行う）
一方でサーバは常駐し随時ポートを監視しているので、突然リクエストが来ても応答を返送できる
言い換えると、リクエストなしにパケットを送りたいのなら、受信側にもサーバとなるプロセスが必要。
それ（受信側へのサーバプロセス配置）を意図していないなら、シーケンス図が間違っていることになる。
具体例 その１
Webアプリケーションのシーケンス図の一部。
つまりクライアント＝Webブラウザ、サーバ＝Webサーバ。
（リダイレクトやjavascriptによる自動更新で）ユーザの操作なしに画面遷移する場合です。
クライアントは操作せず、サーバ側から更新後の画面がでるので
|クライアント| |サーバ| ｜ ｜ ｜ 自動更新された画面 ｜ ｜<-----------------------------｜ ｜ ｜
と書きたくなるけれど、これは間違い。
Webブラウザは、サーバプロセスではないのでWebサーバから突然パケットを受けることはできない。
（必ず、対応するリクエストが存在する）
つまりは、裏側で（ユーザに見えないだけで）リクエストを送っているので
|クライアント| |サーバ| ｜ ｜ ｜ 画面の自動更新要求 ｜ ｜----------------------------->｜ ｜ ｜ ｜ 自動更新された画面 ｜ ｜<- - - - - - - - - - - - - - -｜ ｜ ｜
と、するべき。
具体例 その２
おなじく、Webアプリケーションのシーケンス図の一部。
認証機能で、パスワードを要求する場合。
サーバ側からパスワード要求が行われるので
|クライアント| |サーバ| ｜ ｜ ｜ パスワード入力画面 ｜ ｜<-----------------------------｜ ｜ ｜ ｜ パスワード ｜ ｜- - - - - - - - - - - - - - ->｜ ｜ ｜ ｜ 認証結果 ｜ ｜<- - - - - - - - - - - - - - -｜ ｜ ｜
と書きたくなるけれど、これは間違い。
この場合の間違いは２点
- パスワード入力画面は、パスワード入力画面表示を要求されて初めて表示される
- 認証結果をいきなりおくっているが、これに対応するリクエストがない
理由は具体例１と同じ。
クライアントには、要求に応答する機能はないので、入力画面にパスワードを返すことはできない。
また、呼び出しなしに応答があるのはシーケンス図としておかしい。
（関数呼び出ししていないのに返り値が帰ってくるようなもん。異次元ｗ）
なので、
|クライアント| |サーバ| ｜ ｜ ｜ パスワード入力画面表示要求 ｜ ｜----------------------------->｜ ｜ ｜ ｜ パスワード入力画面 ｜ ｜<- - - - - - - - - - - - - - -｜ ｜ ｜ ｜ パスワード（認証要求） ｜ ｜----------------------------->｜ ｜ ｜ ｜ 認証結果 ｜ ｜<- - - - - - - - - - - - - - -｜ ｜ ｜
と、するべき。
偉い人から見たら、突込みどころ満載＆何を今更 かもしれないけれど、現場でこの説明が必要だったのです。ご勘弁を。
（でも、有識者による変なところへの指摘は大歓迎です。 よろしくご鞭撻ください）
