zkat’s diary

技術ブログ

Auditdのaureportをcronで使おうとしてハマる

aureportコマンドをcrontabで実行した際、何度やっても<no events of interest were found>と出力されてしまっていました。

結論としては、--input-logsオプションをつけることで想定通り動作するようになりました。

--input-logs
   Use the log file location from auditd.conf as input for analysis. 
   This is needed if you are using aureport from a cron job.

SCT(Signed Certificate Timestamp)のLogIDについて

SCTに存在するLogIDがどのように作成されているのか書きたいと思います。 ここで言っているLogIDとは、下記のものです。

f:id:zkat:20190420122437j:plain
google.co.jp-signed-certificate-timestamp-logid

例としてgoogle.co.jpChromeでアクセスして表示させています。
まずLogIDがなんなのかCertificate TransparencyのRFC 6962を確認してみます。

tools.ietf.org

3.2. Structure of the Signed Certificate Timestamp enum { certificate_timestamp(0), tree_hash(1), (255) } SignatureType;

   enum { v1(0), (255) }
     Version;

     struct {
         opaque key_id[32];
     } LogID;

     opaque TBSCertificate<1..2^24-1>;

     struct {
       opaque issuer_key_hash[32];
       TBSCertificate tbs_certificate;
     } PreCert;

     opaque CtExtensions<0..2^16-1>;

"key_id" is the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo.

LogIDは、key_idをフィールドにもつ構造体の様です。そして、key_idはCTログサーバーの公開鍵を DER形式でSHA256ハッシュをとったものと書いてあるように見えます。

CTログサーバーの公開鍵があれば、LogIDを作れそうです。 CTログサーバー(Chromeのポリシーに対応する)の公開鍵は次から取得することができます。

