NmapのNSEスクリプト「upnp-info」を使ってみた（その2）

メモ

2013年2月11日の日記を書いたあとも、Nmap の NSE スクリプト「upnp-info」を使い、「upnp.lua*1」（「upnp-info」が読み込む lua スクリプト）で次の 2 点を変更しました。このとき「upnp-info」を実行すると、次のような結果が得られます。この日記では、この 2 点の変更についてメモします。

  1. HTTP レスポンスから Location ヘッダ の URL を抽出する正規表現
  2. 取得した Device description の解析処理
$>nmap -sU -p1900 --script=upnp-info -n 192.168.0.106

Starting Nmap 6.25 ( http://nmap.org ) at 2013-03-03 23:35 東京 (標準時)
Nmap scan report for 192.168.0.106
Host is up (0.00s latency).
PORT     STATE SERVICE
1900/udp open  upnp
| upnp-info:
|   192.168.0.106
|       Server: Linux/2.6 UPnP/1.0 nasne/1.0
|       Location: http://192.168.0.106:58888/
|         Webserver: Linux/2.6 UPnP/1.0 nasne/1.0
|         Name: nasne
|         Manufacturer: Sony Computer Entertainment Inc.
|         Model Descr: nasne
|         Model Name: nasne
|         serviceId: urn:upnp-org:serviceId:ConnectionManager
|           SCPDURL   : http://192.168.0.106:58888/MediaServer_ConnectionManager/scpd.xml
|           controlURL: http://192.168.0.106:58888/MediaServer_ConnectionManager/control
|         serviceId: urn:upnp-org:serviceId:ContentDirectory
|           SCPDURL   : http://192.168.0.106:58888/MediaServer_ContentDirectory/scpd.xml
|           controlURL: http://192.168.0.106:58888/MediaServer_ContentDirectory/control
|         serviceId: urn:s-bras-org:serviceId:X_PvrControl
|           SCPDURL   : http://192.168.0.106:64230/X_PvrControl.xml
|           controlURL: http://192.168.0.106:64230/X_PvrControl
|         serviceId: urn:xsrs-org:serviceId:X_ScheduledRecording
|           SCPDURL   : http://192.168.0.106:64230/XSRS.xml
|_          controlURL: http://192.168.0.106:64230/XSRS
MAC Address: 12:34:56:78:9a:bc (XXXXXXXXXXXXXXXX)

Nmap done: 1 IP address (1 host up) scanned in 6.72 seconds

HTTP レスポンスから Location ヘッダ の URL を抽出する正規表現

2013年2月11日の日記を書いたときには、nasne に対する「upnp-info」の実行結果に Device description*2 の friendlyName 要素や manufacturer 要素が出力されていませんでした。他の機器に実行した場合、それらが出力されていました。
そこで、nasne に対する「upnp-info」が送信するパケットをキャプチャして確認したところ、GET リクエストの URI が「0x2f 0x0d」（/）となっていました。このため、nasne の 58888/tcp から HTTP レスポンスコード 404（Not Found）が応答され、「Device description」が取得できていなかったと判断しました。
「upnp.lua」を調べてみると、Location ヘッダから URL を取得するときに「0x0d」を含む文字列（改行コードとして「0x0a」だけを含まない文字列）に一致する正規表現が書かれており、この部分に問題がありました。
この問題を修正するため、次のようなパッチを作成してみました。改めて読み返すと適当すぎますね...この正規表現（ｘ。このパッチをメーリングリスト「nmap-dev」に投稿したところ、（きちんとした正規表現に修正されたうえで）upnp.lua に反映されたようです:)

--- upnp.lua	2013-02-16 17:49:50.745090000 +0900
+++ upnp_edited.lua	2013-02-16 18:28:38.307590000 +0900
@@ -183,7 +183,7 @@
 			local server, location
 			server = string.match(response, "[Ss][Ee][Rr][Vv][Ee][Rr]:%s*(.-)\010")
 			if server ~= nil then table.insert(output, "Server: " .. server ) end
-			location = string.match(response, "[Ll][Oo][Cc][Aa][Tt][Ii][Oo][Nn]:%s*(.-)\010")
+			location = string.match(response, "[Ll][Oo][Cc][Aa][Tt][Ii][Oo][Nn]:%s*(.-)[\010\013]+")
 			if location ~= nil then
 				table.insert(output, "Location: " .. location )

取得した Device description の解析処理

どうせなら Service description*3 の URL（SCPDURL 要素）なども出力したいと思い、さらに次のようなパッチを作成しました。このパッチを upnp.lua に適用すると、冒頭にある出力結果が得られます。

--- upnp.lua	2012-11-30 04:39:54.000000000 +0900
+++ upnp-edited.lua	2013-03-12 23:40:17.140625000 +0900
@@ -183,7 +183,7 @@
 			local server, location
 			server = string.match(response, "[Ss][Ee][Rr][Vv][Ee][Rr]:%s*(.-)\010")
 			if server ~= nil then table.insert(output, "Server: " .. server ) end
-			location = string.match(response, "[Ll][Oo][Cc][Aa][Tt][Ii][Oo][Nn]:%s*(.-)\010")
+			location = string.match(response, "[Ll][Oo][Cc][Aa][Tt][Ii][Oo][Nn]:%s*(.-)[\010\013]+")
 			if location ~= nil then
 				table.insert(output, "Location: " .. location )
 			
@@ -271,6 +271,19 @@
 				if nm ~= nil then table.insert(output,"Model Name: " .. nm) end
 				if ver ~= nil then table.insert(output,"Model Version: " .. ver) end
 			end
+
+			for service in string.gmatch(response['body'], "<service>(.-)</service>") do
+				local serviceId, SCPDURL, controlURL
+
+				serviceId = string.match(service, "<serviceId>(.-)</serviceId>")
+				SCPDURL = string.match(service, "<SCPDURL>(.-)</SCPDURL>")
+				controlURL = string.match(service, "<controlURL>(.-)</controlURL>")
+
+				if serviceId ~= nil then table.insert(output, "serviceId: " .. serviceId) end
+				if SCPDURL ~= nil then table.insert(output, "  SCPDURL   : " .. SCPDURL) end
+				if controlURL ~= nil then table.insert(output, "  controlURL: " .. controlURL) end
+
+			end
 			return true, output
 		else
 			return false, "Could not retrieve XML file"

*1:Nmap インストールディレクトリ\nselib\ 以下にあります。

*2:pp.43-48 2.3 Device description, "UPnP Device Architecture 1.1"

*3:pp.48-55 2.5 Service description, "UPnP Device Architecture 1.1"

NmapのNSEスクリプト「upnp-info」を使ってみた

メモ

Nmap の NSE(Nmap Scripting Engine)スクリプト「upnp-info」を使ってみたところ、使用前に思っていた実行結果と異なっていたため、スクリプトを一部編集してみました。この日記では、「upnp-info」の実行結果と編集したスクリプトについて書きます。

「upnp-info」の実行結果

まず「upnp-info」の実行環境は下表の通りです。

IPアドレス デバイス 説明
192.168.0.101 Windows XP SP3 マシン 「upnp-info」を実行するデバイス
192.168.0.106 nasne 「upnp-info」の実行対象デバイス


この実行環境で「upnp-info」を実行してみると、nasne の UPnP に関する情報が実行結果に出力されませんでした。なお、Nmap の実行結果のうち、MAC アドレスおよび OUI 情報については「12:34:56:78:9a:bc」、「XXXXXXXXXXXXXXXX」に置換しています。

