自分なりの判断基準を持つということ

エリートな雰囲気の方々が再現性のない成功に意味はないみたいなことを言ってるのを何度か見たことがあります。再現性をどうやって見出すのかという話。

この「再現性が大事！！」という話を聞くと、「ふむふむ、つまりちゃんと振り返りをしようぜということか〜」と挑戦した事後に再現性を見出そうとするのをイメージしちゃうんですが、エリートな雰囲気の方々が言う、再現性の見出し方って逆なんじゃないかという気がします。

自分の失敗談なのですが、最近資格試験に落ちました。本気で取りにいった資格試験に落ちたのが人生で初めてで結構ショッキングだったのですが、落ちたものは仕方がないとどうにか踏ん切りをつけて試験期間と試験の振り返りをしました。

ところがどっこい、なんで試験に落ちたんだろう。をいくら自分に問いかけても「あの問題の解き方を知らなかったから」とか「緊張してたから。」とかみたいな「再現性と呼ぶには具体的すぎる解けなかった原因」しか思いつきませんでした。結果の後から再現性を見つけようとすると、細々としたいろんなファクターが頭に浮かぶせいで最も重要なファクターを見逃してしまう気がします。

それでもなんとか反省をしなければ、と頭を捻りまくったところ「問題に対して試したことを整理できていなかった」という少し抽象的な反省点も見つかりました。ただこれを試そうとしたわけではないので、仮説の域をどうしても抜けれませんでした。

というわけで、何かに取り組む前に試すことを決めようというわけです。 試すことを決めるのも結構難しいので、それもまたいつか自分の考えをお話ししようと思います。

【Go言語】特定のメソッドを持っているかどうかチェックする。

以下のようにチェックできます。

package main

import (
    "fmt"
)

type Animal interface {
    Eat()
}

type Human struct {
    Name string
}

func (h *Human) Eat() {
    fmt.Println("eating!!")
}

func (h *Human) Hello(){
    fmt.Printf("Hello, %v", h.Name)
}

//存在チェックしたいメソッドを持つインターフェースを定義
type Hello interface {
    Hello()
}

func check(animal Animal)bool {
    if _, ok := animal.(Hello); ok {
        return true
    }
    return false
}


func main() {
    h := &Human{Name: "bob"}
    if check(h) {
        fmt.Println("Human has Hello() method.")
    }
}

play.golang.org

.htaccessファイルを使ったファイルアップロード攻撃

始めに

ファイルアップロードによりweb上で任意のスクリプト実行に至る攻撃手法を紹介します。.htaccessファイルとはApacheで利用できる、ディレクトリ単位でwebサーバの設定をするための設定ファイルのことです。.htaccessを用いたファイルアップロード攻撃は次の要素が揃うと成立します。

  • Apacheを利用している。
  • アップロードしたファイルにアクセスできる。
  • アップロードしたファイルの種類チェックが不十分である。

また、この攻撃はスクリプトを実行できる拡張子(.php, .py等)がブラックリスト形式でブロックされている場面で役にたつと思われます。

攻撃手法

設定ファイルhttpd.confでAllowOverrideディレクティブがALLと設定されている場合.htaccessファイルを用いた設定が制限なく行えます。このAllowOverrideディレクティブは2021/07/17現在CurrentとなっているApache version2.4では、デフォルトでALLとなっています。

ファイルアップロード機能を使い、.htaccessファイルをアップロードすることで、.htaccessファイルが保存されるディレクトリの設定を書き換えてしまうことができます。

【攻撃手順】
1. 次のような.htaccessをアップロードし、アップロード先のディレクトリの設定を変更します。この設定により拡張子.yarikomiはphpの実行ファイルとして認識されるようになります。

AddType application/x-httpd-php .yarikomi

設定上アップロードしたファイルは/files/username/filenameというパスでアクセス可能とします。
2. 悪意のあるスクリプトrce.yarikomiをアップロードします。

<?php system($_GET['cmd']);?>

3. 悪意のあるスクリプトにアクセスすることで任意のコマンドを実行することができます。

$ curl http://vulnsite.com/files/attacker/script.yarikomi?cmd=ls

その他の攻撃手法

.htaccessを用いた攻撃手法は上記のようなAddTypeディレクティブを用いた方法以外にも複数存在します。

php_valueディレクティブを用いた攻撃手法

php_valueディレクティブを用いると、ChangeableがPHP_INI_PERDIRな項目を設定できます。 任意のスクリプトを実行するためにauto_prepend_fileまたはauto_append_fileの設定を利用することができます。

# .htaccessの設定例
AddType application/x-httpd-php .yarikomi
php_value auto_append_file /path/to/script.yarikomi

【攻撃手順】
1. 上記のような.htaccessをアップロードします。
2. 悪意のあるスクリプトscript.yarikomiをアップロードします。 3. エントリーポイントとなるentory_point.yarikomiをアップロードします。(auto_append_fileで設定したscript.yarikomiを実行させるために利用しているので中身はなんでも大丈夫です。)
4. entory_point.yarikomiにアクセスして,script.yarikomiを実行します。

AddHandlerディレクティブを用いた攻撃手法

# .htaccessの設定例
AddHandler php5-script .php

上記のような設定をした.htaccessを用いることで.phpという文字列の入ったファイルはphpの実行ファイルとして認識されるようになります。(このあたりもしかしたら嘘かもしれないです...)

参考資料

Insomnihack Teaser 2019 / l33t-hoster
How File Upload Forms are Used by Online Attackers

個人的CSRFを見つけるためのtips