[https://www.certificate-transparency.org/known-logs:embed:cite]

始めの図の一つ目のLogIDである、Google 'Pilot' logを作ってみます。Google 'Pilot' logの公開鍵は下記のようです。

{
   "description": "Google 'Pilot' log",
   "key": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEfahLEimAoz2t01p3uMziiLOl/fHTDM0YDOhBRuiBARsV4UvxG2LdNgoIGLrtCzWE0J5APC2em4JlvR8EEEFMoA==",
   "url": "ct.googleapis.com/pilot/",
   "maximum_merge_delay": 86400,
   "operated_by": [
    0
   ],
   "dns_api_endpoint": "pilot.ct.googleapis.com"
  }

KEYにある値をEC鍵(Elliptic Curve)としてopensslでSHA256ハッシュをとってみます。

$ cat << EOF | openssl ec -outform der -pubin | openssl dgst -SHA256 -binary | hexdump -C
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEfahLEimAoz2t01p3uMziiLOl/fHTDM0YDOhBRuiBARsV4UvxG2LdNgoIGLrtCzWE0J5APC2em4JlvR8EEEFMoA==
-----END PUBLIC KEY-----
EOF
read EC key
writing EC key
00000000  a4 b9 09 90 b4 18 58 14  87 bb 13 a2 cc 67 70 0a  |......X......gp.|
00000010  3c 35 98 04 f9 1b df b8  e3 77 cd 0e c8 0d dc 10  |<5.......w......|
00000020

すると、はじめの図に記載した通りのLogIDを得ることができました。

ちなみに、CTでの署名アルゴリズムRFC 6962に下記のように記載されているように NIST P-256に記載される楕円曲線暗号を使うか、RSAの最低2048bitの鍵で署名する必要があるようです。

2.1.4. Signatures

Various data structures are signed. A log MUST use either elliptic curve signatures using the NIST P-256 curve (Section D.1.2.3 of the Digital Signature Standard [DSS]) or RSA signatures (RSASSA-PKCS1- V1_5 with SHA-256, Section 8.2 of [RFC3447]) using a key of at least 2048 bits.

TLS ExtensionによるSCTの提供について

CT1において、SCT2をクライアントに提供する方法は3つあります。

1. X.509 v3 Extensionによる方法

これは、いろいろなウェブサイトのサーバー証明書で見ることができます。証明書自体にSCTが埋め込まれているものです。 例えばtwitter.comの現時点の証明書であれば以下の様な感じで書かれていました。

            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
                                3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
                    Timestamp : Jul 17 19:51:00.991 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:8B:F9:25:DD:54:D4:8F:0C:F6:61:1E:
                                9C:10:3D:12:BA:C5:07:1C:E5:74:9D:AE:B1:E5:A1:0A:
                                95:EB:10:E4:19:02:20:23:7B:A2:00:02:68:8A:80:00:
                                20:97:B6:11:BD:16:0B:B6:E2:EF:EC:EC:1E:F7:0B:E3:
                                E3:9F:B3:8B:51:C8:30
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : 87:75:BF:E7:59:7C:F8:8C:43:99:5F:BD:F3:6E:FF:56:
                                8D:47:56:36:FF:4A:B5:60:C1:B4:EA:FF:5E:A0:83:0F
                    Timestamp : Jul 17 19:51:01.145 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:6E:08:9D:A7:60:20:E5:B9:85:22:FD:4E:
                                BE:9C:24:DB:6F:28:D6:BB:FC:52:75:9C:98:B1:32:91:
                                9E:8B:36:26:02:21:00:FF:6E:5A:E9:72:34:F0:03:4B:
                                15:BF:96:1C:C0:ED:9B:2F:33:18:0B:E8:D9:BC:86:C5:
                                0A:4C:89:67:2D:BF:8A

2.TLS Extensionによる方法

TLSネゴシエーションServer Helloの際に、SCTを提供する方法です。 google.co.jpHTTPSでアクセスしたときのTLSネゴシエーションWiresharkで見てみると以下のような形で SCTが書かれていました。

f:id:zkat:20190417005004j:plain
wireshark-signed-certificate-timestamp

TLS Extensionによる方法でSCTを提供する場合、証明書に埋め込む必要がないので、 1の方法と比べて、Precertificateがいらないメリットがあるのかなと思います。

認証局から証明書(SCTが含まれない)を発行してもらい、CTログサーバーには 自分で登録し、受領したSCTを自身のウェブサーバーに設定して公開すればよいからです。

CTログサーバーに登録する方法としては、例えばSectigo(COMODO)が下記のように公開しています。

support.sectigo.com

上記の手順に従うと、手動でMammoth(Sectigoが運用するCTログサーバー)に登録することができそうです。

3.OCSP Stapling

TLS通信を行う際の、OCSP StaplingにてSCTを提供する方法がある様なのですが 実例を知らない為どのように実際に見えるのかわかりません。


  1. Certificate Transparency

  2. Signed Certificate Timestamp

CT(Certificate Transparency)ログサーバーの可用性

CTログサーバーの可用性を確認できるウェブサイトを見つけました。
作者は、イギリスのNetcraft社(セキュリティ関連の会社)の人の様です。

This website monitors Certificate Transparency log servers to check that they are behaving correctly. ct.grahamedgecombe.com

OWASP ZAPでHTTPS通信の中身を確認したい

手順は以下の通り。
ちなみに、得体のしれないルート証明書をインポートすると、
得体のしれないソフトウェアや人に、中間者攻撃を許すことに繋がるので要注意。

1. OWASP ZAPでルート証明書を作成する

「ツール」→「オプション」→「ダイナミックSSL証明書」にて画面を開き「生成」ボタンをクリック。

f:id:zkat:20190415220147j:plain
owasp-root-certificate
生成された下記のような証明書データを、.crtを拡張子としてファイルに保存する。

-----BEGIN CERTIFICATE-----
MIIFCDCCA/CgAwIBAgIEjYma0zANBgkqhkiG9w0BAQsFADCBhDEnMCUGA1UEAwwe
...
-----END CERTIFICATE-----

2. ルート証明書を適当なブラウザでインポートする

適当なブラウザ(Firefoxがおすすめ1)の設定画面を開き、先ほどのルート証明書をインポートする。


  1. Firefoxは独立してルートストアを持っているので、システムに影響を与えない

OWASP ZAPでHTTPヘッダを追加したり削除したりする

調査対象ウェブサイトへのHTTPリクエストについて、HTTPヘッダを書き換える手順は下記の通り

1. 書き換え用スクリプトひな形を作成する。

スクリプト」タブの「HTTP Sender」を右クリックして新規スクリプトのひな形を作成する。

f:id:zkat:20190415221830j:plain
owasp-manipulate-http-header

2. 書き換え内容をスクリプトに書く

例えばUser-Agentを削除して、X-hogehoge-hedaerを追加する場合は下記の通りスクリプトを書きます。

function sendingRequest(msg, initiator, helper) {
    msg.getRequestHeader().setHeader("User-Agent", null);
    msg.getRequestHeader().addHeader("X-hogehoge-hedaer", "123");
}

スクリプトファイル名を右クリックして、「有効化」するのを忘れずに。

f:id:zkat:20190415223826j:plain
owasp-http-sender-script

3. OWASP ZAPを介してブラウザでアクセスする

OWASP ZAPではローカルプロキシ設定を有効にして、ブラウザからのアクセスを受け付けるようにしておきます。
HTTPサーバーを立ち上げるのは面倒なのでncコマンドを起動しておきます。

$ nc -l 8080
GET / HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-US;q=0.7,en;q=0.3
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
X-hogehoge-hedaer: 123
Host: localhost:8080

ブラウザにてアクセスしてみると、User-Agentが消え、X-hogehoge-headerが追加されていることを確認できました。

Alloyに入門している

Alloyを用いたモデル検査が行えるようになりたくて、勉強をしています。 勉強がてら、「顧客が商品を買う」という挙動についてAlloyで記述してみました。

open util/boolean

sig Consumer {}
sig Product {
    price: Consumer -> one Int,
    bought : Consumer -> one Bool,
    billed: Consumer -> one Bool,
    paid:  Consumer -> one Bool
}

fact {
    all product : Product, consumer : Consumer |
        // 支払いが済んでいるということは、請求されたということ
        (consumer.(product.paid) = True implies consumer.(product.billed) = True) and
        // 購入したならば請求が立つ。 請求が立っているならば購入された。
        (consumer.(product.bought) = True iff consumer.(product.billed) = True) and
        // 金額は0円以上
        (consumer.(product.price) >= 0)
}

pred showTwoProductOneConsumer(){
    #Product = 1
    #Consumer = 1
}

run showTwoProductOneConsumer

これを実行すると下記のような例が出力されました。

f:id:zkat:20190415225750j:plain
alloy-sample
顧客が品物を買ってくれて、請求が立っているけど支払いはまだ。金額は3円。みたいな内容を表していると思います。 predで述語を定義し実行することで、その条件を満たす例を挙げてくれる様です。

Alloyのはまりどころに関してですが.(ドット)による演算の意味を正しく理解しなければならないなと思いました。 オブジェクト指向的な意味でのオブジェクトフィールドの参照と捉えていましたが、全くの別物でした。 集合ABをそれぞれ、A=\{ (a,b),(c,d) \}B=\{ (b,α),(d,γ) \}とする時A.B\{ (a,α),(c,γ) \}となる様な演算です。