$>nmap -V

Nmap version 6.25 ( http://nmap.org )
Platform: i686-pc-windows-windows
Compiled with: nmap-liblua-5.2.1 openssl-1.0.1c nmap-libpcre-7.6 libpcap-4.1.2 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: select

$>nmap -sU -p1900 --script=upnp-info -n 192.168.0.106

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-10 22:40 東京 (標準時)
Nmap scan report for 192.168.0.106
Host is up (0.00s latency).
PORT     STATE         SERVICE
1900/udp open|filtered upnp
MAC Address: 12:34:56:78:9a:bc (XXXXXXXXXXXXXXXX)

Nmap done: 1 IP address (1 host up) scanned in 6.92 seconds


一方で、UPnP を実装しているデバイスを探す NSE スクリプト「broadcast-upnp-info」の実行結果には、nasne の UPnP に関する情報が出力されました。「upnp-info」を使用する前には、このような出力を思い描いていました。

$>nmap -sU -p1900 --script=broadcast-upnp-info -n 192.168.0.106

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-10 23:37 東京 (標準時)
Pre-scan script results:


    

     broadcast-upnp-info:
    

    

       192.168.0.106
    

    

           Server: Linux/2.6 UPnP/1.0 nasne/1.0
    

    

           Location: http://192.168.0.106:58888/
    

    

    _        Webserver: Linux/2.6 UPnP/1.0 nasne/1.0
    


Nmap scan report for 192.168.0.106
Host is up (0.00s latency).
PORT     STATE         SERVICE
1900/udp open|filtered upnp
MAC Address: 12:34:56:78:9a:bc (XXXXXXXXXXXXXXXX)

Nmap done: 1 IP address (1 host up) scanned in 8.86 seconds


「upnp-info」と「broadcast-upnp-info」のパケットキャプチャデータを確認したところ、UPnP の M-SEARCH リクエスト（後述）の送信方法に違いがありました。「upnp-info」の場合、この違いによって nasne が M-SEARCH リクエストに応答していないと考えました。

スクリプト実行時に送受信されるパケット

「upnp-info」の場合、Nmap で指定した 192.168.0.106 に M-SEARCH リクエストを送信していましたが、「broadcast-upnp-info」の場合、マルチキャストアドレス 239.255.255.250 に送信していました。

  • 「upnp-info」のパケットキャプチャデータ（CloudShark）
    • パケットキャプチャデータ No.3 を参照
  • 「broadcast-upnp-info」のパケットキャプチャデータ（CloudShark）
    • パケットキャプチャデータ No.1 を参照

「upnp-info」および「broadcast-upnp-info」ともに、下記の M-SEARCH リクエストを送信します。それぞれのパケットキャプチャデータを確認すると、宛先 IP アドレスおよび宛先 MAC アドレスが異なること*1が分かります。なお、「192.168.0.101」および「192.168.0.106」の MAC アドレスについては、それぞれ「bc:9a:78:56:34:12」、「12:34:56:78:9a:bc」に置換しています。

M-SEARCH * HTTP/1.1
Host:239.255.255.250:1900
ST:upnp:rootdevice
Man:"ssdp:discover"
MX:3
UPnP における M-SEARCH リクエスト

「UPnP Device Architecture 1.1」の「1.3 Search」では、M-SEARCH リクエストが「ネットワーク上の UPnP を実装しているデバイスを探すリクエスト」である旨が記述されています。この仕様書によると、マルチキャストアドレス宛てにM-SEARCH リクエストを送信する以外にも、ユニキャストアドレス宛てに送信できます*2。
「upnp-info」の場合、192.168.0.106 宛てにも関わらず、Host ヘッダを「239.255.255.250:1900」としていることが原因かと推測しましたが、違いました。Host ヘッダを「192.168.0.106:1900」に修正して ncatで送信してみましたが*3、やはり応答がありませんでした。結論としては、UPnP を実装したデバイスの中には、ユニキャスト宛て M-SEARCH リクエストに応答しないものもある、と理解しました。

「upnp-info」の編集

「broadcast-upnp-info」スクリプト broadcast-upnp-info.lua や upnp.lua を読みながら、「upnp-info」スクリプト upnp-info.lua を次のように編集してみました。

  • M-SEARCH リクエストをマルチキャストアドレス宛てに送信する
  • M-SEARCH リクエストに対する応答から対象 IP アドレスの結果のみ抽出する

編集した upnp-info.lua は下記の通りとなります。僕が追加したコードは「-----追加 ここから」と「-----追加 ここまで」に囲まれたコード部分です。M-SEARCH リクエストに対して複数の応答が得られる環境で、簡単な動作確認のみ実施しています。

local nmap = require "nmap"
local shortport = require "shortport"
local stdnse = require "stdnse"
local string = require "string"
local upnp = require "upnp"
-----追加 ここから
local table = require "table"
-----追加 ここまで

description = [[
Attempts to extract system information from the UPnP service.
]]

---
-- @output
-- |  upnp-info:  System/1.0 UPnP/1.0 IGD/1.0
-- |_ Location: http://192.168.1.1:80/UPnP/IGD.xml
--
-- @args upnp-info.override Controls whether we override the IP address information
--                          returned by the UPNP service for the location of the XML
--                          file that describes the device.  Defaults to true for 
--                          unicast hosts.

-- 2010-10-05 - add prerule support <patrik@cqure.net>
-- 2010-10-10 - add newtarget support <patrik@cqure.net>
-- 2010-10-29 - factored out all of the code to upnp.lua <patrik@cqure.net>
-- 2013-02-11 - call helper:setMulticast(true), and filter only result of target ip <kaito834@gmail.com>

author = "Thomas Buchanan"

license = "Same as Nmap--See http://nmap.org/book/man-legal.html"

categories = {"default", "discovery", "safe"}


---
-- Runs on UDP port 1900
portrule = shortport.portnumber(1900, "udp", {"open", "open|filtered"})

---
-- Sends UPnP discovery packet to host, 
-- and extracts service information from results
action = function(host, port)
	local override = stdnse.get_script_args("upnp-info.override")
	local helper = upnp.Helper:new( host, port )
	if ( override ~= nil ) and ( string.lower(override) == "false" ) then
		helper:setOverride( false )
	else
		helper:setOverride( true )
	end
	-----追加 ここから
	helper:setMulticast(true)
	-----追加 ここまで
	local status, result = helper:queryServices()

	-----追加 ここから
	for key, value in ipairs(result) do
		if(not(value['name'] == host['ip'])) then
			table.remove(result, key)
		end
	end
	-----追加 ここまで

	if ( status ) then
		nmap.set_port_state(host, port, "open")
		return stdnse.format_output(true, result)
	end
end


編集した「upnp-info」を実行すると、下記のように「broadcast-upnp-info」と同様の出力が得られました。

$>nmap -sU -p1900 --script=upnp-info -n 192.168.0.106

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-11 09:46 東京 (標準時)
Nmap scan report for 192.168.0.106
Host is up (0.00s latency).
PORT     STATE SERVICE
1900/udp open  upnp


    

     upnp-info:
    

    

       192.168.0.106
    

    

           Server: Linux/2.6 UPnP/1.0 nasne/1.0
    

    

           Location: http://192.168.0.106:58888/
    

    

    _        Webserver: Linux/2.6 UPnP/1.0 nasne/1.0
    


MAC Address: 12:34:56:78:9a:bc (XXXXXXXXXXXXXXXX)

Nmap done: 1 IP address (1 host up) scanned in 8.11 seconds

*1:「broadcast-upnp-info」では、宛先 MAC アドレスが 01:00:5e:7f:ff:fa となります。参考：http://d.hatena.ne.jp/naablaa/20061129#p1

*2:「Control points can also send a unicast search message to a known IP address...」という記述が該当します

*3:ncat -u --send-only 239.255.255.250 1900 < msearch.txt

Bluetoothトラフィックをキャプチャしてみる

メモ

Bluetooth デバイス間を流れるトラフィックをキャプチャしたいと思い、関連する情報を調べてました。その調べた結果を整理するために、日記にまとめてみました。

Bluetooth デバイス間を流れるトラフィックのキャプチャ

ノート PC 等に内蔵されている Bluetooth デバイスなどを使用する場合、「そのデバイスが送信する HCI データ」または「そのデバイスに向けて送信される HCI データ」しかキャプチャできません。Wireshark Wiki における「Bluetooth traffic to or from your machine」という記述、および hcidump の man マニュアルにおける「raw HCI data coming from and going to a Bluetooth device」という記述が、このことを裏付けています。

Bluetooth デバイス間を流れるトラフィックを無作為にキャプチャする場合*1、商用製品または Ubertooth One などの特殊な Bluetooth デバイスが必要となるようです。neko氏のブログ記事によると、商用製品には Frontline 社の製品（FTS4BT？）があるようです。「Ubertooth One」を使うと、Bluetooth トラフィックのキャプチャやインジェクションが実現できるようです。


試しに Linux の Bluetooth スタック「BlueZ」の「hcidump」を使って、Buffalo 製 Bluetooth デバイスが送受信する HCI データをキャプチャしてみました。

「hcidump」による Bluetooth トラフィックのキャプチャ

動作環境

下図の通りです。BackTrack 5R3 を起動した「ノート PC」から「l2ping」コマンドを実行して、「ノート PC」と「Galaxy Nexus(SC-04D)」でやり取りされる HCI データを「hcidump」コマンドでキャプチャします。


実践

BackTrack 5R3 に同梱されている「hcidump」コマンドのバージョンを確認した後、Bluetooth 論理インターフェイス hci0 で HCI データをキャプチャしました。キャプチャした HCI データを bt.pcap に保存しました（下記参照）。

root@bt:/tmp# hcidump -version
2.3
root@bt:/tmp# hcidump -i hci0 -w bt.pcap
HCI sniffer - Bluetooth packet analyzer ver 2.3
btsnoop version: 1 datalink type: 1002
device: hci0 snap_len: 1028 filter: 0x0


「hcidump」コマンドを実行しているときに、「l2ping」コマンドを「Galaxy Nexus(SC-04D)」の MAC アドレス宛に実行しました（下記参照）。「l2ping」コマンドの実行結果では、Buffalo 製 Bluetooth デバイスの MAC アドレスを「aa:bb:cc:dd:ee:ff」、「Galaxy Nexus(SC-04D)」の MAC アドレスを「00:11:22:33:44:55」に置換しています。

root@bt:~# l2ping -i hci0 -c 5 00:11:22:33:44:55
Ping: 00:11:22:33:44:55 from aa:bb:cc:dd:ee:ff (data size 44) ...
44 bytes from 00:11:22:33:44:55 id 0 time 6.85ms
44 bytes from 00:11:22:33:44:55 id 1 time 25.81ms
44 bytes from 00:11:22:33:44:55 id 2 time 4.82ms
44 bytes from 00:11:22:33:44:55 id 3 time 27.81ms
44 bytes from 00:11:22:33:44:55 id 4 time 28.83ms
5 sent, 5 received, 0% loss


「l2ping」コマンドを実行したあと、「hcidump」コマンドを終了しました。bt.pcap を Wireshark で開くと、下図のようになります。bt.pcap ファイルから「l2ping」コマンドの実行結果（リクエストおよびレスポンス）のみ抽出して、CloudShark にアップしました。


「hcidump」コマンドで取得した bt.pcap のファイルタイプを「file」コマンドで確認したところ、「BTSnoop」のファイルタイプに該当していました。この「BTsnoop」は、Symbian OS における Bluetooth HCI layer のログフォーマットに該当します。

root@bt:/tmp# file bt.pcap 
bt.pcap: BTSnoop version 1, HCI UART (H4)


「Ubertooth One」で Bluetooth トラフィックをキャプチャする場合、libbtbb のデータ形式で保存されるようなので、「hcidump」のデータ形式と異なるようです。このブログ記事で Wireshark のスクリーンショットをみてみると、確かに違う... とはいえ、「Bluetooth デバイス間をどんなデータが流れるか」を知る目的であれば、「hcidump」のキャプチャデータでも参考になります。

まとめ

Bluetooth トラフィックをキャプチャすることは難しい。

関連情報

*1:Ehternet(802.3) の Network Interface Card(NIC) における promiscous モードや、無線 LAN(802.11) の NIC における Monitor モードに該当します。

Scapyにおける「WARNING: Mac address to reach destination not found」

メモ

2012年12月2日の日記で書いた方法で、Scapy による無線LAN（802.11）frame injection を実践していたところ、「WARNING: Mac address to reach destination not found」という警告メッセージが出力されました（下記参照）。このとき、Wireshark でパケットキャプチャしていも、802.11 フレームが送信されていませんでした。

root@bt:~# scapy
WARNING: No route found for IPv6 destination :: (no default route?)
Welcome to Scapy (2.0.1)
>>> send(RadioTap()/Dot11(addr1="ff:ff:ff:ff:ff",addr2="00:11:22:33:44:55",addr3="00:11:22:33:44:55")/Dot11Beacon(cap="ESS")/Dot11Elt(ID="SSID",info="scapy-frame-injection")/Dot11Elt(ID="Rates",info="\x82\x84\x0b\x16")/Dot11Elt(ID="DSset",info="\x06")/Dot11Elt(ID="TIM",info="\x00\x01\x00\x00"),iface="wlan1mon",loop=1,inter=1)
WARNING: Mac address to reach destination not found. Using broadcast.
.WARNING: Mac address to reach destination not found. Using broadcast.
.WARNING: more Mac address to reach destination not found. Using broadcast.
...WARNING: Mac address to reach destination not found. Using broadcast.
(snip)


この警告メッセージが出力された原因は、OSI 参照モデルにおける Layer 2 のプロトコルを編集したフレームを送信するために send() 関数を使用したことにありました。Layer 2 のプロトコルを編集したフレームを送信する場合、sendp() 関数を使用する必要があります。下記がマニュアルの該当部分の記述です。

The send() function will send packets at layer 3. That is to say it will handle routing and layer 2 for you. The sendp() function will work at layer 2.

Sending packets, Usage ― Scapy v2.1.1-dev documentation

2012年に気になった脆弱性をまとめてみる

脆弱性

2013年あけましておめでとうございます（遅い...）。今年も思い立ったときにブログ記事を投稿していきたいと思います。
2012年も変わらず脆弱性情報を読んでいたこともあり、2012年に気になった脆弱性をまとめてみます。2011年も同じような日記を書きましたが、リンク集に近いものだったため、今回は気になった点のコメントを添えました。そうしないと書いた本人も忘れるので...

はじめに

対象とする脆弱性

この日記で取り上げる脆弱性は、「2012年に修正、または発見、報告（記事化も含む）されたもの」です。自分のつぶやきを基に選んだので、2012年の脆弱性を網羅していません。

脆弱性の分類

今回の日記では、脆弱性を次のように分類して表にまとめました。

表の構成

各表は次の列を基本に構成しています。表ごとの独自の列については、その節で改めて書きます。

  • [ソフトウェア名] 列
    • 脆弱性が存在するソフトウェアなどを指します。表によって、列名が少しずつ変わります。
  • [月] 列
    • その脆弱性が修正、または発見、報告（記事化も含む）された月を指します。
  • [CVE番号] 列
    • その脆弱性のCVE番号を指します。CVEで検索して見つからなかった場合は「CVE番号なし」としました。
  • [関連情報] 列
    • その脆弱性に関連するインターネット上の情報を指します。

以上をふまえて、2012年における脆弱性の振り返りの参考にしていただければと思います。

ソフトウェア

2012年のソフトウェアに関する気になった脆弱性を下表にまとめました。定例パッチを提供している Microsoft, Adobe Systems, Oracle のソフトウェアについては、別の表にまとめました。
この分類においては、その脆弱性が悪用されているか否かにも注目して、表に [脆弱性の悪用] 列を加えました。

  • 「○」：脆弱性の悪用（攻撃）が確認されている。
    • 脆弱性の悪用から発覚したものについては「○0day」とした
  • 「-」：脆弱性の悪用が確認されていない。
ソフトウェア名 月 CVE番号 脆弱性の悪用 関連情報
Linux kernel 1月 CVE-2012-0056 ○ ブログ「Nerdling Sapple」
sudo 1月 CVE-2012-0809 - Sudo公式
Samba 4月 CVE-2012-1182 - Samba公式
PHP 5月 CVE-2012-1823 ○ ブログ「徳丸浩の日記」
BIND 6月 CVE-2012-1667 - Internet Systems Consortium
7月 CVE-2012-3817 - Internet Systems Consortium
7月 CVE-2012-3868 - Internet Systems Consortium
9月 CVE-2012-4244 - Internet Systems Consortium
10月 CVE-2012-5166 - Internet Systems Consortium
12月 CVE-2012-5688 - Internet Systems Consortium
Mysql 5月 CVE-2012-2122 - IIJ-SECT
12月 CVE-2012-5611他 - SANS, exploit-db
phpMyAdmin 9月 CVE-2012-5159 ○ SourceForge
Safari 10月 CVE-2012-3713 - JVN, mala氏ブログ記事

それぞれの脆弱性で気になった点を下記に記述します。

定例パッチ関連：Microsoft

毎月定例パッチを提供している Microsoft のソフトウェアのうち、気になった脆弱性を下表にまとめました。

月 ソフトウェア名 MS番号 CVE番号 脆弱性の悪用 関連情報
1月 Windows Media Player MS12-004 CVE-2012-0003 ○ ISS
1月 Windows Packager MS12-005 CVE-2012-0013 - Exploit Shop,NTTデータ 先端技術
3月 リモートデスクトップ MS12-020 CVE-2012-0002 - IIJ-SECT
4月 Windows コモン コントロール MS12-027 CVE-2012-0158 ○ -
6月 Internet Explorer MS12-037 CVE-2012-1875 ○ IBM東京SOC
7月 VBA MS12-046 CVE-2012-1854 ○ Symantec
7月 Windowsシェル MS12-048 CVE-2012-0175 - IBM
9月 Internet Explorer MS12-063 CVE-2012-4969 ○0day ZATAZ.com
12月 Internet Explorer MS番号なし CVE-2012-4792 ○0day Fireeye

それぞれの脆弱性で気になった点を下記に記述します。[脆弱性の悪用] 列が「○」のものには「脆弱性が悪用されたこと」のみ気になったものがあります。それらの脆弱性についてのコメントはありません。

定例パッチ関連：Adobe Systems

定期的にパッチを提供している Adobe Systems のソフトウェアのうち、気になった脆弱性を下表にまとめました。

月 ソフトウェア名 Adobe番号 CVE番号 脆弱性の悪用 関連情報
2月 Adobe Flash Player APSB12-03 CVE-2012-0767 ○ -
2月 Adobe Flash Player APSB12-03 CVE-2012-0753 ○ contagio
5月 Adobe Flash Player APSB12-09 CVE-2012-0779 ○ -
5月 Adobe Illustrator APSB12-10 CVE番号複数 - Adobe
5月 Adobe Photoshop APSB12-11 CVE番号複数 - Adobe
5月 Adobe Flash Professional APSB12-12 CVE-2012-0778 - Adobe
12月 Adobe Shockwave Player - CVE-2012-6270 - JVNVU
12月 Adobe Shockwave Player - CVE-2012-6271 - JVNVU
12月 Adobe Shockwave Player - CVE番号なし - JVNVU

それぞれの脆弱性で気になった点を下記に記述します。[脆弱性の悪用] 列が「○」のものについては前述 Microsoft の場合と同様です。

  • Adobe Illustrator: APSB12-10
  • Adobe Photoshop: APSB12-11
  • Adobe Flash Professional: APSB12-12
    • Security Bulletin 公開当初、解決策としてバージョンアップが提示されていた。
    • だが、最終的に修正パッチを提供することとなった（ITmedia関連記事）
  • Adobe Shockwave Player: CVE-2012-6270, CVE-2012-6271, CVE番号なし
    • 「旧バージョンの Shockwave ランタイムなどが同梱されている」という珍しい脆弱性

2012 年の Adobe Flash Player における脆弱性情報が「ERIC ROMANG BLOG」でまとめられていました。修正された脆弱性 68 件のうち 44 件（64,7%）が Google による報告なんですね。そういえば、APSB12-16 では、fuzzing によって発見された脆弱性が 12 件修正された話題もありました。

定例パッチ関連：Oracle

定期的にパッチを提供している Oracle のソフトウェアのうち、気になった脆弱性を下表にまとめました。

月 ソフトウェア名 Oracle CPU CVE番号 脆弱性の悪用 関連情報
2月 Java関連 2012年2月 CVE-2012-0500 ○ この日記
2月 Java関連 2012年2月 CVE-2012-0507 ○ Microsoft
4月 Oracle Database Server SecurityAlert CVE-2012-1675 - ITmedia
6月 Java関連 2012年6月 CVE-2012-1723 ○ NTTデータ先端技術
7月 Oracle Outside In 2012年7月 CVE番号多数 - JVNVU
8月 Java関連 SecurityAlert CVE-2012-4681 ○0day Fireeye,SE-2012-01
10月 Java関連 2012年10月 CVE-2012-5076 ○ NTTデータ 先端技術

それぞれの脆弱性で気になった点を下記に記述します。[脆弱性の悪用] 列が「○」のものについては前述 Microsoft の場合と同様です。Adobe Flash Player 同様、2012 年の Java 関連の脆弱性情報が「ERIC ROMANG BLOG」でまとめられていました。

  • Oracle Database Server: CVE-2012-1675
    • 発見者が修正されたと思い、脆弱性情報を公開
  • Oracle Outside In: CVE番号多数

組み込みシステム

2012年の組み込みシステムに関する気になった脆弱性を下表にまとめました。スマートデバイス（スマートフォンやタブレット）、スマートデバイス向けアプリについては、別の表にまとめています。

製品種別 メーカ／型番 月 CVE番号 関連情報
IPカメラ Trendnet社／TV-IP110W 1月 CVE番号なし consolecowboys
複数ベンダ 10月 CVE-2012-3002 JVNVU
ルータ TP-Link社／8840T 4月 CVE番号なし JVNVU
Netgear社／FVS318N 4月 CVE番号なし JVNVU
Logitec社／LAN-W300N/Rシリーズ 5月 CVE-2012-1250 JVNVU
Alpha Networks社／ASL-26552 8月 CVE番号なし OSVDB
D-Link社／DSL2730U 12月 CVE-2012-5966 JVNVU
Huawei社／E585 Pocket WiFi 2 12月 CVE-2012-5968他 JVNVU
テレビ Samsung社／D6000 4月 CVE-2012-4329 exploit-db
Samsung社／型番不明 12月 CVE番号なし TheHackerNews
ネットワーク機器 F5 Networks社／BIG-IP 6月 CVE-2012-1493 Matta Consulting
コーヒーメーカー JURA Elektroapparate AG社／IMPRESSA F90 9月 CVE-2008-7173 はてぶ
無線LANチップセット Broadcom社／BCM4325・BCM4329 10月 CVE-2012-2619 Core Security
プリンタ Samsung社／型番不明 11月 CVE-2012-4964 JVNVU
カード式ロック Onity社／型番不明 7月 CVE番号なし eWEEK,WIRED

組み込みシステムについては、表に[製品種別] 列を加えました。製品種別ごとに気になった点を下記に記述します。まとめてみると、システムの設計に起因する脆弱性が多い印象があります。

  • IPカメラ
    • 認証なくカメラの映像を視聴できてしまう（特定の URL にアクセスするだけ）
    • 認証回避の脆弱性
  • ルータ
  • テレビ
    • 再起動を繰り返す状態に陥る
    • テレビに接続したストレージに保存されたデータを外部から取得できてしまう
  • ネットワーク機器
  • コーヒーメーカー
    • 脆弱性云々ではなく、100 を超えるはてぶ数
  • 無線LANチップセット
  • プリンタ
    • SNMP コミュニティ文字列がハードコーディングされている
  • カード式ロック
    • 2012 年 8 月に BlackHat USA で公開された手法が実際に悪用された
スマートデバイス（スマートフォン、タブレット）

スマートデバイス上で動作する OS 等の脆弱性のうち、気になった脆弱性を下表にまとめました。これらの脆弱性の影響範囲は、OS そのものや特定の製造メーカのデバイスのみであったりと影響範囲が異なるため、[影響範囲] 列を加えました。

OS 影響範囲 月 CVE番号 関連情報
Android HTC製Androidデバイス 2月 CVE-2011-4872 JVNVU
HTC製Androidデバイス 4月 CVE-2012-2217 VSR
ZTE製Androidデバイス 5月 CVE-2012-2949 pastebin
Android SQLiteエンジン 5月 CVE-2011-3901 IBM
Android init 6月 CVE番号なし ブログ「8796.jp管理日誌」
Samsung製およびHTC製Androidデバイス 8月 CVE-2012-2980 JVNVU
Samsung製Androidデバイス 9月 CVE番号なし SLASHGEAR
NTTDocomo,KDDI,Softbank販売Androidデバイス 11月 CVE番号なし JVN,FFRI
Exynos 4210, 4412搭載Androidデバイス 12月 CVE-2012-6422 TheHackerNews
iOS Safari on iOS 5.1 5月 CVE-2012-0674 MajorSecurity
Safari on iOS 5.1.1 5月 CVE番号なし exploit-db
Telephony on iOS 6未満 8月 CVE-2012-3744 pod2g's iOS blog
WindowsPhone Windows Phone 7 9月 CVE-2012-2993 JVNVU

それぞれの脆弱性で気になった点を下記に記述します。

スマートデバイス向けアプリ

スマートデバイス向けアプリの脆弱性のうち、JVN や AppSec 以外で報告された脆弱性を下表にまとめました。2012 年は JVN や AppSec にて Android アプリの脆弱性が公表されたので、すべてまとめるのは厳しい（ｘ

まとめてみると、スマートデバイス向けアプリの脆弱性には CVE 番号が割り当てられていないことが多いです。

OS アプリ名 月 CVE番号 関連情報
Android K-9 Mail 2月 CVE番号なし TrustGo
Facebook Android SDK 4月 CVE番号なし Parse blog
spモードメール 4月 CVE-2012-1244 JVN
Nessus app for android 7月 CVE番号なし Full Disclosure
iOS iOS向けFacebookアプリ 4月 CVE番号なし garethwright.com
TreasonSMS 4月 CVE番号なし threadpost
iOS向けFacebookアプリ 8月 CVE番号なし ブログ「My IT projects」
GoodReader 8月 CVE-2012-2648 JVN
iOS向けDropboxアプリ、iOS向けGoogle Driveアプリ 10月 CVE番号なし IBM
Facebook Cameraアプリ 12月 CVE番号なし TechCrunch

Android アプリの脆弱性については、下記のようなものがありました。JVN で公開された脆弱性については JSSEC の資料で解説されています。WebView に関する脆弱性については、Androidセキュリティ勉強会の @goroh_kun さんの資料、CodeZine 連載記事がとても参考になります。

  • 機密性の高い情報の取扱い不備
    • ログ
    • 暗黙的 Intent
    • SD カード
  • アクセス制限の不備
    • Activity
    • Content Provider
  • SSL サーバ証明書の検証不備
  • WebView に関する脆弱性

iOS アプリに関しては、上表のもの以外には NSLog の話題が印象に残っています。

Webアプリケーション

2012年の Web アプリケーションに関する気になった脆弱性を下表にまとめました。Web アプリの脆弱性には CVE 番号が割り当てられないため、[CVE 番号] 列を削除しました。

月 Web アプリ 脆弱性の悪用 関連情報
4月 Hotmail ○ threatpost,TheHackerNews
5月 Yahoo! Mail - TrendLabs
8月 Amazon ○ Ars Technica,WIRED
11月 Skype ○ ITmedia,Reddit
12月 Tumbler ○ ITmedia,twitterセキュリティネタまとめ

それぞれの脆弱性で気になった点を下記に記述します。

  • Hotmail
    • パスワードリセット機能における脆弱性
  • Yahoo! Mail
    • DOM based Cross Site Scripting(XSS)
  • Amazon
    • パスワード再発行等の手続きにおける問題
    • Mat Honan 氏の iCloud 乗っ取り事件
  • Skype
    • パスワードリセット機能における脆弱性
  • Tumbler

その他

その他に下記のようなことがありました。分類に悩んだので、箇条書きでメモしておきます。

終わりに

気になった点のコメントを添えてみたら、大分時間がかかってしまいました。だけど、2011年の脆弱性まとめ記事よりはよいものになったかなぁ。

それでは、2013 年もよろしくお願いします:)

