Dendai is Secure?

Dendai is Secure?at “TDU FEN #4” - #TDUFEN

Dendai is Secure? 〜実際にあった脆弱性から仮想的に再現したマシンを攻撃する〜

@nomuken - Nomuken


Agenda

1. 自己紹介

2. 今日話す事の前に

3. CTFを含めた話

4. ターゲットと予備知識

5. ぶっ潰す

6. 解説


1.自己紹介


＿人人人人人人人＿＞　さっき見た　＜￣Y^Y^Y^Y^Y^Y￣


自己紹介

● Twitterは@nomuken● 13なEのC（工学部，情報通信工学科）● 宗派はArchLinuxとvim● コンピュータ初心者● ご注文はうさぎですか？のために生きている● CTFの運営をやりました（TDU CTF）● あとEnlightenedです


2.今日話す事の前に


今日話す事の前に

● あまり表に出せない系の話かもしれないです→実際にあった脆弱性で，結構クリティカルでした

● 今日は実際に攻撃を行います→言わずともがな真似しないでください



● 後でブログにも公開しますが一部非公開にするかもです

● 攻撃じゃなくて対策に目を向けてください→次の話につながりますが気にするべく場所は違います



● 今日は最悪な場合の例です→なので現実では今日ほどうまくいきません→し，大部分は後付で作り話をしています


3.CTFに絡めた話


の前に「TDU CTF 2014 Satellite in ConoHa」の話

● ご参加いただいた方ありがとうございます！

● 大盛況で81名のご参加いただきました

● 非常に大変でした

● まとめはこちらから → https://spica.bz/blog/?p=399


そもそもCTFって何？


CTFとは？

● Capture The Flag の略● セキュリティがメインの一種の競技● 侵入，解析，防衛等がメイン● 特定のキーワードである"flag"を探す● flagは侵入を行ったサーバー内，解析した結果から得られる● 防衛は本戦でのみ（予選参加者分の鯖を立てるのは無理な話）


……つまり

ハッキングを楽しむ競技（？）


対象となるジャンル（知識）

● 非常に多岐にわたっていて常人じゃ無理リバースエンジニアリング，Forensics（解析），Pwnable（脆弱性攻撃），Web（XSSやSQLインジェクション），Network（パケット解析），Miscellaneous（その他）

- Wikipediaより

● なので，基本的にチーム戦として行う


＿人人人人人人＿＞　使い回し　＜￣Y^Y^Y^Y^Y￣


CTF ……は楽しいけど

● なんか最近雰囲気的に大丈夫なのかなぁと心配することが多い

● ツール使って俺つえぇぇと言うおじさん

● CTFじゃないサイトに攻撃するツールを使うおじさん

● CTFを解くことばかり考えて他のことを勉強しないおじさん


CTF ……は楽しいけど

● ちょっと待ってそれでいいの？→それで捕まる事象が出てしまうとCTF界隈が後ろ指刺される→セキュリティ界隈は後ろ指を刺されてしまうことが多い

● CTF……の前に→それ以前を勉強するべきでは？

……→基礎知識，プログラミング→CTFは応用，基本を勉強するべきでは？


ではCTFを何につなげるべき？

● 自分の作るものにつなげるべき→CTFはある意味で脆弱性の例→それを作らないように攻撃を知るべき

● それを周知しよう……→友人を助ける意味でも


閑話休題


で，今回の目的

● 「これくらいの脆弱性大丈夫だよね」を殺す

● 脆弱性はむっちゃ身近に存在することを伝えたい

● ……脆弱性の対策もできれば


ともあれ

● 今日は身近な脆弱性をご紹介します


4.ターゲットと予備知識


本日のターゲット

見せられないよ ><


本日のターゲット

● よくあるウェブサイト

● ファイルのダウンロードページに脆弱性

● 去年の終わりに報告，現在では修正済み


……本題に入る前に

● 攻撃者は何がしたい？


攻撃者の目的（Web関連において）

● サーバーを奪取する→自分の操作を増幅してくれるbotにしたい，bitcoinマイニング

……に使いたい

● 情報を奪いたい……→クレジットカード番号，個人情報，パスワード

● 実力誇示

→これをする実力があると見せつける（過激派組織に多い？）


……目的のために

● こういった残った脆弱性を利用して達成することがある


今回攻撃するサーバに存在する脆弱性

● ディレクトリトラバーサル

● 脆弱なパスワード

● ポート管理の不備

● 設定ミス


ディレクトリトラバーサル

● 本来公開されていないファイルを表示してしまう脆弱性

● 例えば，「/var/www/html」以下しか公開していないのに「/etc/passwd」が読めてしまう

● 親ディレクトリに遡る文字列で，ディレクトリを横断（トラバーサル）してファイルにアクセスできてしまう脆弱性


脆弱なパスワード

● 簡単に想像できてしまう単純なパスワード→User.chino Password.chino

● 初期設定のままのパスワード

→User.pi Password.raspberry

● 流失してしまったパスワード→PSNなど


【余談】パスワードを定期的に変更するべきか

● 専門家の皆様方でも意見が分かれる→定期的に変更することは漏れた後の対策→定期的に変えると覚えられにくくなり簡単なパスワードへ（書ききれない考察が沢山あるが割愛）

● ……パスワードの定期変更より別の対策が必要？→複数回のミスでアカウントロック，2 ……段階認証

● 徳丸さんの記事 http://blog.tokumaru.org/2013/08/2.html

http://blog.tokumaru.org/2013/08/2.html


【余談】パスワードを定期的に変更するべきか

● 本学では教職員のシステムは定期的な変更を強制（要出典）

● 2 ……段階認証をするにも既存のシステムを変更するのは……→コスト的にそれは無理では？

