SECCON 2016 WriteUp

はじめに

SECCON2016に参加しました。

初CTFです。

開催されていることに当日気がついた程度の情弱ですが、 とりあえず手を動かしてみたかったのでチャレンジしてみました。

結果1問解答でした。せっかくなのでwriteup残します。

Vigenère

問題

k: ????????????

p: SECCON{???????????????????????????????????}

c: LMIG}RPEDOEEWKJIQIWKJWMNDTSR}TFVUFWYOCBAJBQ

k=key, p=plain, c=cipher, md5(p)=f528a6ab914c1ecf856a1d93103948fe

解答

Vigenère暗号です。

問題文にもWikipediaのリンク付きです。

ただオリジナルがアルファベット26文字に対して{,}の2文字が追加の28文字版です。

ASCIIコード見ながらAが0になるように65文字シフトさせます。

ただし、{}はASCIIコードの123と125でZの次じゃないので、それぞれ[\に置換して順番を揃えます。

pのSECCON{を対応表からkがk: VIGENE??????だとわかります。 それならあと2文字も暗号名から推測してk: VIGENERE????でしょうか。 この時点でとりあえず復号してみます。

c = 'LMIG}RPEDOEEWKJIQIWKJWMNDTSR}TFVUFWYOCBAJBQ'
c = c.replace('{', '[')
c = c.replace('}', '\\')

p = len(c)*[0]

k = 'VIGENERE'
shift = 0 # len(k)ずつずらす

for i in range(len(k)):
    p[i] = (ord(c[i + shift]) - ord(k[i])) % 28
    p[i] = chr(p[i] + 65)

print p

ここまでで p: SECCON{A????BCDEDEFG????KLMNOPQR????VWXYYZ} とわかります。

いい感じにアルファベット順ですね。

残り4文字はcipherとかcryptとかかなぁと思ったものの文字数が合わないものの最初はCでいってみるかと思いやってみると p: SECCON{AB???BCDEDEFGH???KLMNOPQRS???VWXYYZ} となりました。

最初の???をBABとなれば綺麗かなぁと思って暗号文cを見ながら対応表を見て、k = 'VIGENERECODE'となったので良さそうです。 あとは上記のコードそのままkだけ変えて終わりです。

p: SECCON{ABABABCDEDEFGHIJJKLMNOPQRSTTUVWXYYZ}

感想

Vigenèreはわりとすぐにできたのでもう1問!!と思ってVoIPやってみたのですが、何をしていいやらとなったので他の方のwriteup見て研鑽が必要です。

でもいろいろ記事ばっかり読んでいて自分で手を動かさないとwriteup読んでも楽しさが欠けるのでこれから数こなしていきたいです。

最後に。参加されたみなさん、お疲れ様でした。

運営の方、ありがとうございました。

Golangのdeferの処理順序

背景

Jxckさんのgihyo連載 でGoを触っていて、以下の記載を読んで、エラー処理でlog.Fatalとかしていたら実行されないのでどういう仕組なのか遊んだメモです。

先の例ではfile.Close()の関数呼び出しをdeferの後ろに記述すると,この処理がmain()を抜ける直前に必ず実行されるようになります。

処理順序

Golang の defer 文と panic/recover 機構について にてdeferが記述されたstatementが関数を抜ける直前に実行されることがわかります。

(Jxckさんの記事では「必ず」じゃなくて「直前」ってほうが言いたいことだったんですね......)

上記に加えて複数defer付けたらどうなるのか試してみました。

gist7b299b8f60a9ac6a3296f9d8f09fbfa5

実行結果です。

[vagrant@localhost gihyotest]$ go run defer.go
execute this statement firstly
execute this statement secondly
execute this statement thirdly

後入れ先出しになっていることがわかります。

記事を書いてからReference見てたら Goブログでそのまんま同じことやっていますし、 以下のように記載されていました。

Deferred function calls are executed in Last In First Out order after the surrounding function returns.

参考

Googleクラウド自然言語APIをPostmanで遊ぶ

背景

Googleクラウド自然言語APIを使ってみた を拝読しました。 自分でも試したいと思いつつもGoogle Cloud Platform(GCP)を使ったことがなかったので、せっかくの機会なので触ってみることにしました。

GCPのプロジェクト作成

CCPにログイン後、ホーム画面から「プロジェクトを作成」を押下します。

f:id:cipepser:20160815152042p:plain

「プロジェクト名」を入力し、「作成」を押下します。

ここでは「NLPtrial」としました。

(少し時間が掛かるようです) f:id:cipepser:20160815152047p:plain

認証情報の作成とAPIキーの取得

プロジェクトの作成が完了すると左上の方に作成したプロジェクト名が表示されているはずです。

この状態で「Google Cloud Natural Language API」で検索すると自然言語APIが出てきます。

f:id:cipepser:20160815152050p:plain

有効にします。

f:id:cipepser:20160815152054p:plain

APIを有効にしたらAPIを使用するための認証情報を作成します。

今回は「APIキー」で「サーバーキー」を使用します。

(このあたりは初めて触ったのでもっと適切な設定がある気がします。。。)

f:id:cipepser:20160815152100p:plain f:id:cipepser:20160815152102p:plain f:id:cipepser:20160815152107p:plain

名前を適当に入力します。ここでは「nlp」としました。

IPアドレスは未入力で作成しました。 f:id:cipepser:20160815152114p:plain

APIキーが作成されます。

(画像では消していますが、赤枠のところに現れます)

APIを叩く際に利用するのでコピーしておきましょう。

f:id:cipepser:20160815152118p:plain

一覧でも見れます。 f:id:cipepser:20160815152121p:plain

APIを叩く前に

前ステップで取得したAPIキーを使用してAPIを叩くにあたって認証情報をどうやって送ればいいのか確認しておきます。

によると

The application passes this key into all API requests as a key=API_key parameter.

とのことです。

Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them:

の記述があるのですが、Refferヘッダから第三者に参照されてしまったりしないのか不安です。URLにパラメータ直書きで問題ないのでしょうか。

セキュリティ上よろしくないというようなことでしたご指摘ください。

APIを叩く

いよいよAPIを叩きます。

Entities(固有表現抽出)のAPI仕様は公式ドキュメントに記載があります。Typeについてはこちら から。

gist9a8307d8b14251d45999da818b2b084e

上記のような仕様に従ったjsonを以下にPOSTすればよいそうです。

https://language.googleapis.com/v1beta1/documents:analyzeEntities

手軽にやるために今回はPostmanを利用します。

リクエストを「POST」とし、上のURLに先ほど作成したAPIキーをパラメータとして渡してあげます。

あとはBodyにjsonを入れてSendするだけです。

f:id:cipepser:20160815152126p:plain

文章は何もおもいつかなかったので山月記の書き出しを拝借します。

隴西の李徴は博学才穎、天宝の末年、若くして名を虎榜に連ね、ついで江南尉に補せられたが、性、狷介、自ら恃むところ頗る厚く、賤吏に甘んずるを潔しとしなかった。

結果です。

gistb77a1571570c7bc080bfc3d6c89cf344

李徴はPERSONと出ていますし、URLも返ってきていますね。

各単語のbeginOffsetがわかるので、その単語が文章の何文字目か分かるようになっています。

一方で、隴西のように地名がPERSONとなってしまっていたり、

江南尉もORGANIZATIONとなっています。また天宝や狷介は結果も返ってきません。

感想

Googleクラウド自然言語APIを使ってみた でも言及されていますが、wikipediaから引っ張ってくるだけですし、今はちょっと微妙で、今後の発展次第ではもっとおもしろいことできそうかなーという感想です。

自然言語APIというよりその前段階の認証の記事みたいになってしまったもののGCPに触れてよかったです。

繰り返しになりますが、認証のkeyの渡し方で問題があればご指摘ください。

参考

Javaでwavを再生する

背景

Javaで音声ファイルを再生させたくて Javaでmp3を再生する(コード編) を参考に書いていたもののjavax.sound.sampled.UnsupportedAudioFileException: could not get audio input stream from input fileのエラーが出て手が止まりました。

エラーにも書いてありますし、以下にもあるようにmp3のcodecの問題ですね。

facing issue in loading a mp3 file in java getting could not get audio input stream from input file

mp3のフォーマットまで深入りしたくないなぁと調べていたら [memo]JavaでMP3プレイヤーを作る に以下の記述がありました。

Javaは標準ではMP3を再生できないので、次のライブラリを使う必要があります。

MP3 SPI for Java Sound

SPIライブラリ使ってもよさそうでしたが、特にmp3にこだわってなかったので wavでやることにしました。

いじったところ

あとは Javaでmp3を再生する(コード編) のコードのままで問題なくコンパイルでき、実行もできるものの 音声が出ません。 再生はできているようなのにおかしいということで、疑ったのはミュート設定です。

playerオブジェクトに対してstartメソッドを実行する前に 以下を追記したら無事音声が出ました。

player.mute(false);

疑問が残っているところ

Javaのドキュメント にもあるようにbooleanのDefault Valueはfalseです。

特に設定していないBooleanControl.Type.MUTEがtrueになっているのに 納得いかないですが、 動くようになったので同じところでハマってしまった方のために残します。

参考

RapidSSLのファイル認証タイプ証明書のクローリングでハマったこと

背景

LINE bot APIが公開されたので遊んでみようということで ドメインも取得したものの、https通信が必須かつ Let's Encryptのような無料の証明書は受け付けてもらえないという 噂を耳にし、ニジモのSSLストアからRapidSSLにて購入することにしました。

証明書発行の流れと事前準備

証明書は最安1620円のファイル認証タイプを選択しました。

発行の流れは以下の記事に沿って行っていくのみです。

RapidSSLを1,500円で発行する流れ

記事中でも以下の記載があるように事前準備としてCSR秘密鍵の生成が必要です。

CSRは使用するサーバがApacheであれば→CSR秘密鍵生成ツールを利用して生成することも可能です。

OpenSSLでkeygenしてもよいのですが、 今回はApacheサーバを利用するつもりだったのでCSR・秘密鍵生成ツールを利用しました。 必要事項を記載し、「生成」を押すだけでCSR秘密鍵が生成されます。

この2つを認証局に提出し、認証してもらいます。

ハマったこと

RapidSSLを1,500円で発行する流れ に沿って順調に進めていくと最後の最後「15. サーバ証明書の発行」でハマってしまいました。 記事には

30分程度で証明書がSSLストアにご登録いただいているアドレス宛に以下の件名で届きます。 RapidSSL Fulfilment E-Mail [Common Name=ご申請いただいたコモンネーム]

と記載があるものの30分過ぎても、一晩経っても一向に連絡がきません。 いろいろと調べたのでせっかくですし以下にまとめます。

ファイル認証タイプ証明書について

上記で生成したCSR(と秘密鍵)に対して、購入した証明書をひも付けるために 認証局は本人確認を行います。

お高い証明書では実際に対面で本人確認をしたりするようです(手間や費用が掛かる分、信頼性も高い)。

今回使用したファイル認証では、CSR認証局へ提出すると.htm形式のファイルが送られてくるので、 これをCSR内に記載されているドメインのURLに配置し、それを認証局がクローリングすることで本人確認を行います。

価格も低いため手間も少なめですね。

クローリングでは送られてきた.htmファイルのファイル名と中にもハッシュ値が記載されているのでMACのような認証を行うものと思われます。

クローリングの時間について

RapidSSLでは受付完了後20分以内は1分半間隔でクローリングし、その後80分までは5分間隔、80分移行は10分間隔とだんだんクローリング間隔が延びていくようです。

妥当な設定な気がしますが、ゆっくりしているとすぐにクローリングしてもらえないので、こちら側としては受付されたらすぐに認証ファイルを配置したほうが、待たされないのでよさそうです。

時間間隔については会社ごとに設定が異なるようなので、購入された会社にてご確認ください。

GeoTrustは初めこそ1分間隔ですが、1週間後には1日間隔になるようなのでうまく認証されなくても1日待つことになりそうです。

解決

結局なにかをしたから解決した、というわけでないです。 翌営業日になったら普通に認証完了のメールを受信しました。 土曜に始めて日曜まで消費してしまったことが悔やまれます......。

自動でクローリングしてもらえるものだとばかり思っていたのですが、認証情報のチェックなども行っているのでしょうか?それとも土日はクローリングしない?

同じような状況の方のためにブログに残しますので、翌営業日まで待ってみてはいかがでしょうか。

参考

2015年度に読んだ本まとめ

年度も変わったので2015年度の一年間で読んだ本をまとめました。
小説とか漫画は数が多くなりすぎるので割愛です。

技術書

冗長構成という概念すらよくわかっていない時に読みました。VRRPなどが知れてよかったですね。

定番。暗号技術についてひと通り聞いたことがあるかなって状態にできました。 実際に使用するときに自分で実装するのはNGですが、自分の手を動かしてしっかり身につけるために再読したいです。

ネットワークを設計するときにL1〜L4を中心に気をつけるべきことが体系的に学べました。 詳しくは前回に感想を書いたので。

データセンターのお話。データセンターについて考える時の基準の一つとして電力量があることとか知れてよかったです。

こちらも定番。脆弱性がどういう風に発現するのかPHPのコードを見ながら理解できました。 こちらで勉強したことを元にXSS challengesなどが解けてすごい楽しかったです。

マネジメントとか

プロジェクトマネジメントの古典。当然読んでますよって言うためだけに読んだ感じなのでマネージャーさんとかになったら再読したいですね。

資格系

エッセイ

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門を読んだ

この本を手にとった理由

友人におすすめされて本屋で手に取ってみたら、自分が今までふわっとしか理解していなかった事柄が網羅されていそうだったので、そのままレジでした。

感想

全体の流れ

L1〜L4の物理層データリンク層ネットワーク層トランスポート層について、ネットワークを設計する時に、保守運用のことも考え、気をつけるべきポイントが書かれています。L5〜についても触れられていますがタイトルにも「インフラ」とあるように低めの層がメインです。

筆者が実際に体験した障害を想定しているので、「あぁ、そういう障害が起こり得るのか」って感じながら読めました。
全体を通じて「わかりやすい!」という感想だったので、ざっとネットワーク設計について知りたいという方におすすめです。

序盤〜中盤

基本的な構成は、各層の要素技術の紹介→どうやって設計するか、という流れです。

物理層だと光ケーブルやMDIの規格についてとか。
ここは覚えておくべきポイントとどうやって覚えるかという覚え方が書いてあってとっつきやすいですね。

L2〜L4だとNW機器の配置、VLAN、ルーティングプロトコル、LB、FWなどについて、ここは抑えておこう、また、どこに統一性を持たせて設計すれば、障害が起きた時に対処しやすいかという内容になっています。あとこういう仕組みだからこう設計すべきだよねってお話など。

例えば、設計だとFWの通信許可設定も内部→DMZは多少ゆるく設定しても問題ないけど、DMZ→内部は必要最低限だけ許可するというようなことも書かれています。

終盤

最後2章の高可用性・管理では、ネットワークに障害が起こった時に通信フローがどのように変わるのかということについても、ここのLBに筐体障害が起こったらこういうフロー、L2SWのリンクに障害が起こったらこういうフローという風に一つ一つ図で説明されていてわかりやすかったです。
図が多いからさっさと読めて進んでる感が出るのも嬉しい感じです。
しかも単純に通信フローの切り替わりを述べるだけでなく、ここのリンクダウンだとこのNW機器がダウンを検知して、failoverするからこっちの通信フローに切り替わるんだよって理由が書いてあるので納得できました。

全体を通じて

ネットワーク設計全体を網羅することに重点を置いているように感じました。その分、各技術の勘所だけ抑えていて、さらに詳細について知りたい場合は別の書籍やRFCを読むなりする必要がありそうです。
勘所を抑えられるので、本書で、その技術の概要を頭に入れた状態で詳細を調べるという流れがよさそうですね。

個人的に概要を知れてよかったのは、ARPDHCP、MIB、OSPF、TCP/UDPあたりでしょうか。順番も粒度もめちゃくちゃですが。
DHCPとかなんかいい感じに空いてるIPアドレスくれるくらいのイメージしかなかったので、DHCP Discover→Offer→Request→Ackという流れで、最初はクライアントにIPアドレスが振られてないからブロードキャストするとか知れてよかったです。

WireSharkで実際の通信のキャプチャが随所で取っていて、どこに注目するか枠が囲ってあったりでプロトコルのフォーマットを見せて終わりにされるより実感が湧くのもよかったです。

大筋の流れではないですが、うまくやるためにはこうやったほうが早いよというようなベストプラクティスもそうですが、これはやってはいけないというようなバットノウハウも書いてあって、「なるほど、気をつけよう」ってなりました。

こういう人におすすめ

タイトルの「入門」にあるように実務で使用している方にとっては物足りなそうです。新卒1〜2年目でネットワーク系部署の方だと、自分が触っていたシステムの構成がそうなっていた理由がわかるのでおすすめです。
(この書評で良い所ばかり挙げてしまっているのも自分自身が学び始めだからです、おそらく)

インフラといっても「自分はAWSでいいや」って方だとあまり必要ないかもしれないです。AWSのようなインフラを提供する側というか、業務でデータセンター行くことがありますって人のほうがおすすめです。ケーブル色を用途に応じて決めておきましょうと言う話もあったりするので。
本書の「はじめに」にも以下のように書かれているので、思うところがある方も。

ここ最近、クラウドコンピューティングという大きな波に逆流するかのように、新たな潮流が生まれています。 オンプレミス(自社運用)への回帰です。

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 - みやた ひろし

参考