Scapyによる802.11 frame injectionを実践してみる

メモ

無線LAN通信（IEEE802.11）における 802.11 frame injectionを調べていたときに、「frame injection に成功していることを他のデバイスで確認する方法」として Scapy による 802.11 frame injection を試していました。ところが、Scapy 2.1-dev のマニュアルの手順をそのまま実践しても、送信した 802.11 フレームを他のデバイスで観測できませんでした*1。

試行錯誤した結果、Scapy で送信した 802.11 フレームを他のデバイスで観測できました。この日記では、Scapy による 802.11 frame injection の実践方法と観測方法をメモしておきます。

実践環境

802.11 frame injection を実践した環境は以下の通りです。

  1. ノートPC
    • 「BackTrack 5 R3」*2を USB メモリから起動
    • Scapy(BackTrack 5 R3 に収録されているバージョン)
    • 802.11 frame injection が可能な無線 LAN ネットワークカードを準備
  2. Galaxy Nexus(SC-04D)
  3. iPad2

1 のノート PC で 802.11 frame injection を実施、2,3 の「Galaxy Nexus(SC-04D)」、「iPad2」で送信した 802.11 フレームを観測、という環境で実践しました。

Scapy による 802.11 frame injection

Scapy による 802.11 frame injection を実施する手順としては、Scapy を起動して以下を実行するだけです。これは、Scapy 2.1-dev のマニュアルの手順に RadioTap() を付与した手順となります。