CSRFは他の脆弱性に比べて対策が容易にできる。そのためCSRFを見つけるのも割と簡単である。
脆弱性があるかどうかは、CSRF対策がなされているかを確認すればいい。(基本的には)
CSRF対策がなければ脆弱という判断ができるので、判断するためにCSRFの対策方法を知る必要がある。

CSRFの対策方法

CSRFの対策の目的は、webアプリが正規のユーザによる捏造されていないHTTPリクエストのみ受付ける仕組みを提供すること。
具体的な対策方法には、
1. ワンタイムトークン(CSRFトークン)の利用
2. リクエスト送信前にパスワードを入力させる
3. Refererヘッダーの検証

などがある。 一番ワンタイムトークンの利用が一般的だと思われる。
他の記事や書籍で丁寧に解説されているものを見ていたただければ対策の詳細がわかるので気になる方はそちらをどうぞ。

基本的なCSRFの見つけ方

具体的にCSRFを見つけるための手順をご紹介。

1.CSRFが起こりうるフォームを特定する

webアプリを探索して重要な処理を行っているフォームを確認する。チェックする場所としては、 ログインフォーム、ログアウトフォーム、パスワード変更フォーム、決済フォームなど。
他者に実行されたら困るようなフォームを探せばいい。

2.CSRF対策がされているかを確認する

まずはCSRFトークンがあるか、リクエスト送信前にパスワードを入力する画面があるかを確認する。

tipsの紹介

  • CSRFトークンを消してリクエストを送信してみる。
    CSRFトークンがあるだけ処理されてないことがあるかもしれないので確認してみる。
  • CSRFトークンの値を変更してリクエストを送信してみる。
    CSRFトークンの検証の実装が不適切な可能性があるため確認してみる。
  • CSRF対策はないが、bodyにjsonを利用したリクエストがある場合
    ぶっちゃけ記事ここだけでよかった気がしてる。 重要な処理を行うリクエストにjsonを使うとContent-Typeヘッダーにapplication/jsonを指定する必要があるため、Same Origin Policyによって異なるオリジンからのリクエストが拒否される。
    そのため"原理上は"CSRFができない。
    しかし、
    Content-Typeがapplication/jsonでなくてもbodyがjson形式であれば,サーバ側のフレームワークが自動でjsonにパースしてくれることがよくある.
    Content-typeをシンプルリクエストに沿ってContent-Typeをtext/plain, application/x-www-form-urlencoded, multipart-/form-dataのいずれかに変更したリクエストを送れば、Same Origin PolicyをバイパスしてCSRFができる。

2020年振り返り

前書き

2020年振り返ります

出来るようになったこと

基本的にIT技術関連について。

2019年にプログラミング学習を開始しました。

f:id:taisec:20210101095915j:plain
去年の秋
まだまだ未熟ですが初学者だっただけに学んだことも多かったように感じます。

1~3月

  • 初めてプログラミングバイトをさせてもらった
  • 初めて自分でwebアプリを作った

    感想

    全てが新しいことだったので学ぶのが大変でした(汗)。この時利用してた言語はKotlinです。自分で実装してみて初めてこんな感じの図の意味がわかるようになりました。

    f:id:taisec:20210101102643p:plain
    こんな感じの図

4~6月

  • 基本情報レベルの知識の定着
  • CTF始めた
  • OWASP 仙台に行ってみた

感想

元々基本情報技術者試験は合格していたのですが、定着していないところも多かったので学び直しました。これが結構良かったように思います。
プログラミングを始めた頃からなんとなく情報セキュリティを学びたいなぁと思っていたのでCTFにもチャレンジしてみました。全く解けずにwrite up を読んでもどかしい気持ちになる毎日でしたね。。。OWASP 仙台はお世話になってる方が紹介してくれて行きました。あの頃の僕にはレベル高すぎてついていけなかったです。

7~9月

感想

バイトが忙しくて特別何かしたわけではなかったです。

10~12月

  • CTFに出まくった
  • Golangをちゃんと勉強した
  • pwnable.krをやりまくる

感想

ctfがeasy問であれば解けるようになってきました。secconの学生向けctfチャレンジで上位15%くらいに入れたのも良かったです。
pwnを始めたのもこの時期です。buffer overflow, ret2lib, GOT overwritte, ROP, one gadlet rce, use after freeあたりを学びました。演習が足りないのは感じているので精進します。

反省

こうやって振り返ってみるといろいろ学んだけど実績が伴ってないなと感じます。来年は継続した学びをしながら実績を積んでいきたいと思います。

おまけ

技術関係なく学んだことについて

学び

1. 足を動かすということ

足を動かす=興味のある分野のイベントやコミュニティに参加すること。 足を動かしてから、人生を180°どころか540°変える出会いがありました。
助けてくれる方、応援してくれる方、憧れのあの人、良き友人などいい出会いがたくさんあった年でした。そんなわけで来年も足を動かします。世界が広がるので。

2. 自律

僕は素晴らしい出会いがたくさんありました。その結果僕はコミュニティ(や個人)に依存してしまいました。自分の人生を自分の足で進む感覚を忘れないようにするために自律する必要がありました。自律とは責任を持つことなのかなぁと思ってます。怒られたくない、嫌われたくないといった感情に流されてしまったせいで自分の選択に責任を持ってませんでした。 怒られても、嫌われても自分の選択だと割り切れてからはかなり生きやすくなりました。

バイトで学んだこと

職場でも素晴らしいことをたくさん学びました。 忘れないように残しておきます。

  • 質問に定量的に答える
  • 評価できる目標を立てる
  • 理解してから手を動かす

後書き

一年の振り返りを記録するのは初めての試みでした。 拙い文章ですが読んでくれた方、ありがとうございます。
学びの多い一年だっただけにこの記事が5年後,10年後の僕や読んでくれた誰かの役に立つものでありますように。