雑記」カテゴリーアーカイブ

DEF CON 2019 Online Quals / Write-up


どうもみむらです。
久しぶりに wasamusume の CTF の活動を再開したくなり、リハビリがてらに参加してみました。

結果としては98位。
3人だけでひっそりと参加していたのですが、結果としてはかなり上々かも。

というわけで、解いた問題についての Write-up です。


問題のおしながき:
・welcome_to_the_game
・babytrace
・know_your_mem


welcome_to_the_game

FLAG : OOO{Game on!}
ファイルを開くと出てくる。


babytrace

FLAG : OOO{memory_objects_get_you_every_time}

claripy と angr で作られたトレーサを経由して問題のファイルを覗く問題。
プログラムは純粋に使うと2文字までしか表示されないようになっています。

eax が文字位置.

解き方

0x856 の位置に “movzx eax,[rbp+eax+buf]” という処理があり
ここで、任意の位置の文字が “eax” に積まれます。

その処理を利用して、任意の文字の位置を読んでみます。

読みたい位置を標準入力に設定(ここでは 0x25 = 最後の文字)
文字列が代入される 0x856 より先の位置まで進める。(ここでは 0x86E の puts の中で止まっている)
その状態で eax の値 (ここでは eax_63_32)を読むと、 0x7d = ‘}’ の値が取得できていることが分かる。

あとは上記を繰り返して、文字列を読んでいくとフラグが得られます。


know_your_mem

FLAG : OOO{so many bits, so many syscalls}

実行すると下記のように、シェルコードを入れるように指示されます。
ここに、文字列長とシェルコードを入力するとそれが実行されます。

シェルコードで実現する必要があることは、
プログラムのどこかに読み込まれている「フラグ」のデータを探し出して
それを読み込んで表示すること。
また、10秒間のタイムアウト値が設定されているため、それを越えての探索は出来ません。

解き方

方針1(基本的な方法)

64bit 空間のメモリを全部探すのは現実的ではないので
スタック中から何か出ていないか探します。

下記のようなアセンブラを書いて、それをシェルコードとして与えます。

bits 64

section .text
global _start

_start:
mov rsi,rsp
mov rdx,70
mov rdi,1
mov rax,1
syscall
mov rax,0
ret

どうやら白く塗ってある場所に同じ表示が出ているのでこれが使えそう。

ただ大会期間中は、メモリ位置を考慮するのが面倒くさくなったので
別の方法を使いました。


方針2(実際に試した方法)

“flag” の読み込みを r15 が指し示すメモリアドレスに読み込む処理が入っています。

shellcode 読んだ直後でも R15 が flag の入っているメモリを指し示し続けてる。
(今回はソースコードで提供されたので、コンパイラによっては別のレジスタが使われる場合もある)

というわけで下記のようなアセンブラを書いてみました。

bits 64

section .text
global _start

_start:
mov rsi,r15
mov rdx,50
mov rdi,1
mov rax,1
syscall
mov rax,r15
ret

結果としては下記の通り

というわけで r15 レジスタを参照するだけで解けました・・。
うーんこれで良いのだろうか・・。

ところで
フラグが OOO{so many bits, so many syscalls} なので
下記のようなコードを書くのが正しいのかもしれませんね・・?

余談(メモリ全探索。間に合わないけど・・。)

(ただし速度が追いつかないので改良等をする必要は大いにあります)

bits 64

section .text
global _start

_start:
mov rsi,0x100000000000

_nextpage:
add rsi,0x1000 ; mmap のアライメント.

_nextbyte:
mov rdx,10
mov rdi,1
mov rax,1 ; write は今回の seccomp の設定で許可されていたので.
syscall

_faultcheck:
cmp al,0xf2 ;EFAULT
jz _nextpage
mov eax,0x4F4F4F7B ; egg "OOO{"
inc al
scasd
jnz _nextbyte
mov rax,rdi
ret

普通に Egg Hunter の Exploit code のもじりです(苦笑)


というわけで、
久しぶりに CTF やるのと、久しぶりにアセンブラ読み書きしてるのが楽しかったので
また機会があれば CTF やりたいかもしれません。

また家にメンバーを読んでやってたのですが、
あのワイワイした感じで解くのも面白かったし。であであー。

Windows Terminal (Preview) をビルドして使おう


どうも、みむらです。

先日発表されたばかりの “Windows Terminal” を使ってみました。
とりあえず、これは今すぐ会社用PCとかにも入れておこうかと思いました。

普段使いそうなツール群を呼び出せるようにしてみたのですが、
結構使いやすそうな子のようです。

