かさやぬすの日記

後で思い出したいことを書く

【ハッキングの気持ち】パスワード"AAAAAAAAAAAAAAAAAAAAAAAAAAAAA"でログインする

こんにちは!まさです

今回はプログラムのIF文を不正にパスするハッキングの方法を紹介したいと思います。
この方法を使ってIF文をパスできてしまうと、不正な文字列でのログインや、Linuxなどの場合、管理者権限を奪われてしまうという恐ろしい危険性が
あります。
そんな攻撃の中でも最も簡単な方法を紹介したいと思います。

今回攻撃するのは"auth_overflow"というプログラムです。
(下にC言語のコードを載せています)
このプログラムは、ユーザが入力した文字列が、あらかじめ決まったパスワードと一致しているか判定し、その結果を出力するというものです。
今回は"brillig"または"outgrabe"という文字列が入力されるとパスするようにしています。




★ auth_overflowの挙動

1. gccを使ってauth_overflow.cをコンパイルし、実行ファイル(a.out)を作ります。
今回はオプションで"-fno-stack-protector"を付け加えます。
このオプションは、"メモリへの不正な上書きを許す"という意味だと思ってください。

gcc auth_overflow.c -fno-stack-protector

2. パスワード以外の文字列を入力するとアクセス拒否します。
f:id:kasayanus:20180712170650p:plain



3. パスワード文字列を入力するとアクセス許可されます。
f:id:kasayanus:20180712170701p:plain


このプログラムの動きはこれだけです。


以下は"auth_overflow.c"のソースコードです。

#include <stdio.h> 
#include <stdlib.h> 
#include <string.h>

int check_authentication(char *password) { 
   char password_buffer[16];
   int auth_flag = 0; 

   strcpy(password_buffer, password);

   if(strcmp(password_buffer, "brillig") == 0) 
      auth_flag = 1;
   if(strcmp(password_buffer, "outgrabe") == 0) 
      auth_flag = 1;

   return auth_flag;
}

int main(int argc, char *argv[]) { 
   if(argc < 2) {
      printf("使用方法: %s <パスワード>\n", argv[0]); 
      exit(0);
   }
   if(check_authentication(argv[1])) {
      printf("\n-=-=-=-=-=-=-=-=-=-=-=-=-=-\n"); 
      printf("   アクセスを許可します。\n"); 
      printf("-=-=-=-=-=-=-=-=-=-=-=-=-=-\n");
   } else { 
      printf("\nアクセスを拒否しました。\n");
   }
}



さて、ここでパスワードとは全く異なる文字列"AAAAAAAAAAAAAAAAAAAAAAAAAAAAA"(A×29回)を入力したらどうなるでしょうか?
その結果は...
f:id:kasayanus:20180712170928p:plain


”アクセスを許可してしまいました!”


プログラムのソースコードにはもちろんこのような文字列での分岐は想定されていません。
ではなぜこの文字列でパスしてしまうのでしょうか。

その秘密はバッファーオーバーフロー攻撃という、有名な攻撃手法にあります。

このプログラムで起きたことを説明します。

このプログラムでは"password_buffer[16]"という配列にユーザーからの入力文字列を格納します。
しかし、ここに29文字のAを格納しようとすると、溢れてしまった13文字はpassword_bufferのすぐ隣のメモリ領域に"無理矢理"格納されてしまいます。
これがバッファーオーバーフローです。
その結果、運の悪いことに、その隣にあった変数"auth_flag"のメモリ領域が、"A"という文字(16進数で41)で上書きされてしまったというわけです。
c言語では0以外の数はTrueとみなされるので、その結果アクセスを許可してしまったというわけです。
41という文字がAを意味しています。


ここでは長くなるので触れませんが、実際にデバッグツールgdbを使うとpassword_bufferからバッファーオーバーフローが起きている様子を確認することができます。
下の写真では、auth_flagのアドレス”0x7fffffffdbec”を見事なまでに"A"が侵食していることがわかります。

f:id:kasayanus:20180712173158p:plain



いかがでしたでしょうか。

気づいた方もいるかもしれませんが、この攻撃はpassword_bufferのメモリアドレスの”後ろ”にauth_flagのメモリアドレスがあったからこそ成功していました。

では逆の位置関係の場合どうなるでしょうか。

ソースコードでこの2つの変数宣言の順番を変えれば、メモリアドレスの位置関係を逆にすることができます。

この場合同様の攻撃は通用しません。

しかし、攻撃の仕方を変えると、実は不正な文字列でパスすることが可能です!
この場合は少し話が複雑になります。
アセンブリやスタックセグメント、インストラクションポインタの仕組みを理解すると、攻撃可能になります。
具体的には、auth_flagを汚染するのではなく、スタックフレームの戻りアドレスを汚染することで可能となります。

