Nature Remo + AWS Lambda + Mackerel で室温を記録してみた

暑くなってきたのでスマートホーム化していきたいなと思い、ひとまずNature RemoのAPIで遊んでみるか〜と、Nature Remo + AWS Lambda + Mackerel で室温を記録していくようにしてみたところ、以下のようなグラフになった。

冷房をかけたときに温度が下がったところ以外は常時27.4度前後で遷移していて、あまり変化がなくおもしろくはないグラフになったが、日中暑いときも全く室温に影響なくて、「鉄筋コンクリート造はさすがだなー！」と思った。 Nature Remoから室温を取得しMackerelにPOSTする関数を、Lambdaにアップロードし、CloudWatch Eventsをトリガーに10分毎に実行している。

コードは以下のようになった。Nature RemoとMackerelにはあんまりいいかんじのAPIクライアントがなさそうだったので、requestsライブラリを使ってがんばってAPIを叩いている。APIトークンは環境変数として出してあるので、コードを貼っても安心。

github.com

#!/usr/bin/env python3.7
# coding: UTF-8

import datetime
import json
import os
import requests

def get_room_temperature():
    headers = {
        'accept': 'application/json',
        'Authorization': 'Bearer ' + os.environ['REMOTOKEN'],
    }

    response = requests.get('https://api.nature.global/1/devices', headers=headers)
    json = response.json()
    return json[0]['newest_events']['te']['val']

def post_service_metrics(temperature):
    headers = {
        'accept': 'application/json',
        'Content-Type': 'application/json',
        'X-Api-Key': os.environ['MACKERELKEY'],
    }

    now = datetime.datetime.now()
    metrics = [
        {
            'name': 'Temperature.temperature',
            'time': int(now.timestamp()),
            'value': temperature
        }
    ]

    json.dumps(metrics),
    response = requests.post('https://api.mackerelio.com/api/v0/services/nature-remo/tsdb', json.dumps(metrics), headers=headers)
    print(response.json())
    
def lambda_handler(event, context):
    temperature = get_room_temperature()
    post_service_metrics(temperature)

AWS Lambda上で動かす関数で外部ライブラリを使っていた場合、そのライブラリもzipで固めてアップロードしないといけないので少しめんどう。先人のように、Goでやったほうがシングルバイナリになって、アップロードは楽そう。

$ mkdir packages
$ cd packages/
$ pip install requests -t .
$ zip -r9 ../function.zip .
$ zip -g function.zip lambda_function.py

AWS Lambda触ったことなかったので、いい機会になってよかった。1か月に100万件のリクエストまで無料で、今回みたいな10分に1回リクエストを飛ばすくらいだと無料で使えるので、スマートホーム化していくに当たってバンバン活用していきたい。

globalのgitignoreの設定をdotfilesでやるようにした

新しいPCにglobalのgitignoreを入れ忘れてたからdotfilesの中でやるようにした。

github.com

以下のシェルスクリプトで、github/gitignoreからダウンロードしてきたgitignoreを~/.gitignoreに設置している。

  if [ "$(uname)" = 'Darwin' ]; then
    curl -fL 'https://raw.githubusercontent.com/github/gitignore/master/Global/macOS.gitignore' >> ~/.gitignore 
  else
    curl -fL 'https://raw.githubusercontent.com/github/gitignore/master/Global/Linux.gitignore' >> ~/.gitignore
  fi

  echo '' >> ~/.gitignore
  echo '# VisualStudioCode' >> ~/.gitignore
  curl -fL 'https://raw.githubusercontent.com/github/gitignore/master/Global/VisualStudioCode.gitignore' >> ~/.gitignore
  echo '' >> ~/.gitignore
  echo '# Vim' >> ~/.gitignore
  curl -fL 'https://raw.githubusercontent.com/github/gitignore/master/Global/Vim.gitignore' >> ~/.gitignore

Xcode Command Line ToolsやHomebrewのインストール、Homebrewやcaskで入るツールのインストールもdotfilesの初期設定スクリプトでやるようにしていて、それぞれをセットアップするかどうかを尋ねてくれるようにしている。便利！

$ git clone https://github.com/tkmru/dotfiles.git
$ cd dotfiles
$ ./init.sh 
Do you setup global .gitignore? [y/N]
y
...
Do you setup Xcode Command Line Tools? [y/N]
y
xcode-select: note: install requested for command line developer tools
Do you setup Homebrew? [y/N]
y
Do you setup some tools by Homebrew and Homebrew cask? [y/N]
y
...

dotfilesの配置にはMitamaeを使っている。これはプロビジョニングツールのitamaeのmruby実装で、シングルバイナリで動作するため、rubyの環境を整えることなく使えるところが便利。