……→なれば，定期変更？うーん

● これだけで30分話せそう？


ポート管理の不備

● 人為的なミスによってポートが空いていた→設定項目の意味がつかめなかった→デバッグ環境のままだった→ファイアウォールの設定をミスった


設定ミス

● httpで，ディレクトリインデックスが見える→「Option Indexes」が設定されている

● sshで，rootログインができる→「PermitRootLogin yes」が設定されている


ともあれ攻撃


5.ぶっ潰す


攻撃対象の仮想マシン

● お世話になっているConoHaに立てました→2C/1GBプラン,CentOS 7のLAMP環境

● みなさんは何もしないでね！

→アドレスは「tdufen.spica.bz」

● あとこの仮想マシンは即削除します→お財布的な関係


やってやるデース



攻撃のシナリオ

1. ディレクトリトラバーサルを発見

2. とりあえずポートスキャン

3. Linuxのユーザリストを取得

4. 攻撃対象の情報を入手する

5. データベースのパスワードが書いてそうなファイルを入手

6. データベースのユーザ名とLinuxのユーザ名が同じ

7. sshでPassword認証を受け付けているので接続

8. シェルを奪取

9. データベースのroot権を入手

10.bash_historyから他のサーバへの接続を入手


ディレクトリトラバーサル

● 「../」という文字列は親ディレクトリに遡る→任意の個数続けて，「/」に達したらよくあるファイルのパスを入れる

● Linuxシステムなら「/etc/passwd」は絶対にあるはず→しかも，全ユーザから参照できないといけないので確実に読める


脆弱なコード


注目するのはここ


readfile関数


readfile関数

● filenameを指定するとそのファイルを出力する

● パスはそのファイルからの相対指定となる

● 今回攻撃で用いた絶対パス「/var/www/html/album/../../../../../etc/passwd」


ポートスキャン

● どのポートでどのサービスが待ち受けているのかを調べる

● 俺達のnmapの出番！！→nmap -O -F tdufen.spica.bz


/etc/passwdを奪う意味

● 大抵は総当り攻撃に非常に役に立ちます

● sshは標準設定だと存在しないユーザでも認証を受け付けます→ので，存在しないユーザで総当りは無駄

● どのユーザが有効なのかが分かれば，そのユーザで無限に認証すればいつかは見つかるはず


【余談】総当り攻撃

● ぶっちゃけ無理かもしれない→各VPS，クラウドサービスではそのようなリクエストがあると遮断するらしい（全てを試せない）

● 短いパスワードを強制しているサービスでは有効→もちろん総当り対策されていないことが前提

● 参考，8文字の大文字小文字の英字と数値によるパスワードの総数

→ 62^8 = 218340105584896


攻撃対象の情報

● 攻撃対象から情報を得ることは極めて重要→バージョンを知れることはとても有用

● 今回はapacheのバージョンとディストリビューションの情報を得ました．


ディストリビューションを調べる

● 大体は「*release」というファイル名に記述されている→サーバでよく使われているのはCentOSと考え，今回はcentos-releaseをチェック

● 「/etc/issue」を見るのも良い→ここにバージョンを書いてあるディストリビューションもある


データベースの情報を入手する

● せっかくなので今回はデータベースの情報も奪った

● データベース接続をしているところにパスワードが平で別ファイルに書いてあることが多い

● データベースの接続を行うと思われるページのソースファイルを見る


データベースの情報を入手する

● 設定ファイルはphpでロードしなくてはいけないので，大抵は読める権限が設定されている


データベースの情報をpasswdと照合する

● 管理を楽にするためユーザ名とパスワードをデータベース，システムと合わせている場合がある


sshでのログインを試みる

● ポートスキャンの結果から22番でsshが待ち受けているのでそこから認証を試みる

● 秘密鍵，公開鍵認証ではないのでパスワードによる認証が可能→やろうと思えば総当りも可能？（設定による）


シェルを奪取

● このサーバは完全に自分の物へ→自分の権限を確認するとsudoが使え権限昇格可能

● ホームディレクトリや「.ssh」，「.bash_history」からユーザの行動を調査


データベースのrootを入手

● 作業用として保存された，パスワードが書いてそうなファイルを覗く

● データベースに関しても全権限を奪取→個人情報を扱っていれば，データを抽出して売ることも可能


内部ネットワークに侵入

● ユーザの行動から外部からだとアクセスできないサーバへのアクセスを行っている部分を発見

● ……サーバを踏み台にもっと多くのサーバを自分の物へ


【ボーナスステージ】対策


脆弱性ってむっちゃ危ない

● 今までの通り1つの攻撃をきっかけにサーバを奪取出来てしまう可能性がある

……→（もちろんそうなるように環境を作ったのですが）

● 開発者としては脆弱性を作らない開発をしていこう！


脆弱性の対策

● Webに関して言えばエスケープが重要なキーワード

● 危険な文字列を無毒化をし安全なWebアプリケーション開発を！→"無毒化"は不適切 ……という言葉もありますが→その文字自体は毒ではないし，毒のように感じる開発者の設

……計が悪いとも？


エスケープ

● 例えば，「../」が今回は危険な文字列ですね…→ぶっちゃけ，このような作りをするべきではないのですが

● これを置換したり（不完全），そもそもfilepathをGETに入れない設計したり，dir ……の設定を変えたり（強制したり）


……もっと，書きたいけど

● 時間がない（本当に申し訳ない）


まとめ

● 脆弱性を軽く見たやつ滅んでしまえ

● 開発者の人は，脆弱性の少ないWebアプリ開発を！……→そして作ってしまった場合は速やかに修正を

Technology

Dendai is Secure?