sendp(RadioTap()/Dot11(addr1="ff:ff:ff:ff:ff:ff",addr2="00:11:22:33:44:55",addr3="00:11:22:33:44:55")/Dot11Beacon(cap="ESS")/Dot11Elt(ID="SSID",info="scapy-frame-injection")/Dot11Elt(ID="Rates",info='\x82\x84\x0b\x16')/Dot11Elt(ID="DSset",info="\x06")/Dot11Elt(ID="TIM",info="\x00\x01\x00\x00"),iface="wlan1mon",loop=1,inter=0.1)

上記 802.11 frame injectionを実行すると、0.1 秒ごとに SSID「scapy-frame-injection」の 802.11 Beacon フレームを送信できます。送信した 802.11 フレームを後述の観測方法で確認できました。実践環境にあわせて Dot11() の引数 addr2, addr3、sendp() の引数 iface, inter を変更します。

  • addr2
    • 無線 LAN ネットワークカードの MAC アドレスを指定
    • 上記では、説明上「00:11:22:33:44:55」に置換しています。
  • addr3
    • 無線 LAN ネットワークカードの MAC アドレスを指定
    • 上記では、説明上「00:11:22:33:44:55」に置換しています。
  • iface
  • inter
    • 802.11 フレームの送信間隔（単位：秒）を指定

