9424T/SP-Eを静音化する

先月あたりにヤフオクで購入したAllied TelesisのL3スイッチ9424T/SP-Eを静音化する。他のサイトを参考にしたので特筆すべきことはあまりない気がする。

ファンの購入

交換用のファンは秋葉原の千石で販売されているものを2つ買った。小さいファンでも産業機器へ使われるほどなので値段が高い。

取り付け

以下のサイトを参考に取り付けを行った。

アライドのL3スイッチ・CentreCOM 9424T/SP-Eの静音化: aji blog

CentreCOM 9424T/SP-Eを静音化してみた – @SRCHACK.ORG(えす・あーる・しー・はっく)

気をつけることは、「ファンの取り付け向き(吸気/排気)」と「ピンの並び」の2つだけだった。

ファンの取り付け向きを確認せずに取り付けてしまった。以下は間違えた時の向きで撮影した写真。

ピンの並びは、参考にしたサイトでも書かれているように異なるため自分で変える必要がある。ソケットの隙間にピンセットを差し込んで圧着してある端子を押し出すようにして取り出した。力の入れ方が難しかった。

黒と赤のケーブルの位置を入れ替えれば正常に動いた。怖かったのジャンパーケーブルとブレッドボードを使って慎重に配線して確認した。

配線したら接触不良で回らないときがあったので圧着部分の端子を少し調整して再度差し込んだところ正常に動作した。

余ったケーブルは結束バンドでまとめておいた。ファンを筐体に固定するときに、もともと固定していたビスが交換したファンに合わなかった。そこで、購入したファンに付属していたナットとボルトを使って固定した。

配線して通電してFAULTが点灯せず、ファンが回転していれば問題ない。かなり静音になったので運用にもっていきたいと思う。

母校でワークショップを行いました。

母校の高校でワークショップを行いました。スライドは以下に公開しました。

//speakerdeck.com/assets/embed.js

配布した資料は以下のリンクからダウンロードできます。

パケットワークショップ配布資料

楽しみながらWiresharkの使い方やパケットの仕組みについて興味を持ってもらえたようで良かったと思いました。また、機会があればワークショップを行いたいと思います。

Harekaze CTF 2018やってみた

久しぶりにCTFやれる、まとまった時間が作れたので参加してみた。全体での順位は230ptで131/447だった。修行が足りなすぎる。

ObfuscatedPasswordChecker

配布されるsrc.zipを展開してみるとhtmlファイルとjsファイルが含まれている。htmlファイルをブラウザで開いてみるとパスワードフォームが表示される。ここに何かの入力値を入れると、何か起きそうだと考えた。

試しに開発者ツールのNetworkタブを開きながら、適当な文字列を入力してボタンをおしてみる。タブ内に変化はなく、リクエストは送信されていないと分かる。つまり、このhtmlとjsで構成されるクライアント側で完結するアプリだと考えられる。

次に、JavaScriptの挙動を追跡してみる。ブラウザの開発者ツールから「ボタンが押された時」に関するイベントを探してみる。

bundle.jsの1行目にボタンを押した時の処理があることが分かる。実際にbundle.jsを表示して整形してみる。

次にボタンが押された時に、「入力値がどのように判定されているか」を調べてみる。ボタンが押された後の処理は311行目から319行目までの範囲にかかれている。

この中にif文がふくまれている。このソース全体は軽めな難読化がされているのでif文の内部の処理を分析してみる。

ブラウザのConsoleで変数やメソッドなどを展開できるので、これを使って値の中身を確認する。するとsuccessという文字列が314行目で代入されていることが分かる。次に315行目ではcongraz! the flag is: という文字列と変数_0x256968の値が文字列結合されていることが分かる。

つまり、変数_0x256968がFLAGに関わっていると考えられた。この変数に着目すると313行目で変数_0x5d7c01と比較されており、305行目で宣言と代入が行われていることが分かる。

試しに305行目の代入値をConsoleで確認してみるとFLAGの中身であった。おそらく変数_0x5d7c01がブラウザのフォームでの入力値だったと考えられる。

HarekazeCTF{j4v4scr1pt-0bfusc4t0r_1s_tsur41}

Lost_data

ファイルlost_data.zipを解凍すると xxxxx.zip と data.zipが出てくる。さらに data.zip を解凍すると1, 2, 3というファイルが出てくる。テキストエディタなので開いてみるとファイルがバイナリファイルであることが分かる。