tkmr.hatenablog.com

GhidraのScriptまわりについて

はじめに

先日、NSAがリバースエンジニアリングツールのGhidraを公開した。 OSSであることや、Hex-rays社が高価で販売しているようなデコンパイラがついていることから注目されている。 SREを「Site Reliability Engineering」ではなく「Software Reverse Engineering」としてSRE frameworkを標榜しているのもかっこいい！！！！！

IDAでいうIDAPythonのように、GhidraでもJavaやJythonとしてのPythonで解析に役立つScriptを動かすことができる。 docs/GhidraAPI_javadoc.zipにAPIリファレンスがあり、それらのAPIを扱える。 この記事では、そんなGhidraのScriptまわりを見ていこうと思う。

Pythonインタプリタ

CodeBrowserのツールバーのWindow->PythonよりPythonインタプリタを起動できる。 APIの挙動をシュッと確認できて便利。

上では、currentProgram.getName()でバイナリのファイル名を取得し、 askString()でポップアップを出し、ユーザーからの入力を受け取っている。

Script Manager

Code Browser上の再生ボタンのような▷のボタンを押すとScript Managerが開かれる。

ダウンロードしてきたScriptを読み込むにはScript Directoriesのボタンを押して、Scriptがあるディレクトリを追加してあげるとよさそう。

Create New Scriptボタンを選択するとScript Managerの右側に簡易的なエディタが出現する。 Script Manager上でコードを書けるので便利そう。 ここで作成したScriptはデフォルトでは~/ghidra_scriptsに保存される。

参考になりそうなScript

Ghidra/Features/以下にJavaやPythonのScriptがたくさん置かれている。

Script Mangerを開くとExamplesというディレクトリがあり、ここにあるScriptを読んでいくとチュートリアル代わりになりそう。

ExamplesというディレクトリがあるかのようにUI上では表示されるが、これはカテゴリのようなもののようで、実際には全然違うディレクトリにあるので注意。

$ find . -name ghidra_basics.py
./Ghidra/Features/Python/ghidra_scripts/ghidra_basics.py

便利そうなScript

ghidraninja/ghidra_scriptsというghidraのscriptがいくつか置かれたリポジトリがある。早い。

github.com

binwalkを走らせて見つけたアドレスをBookmarkに登録するbinwalk.pyや、暗号に使われる定数を見つけるyara.py、 swiftの関数名をdemangleしてくれるswift_demangler.py、stripped Go binaryにシンボルをつけ直すgolang_renamer.pyがあり便利そう。

Nginxのalias traversalについて

Nginxのalias traversalとは

Nginxではaliasディレクティブを使って locationディレクティブで指定したURIのパスをファイルシステム上のパスに対応させることができます。 以下の例のようにconfigを書くと、/var/www/app/static/以下にあるファイルに/static/ファイル名のようなパスでアクセスできます。

location /static {
    alias /var/www/app/static/;
}

しかし、このようにlocationのパスの末尾が/で終わっていない場合、..を使うことで、開発者が意図していない上位のディレクトリへのアクセスが可能になってしまいます。 このケースだと、/static../setting.pyのようにパスを指定することで、aliasで指定したディレクトリより上位のディレクトリである/var/www/app以下のsetting.pyにアクセスすることができます。これがNginxのalias traversalです。

以下のようにlocationで指定するパスの末尾に/を書いておくことで防ぐことができます。

location /static/ {
    alias /var/www/app/static/;
}

Nginxは、alias traversalを脆弱性として扱っておらず、Nginx側で修正されることはありません。

初出は2016年のHCTFの問題のようです。 http://momomoxiaoxi.com/2016/11/29/HCTF2016/#10%E4%BD%A0%E6%B2%A1%E8%B5%B0%E8%BF%87%E7%9A%84%E5%A5%97%E8%B7%AF

ぼくはCODEBLUE 2018でorangeさんのBreaking Parser Logic - Take Your Path Normalization Off and Pop 0days Outを聞いて知りました。 ちなみに、この発表はDEFCON26やBlack Hat 2018やHack.lu 2018でも行われています。ぼくもつよいexploit手法を見つけたら海外カンファレンス巡業したい。

実例

hackeroneでは以下のようなものが見つかっていました。

• #312510 [mobs.mail.ru] nginx path traversal via misconfigured alias
• #317201 [vulners.com] nginx alias_traversal

やってみる

alias traversalの問題があるNginxサーバーを立てることができるDockerfileを書きました。

github.com

このリポジトリは以下のファイルから構成されています。