送信した 802.11 フレームの観測方法

次の 2 つの方法で、Scapy で送信した 802.11 フレーム（Beacon フレーム）を観測できました。

アプリ「Wifi Analyzer」による観測

Android で動作するアプリ「Wifi Analyzer」を使うと、SSID ごとにシグナル強度[dBm]、使用しているチャネルなどが分かります。Scapy で 802.11 Beacon フレームを送信すると、指定した SSID がアプリ上に描画されます。SSID「scapy-frame-injection」で送信すると、下図のようになりました。この「Wifi Analyzer」の動作から、「Galaxy Nexus(SC-04D)」が Scapy で送信した 802.11 フレームを受信していると判断しました。

iOS の [設定]-[Wi-Fi] による観測

iOS の [設定]-[Wi-Fi]では、接続する無線 LAN アクセスポイント（SSID）を指定できます。Scapy で 802.11 Beacon フレームを送信すると、指定した SSID が接続できるネットワークに表示されます。SSID「scapy-frame-injection」で送信すると、下図のようになりました。この結果から、「iPad2」が Scapy で送信した 802.11 フレームを受信していると判断しました。


最後に、「Scapy 2.1-dev マニュアルの手順」、「この日記の手順」で送信した 802.11 フレームを Wireshark でテキスト出力した結果*3を掲載しています。興味がある方だけどうぞ。