マイクロソフト社からちゃんとストア経由で今後出てくると思いますが
常に最新のものを触りたい!という人向けに、ビルド方法のメモになります。


1.ビルド環境の準備

執筆時点(2019年5月8日)では、下記のものを用意する必要があります。

1. Visual Studio 2017 (2019 だと上手くビルド出来ませんでした..)
2. Windows 10 (ストアアプリ扱いになります)

また、ビルドするためには Visual Studio 2017 にて
「C++ ユニバーサル Windows プラットフォームツール」を有効にする必要があります。


2.ビルド

下記 URL より git clone を実施してソースコードを取得します。
https://github.com/microsoft/Terminal

Clone 完了後、”git submodule” を使用して、
依存関係にあるコードもダウンロードします。

# git submodule update –init –recursive

コードの準備が完了したら “OpenConsole.sln” を Visual Studio 2017 で開きましょう。

“CascadiaPackage” を右クリック → ストア → 「アプリパッケージの作成」と選択します。

そして「サイドロード用」のパッケージとして、
お使いのアーキテクチャにチェックを入れて “Release” となっていることを確認してパッケージを作成します。

注意

ビルド中、もの凄くメモリを使います。
下手をすると下記のようなエラーが出てコンパイルエラーになることもあります。

13>c1xx : error C3859: PCH の仮想メモリを作成できませんでした
13>c1xx: note: PCH: ファイル マップ全体にメモリをコミットできません
13>c1xx: note: 詳細については https://aka.ms/pch-help をご覧ください

そのときは Visual Studio の同時コンパイル数を1にすることで
改善できる場合があります。

ツール → オプション → プロジェクトおよびソリューション → ビルド / 実行
にて「平行してビルドするプロジェクトの最大数」を1にします。


3.インストール

下記のようにビルドが完了したら、Add-AppDevPackage.ps1 を実行します。
あとはウィザードに従って進めればインストール完了となります。


なお、このファイルを常用するコンピュータに持って行き、
インストールをすることで他のコンピュータでも利用することが可能になります。

動作しないときは:

開発者モードになっているかを確認しましょう。


4.使う

早速スタートに登録されましたのでバンバン使っていきましょう。


初回起動時はこんな感じの無機質なターミナルが表示されます。

ここで Ctrl + T を押しましょう。
下図のようにいい感じにタブと設定メニューが登場します。

では右端のボタンから “Settings” を開きましょう。

下図のように json が表示されると思いますので、適宜成形 (Visual Studio であればドキュメントの整形機能があります)して眺めます。

まず、全体設定ですが確認できるのは次の通りです:

“alwaysShowTabs” はタブを画面に常時表示するかどうか。これについては “true” に書き換えておいた方が無難です。
“showTerminalTitleInTitlebar” はタイトルバーにアクティブなタブのタイトルを表示させるかどうか。
“experimental_showTabsInTitlebar” はタブをタイトルバー部分に表示するかどうか。

つぎに “profiles” の中ですが、ここに項目を追加すると呼び出せるプログラムが増えます・・!

お好きなフォントを “fontFace”, “fontSize” で設定し、
透過させたい場合は “useAcrylic” を true にした上で、 “acrylicOpacity” (1に近いほど無透過)を設定すると良いと思います。

参考までに、私の設定ファイルも置いておきます。参考までにどうぞ・・!
https://gist.github.com/mimura1133/4e65fdbf8fd686d3a3691bd9b43678ac


発表されてすぐさま使ってみて、かなり使い勝手がよさそうでしたので
私としては早く標準のコマンドプロンプトの代わりになって欲しいなと思うそんな今日この頃です。

CUI なアプリケーションを全部このタブに纏めておいたら凄く使いやすそうな感じがする。。

巻末に、私の環境でビルドしたファイル(x64 専用)もおいておきます。
どうしてもビルドに失敗してしまうかたがいれば、自己責任にてお試しください。

http://mimumimu.net/beta/programs/CascadiaPackage_1.0.0.0_Test.zip

Windows と Linux の和暦対応


どうも、みむらです。
しばらく記事を書かない間に、新暦が発表され、
そして私も会社が変わってしまいました。
 
最近はアプリ診断員にジョブチェンジしました。
IDA さんが友達です。

特に最近は iOS アプリを見ているので、
フォレンジックネタとか iOS に関するセキュリティ診断ネタであれば、
凄く話に乗れると思います。

それ以外には、Unity のアプリとか (lib2cpp の読み解きとか)
Windows ならユーザランドからカーネルランドまで。お話まってます。