nginx-alias-traversal-sample$ tree .
.
├── Dockerfile
├── LICENSE.md
├── README.md
├── index.html
├── screenshots
│   ├── flag.png
│   └── top.png
└── vulnerable.conf

1 directory, 7 files

$ docker build -t nginx-traversal .
$ docker run -d -p 3000:80 nginx-traversal:latest

上のコマンドでdocker runすると、http://localhost:3000でNginxサーバーが動きます。

http://localhost:3000/static/がalias traversal可能なパスになっています。

alias traversalを利用して、aliasで指定されたディレクトリの一つ上の階層にあるflagを読み出すことができました。

発見するのに使えるツール

Nginxのconfigにアクセスすることができる開発者側であれば、 gixyというNginxのconfigの静的解析ツールを使って、alias traversalを検出することができます。

github.com

$ gixy vulnerable.conf 

==================== Results ===================

>> Problem: [alias_traversal] Path traversal via misconfigured alias.
Description: Using alias in a prefixed location that doesn't ends with directory separator could lead to path traversal vulnerability. 
Additional info: https://github.com/yandex/gixy/blob/master/docs/en/plugins/aliastraversal.md
Pseudo config:

server {
    server_name localhost;

    location /static {
        alias /var/www/app/static/;
    }
}

==================== Summary ===================
Total issues:
    Unspecified: 0
    Low: 0
    Medium: 0
    High: 1

また、脆弱性を発見するペンテスターはBurpの拡張を使って検出することができます。

github.com

自分向けDockerコマンドのメモ

Dockerは便利だけど、ぼくにとっては普段そんなに使うツールではなくて、よくコマンドを忘れてしまう。 覚えられるように、すぐ見返せるように、メモしておく。

Dockerイメージに関するコマンド

一覧

$ docker images

ビルド

直下にあるDockerFileからビルド。

$ docker build ./ -t example

削除

イメージIDを指定して削除。複数のイメージIDを指定できる。

$ docker rmi IMAGE-ID IMAGE-ID IMAGE-ID

すべてのイメージを削除

$ docker rmi -f $(docker images -q)

Dockerコンテナに関するコマンド

一覧

$ docker ps -a

ビルド

イメージからコンテナをビルド。 -tは、Dockerコンテナ内の標準出力とホスト側の出力をつなげるオプション。-iは逆にホスト側の入力とコンテナの標準入力をつなげるオプション。

$ docker run -it IMAGE-ID /bin/bash

-pは外部からアクセスされるポート番号:コンテナ側のポート番号を指定し、ポートフォワーディングするオプション。 -dはデーモンとしてバックグラウンドで実行するオプション。

$ docker run -d -p 3000:80 IMAGE-ID

コンテナの中に入る

起動済みのコンテナの中に入る。ビルドする際との違いはrunがexecになって、イメージIDがコンテナIDになっている点。

$ docker exec -it CONTAINER-ID /bin/bash

停止

コンテナIDを指定して停止。

$ docker stop CONTAINER-ID

再開

コンテナIDを指定して再開。

$ docker start CONTAINER-ID

削除

コンテナIDを指定して削除。複数のコンテナIDを指定できる。

$ docker rm CONTAINER-ID CONTAINER-ID CONTAINER-ID

停止しているコンテナをすべて削除。

$ docker container prune

状態に関わらず、すべてのコンテナを削除。

$ docker rm -f $(docker ps -aq)

その他Tips

no Space Left on Deviceの対処法

空き容量不足によるエラー。単純にディスクが不足している以外に、Dockerに割り当てられている仮想ディスクの容量不足が原因のことがある。 不要なイメージやコンテナを消すか、仮想ディスクの容量を増やしてあげると解決する。

blog.kasei-san.com

ISUCONがきっかけでSinatraにコントリビュートした話

ISUCON8の予選へ向けてSinatraで作られたwebアプリケーションを高速化する方法を模索する最中、 ErubisというERBテンプレートエンジンが使われているコードを見かけました。 これがきっかけでより高速なeRubyテンプレートエンジンであるErubiをサポートするためのコードをSinatraにコミットしました。この記事ではその詳細について説明したいと思います。

ISUCONというのはお題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです。

isucon.net

ErubisとErubi

eRubyのテンプレートエンジンはRubyの標準ライブラリのERB以外にも存在し、ErubisとErubiといったものがあります。 ErubisはERBより高速に動作し、Rails 5.0.xまではデフォルトのeRubyテンプレートエンジンとして使われていましたが、2011年ごろからメンテされていませんでした。 ErubiはErubisより高速に動作し、現在もメンテされています。

github.com

Railsでは5.1からデフォルトのeRubyテンプレートエンジンがErubisからErubiに変更されました。 github.com

どんなコードをコミットしたのか