「Scapy 2.1-dev マニュアルの手順」と「この日記の手順」における 802.11 フレームの違い

「Scapy 2.1-dev マニュアルの手順」を実行した場合でも、同ノート PC で動作する Wireshark では、送信した 802.11 フレームをパケットキャプチャできました。「Scapy 2.1-dev マニュアルの手順」、「この日記の手順」をそれぞれ実行して、Wireshark でパケットキャプチャした 802.11 フレームを比較してみると、次の点が異なりました。

  • RadioTap Header
    • 「Scapy 2.1-dev マニュアルの手順」の場合、invalid。
  • 送信された 802.11 フレームの数
    • 「Scapy 2.1-dev マニュアルの手順」の場合、1 フレーム。
    • 「この日記の手順」の場合、2 フレーム。
      • sendp() の引数 inter で指定した秒間隔で 2 つずつ送信していたことから判断。
Scapy 2.1-dev マニュアルの手順で送信した 802.11 フレーム
Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
    WTAP_ENCAP: 23
    Arrival Time: Dec  2, 2012 00:49:56.579624000 東京 (標準時)
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1354376996.579624000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 74 bytes (592 bits)
    Capture Length: 74 bytes (592 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: radiotap:wlan]
Radiotap Header v128, Length 0 (invalid)
    Header revision: 128
    Header pad: 0
    Header length: 0
IEEE 802.11 Beacon frame, Flags: ........
    Type/Subtype: Beacon frame (0x08)
    Frame Control: 0x0080 (Normal)
        Version: 0
        Type: Management frame (0)
        Subtype: 8
        Flags: 0x0
            .... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x00)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    Duration: 0
    Destination address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
    Source address: 00:11:22:33:44:55 (00:11:22:33:44:55)
    BSS Id: 00:11:22:33:44:55 (00:11:22:33:44:55)
    Fragment number: 0
    Sequence number: 0
IEEE 802.11 wireless LAN management frame
    Fixed parameters (12 bytes)
        Timestamp: 0x0000000000000000
        Beacon Interval: 0.102400 [Seconds]
        Capabilities Information: 0x0001
            .... .... .... ...1 = ESS capabilities: Transmitter is an AP
            .... .... .... ..0. = IBSS status: Transmitter belongs to a BSS
            .... ..0. .... 00.. = CFP participation capabilities: No point coordinator at AP (0x0000)
            .... .... ...0 .... = Privacy: AP/STA cannot support WEP
            .... .... ..0. .... = Short Preamble: Short preamble not allowed
            .... .... .0.. .... = PBCC: PBCC modulation not allowed
            .... .... 0... .... = Channel Agility: Channel agility not in use
            .... ...0 .... .... = Spectrum Management: dot11SpectrumManagementRequired FALSE
            .... .0.. .... .... = Short Slot Time: Short slot time not in use
            .... 0... .... .... = Automatic Power Save Delivery: apsd not implemented
            ..0. .... .... .... = DSSS-OFDM: DSSS-OFDM modulation not allowed
            .0.. .... .... .... = Delayed Block Ack: delayed block ack not implemented
            0... .... .... .... = Immediate Block Ack: immediate block ack not implemented
    Tagged parameters (38 bytes)
        Tag: SSID parameter set: scapy-frame-injection
            Tag Number: SSID parameter set (0)
            Tag length: 21
            SSID: scapy-frame-injection
        Tag: Supported Rates 1(B), 2(B), 5.5, 11, [Mbit/sec]
            Tag Number: Supported Rates (1)
            Tag length: 4
            Supported Rates: 1(B) (0x82)
            Supported Rates: 2(B) (0x84)
            Supported Rates: 5.5 (0x0b)
            Supported Rates: 11 (0x16)
        Tag: DS Parameter set: Current Channel: 6
            Tag Number: DS Parameter set (3)
            Tag length: 1
            Current Channel: 6
        Tag: Traffic Indication Map (TIM): DTIM 0 of 0 bitmap
            Tag Number: Traffic Indication Map (TIM) (5)
            Tag length: 4
            DTIM count: 0
            DTIM period: 1
            Bitmap control: 0x00
                .... ...0 = Multicast: False
                0000 000. = Bitmap Offset: 0x00
            Partial Virtual Bitmap: 00