閑話休題。

新暦と言えば、やはり新暦対応でしょう。
私も新暦が発表された直後から「なんとしても対応しよう」と遊んでました。

画像
(from : https://twitter.com/mimura1133/status/1112566297135480838/ )

などなど。
 
今回は、もし「令和じゃない元号にします」と発表があった際に
素早く手持ちの環境を自己責任において対応させられるように
(要出典)
Windows と Linux の対応の仕組みを見ておこう
、とそういうテーマです。

 


Windows 側での対応

Windows の場合はレジストリキーを追加します。

(注:本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します)

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras 以下に
年号情報が詰まっていますので

REG_SZ 型にて
キー名:”<開始年> <開始月> <開始日>”
値:”<フル読み>_<代表する一文字>_<英語表記>_<英語短縮表記>”

のフォーマットにてキーを生成すれば OK のようです。

 

この値を設定すると、
この値を参照しているプログラムの処理系であれば
基本的に新年号に対応出来るようになります。

画像

 


Linux (glibc) での対応

Linux の場合は locale ファイルを修正します。

(注:本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します)
 

locales ファイルは下記のパスに保存されています。
(Arch Linux, CentOS 7 にて確認)

/usr/share/i18n/locales/ja_JP

 
修正するのは、”era” の部分。

「○○元年」(+1 で始まるレコード)と「○○年」(+2 で始まるレコード)
を用いて年号の変換を行います。

そして年号は UTF-16BE の順番で書いていきます。

リトルエンディアンでの「令和」のバイト列

できあがった例は次の通り

新しい年号に対応させた ja_JP ファイル.

1つめの “+:1:2019//05//01:2019//12//31:<U4EE4><U548C>:%EC<U5143><U5E74> は
2019年5月1日~2019年12月31日までを「令和(<4EE4><548C>) 元年(<5143><5E74>)」

表記するというもの。

2つめの “+:1:2020//01//01:+*:<U4EE4><U548C>:%EC%Ey<U5E74> は
2020年1月1日以降を「令和(<4EE4><548C>) %Ey(+2)年(<5E74>)」

表記するというものになります。

ですので上記のような ja_JP ファイルを作成し、locale-gen をすると
下記のように新暦に対応することができます。

新暦対応後の図

 


最後に。

Windows や Linux のシステムがかなり柔軟に新暦対応させられる作りになっていることはおわかりいただけたかと思います。
 
ただ、これは一人のソフトウェア作者としてのコメントではありますが
全てのプラットフォームが上記で挙げたような簡単な方法で
すぐ対応出来るようになっているわけではありません。

 
また、上記のようなレジストリキーやファイルを参照するものであっても
(平成)31年から(令和)1年へ変わるわけですので
エラーが発生するシステムも十二分に考えられます。
 
ですので上記の方法で対応ができ、
ご利用のソフトウェアで問題なく稼働した場合でも
これは運が良かったという程度にお考えいただき、
ベンダーの正式対応を基本的にはお待ちいただくようにしてください。
 
上記のリスクにご理解いただけるかたで、新しいものに楽しみを感じるかたは
ぜひ自己責任において新暦対応を一足お先にお試しくださいませ。
なお、それによりデータ破損等が発生しても当方では責任を負いかねます。

・・というわけで。であであー。

#ssmjp 2018/05 に参加してきた。


20180524_100644896_iOS

 

気がついたら一番前の演題の前に「blog枠」という席が用意されていて
そこに座っていました。

 

どうも、みむらです。

 

前回参加した際に、  
知り合いに「実は5月は喋るんですよ!」と前回参加時に教えてもらいまして
その時から、これは行かねばならぬ、と使命感的なものを感じておりました。

 

うそです。前回が楽しかったから参加してます。
もちろん、知り合いの発表もわくてかですよ。

 

冗談はさておいて、#ssmjp です。 

 


 

#ssmjp の勉強会について。

 

アウトプットしないのは知的な便秘

 

「インフラ/運用」がテーマの勉強会。
でも「面白ければ別に IT じゃなくても何でもいいんじゃない?」というポリシー。

@tigerszk 先生のクソコラが見られるのは ssmjp だけ!

 

大人数の前で喋ることの練習の場として利用するのも OK.
気軽な気持ちで参加をすればよい、とのこと。

喋りたい方はサイトを確認してくださいとのことですので、
チャレンジしてみてはいかがでしょうか。
http://ssm.pkan.org/

 


 

“KYT” の話

Speaker : @actanx93 さん

 

KYT とは?

危険予知訓練 (Kiken Yochi Training) のこと。
労働安全衛生法の中でも実施する事が述べられている。

ある事象に対して「危険の例」と「対策の例」を考えていく。
ex.) http://jafmate.jp/jmp/prediction_of_risks/

 