Erubiを動作させるためのコードをごりごり書くつもりだったのですが、 Sinatraの内部で使われているTiltという複数のeRubyテンプレートエンジンへのインターフェースを提供するライブラリが 既にErubiに対応済みでした。

github.com

これによって、 SinatraのREADMEではErubiを使えると書かれていないものの、すでにErubiを使用可能であるという状況になっていました。 というわけでテストコードとドキュメントの修正を行いました。 最終的にマージされたプルリクエストはこれです。

github.com

結果として、テストコードとドキュメントの修正しかすることがなかったですが、SinatraがErubiをサポートしていることが明確になってよかったと思います。今年のISUCON9からはErubiを使えますね！！！

IDAの便利プラグイン3選！！！

これはセキュリティツール系 Advent Calendar 2018 の25日目の記事です。

この記事では便利なIDAのプラグインを3つ紹介したいと思います。

findCrypt

findCryptは暗号に使われる定数をgrepすることで、どんな暗号が使われているか判別するIDAプラグインです。

github.com

使い方

IDAにバイナリを読み込ませた状態で、メニューバーのFile->Script file...からfindcrypt.pyを実行することで使えます。 実行すると以下のようにOutput windowにスキャンの結果が出力されます。以下の例ではRijndaelで用いられている定数が見つかっていますね。

Output windowに出力されたfindCryptによるスキャンの結果

また、見つけた定数に名前をつけてくれるので、ディスアセンブル結果が表示されているIDA View-A上からも定数を確認しやすいです。

findCryptによって発見されたRijndaelの定数

シュッと用いられている暗号がわかって便利ですね。定数を使わないようにカスタムされた暗号が用いられている場合はこのプラグインでは見つけられないので、自力でがんばる必要があります。

LazyIDA

LazyIDAはMake your IDA Lazy!を目指しているプラグインです。 いくつか機能がありますが、データをC/C++の配列やPythonのlistに変換してくれる機能が便利です。

github.com

使い方

IDAのpluginsディレクトリ以下にLazyIDA.pyを配置すると使えるようになります。 IDAの画面上で左クリックすると、Convertというメニューが追加されていると思います。ここから好きなフォーマットを選択し変換することができます。

ここでは、先ほどfindCryptで見つけたRijndaelの定数をLazyIDAでPythonのlistに変換してみます。

LazyIDAでデータを変換する様子

変換した結果はOutput windowに出力され、これをコピペしてPythonスクリプトから扱うことができます。

Output windowに出力されたLazyIDAで変換したデータ

これはエンコードされたデータをデコードするときや、暗号化を解くときのスクリプトを書くときに便利です。

KeyPatch

IDAにはx86/x64を対象にしたアセンブラが組み込まれていますが、他のアーキテクチャを対象としたものはありません。 Keypatchは軽量なmulti-platform, multi-architecture assembler frameworkである Keystone – The Ultimate Assemblerを使って、IDA上で様々なアーキテクチャへのアセンブルを実現し、x86/x64以外のバイナリへパッチを当てやすくするプラグインです。

github.com

このプラグインはHex-Raysが行っているPlug-In Contest 2016で3位になっています。

www.hex-rays.com

使い方

Keystoneをインストールし、 IDAのpluginsディレクトリ以下にkeypatch.pyを配置すると使えます。 macOS上のIDAPythonは/usr/bin/pythonを使っているため、普段macOSのデフォルトではないPython(pyenvでインストールしたPythonなど)を使っている場合は、 IDAPythonからpipでインストールしたライブラリを使えません。 その場合はpipでインストールしたライブラリをIDAのディレクトリの中にコピーする必要があります。 わたしはpyenvでインストールしたPythonを使っているので以下のようなコマンドになりました。パスは適宜変更してください。

$ sudo cp -r ~/.pyenv/versions/2.7.15/lib/python2.7/site-packages/keystone /Applications/IDA\ Pro\ 7.2/ida.app/Contents/MacOS/python/

インストールに成功していると、IDAの画面上で左クリックして出るメニューにKeypatchが追加されています。ここからPatcherを選択することでKeyPatchのWindowが出現します。

KeypatchのWindowを出す様子

ここではMOV R0, R3というARMのアセンブリをMOV R0, 1に変更しています。

Keypatchでパッチを当てる様子

以下はパッチを当てたあとの様子です。コメントにパッチを当てる前のアセンブリが残されていて親切ですね。

パッチを当てたあと

このプラグインを使わずに、現状のIDAでx86/x64以外のバイナリに対しパッチを当てるには機械語のパッチを当てることになります。 このプラグインのおかげでARMなどのバイナリにパッチを当てる作業は楽になりました。