バイナリエディタやhexdumpなどで中身を覗いてみるとPNGファイルにみられるチャンクとよばれる構造が確認できる。ファイル構造を確認するとヘッダにPNGの特徴であるASCII表現された「PNG」が見られない。

hexdump -C 1
00000000  89 2e 2e 2e 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |............IHDR|
00000010  00 00 00 6f 00 00 00 6f  01 03 00 00 00 d8 0b 0c  |...o...o........|
00000020  23 00 00 00 06 50 4c 54  45 7d c7 ff ff ff ff 97  |#....PLTE}......|

そこで、バイナリエディタでその部分を書き換える。

hexdump -C ../../data/1
00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
00000010  00 00 00 6f 00 00 00 6f  01 03 00 00 00 d8 0b 0c  |...o...o........|
00000020  23 00 00 00 06 50 4c 54  45 7d c7 ff ff ff ff 97  |#....PLTE}......|

そして、画像ビューワなどで開くと2次元コードの画像が計3枚でてくる。これらをスキャンして結合すると HarekazeCTF{Y0u_G0t_FuNNy_F1ag_?DF?_T?_is_xxxxx} が出てくる。

この後に xxxxx を置き換えることが必要になるが、ファイル xxxxx.zip が関連していることは分かったが何をすればいいのか方針が立たない。ひとまず放置しておいた。

後からヒントでファイルシステムという単語と xxxxx.zipに含まれるファイル一覧から何となく「FAT(16|32|64)」あたりで試したらフラグが落ちてきた。

HarekazeCTF{Y0u_G0t_FuNNy_F1ag_?DF?_T?_is_FAT32}

Sokosoko Secure Uploader

ソースコードを読んでSQLiであることまで分かった。入力値があらかじめ決められた形式でないと弾かれると特定して、それに合う形式で入力値を組み立てるところで上手く行かずに時間切れ。いろいろトライした形跡が残っていたので貼っておく..。
'OR 2=10-1OR3-2=22-(100-1)OR
id LIKE'5a%'
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
21313134-3413-3134-3143-311232131231
'OR 1=1;--222-2222-2222-222222222222
'OR id LIKE
'|| id LIKE '9e5a%' --    -    -    -
1=1 --222-2222-2222-22222222222'

21313134-3413-3134-3143-311232131231
'||1=100-1000-1000-1000-1||
'OR id/*-0000-0000-0000-*/9e5a

21313134-3413-3134-3143-311232131231
'OR id BETWEEN '9e5a0' AND '9e5a1'

21313134-3413-3134-3143-311232131231
'OR id LIKE '%e5a%';
'OR id LIKE CONCAT('%e5a%';
あとでWriteUp見たらコメントアウトで良かったと知って絶望した。
もっと精進していきたいと思った。あとCTF面白いね。

学生LT #8に参加した

第2回の学生LT以来、久しぶりに参加してきた。参加者の層も前回よりも幅広くなった気がする。

第8回 学生エンジニア限定LT大会!!! – connpass

基調講演でうみさまが話していた内容はかなり共感できることがあった。スキルがあっても自信がないとチャンスは生まれないと改めて感じた。少しでも踏み出すことの大切さは、先人のツイートやブログ、スライドでも上げられているし。

今回の会場のfreeeさんはスマートなプロダクトで素晴らしいなと紹介プレゼンを聞いて感じた。「JavaとJavaScriptはハムとハムスターぐらい違う」がかなり印象的だった。

(たしか)もっちーさんのIoTが実際の問題に対してはっきりとしたアプローチを提案しているあたりすごいなーと思った。あれ全国で欲しがっている人いると思う。ワナにひっかかる時間帯とか傾向をデータ化して共有したら面白そう。

N高校の@waritocomatta さんのLTが慣れた感じの技術系LTで面白かった。とくに某Y社のハッカソンが発表時間90秒という短さは意外だった。なんというか、その方面で突き抜けた感じ(分かる人には伝わるかな)があると思った。やっぱり未踏ジュニアなだけあるなと。

中学生でRails使ってWebアプリ作った@anharuさんもすごいなーと。中学生の時にここまで出来なかったよなぁと。特にDB設計、サーバサイド、フロントエンドという設計の順番を考慮しているあたり分かっているんだなと思った。

//speakerdeck.com/assets/embed.js

自分の発表はスライドがイベント始まってから完成するくらい遅かったので、内容が薄くなってしまったので反省してる…。時間の配分もまったく考えていなかったので気をつけたい。本当はXSSの入力値についてひたすら語るLTにしたかったけど、使えるほどの数の検証が出来ていなかったので断念。次はもっとクオリティの高いLTをやりたい。