実際の IT のケースに適用してみる

たとえば「バックアップ」をするために下記のオペレーションを実施することを考える。
どのような危険があるか?

cd ~ftp
mkdir etc
cd etc
cp /etc/group /etc/passwd .

考えられること:

どこで読み書きしてる?
cp コマンドの末尾の “.” を忘れると、 /etc/group で /etc/passwd で上書きする危険性がある
  ..などなど…

では、どうすべきか?
→ 「作業用のディレクトリにまるっとコピーしてから」「全部フルパスで」 etc…

他にも色々と考えられる。
→ “tar cvzf backup.tar.gz *.html” と打とうとして “tar cvzf *.html” と打ってファイルを破壊する
→ “kill –9” と打とうとして “kill 9” と打って PID:9 のプロセスを殺してしまう..

 

危険予知トレーニングの実施の意義

はじめて実施する作業に対して適用し「危険工程」を見つける(嗅覚を磨く)ことで
オペミスやトラブルを少しでも未然に防げるようにする。

「暗黙知」をトレーニングを通して「形式知」に変換し、「共有知」に持って行くことができる。
→ 同時に “手順書” “ドキュメント化” の課程における手助けになる。

「ビギナー」や「若手」に KYT を適用するのも凄く有用。

 


 

続・広く知って欲しい DNS のこと
~DNSの運用をちょっとずつよくしていく話~

Speaker : 中島さん  (DNSOPS.JP)

 

前回までのあらすじ

前回はこちら : https://www.slideshare.net/nakatomoorg/ssmjpdnssecurity

 

今回の内容

DNS やドメインにまつわるちょっと耳寄りの話を通じて、
DNS の運用品質がちょっと良くなる、トラブルを未然に防止できる。

 

DNS とは?

ネットワーク上で名前解決を行うためのプロトコル
SSL 証明書や送信ドメイン認証など、認証の目的としても使われている。

ネームサーバ
ゾーン情報の公開。権威 DNS サーバのこと。  

フルリゾルバ
ネームサーバで公開されている情報をルートからたどって参照できるリゾルバ。
再起問い合わせとキャッシュの機能を持つ。  

スタブリゾルバ
再起問い合わせ機能を持たない。単に名前解決をしたいだけ。
よくあるクライアントOSのDNS設定はこのスタブリゾルバの設定。

レジストラント
登録者(使いたい人)  

レジストラ
登録取次事業者 (レジストラント <—[WEBUI など]—> レジストラント)  

レジストリ
登録管理機関 (レジストラ <—[EPPなど]—> レジストリ)

 

ドメインハイジャックなどの危険から守る技術

・・・ドメインの情報を書き換えられたら、ビジネスにもかなりの影響が出る。
そのため、各種保護する機構が存在する。

「レジストリロック」
→ WHOIS の登録情報変更を制限する。

「レジストラロック」
→ ドメインの移転や削除を制限する機能。

また、各社において多要素認証なども始まっている。

 

ドメインが利用不可になることも。

example)
serverHold (Expire) : ドメイン有効期限切れ。
clientHold : 登録情報不備。無効なメールアドレスをずっと設定し続けた場合など。

ほかにもネガティブキャッシュという存在があり、ちゃんと見ていないとサービスが止まる可能性がある。
「その名前が存在しないこと」をキャッシュするキャッシュ
 JP ccTLD なら 900.  gTLD なら 86400. が TTL として設定されている。

 

DNS は自前で運用する必要ありますか?

