追記

meta's blog - The Power To Serve

筆者について - No Unix, No Life

日本xrdpユーザ会発起人。

とある元大学院生の UNIX 系日記。FreeBSDを通じてOSSに囁かな貢献を。 FreeBSD ports contributor やってます。

For non Japanese native people:
If you are interested in my articles, please leave comments. I will do my best to give you articles in English.


2018-08-21 Mac版RDPクライアント10系が正式リリースされていた [長年日記]

Mac版RDPクライアント10系が正式リリースされていた

Microsoft公式のMac版リモートデスクトップクライアントには、2種類ありました。赤い四角いアイコンの8系と、青い丸いアイコンの10系です。青いアイコンの方は長らくBeta版で、App Store外からインストールする状態でしたが、めでたく10系が正式リリースとなっています。

Mac App Store では8系と10系は別アプリとして提供されているようです。

10系の正式リリースに伴い、旧版の8系はリタイアとなり、2018年9月以降8系はダウンロードできなくなります。


2018-08-09 自分のパスワードがメールで送られてきた [長年日記]

自分のパスワードがメールで送られてきた話

今朝、突然自分のパスワードがメールで送られてきました。以下がそのメール。メールアドレスとパスワードのみ伏せています。example.jp は自分のメールアドレスのドメイン名部分です。

From: Leann <info@example.jp>
To: meta@example.jp
Subject: meta@example.jp:__PASSWORD__

It appears to be that, (__PASSWORD__), is your password. You might not know me and you are most likely wondering why you're getting this e-mail, right?
 
actually, I setup a malware over the adult videos (adult) website and you know what, you visited this web site to have fun (you really know what What i'm saying is). When you were watching videos, your internet browser began functioning like a RDP (Team Viewer) which provided accessibility of your screen and web cam. after that, my software programs obtained your complete contacts from your Messenger, Microsoft outlook, FB, as well as emails.
 
What did I actually do?
 
I produced a double-screen video clip. First part shows the video you're watching (you've got a good taste haha . . .), and 2nd part shows the recording of your web cam.
 
exactly what should you do?
 