また機会があれば書きたいと思います。






たったの30行でYouTubeの動画を簡単ダウンロード!【Python】

pythonは僕が好きなプログラミング言語の一つです。
その魅力はそれなりに使えるスクリプトを自分で簡単にかけることだと思います。

自分はよくYoutubeを利用するので、好きな動画や曲を簡単にダウンロードできたらいいなぁ
ということで、youtubeの動画ダウンロード用スクリプトを昔作りました。

すでにオンラインサービスやCravingExplorerなどでyoutubeの動画をダウンロードできる既存のアプリは
存在するのですが、自分で書いたスクリプトなので愛着もあり、
このスクリプトを今でも愛用しています。

以下簡単に使い方を説明します。


1. python3コマンドでこのスクリプトを起動します。

python3 download.py


2. 起動したら下の画像のようにURLを聞かれるので落としたい動画のURLを入力してENTERします。


      f:id:kasayanus:20180705001036p:plain


3.  数秒後、スクリプトと同じディレクトリにmp4とmp3のファイルが保存されます。

    f:id:kasayanus:20180705001230p:plain




下のコードが今回紹介したdownload.pyです。
(このスクリプトではダウンロードしたmp4をmp3に変換するためにfffmpegを併用しています)

みていただければわかるように非常に短いコードで、簡単に
使える実用的なスクリプトが作れます。
pythonは学習コストも低く初心者でも勉強しやすいことで知られています。
新しいフレームワークやライブラリのインストールもコマンド一つで簡単にでき、知っているととても便利な言語だと思います!

import pytube
import subprocess
import os
import sys

while(True):
 input_text=input("URL or EXIT:")

 if(input_text=="exit"):
  sys.exit()
 else:
  yt = pytube.YouTube(input_text)
   if(yt==None):
    print("invalid URL")
   else:
    vids= yt.streams.all()
    parent_dir = r""
    vids[0].download(parent_dir)
    default_filename = vids[0].default_filename 
    new_filename = default_filename+".mp3"
    subprocess.call(['ffmpeg', '-i', 
			    os.path.join(parent_dir, default_filename),
			    os.path.join(parent_dir, new_filename)
			])

    print('done')

"はじめてのハッカソン"に参加してきました

今日は六本木一丁目の泉ガーデンというコワーキングスペースハッカソンのイベントに参加しました。

4〜6人のグループを4つ作りそれぞれのグループがアイデアを出し合って、一からWebサービスを開発するというものでした。

率直に言えば自分は今まで共同開発の経験がなかったので、未熟さを感じました。

それは技術力の未熟さでもあるし、自分の考えていることをうまく言葉で伝えられないという情報伝達力(コミュ力)の未熟さでもありました。

自分はRailsでサーバプログラムを担当しましたが、他のメンバーの方が作ったHTMLやCSSJavascriptクラウドサーバとのマージ作業がうまく行かず当初予定していたようになかなか開発が進みませんでした。

結論としては、今回のハッカソンでは、ハッカソンのもつハッカソンが大好きな人たちの感じるハッカソンの”本当の楽しさ”には達しなかったんじゃないかな、と思いました。

あくまで想像ですが、ハッカソンの本当の楽しさというのは、それぞれが作った部品を結合させていきプロトタイプを作り上げて、そこからさまざまな実現可能な拡張機能をメンバー全員で検討していき、それを再びプロトタイプの上に乗っけて、どんどんサービスの規模を広げていくこと、これがハッカソンの楽しさなんじゃないかな、と思いました。

今回のハッカソンではこの段階まで行かなかったのがとても残念でした。

また、今回のハッカソンで得た気づきというのがあります。

それは深く狭く型の学習の重要性です。

自分はウェブプログラミングを始めてまだ日が浅いので、とにかくいろんなフレームワークやウェブ技術を"広く浅く"学習していくという方針で今まで学習を勧めていました。そうすることで、例えばなにかネット上記事を読んでいたり、人との会話で出てきたウェブ技術に対して知らないよりは少しでも知っていたほうが飲み込みやすくなると思ったからです。しかし、それはサービスを作り上げる上ではあまりよくない勉強法だというふうに気づきました。一つの技術をもっと深く勉強していくことの必要性を今回のハッカソンで感じました。

なにはともあれ。今回のハッカソンは自分の技術力をはじめて客観的に見ることができたいい機会でした。

参加した皆さんありがとうございました!

めちゃくちゃ疲れて眠いのでこのへんで終わります。