熊本地震の際に、ある自治体のウェブサイトが参照不可になった。
→ 権威 DNS サーバ2台が同一サブネット上にあり、2台とも到達出来なくなっていたことがある。
(ref : https://dnsops.jp/event/20160624/h28_kumamoto_earthquake.pdf)

 

DNSSEC, RPKI はできればしっかりと設定したほうがいい。

MyEtherWallet.com の事例は、これらで防げた。

なぜ? : 経路ハイジャックと不正な DNS 応答の合わせ技だったため。
→ どちらか一方だけでも「攻撃成功の難易度」が格段に高まる。

 

余談

「ヒト」「モノ」「カネ」のバランスは重要。
深圳が特に回っている例。

GDPR対応
→ “GDPR Legal Analysis” 参照.

Registration Data Access Protocol (RDAP)
→ Whois に変わるドメイン登録者データへアクセスするプロトコル。
→ GDPR の対応に際し、こちらへの移行が後押しされている。

 


 

DNS トンネリングの手法

Speaker : shutingrzさん

 

DNS トンネリング?

DNS通信に別の目的を持った情報を含めること
偽装通信の一つ。

暗号通信
「どのようなデータが流れているか」を分からないようにする。
データが流れていることに関しては把握されてもよい。

偽装通信
「意味あるデータを送信していることを知られないようにする」こと

 

マルウェアの通信にもよく使われる。

マルウェアは Malicious Ware の通信。
悪意あるソフトの通信、ということで狭義のウイルスということになる。

普通は HTTP が使われる。ほとんどのPCで喋れて、なんだかんだ外に出られるから。
一方、DNS もまた、ほとんどの PC で喋れて、なんだかんだクライアントの通信が外に出られる。
HTTP と同じような属性を持っている一方で
 HTTP 程ちゃんと見ていないことが多いために悪用されてしまう。

 

もちろん、正規の目的として VPN の手法としても使われる。

ソフトイーサ社の VPN で利用されているのが有名。

 

実際にどうやって通信するのか検討してみる。

1. まずは Basic に “TXT” レコード, “QNAME” を用いて通信してみる。
→ 行きは “QNAME” (雑に書けば 「ドメイン名」)
→ 帰りは “TXT” に直接や “A” に符号化した上で入れてみる。

2. EDNS0 や RRSIG といった、DNS クエリのあまり知られてなさそうなとこに押し込んでみる。
→ 「フルリゾルバ」を経由する場合は使えない。でも直接通信できるなら強力。
→ EDNS0 なら仕様に “PADDING” などもあるので隠せる。

 

ではこれを鑑みて、どう対策する?

直接通信させないようにフィルタを掛けるのが第一歩。
なぜ?:フルリゾルバを経由させると下記の利点があるから:

・同じ “qname” と “RR” は TTL秒キャッシュされるのでリアルタイム通信に適さなくなる。
  (DNS の仕様からすると普通ではありますが・・。)

・再起問い合わせに不要なデータは削除される。

上記の理由から “QNAME” をガシガシ変えて頑張るパターンが鉄板となってくる。

また 「人間は何らかの既知の用語を使って名前を付けることが多い」 ことから
辞書との単語距離を取ることで、機械的に生成されたドメイン名を発見できる可能性がある。
(ex. http://blog.trendmicro.co.jp/archives/3799 )

 


 

宣言型デプロイツールの「正しい」考え方

Speaker : tcsh さん

 

やりたいこと「運用自動化」

 

よくある風景

管理職「現場に任せた」
実装者「ノリノリ」「おれすげー」
メンバー「なんとなくすごそう」

そして、実装者が居なくなってしまい、メンバーが気合いでリバースして調べたり・・。

 

宣言型デプロイツールでよくある光景

「宣言型デプロイツール、いいね!」 → 実装者の10割。
「他人から引き続いたけど、宣言型デプロイツールいいね!」という人を見たことがない。

そして、Chef で書いていたものを引継担当者が Ansible で書き直したり・・。

 

こういう人は2つのことを目指すことに陥りがち

「再現性」
→ 「手を動かしたら負け。再現性!再現性!! 全部自動化してやるぜ!!」

「汎用性」
→ 「みんなこのツール使おうぜ!!」

・・・・メンテできない標準ツール、工数掛けた割に汎用性もイマイチ
新規案件で使うのにも手間が掛かる・・・そんなものに2~3年後になっていることが多い。

 

さてどうするか。

もちろんまずは引き継げるように
何をやっているか、どういうモノなのかはちゃんとドキュメント化する

その上で「再現性」「汎用性」のどちらを取る?
「汎用性」は多くの場合「幻」となる。

・範疇が不明な「汎用性」は未定義と同義
・「汎用性の定義」は上手くいかない。
・「汎用性の確保」は上手くいかない。

→ 「再現性は意外と確保できる」 (何かを捨てることで実現できる再現性)

・汎用性を捨てると再現性が高くなる
・多機能を諦めると再現性が高くなる
・変更や追加をやめると再現性が高くなる

 

宣言型デプロイツールのメリット

・再現性を追求して設計すること。
→ シンプルに、小さく。

→ デザインできない場合 UNIX コマンドの設計思想を考えるとイメージ化出来るかも。

 


 

巻末に

今回もとても面白かったです。
次回も同じ会場とのこと。 さて、申し込みますかねぇ・・!