Edgeブラウザ、PDFを印刷すると表示と異なる数字に
Windows 10専用のブラウザEdgeはPDF表示が可能ですが、印刷するとおかしなことになる場合があると判明しました。
「大笑い案件：Edgeブラウザ、"123456"という表示を印刷すると"114447"に」
「Edgeに危険なバグ、表示と印刷で数字が異なってしまう」
Anniversary Update適用後、Creators Update適用前のEdgeのPDF処理にバグがあり、数字が印刷すると違ってしまう模様です。
Creators Updateでは直っているそうですが、基本的にはPDFは本家のAcrobat Readerを使ったほうがいいんじゃないでしょうか。
インストール時に他のソフトを入れようとしてくるのは困りものですが。
電話網を支えるSS7プロトコルの脆弱性、悪用例が発覚
全世界で使われている電話網プロトコルSS7（共通線信号No.7）については、以前から脆弱性が知られており、かつて米議会でもTed Lieu議員が追及し、さらに同議員のアカウントを（もちろん本人の同意のもと）使った実験をテレビ番組「60 Minutes」が扱ったこともありました。
そして、この脆弱性を利用した銀行アカウントのハッキングが「実際に」起こっていることが判明しました。
「2要素認証で守られた銀行アカウント、SS7プロトコルの悪用で漏洩」
独Süddeutsche Zeitung紙の記事が最初に報じた模様です。
これは、予めマルウェアでパスワードを盗んだ状態からスタートします。パスワードで銀行側にログインし、送金を指示すると、2要素認証が求められるのですが、そこでSS7の脆弱性をついてSMSを横取りし、送金を完了するというわけです。ちなみに従来は被害者の携帯電話のSIMカードを複製してSMSを盗み出していたのだとか。
SMSを使った2要素認証は、近年強く推奨されてきましたが、SS7の脆弱性を含めて問題点があることも知られています。
米NISTの案では「セキュアな認証用アプリ」「生体認証」が挙げられていますが、その他にもYubiKeyなどのハードウェアの利用も考慮に値するでしょう。
MonoのUDPは、制限ブロードキャストの受信に制約あり
これも個人的な調査結果です。
Windows/.NET(4.5)とLinux(Ubuntu16.04)/Mono(4.2.1)での通信を試していたのですが、どうもうまく動作しませんでした。調べた結果、次のようなことが明らかになりました。
- Linux/Monoで、IPAddress.Anyにバインドした場合、ブロードキャスト通信は受信可能
- Linux/Monoで、特定のIPアドレスにバインドした場合、ブロードキャスト通信は受信不可能
- Windows/.NETでは、どちらのバインドでも、ブロードキャスト通信の受信は可能
これは同一環境、同一プログラムで、バインド先IPアドレスだけを変えることで再現します。
検索してみた結果、どうやらMonoのUDP通信は、自らのサブネット外から受信した場合は棄却し、受信処理が一切動かないらしいと判明しました。
実は、送信には制限ブロードキャストを使っていました（IPAddress.Broadcastで簡単に使えるのと、特にルータを超える必要がなかったので）。
制限ブロードキャストを受信するには、IPAddress.Any（0.0.0.0）にバインドする必要があるということで。
ちなみに、IPv4の（制限ではない）ブロードキャストアドレスを求めるためにはサブネットマスクが必要ですが、MonoのUnicastAddress.IPv4Maskプロパティは、長らく実装されておらず、NotImplementedExceptionだったようです。ようやくMono4.4.0（2016-06-08リリース）で実装されました。
https://bugzilla.xamarin.com/show_bug.cgi?id=2033bugzilla.xamarin.com
http://www.mono-project.com/docs/about-mono/releases/4.4.0/www.mono-project.com
2033 - UnicastAddress.IPv4Mask throws NotImplementedException on Mono 2.10 running on open-embedded Linux
※「open-embedded」とありますが、実際はBugZillaを読む限り「Win32以外の全てのプラットフォーム」のバグです。
Monoのソースを見る限り、UnicastIPAddressInformationクラスのプロパティの大半は、いまだに未実装ですね……。
Miraiに見せかけた新ボット、セキュリティカメラに侵入中
「新たなIoTボットネット、脆弱なセキュリティカメラを通じて勃興」
WiFiを搭載したセキュリティカメラのうち、一部のホワイトボックス系の機種に搭載されたGoAhead Webサーバの脆弱性を研究者たちが指摘してきたものの、対応が全く進んでおらず、PoC公開に至っていました。
新しいボットはこの脆弱性をついて侵入するもので、調べた研究者は「Miraiを装っただけの別もの」という見解を示しています。
記事時点で、このボットによると思われる81番ポートのスキャン元6万弱、1日に300万弱のスキャンを行っているようです。また、この脆弱性をもったカメラは、20万台程度はインターネットに接続されているようです。既にロシアの銀行へのDDoSも行われているなど、実害が出ているようです。
米ISPのモデムで大規模障害、原因はBrickerBotか
「米国のプロバイダ、2つのマルウェアによるモデムをめぐる戦いにより落とされる」
4月10日に、米国のプロバイダSierra Telの利用者の間で異常が発生しました。ネットと電話が接続不能になったのです。これは同社が配布していたZyxelのモデムHN-51が外部からの攻撃により故障したのが原因でした。
BrickerBotの作者とみられるjanit0r氏からのメールがBleepingComputerに届きました。
「その頃BrickerBotがSierra Telのネットワークで活動していた。彼らのモデムは以前からマルウェアの大規模感染を受けていたので、付随的にネットワークトラブルが起きたのかもしれない」。
というわけで、記事の筆者（セキュリティニュースを他でもよく扱うCatalin Cimpanu氏）は、Sierra Telのトラブルの原因はBrickerBot（のPlan B）の可能性が高いと考えているようです。BrickerBotは、先日も書いたように、janit0r氏が言うには、可能なら破壊せずにMirai等の侵入を防ぐものの、不可能だった場合はPlan Bとして破壊(Brick)を行うとのこと。
プロバイダのモデムは、まさにインターネットにつながっていながら、しばしば脆弱なので、こういったマルウェアの格好のターゲットになります。昨年からドイツや英国でもプロバイダのトラブルが相次いでます。
BrickerBot、さらにバージョンアップ中
BleepingComputerが作者とみられる人物との接触に成功した「侵入先の脆弱なIoT機器を場合によっては破壊する」BrickerBotですが、さらにバージョンアップが続いている模様です。
「BrickerBot：復讐とともに再来」
以前の調査時点ではバージョン1と2があったBrickerBotですが、さらに3と4も放たれていることが判明しました。ただし、中身はいずれもスクリプトを少し改変した程度です。