この日記の手順で送信した 802.11 フレーム
No.     Time                       Source                Destination           Protocol Info
      1 2012-12-02 00:53:02.288311 00:11:22:33:44:55     ff:ff:ff:ff:ff:ff     802.11   Beacon frame, SN=0, FN=0, Flags=........, BI=100, SSID=scapy-frame-injection

Frame 1: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
    WTAP_ENCAP: 23
    Arrival Time: Dec  2, 2012 00:53:02.288311000 東京 (標準時)
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1354377182.288311000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 82 bytes (656 bits)
    Capture Length: 82 bytes (656 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: radiotap:wlan]
Radiotap Header v0, Length 8
    Header revision: 0
    Header pad: 0
    Header length: 8
    Present flags
        .... .... .... .... .... .... .... ...0 = TSFT: False
        .... .... .... .... .... .... .... ..0. = Flags: False
        .... .... .... .... .... .... .... .0.. = Rate: False
        .... .... .... .... .... .... .... 0... = Channel: False
        .... .... .... .... .... .... ...0 .... = FHSS: False
        .... .... .... .... .... .... ..0. .... = dBm Antenna Signal: False
        .... .... .... .... .... .... .0.. .... = dBm Antenna Noise: False
        .... .... .... .... .... .... 0... .... = Lock Quality: False
        .... .... .... .... .... ...0 .... .... = TX Attenuation: False
        .... .... .... .... .... ..0. .... .... = dB TX Attenuation: False
        .... .... .... .... .... .0.. .... .... = dBm TX Power: False
        .... .... .... .... .... 0... .... .... = Antenna: False
        .... .... .... .... ...0 .... .... .... = dB Antenna Signal: False
        .... .... .... .... ..0. .... .... .... = dB Antenna Noise: False
        .... .... .... .... .0.. .... .... .... = RX flags: False
        .... .... .... .0.. .... .... .... .... = Channel+: False
        .... .... .... 0... .... .... .... .... = HT information: False
        ..0. .... .... .... .... .... .... .... = Radiotap NS next: False
        .0.. .... .... .... .... .... .... .... = Vendor NS next: False
        0... .... .... .... .... .... .... .... = Ext: False
IEEE 802.11 Beacon frame, Flags: ........
    Type/Subtype: Beacon frame (0x08)
    Frame Control: 0x0080 (Normal)
        Version: 0
        Type: Management frame (0)
        Subtype: 8
        Flags: 0x0
            .... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x00)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    Duration: 0
    Destination address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
    Source address: 00:11:22:33:44:55 (00:11:22:33:44:55)
    BSS Id: 00:11:22:33:44:55 (00:11:22:33:44:55)
    Fragment number: 0
    Sequence number: 0
IEEE 802.11 wireless LAN management frame
    Fixed parameters (12 bytes)
        Timestamp: 0x0000000000000000
        Beacon Interval: 0.102400 [Seconds]
        Capabilities Information: 0x0001
            .... .... .... ...1 = ESS capabilities: Transmitter is an AP
            .... .... .... ..0. = IBSS status: Transmitter belongs to a BSS
            .... ..0. .... 00.. = CFP participation capabilities: No point coordinator at AP (0x0000)
            .... .... ...0 .... = Privacy: AP/STA cannot support WEP
            .... .... ..0. .... = Short Preamble: Short preamble not allowed
            .... .... .0.. .... = PBCC: PBCC modulation not allowed
            .... .... 0... .... = Channel Agility: Channel agility not in use
            .... ...0 .... .... = Spectrum Management: dot11SpectrumManagementRequired FALSE
            .... .0.. .... .... = Short Slot Time: Short slot time not in use
            .... 0... .... .... = Automatic Power Save Delivery: apsd not implemented
            ..0. .... .... .... = DSSS-OFDM: DSSS-OFDM modulation not allowed
            .0.. .... .... .... = Delayed Block Ack: delayed block ack not implemented
            0... .... .... .... = Immediate Block Ack: immediate block ack not implemented
    Tagged parameters (38 bytes)
        Tag: SSID parameter set: scapy-frame-injection
            Tag Number: SSID parameter set (0)
            Tag length: 21
            SSID: scapy-frame-injection
        Tag: Supported Rates 1(B), 2(B), 5.5, 11, [Mbit/sec]
            Tag Number: Supported Rates (1)
            Tag length: 4
            Supported Rates: 1(B) (0x82)
            Supported Rates: 2(B) (0x84)
            Supported Rates: 5.5 (0x0b)
            Supported Rates: 11 (0x16)
        Tag: DS Parameter set: Current Channel: 6
            Tag Number: DS Parameter set (3)
            Tag length: 1
            Current Channel: 6
        Tag: Traffic Indication Map (TIM): DTIM 0 of 0 bitmap
            Tag Number: Traffic Indication Map (TIM) (5)
            Tag length: 4
            DTIM count: 0
            DTIM period: 1
            Bitmap control: 0x00
                .... ...0 = Multicast: False
                0000 000. = Bitmap Offset: 0x00
            Partial Virtual Bitmap: 00

No.     Time                       Source                Destination           Protocol Info
      2 2012-12-02 00:53:02.289289 00:11:22:33:44:55     ff:ff:ff:ff:ff:ff     802.11   Beacon frame, SN=0, FN=0, Flags=........, BI=100, SSID=scapy-frame-injection

Frame 2: 87 bytes on wire (696 bits), 87 bytes captured (696 bits)
    WTAP_ENCAP: 23
    Arrival Time: Dec  2, 2012 00:53:02.289289000 東京 (標準時)
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1354377182.289289000 seconds
    [Time delta from previous captured frame: 0.000978000 seconds]
    [Time delta from previous displayed frame: 0.000978000 seconds]
    [Time since reference or first frame: 0.000978000 seconds]
    Frame Number: 2
    Frame Length: 87 bytes (696 bits)
    Capture Length: 87 bytes (696 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: radiotap:wlan]
Radiotap Header v0, Length 13
    Header revision: 0
    Header pad: 0
    Header length: 13
    Present flags
        .... .... .... .... .... .... .... ...0 = TSFT: False
        .... .... .... .... .... .... .... ..0. = Flags: False
        .... .... .... .... .... .... .... .1.. = Rate: True
        .... .... .... .... .... .... .... 0... = Channel: False
        .... .... .... .... .... .... ...0 .... = FHSS: False
        .... .... .... .... .... .... ..0. .... = dBm Antenna Signal: False
        .... .... .... .... .... .... .0.. .... = dBm Antenna Noise: False
        .... .... .... .... .... .... 0... .... = Lock Quality: False
        .... .... .... .... .... ...0 .... .... = TX Attenuation: False
        .... .... .... .... .... ..0. .... .... = dB TX Attenuation: False
        .... .... .... .... .... .0.. .... .... = dBm TX Power: False
        .... .... .... .... .... 0... .... .... = Antenna: False
        .... .... .... .... ...0 .... .... .... = dB Antenna Signal: False
        .... .... .... .... ..0. .... .... .... = dB Antenna Noise: False
        .... .... .... .... .0.. .... .... .... = RX flags: False
        .... .... .... .0.. .... .... .... .... = Channel+: False
        .... .... .... 0... .... .... .... .... = HT information: False
        ..0. .... .... .... .... .... .... .... = Radiotap NS next: False
        .0.. .... .... .... .... .... .... .... = Vendor NS next: False
        0... .... .... .... .... .... .... .... = Ext: False
    Data Rate: 1.0 Mb/s