Well, in my opinion, $1200 is a reasonable price for our little secret. You will make the payment by Bitcoin (if you don't know this, search "how to buy bitcoin" search engines like google).
 
BTC Address: 1L8nG6ETuWEvoBkTS2GGx7oncATc9vkcq1
(It's case sensitive, so copy and paste it)
 
Important:
You've 1 day to make the payment. (I've a completely unique pixel within this e mail, and at this moment I know that you have read through this email message). If I do not get the BitCoins, I will certainly send your videos to all of your contacts including family, colleagues, and so forth. Having said that, if I get the payment, I'll destroy the video immidiately. If you want evidence, reply with "Yes!" and i'll definitely mail out your video recording to your 6 contacts. It is a non-negotiable offer, that being said don't waste my personal time and yours by responding to this message.

要するに、PCにマルウェアを仕込んでお前の恥ずかしい動画を撮ったから、友達や家族にその動画を送られたくなかったら1200ドルビットコインで払えという要求。そのメールに実際に使われていたパスワードをつけることによって、説得力を増すいうからくり。

パスワードは昔実際に使っていたもので、結構なサイトで使いまわしていました。2010年のTwitterパスワード強制リセットのときにはそのパスワードをTwitterのパスワードにしていました。

かなり多くのサイトで使いまわしていたパスワードなので、今となってはどこのサイトが流出させたものかはわかりませんが、どこかのサイトが流出させたメールアドレスとパスワードのリストを入手してメールアドレス宛に脅しめいたメールを送っているパスワードリスト型攻撃ですね。

Twitterパスワードの強制リセット当時、同じパスワードを使いまわしていたサイトのパスワードも同時に変えましたが、いくつかのサイトで未だに使っていたので一通りパスワード変更して対応完了。普段の生活環境はFreeBSDデスクトップなので、絶対にマルウェアを仕込まれないとは言いませんが他にもっと効果的なターゲットがいるのは明らかなので、ウェブカムで恥ずかしい動画を撮ったというのははったりとすぐにわかりました。

みなさんも、自分が実際に使っているパスワードが「お前のパスワードこれだろ?」というメールに書かれて送られてきても落ち着いて対応できますように。

自分以外にも同様のメールが届いている人がいるようです。

追記: こうやってブログを書いている間にも、同じような文面をちょっと変えたメールが何通も届いていました。同じパスワードがメールに含まれるのは最初にきたメールと同様。

一応拙訳置いときます。

あなたのパスワードは (__PASSWORD__) のように見えます。私のことはご存じないだろうし、なぜこんなメールを受け取っているのか不思議に思っていることでしょう。
実はとあるアダルトサイトを通じてマルウェアを仕込みました、例のあのサイトです。あなたはこのサイトを訪れてお楽しみでしたね(言っている意味がわかりますよね)。あなたが動画を見ている間、ブラウザがリモートデスクトップのように機能し、あなたの画面とウェブカムにアクセス可能でした。そして、メッセンジャーやメールからあなたの知り合いの連絡先を手に入れました。
私は何をしたでしょうか?
2画面の動画を作ったんです。片方があなたが見ていた動画(いい趣味してるね笑)、もう片方がそれを見ていたあなたをウェブカムで撮影したもの。

さあ、どうしますか?$1200 は私達の秘密の値段として高くないと思います。あなたはビットコインで支払いをすることになるでしょう(方法がわからなければググって)。

BTC Address: 1L8nG6ETuWEvoBkTS2GGx7oncATc9vkcq1

重要:
支払いまでに1日の猶予があります(1x1ピクセルのユニークな画像を仕込んでいるので、あなたがこのメールを読んだことはわかっています)。もし支払わなければ、さっきの動画をあなたの家族、友人などに送ります。支払えばすぐに動画を破棄します。証拠が欲しければ「Yes!」と返信してください。あなたの友達6人に動画を送ります。メールでのやり取りでお互いの時間を無駄にしたくないので、交渉の余地はありません。

訳注: 1x1の画像はなかった(メールはプレーンテキストだった)


2018-08-08 [長年日記]

freebsd-update したら ZFS のバージョンも上げるのを忘れずに

割と忘れるのでメモ。

freebsd-updatebuildworld 等ででFreeBSDのバージョンを上げたら、ZFSのバージョンも上がっていることがある。メジャーバージョンが上がるとZFSのバージョンも上がっていることが多いが、必ずしも上がるわけではない。

いつもFreeBSDのバージョンを上げただけで満足してしまうので、ZFS (zpool) のバージョンの確認も忘れないように。

$ zpool status -v                                                                                           
  pool: zroot1                                                                                                         
 state: ONLINE                                                                                                         
status: Some supported features are not enabled on the pool. The pool can                                              
        still be used, but some features are unavailable.                                                              
action: Enable all features using 'zpool upgrade'. Once this is done,                                                  
        the pool may no longer be accessible by software that does not support                                         
        the features. See zpool-features(7) for details.                                                               
  scan: resilvered 8.32M in 0h0m with 0 errors on Wed May 10 10:10:15 2017                                             
config:                                                                                                                
                                                                                                                       
        NAME                               STATE     READ WRITE CKSUM                                                  
        zroot1                             ONLINE       0     0     0                                                  
          mirror-0                         ONLINE       0     0     0                                                  
            diskid/DISK-WD-WMC4M3026594p3  ONLINE       0     0     0                                                  
            diskid/DISK-WD-WMC4M3152869p3  ONLINE       0     0     0                                                  
        cache                                                                                                          
          gpt/l2arc0                       ONLINE       0     0     0                                                  
                                                                                                                       
errors: No known data errors

zpool upgrade すると全ての機能が使えるようになるといわれるので、OS側のZFSの対応バージョンが上がっている。 あまり調子に乗って上げていると、トラブルが発生してOSのバージョンを下げる必要があるときに困ったことになる。

ファイルシステムのバージョンは基本的に下げられないと思っていたほうがいいので、OSの新しいバージョンが十分に安定稼働していることを確認してから上げたほうがよさそう。

ZFS (zpool) のバージョンを上げるには、言われたとおりのコマンドを実行する。

# zpool upgrade zroot1
This system supports ZFS pool feature flags.

Enabled the following features on 'zroot1':
  device_removal
  obsolete_counts
  zpool_checkpoint

If you boot from pool 'zroot1', don't forget to update boot code.                                                      
Assuming you use GPT partitioning and da0 is your boot disk
the following command will do it:

        gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

最後に、ブートローダーも新しいZFS対応のものに上げないと起動できなくなるのでこれはきっちりやっておく。da0は適宜読み替える。

以上、手順自体は今更メモしておくほどのことではないけど、ZFSのバージョンを上げるのを数年忘れていたので思い出しついでにメモ。


2018-08-07 [長年日記]

Amazon Route 53 Health Check の User-Agent が変わっていた

Amazon Route 53 Health Check で HTTP/HTTPS でヘルスチェックするときの User-Agent が変わってました。

新旧はこんな感じ(UUIDはダミーです)。

旧:

Amazon Route 53 Health Check Service; ref:b0eb04d5-cb5e-40e7-839b-558e52fc3f0d; report http://amzn.to/1vsZADi

新:

Amazon-Route53-Health-Check-Service (ref b0eb04d5-cb5e-40e7-839b-558e52fc3f0d; report http://amzn.to/1vsZADi)

Apache 側で以下のようにしてヘルスチェックのアクセスはログに残さないようにしていたので、User-Agent が変わっていていつのまにか全部ログに残っていました。

SetEnvIf      User-Agent      "Amazon Route 53 Health Check Service;.*"       nolog
CustomLog     /path/to/access_log combined env=!nolog

ログによると、JSTで 11/Jul/2018:02:03:16 +0900 からこのUser-Agentでアクセスしているっぽい。

ちょっとググったところ、以下のAWSフォーラムの投稿が見つかりました。以前のUser-Agentのセミコロンの使い方がよくないということで、それを反映した変更っぽい? RFC7231を斜め読みしただけではいまいちよく理解できてないけど、( ) の中にセミコロンが登場するのは許されるということだろうか。


2018-07-31 SoftEther VPN でRADIUS認証時に送信される Attribute [長年日記]

SoftEther VPN でRADIUS認証時に送信される Attribute

SoftEther VPN でRADIUS認証を使用する際、RADIUSサーバに送られるAttributeを調査したのでメモ。

本当はソースコードを参照するべきかもしれないが、とりあえずパケットキャプチャして調査。IPsec over L2TP で接続した場合の結果。

AVP: l=6 t=User-Name(1): username
AVP: l=34 t=User-Password(2): Encrypted
AVP: l=22 t=NAS-Identifier(32): SoftEther VPN Server
AVP: l=6 t=Service-Type(6): Framed(2)
AVP: l=6 t=NAS-Port-Type(61): Virtual(5)
AVP: l=6 t=Tunnel-Type(64) Tag=0x00: PPTP(1)
AVP: l=6 t=Tunnel-Medium-Type(65) Tag=0x00: IP(1)
AVP: l=5 t=Called-Station-Id(30): rad
AVP: l=14 t=Calling-Station-Id(31): (VPN接続元IPアドレス)
AVP: l=14 t=Tunnel-Client-Endpoint(66): (VPN接続元IPアドレス)

SoftEtherはVPN接続時、@suffix をつけることによって接続先の仮想ハブを制御することができるので username@hub というフォーマットでユーザ名が与えられたら、@ で分割して usernameUser-Name に、 hubCalled-Station-Id にセットしたRADIUSサーバに送信する。

本来のユーザ名に@を含む、メールアドレス形式のような場合は username@example.com@hub とするとRADIUSサーバに送信されるユーザ名は username@example.comCalled-Station-Idhub となる。

NAS-IdentifierCalled-Station-Id の組み合わせを見ると、いろいろ細かく制御できるかもしれない。

802.1X で Wi-Fi の認証を行う場合

余談として、802.1X で Wi-Fi の認証を行う場合は Called-Station-Id にAPのMACアドレスと、接続しようとしているSSIDをセットして送信する。SSIDごとに接続できるユーザを制御したいという場合、このあたりを見れば良さそう。

まともなAPの場合、RADIUS認証のAttributeはRFC3580準拠で送信しているはず。

AVP: l=6 t=User-Name(1): username
AVP: l=6 t=NAS-IP-Address(4): 192.168.0.24
AVP: l=6 t=NAS-Port(5): 0
AVP: l=23 t=Called-Station-Id(30): 00-00-00-00-00-00:SSID
AVP: l=19 t=Calling-Station-Id(31): 01-01-01-01-01-01
AVP: l=6 t=Framed-MTU(12): 1400
AVP: l=6 t=NAS-Port-Type(61): Wireless-802.11(19)
AVP: l=23 t=Connect-Info(77): CONNECT 0Mbps 802.11a
AVP: l=96 t=EAP-Message(79) Last Segment[1]
AVP: l=18 t=State(24): 7e1b872e76259ebf56d52794715f8ebb
AVP: l=18 t=Message-Authenticator(80): 9040a06e011eaeb51518a6fa683f0293

2018-07-30 tDiary の記法を GFM に変更してみた [長年日記]

tDiary の記法を GFM に変更してみた

このブログで使用している、tDiary の記法をGFM に変更してみた。今までは Wiki スタイルだったけど、 OSS の開発をする上で GFM や GF でない Markdown で書くことも多いので統一されていたほうが書くのが 楽かと思って。

tDiary では各エントリ毎にどの記法で書いたかが保存されているので、過去に書いたものは過去に書いたもの で引き続き Wiki スタイルで運用できる。

変更するには、tDiary のソースディレクトリのトップにある Gemfile に

gem 'tdiary-style-gdm'

を追加する。追加したら bundle install して tdiary.conf

@style = 'Wiki'

という行を GFM に書き換えるだけ。なのだけど、このブログをが動いているサーバは FreeBSD なので、gem のインストールで引っかかった。idn-ruby という gem をインストールする際に libidn を見つけられなかったのが原因なので、これだけ libidn の場所を指定しインストールしてやる。

bundle exec gem install idn-ruby -v 0.1.0 -- --with-idn-lib=/usr/local/lib --with-idn-include=/usr/local/include

あとは bundle install の続きをやっておしまい。

とりあえず GFM でしばらく書いて見よう。


2018-05-07 [長年日記]

xrdp v0.9.5 以前と Windows 10 の組み合わせでコード 0x80004005 のエラーが発生する問題

正確な日付は記憶していないのですが、2018年のGW中にリリースされた Windows 10 Insider Preview と xrdp v0.9.5 以前の組み合わせにおいて、「認証エラーが発生しました (コード: 0x80004005)。」というエラーが発生して Windows クライアントから xrdp に接続できないという問題が発生しています。

2018年5月という日付と、リモートデスクトップという単語の組み合わせから、以下の問題を連想する方が多いかもしれませんが、0x80004005 エラーと CVE-2018-0086 CVE-2018-0886 の修正は無関係です。

2018-05-15 16:28 追記: 下記リンク先のマイクロソフトの記事において、CVE番号が間違っています。正しくは CVE-2018-0886 です。

発生条件

サーバ側

  • xrdp v0.9.5 以下
  • OpenSSL 1.1.0 未満 (OpenSSL 1.0.x)

クライアント側

  • Windows 10 Insider Preview Build 17661.rs_prerelease.180428-1349
  • 今後 Insider Preview でない通常リリースでも発生するかもしれません

その他

  • クライアント・サーバ間の通信モードがTLSであること

何が起こっているか

Microsoft Remote Desktop Protocol (以下MS-RDP) には、RC4により通信を暗号化する従来のモード(もはや安全でない)と、TLSにより通信を暗号化するTLSモードが存在しますが、TLSによる暗号化を使用する場合に本問題が発生します。

上記のバージョンの Windows 10 Insider Preview 以降、リモートデスクトップクライアント(以下mstsc)がTLSモードで使用する暗号化スイートに変更があり、Forward securecyを満たす暗号化スイートのみを使用するようになったようです。

Forward securecy については筋よく説明しているサイトが他にたくさんあるので、ここで詳しくは説明はしませんが暗号化に使用する鍵に一時的な(Ephemeral)な鍵を定期的に交換して使用し、認証用の公開鍵が漏洩しても通信内容の解読を困難にするものです。ECDHE-DHE- が頭につく暗号化スイートがそれです。

一方でxrdpにTLSが実装された最初のまともなリリースであるv0.9.1からv0.9.5以前のバージョンには、OpenSSL 1.1.0 未満との組み合わせで使用した場合、Forward securecyを満たす暗号化スイートが使用されないというバグがありました。このバグは以下のissueで修正され、v0.9.6には含まれています。

ここまで書くと察しの良い方はお気づきになるかもしれませんが xrdp v0.9.5 以前と OpenSSL 1.1.0 未満の組み合わせにおいて、クライアント側はForward securecyを満たす暗号化スイートを要求するにも関わらず、サーバとなるxrdp側はそれを使用できないという状態に陥ります。ここで暗号化スイートのミスマッチが起こりネゴシエーションに失敗、接続できないという結果になります。

対処方法

対処方法は、先に上げた発生条件をどれか1つでも崩せばいいわけですから簡単です。Windowsのバージョンを下げることや、TLSによる暗号化を使用しないのは安全でない場合が多く、おすすめしません。OpenSSLのバージョンを1.1.0以降に上げるのも、OSにかなり根深い部分を触ることになる可能性があり、非常に面倒なのでできれば行いたくないですね。

というわけで、最も簡単なのは xrdp のバージョンを v0.9.6 以降に上げることです。この記事を書いている時点では v0.9.6 が最新です。xrdpとクライアントとの間でどんな暗号化が使用されているかを知るには、/var/log/xrdp.log を見てください。接続時に以下のようなログが記録されるはずです。

[20180507-15:02:00] [INFO ] TLS connection established from ::ffff:192.168.0.60 port 51710: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384

このログの場合は、コネクションはTLSv1.2によって保護され、暗号化スイートは ECDHE-RSA-AES256-GCM-SHA384 であることがわかります。