お疲れ様でした && ありがとうございました

Webのセキュリティで注意したいポイントと脆弱性

この記事はseccamp2017 Advent Calendar 2017 の10日目です。記事の執筆から逃げていたら担当日が終わりそうで焦りながら書いています。

WebセキュリティではXSSやSQLi, CSRFなど比較的よく知られている脆弱性だと思います。これら以外にも様々な種類があることを最近、書籍(脆弱性診断スタートガイド)やWebで学んだので紹介してみます。

cookieのhttponly属性

cookieには属性という情報を付与することが出来ます。このうちのhttponly属性はWebページ(HTML)からcookieに対してアクセス出来るかを表しています。この属性が有効になっている場合、JavaScriptを利用してcookieへアクセスすることが出来ません。

例えば、サイトにXSSの脆弱性がありcookieでセッションを管理していた場合、httponly属性が有効でないとdocument.cookieによりセッション情報が流出する危険性があります。これはセッションハイジャックなどにも繋がる可能性もあります。

この対策は、cookieのhttponly属性を有効にすることです。ただし、Webサイトでcookieの情報を取得する場合 は有効にすると妨げになってしまうので注意が必要です。

参考: httpOnlyなCookieとは? – それマグで!

cookieのsecure属性

上記のhttponly属性と同様にcookieに付与する属性になります。これは本来、httpsでやり取りされるべきcookieがhttpでやり取りされるのを防ぐことが出来ます。なので、httpsサイトでは可能な限り付与するべきだと思います。

参考: http https 混在サイトでの Cookie Secure 属性の扱い方 – 長生村本郷Engineers’Blog

HTTPヘッダ・インジェクション

リクエストに含まれる改行コードがエスケープされずに出力されてhttpヘッダにインジェクションが可能になる脆弱性です。 例えば以下のパラメータ付きURLhttp://test.com/a.php?jump=Location:%20http://yahoo.co.jp/でyahoo.co.jpにリンクされてしまった場合、httpヘッダインジェクションが起きているといえます。

そこで実際に検証してみることにしました。実際に動かしてみたソースコードは以下です。

<?php

if(isset($_GET['jump'])){
$dest=$_GET['jump'];
}else{
$dest="default";
}

header("HTTP/1.1 301 Moved Permanently");
header("Content-Type: text/html");
header("Location: http://koyama.me/?param=$dest");

exit;
?>

環境はapache + php7.0でdockerを使いました。実際にテストで送ったリクエストが以下です。

GET /test.php?jump=%0D%0ALocation:%20http://yahoo.co.jp/ HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

このリクエストに対してサーバからは以下のレスポンスが帰ってきました。

HTTP/1.1 301 Moved Permanently
Date: Sun, 10 Dec 2017 14:46:04 GMT
Server: Apache/2.4.10 (Debian)
X-Powered-By: PHP/7.0.24
Content-Length: 149
Connection: close
Content-Type: text/html;charset=UTF-8

<br />
<b>Warning</b>: Header may not contain more than a single header, new line detected in <b>/var/www/html/test.php</b> on line <b>11</b><br />

正直、これは本来意図していた応答ではありません。しかし、PHPのheader関数の内部でhttpヘッダインジェクション対策が行われているからこそでもあります。徳丸先生の記事が参考になります。

PHPにおけるHTTPヘッダインジェクションはまだしぶとく生き残る | 徳丸浩の日記

本来、意図したレスポンスは以下の形式です。

HTTP/1.1 301 Moved Permanently
Date: Sun, 10 Dec 2017 14:45:43 GMT
Server: Apache/2.4.10 (Debian)
X-Powered-By: PHP/7.0.24
Location: http://koyama.me/?param=
Location: http://yahoo.co.jp/
Content-Length: 0
Connection: close
Content-Type: text/html;charset=UTF-8

このレスポンスを見るとhttpレスポンスのヘッダにLocation: が複数並んでいることが確認できます。書籍によるとApacheでは複数あるLocation:のうち最後に存在するものが優先されるとのことでした。実際に、手元の環境でも試したところ同様の挙動を確認することが出来ました。この挙動に関してもブラウザやサーバソフトウェアに依存すると思われます。もう少し詳しい検証が必要だと感じました。

時間がないので今回はこの辺で…。遅れてごめんなさいm(_ _)m

検証環境

  • Docker(php:7.0-apache)
  • Firefox 57.01(64bit)
  • BurpSuite Community Edition 1.7.29