IEEE 802.11 Beacon frame, Flags: ........
    Type/Subtype: Beacon frame (0x08)
    Frame Control: 0x0080 (Normal)
        Version: 0
        Type: Management frame (0)
        Subtype: 8
        Flags: 0x0
            .... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x00)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    Duration: 0
    Destination address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
    Source address: 00:11:22:33:44:55 (00:11:22:33:44:55)
    BSS Id: 00:11:22:33:44:55 (00:11:22:33:44:55)
    Fragment number: 0
    Sequence number: 0
IEEE 802.11 wireless LAN management frame
    Fixed parameters (12 bytes)
        Timestamp: 0x0000000000000000
        Beacon Interval: 0.102400 [Seconds]
        Capabilities Information: 0x0001
            .... .... .... ...1 = ESS capabilities: Transmitter is an AP
            .... .... .... ..0. = IBSS status: Transmitter belongs to a BSS
            .... ..0. .... 00.. = CFP participation capabilities: No point coordinator at AP (0x0000)
            .... .... ...0 .... = Privacy: AP/STA cannot support WEP
            .... .... ..0. .... = Short Preamble: Short preamble not allowed
            .... .... .0.. .... = PBCC: PBCC modulation not allowed
            .... .... 0... .... = Channel Agility: Channel agility not in use
            .... ...0 .... .... = Spectrum Management: dot11SpectrumManagementRequired FALSE
            .... .0.. .... .... = Short Slot Time: Short slot time not in use
            .... 0... .... .... = Automatic Power Save Delivery: apsd not implemented
            ..0. .... .... .... = DSSS-OFDM: DSSS-OFDM modulation not allowed
            .0.. .... .... .... = Delayed Block Ack: delayed block ack not implemented
            0... .... .... .... = Immediate Block Ack: immediate block ack not implemented
    Tagged parameters (38 bytes)
        Tag: SSID parameter set: scapy-frame-injection
            Tag Number: SSID parameter set (0)
            Tag length: 21
            SSID: scapy-frame-injection
        Tag: Supported Rates 1(B), 2(B), 5.5, 11, [Mbit/sec]
            Tag Number: Supported Rates (1)
            Tag length: 4
            Supported Rates: 1(B) (0x82)
            Supported Rates: 2(B) (0x84)
            Supported Rates: 5.5 (0x0b)
            Supported Rates: 11 (0x16)
        Tag: DS Parameter set: Current Channel: 6
            Tag Number: DS Parameter set (3)
            Tag length: 1
            Current Channel: 6
        Tag: Traffic Indication Map (TIM): DTIM 0 of 0 bitmap
            Tag Number: Traffic Indication Map (TIM) (5)
            Tag length: 4
            DTIM count: 0
            DTIM period: 1
            Bitmap control: 0x00
                .... ...0 = Multicast: False
                0000 000. = Bitmap Offset: 0x00
            Partial Virtual Bitmap: 00

*1:「実際には受信できているかもしれないが、僕の観測方法では分からなかった」という表現がより正確です。

*2:以前こんなつぶやきを書きましたが、「BackTrack 5」でも 802.11 frame injection に成功すると思います。つぶやき時点では、BackTrackのバージョン（収録されている Scapy のバージョン）依存を考えていました。

*3:[File]メニュー - [Export Packet Dissections] - [as "Plain Text" file...]の実行結果となります。実行時には、[Packet Format] の [Packet details] で「All expanded」を選択しました。掲載するにあたり、「Source address」,「Bss Id」だけは「00:11:22:33:44:55」に置換しました。

様々なブラウザで、ID・パスワードを含むURLでBASIC認証できるか確認してみた

調査

BASIC認証が必要となるWebサイトにアクセスする場合、URLにIDとパスワードを埋め込んでBASIC認証の入力ダイアログを表示させずに認証する方法があります（RFC 3986 3.2.1）。この認証方法を調べていたところ、Internet Explorer では MS04-004 以降無効になっていることを知りました（KB834489）。「では、他のブラウザではどうなのだろう」と思い、確認してみました。

確認結果

動作OS ブラウザ/バージョン 結果
Windows 7 SP1 Internet Explorer 9.0.8112.16421 失敗
Mozilla Firefox 16.0.2 成功（確認ダイアログ表示）
Opera 12.10 成功
Google Chrome 23.0.1271.64 m 成功
Android 4.0.4(Galaxy Nexus) ブラウザ 4.0.4-SC04DOMLE3 失敗
Chrome 18.0.1025464 成功
iOS 6.0.1(iPad2) Safari 成功（警告ダイアログ表示）
Chrome 21.0.1180.82 失敗
3DS Ver 4.4.0-10J インターネットブラウザー 1.7498 成功

確認手順、確認時のスクリーンショット（特徴があったもののみ）を以下にまとめます。

確認手順

以下の確認環境にて、1から3の手順で確認しました。


  1. ブラウザで http://192.168.0.1/ にアクセスして、BASIC認証のダイアログウインドウが表示されることを確認する（[キャンセル]を選択）。
  2. ブラウザで BASIC認証のIDとパスワードを含む http://user:password@192.168.0.1/ にアクセスする*1
  3. 2の結果から「成功」または「失敗」を判断する。

確認時のスクリーンショット（特徴があったもののみ）

Internet Explorer 9.0.8112.16421

前述の手順2にて、Internet Explorer 9 で http://user:password@192.168.0.1/ にアクセスしたところ、下記の画像のようにアクセスできませんでした。

Mozilla Firefox 16.0.2

前述の手順2にて、Firefox 16.0.2 で http://user:password@192.168.0.1/ にアクセスしたところ、下記の画像のように確認ダイアログが表示されました。このダイアログにて「OK」を選択すると、BASIC認証に成功して http://192.168.0.1/ にアクセスできました。「キャンセル」を選択すると、192.168.0.1 へのアクセスを中止できます*2。

ブラウザ 4.0.4-SC04DOMLE3

前述の手順2にて、ブラウザ 4.0.4-SC04DOMLE3 で http://user:password@192.168.0.1/ にアクセスしたところ、下記の画像のように BASIC 認証ダイアログが表示されました。これは手順1の結果と同様であったため、手順3では「失敗」と判断しました。

Safari（iOS 6.0.1）

前述の手順2にて、iOS 6.0.1 上の Safari で http://user:password@192.168.0.1/ にアクセスしたところ、下記の画像のように警告ダイアログが表示されました。このダイアログにて「この警告を無視」を選択すると、BASIC認証に成功して http://192.168.0.1/ にアクセスできました。

*1:このブログ記事でのidとpasswordは実際のものと異なります

*2:今回はパケットキャプチャデータまで確認していないため、実際に HTTP リクエストが送信されていないか確認していません。