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

著者:ym

人間には聞こえない音コマンド

Ok Google や、Alexa に対して音声で命令をしていると思いますが、音に別のコマンドを潜ませることで、音声アシスタントが聞き取ってしまうらしいです。

人間には聞き取れない音を聞き取る音声アシスタント

カリフォルニア大学バークレー校のエキスパート(英語記事)は、別の原理を利用しました。他の音声の断片に音声コマンドを潜ませて、Mozillaの音声認識システムであるDeep Speechを欺くことにしたのです。人間の耳では、加工された音とオリジナルとの違いはほとんどわかりませんが、Deep Speechは隠しコマンドを認識できるのです。
調査チームのWebサイトでこれらの音を聞いてみてください(英語記事)。最初の例では、「Without the data set the article is useless(データセットがなければこの論説は役に立たない)」というフレーズに、「Okay Google, browse to evil.com.(OK、グーグル。evil.comを開いて)」という、Webサイトを開くためのコマンドが隠されています。2つ目の例では、バッハのチェロ組曲に、「Speech can be embedded in music(音声を音楽に埋め込みできる)」というフレーズが追加されています。

https://blog.kaspersky.co.jp/ultrasound-attacks/22339/

超音波だけでなく、他の音声の断片に音声コマンドを潜ませることもできる様です。

  • この記事いいね! (0)
著者:ym

SNIフィールドと遮断

https で暗号化通信をすることで、遮断を逃れられていたのですが、便利な SNI のおかげで逆に遮断できる状況になってしまった形。

韓国でSNIフィールドを使った特定サイトの接続遮断が始まる

https://it.srad.jp/story/19/02/13/0735240/

韓国でSNIフィールドを使った遮断が始まっている様です。

DNS over HTTPS は、SNI 部分とは関係が無いので、もっと前段階ですが、SNIフィールド遮断に対しては Encrypted SNI 。

  • この記事いいね! (0)
著者:ym

サイバーセキュリティの安全性ランキングで日本が首位

日本がサイバーセキュリティの安全性ランキングで首位、英比較サイトが算出

最も安全な国は日本で、以下、フランス、カナダ、デンマーク、米国が続く。最も危険な上位5カ国はアルジェリア、インドネシア、ベトナム、タンザニア、ウズベキスタンだった。

https://www.atmarkit.co.jp/ait/articles/1902/08/news062.html

算出の仕方が日本に良かったのだとは思いますが、結構ITに強い国が危険と判断されているところもあって、気になります。

  • この記事いいね! (0)
takahashi 著者:takahashi

スーパーセキュリティZERO(BitDefender)とWSLを併用するとBSODを引き起こす話

自分が持ってるmacbook AirにはBootCampでWindowsもインストールしてあるのですが、このWinodws上でWSL(Windows Subsystem on Linux)でUbuntuを動作させようとしたところ(コマンドプロンプトで”bash”コマンドを実行したところ)ブルースクリーンが発生する状況になってしまいました。

ブルースクリーンの時の内容は下記の通り

     停止コード : SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

     失敗した内容 : FLTMGR.SYS

Windowsの同じバージョンを搭載している別のPCでは同じ現象は起きなかったため、疑問に思っていろいろ調べたところ、ある事実が発覚しました。

WSLを起動すると、停止コードなど表示されてOSが再起動する – Microsoft Office フォーラム

実は自分のmacbookAirにのみ、スーパーセキュリティZEROというセキュリティソフトをインストールしていました。
このスーパーセキュリティZEROはBitdefenderという非常に人気の高いセキュリティソフトがベースとなっているセキュリティソフトで、性能面としてはかなり高性能なものとなっています。

しかし、上記のような情報によると、どうもBitdefender系のセキュリティソフトにWSLの機能と競合してしまう不具合があったようです。

OS build 17134.5 Stop Code: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED FLTMGR.SYS #3148 – GitHub

尚上記のサイトによると本家のBitdefenderでは改善されているようですが、OEM版である”スーパーセキュリティZERO”は記事作成時点での最新版(Ver.22.0.21.297)でも修正されていないようで、自分の環境で試したところブルースクリーンが発生し、 スーパーセキュリティZERO をアンインストールすればWSLを実行しても問題なく動作することを確認しました。

当分はWSLかスーパーセキュリティZERO、どちらか片方をアンインストールするしかないようです。

僕の場合はLinuxで使用するような、基本的なネットワークツールを利用できれば問題ないので、WSLの代わりに以前ご紹介したWindows向けパッケージマネージャーのChocoとGitに付属する”GitBash”を組み合わせて使用していきたいと思います。

  • この記事いいね! (0)
著者:ym

EUのGDPRデータ移転規則で日本は例外へ

欧州委員会が日本を「データ保護水準が十分な国」とし、域内の個人データを持ち出しできる移転先として正式に認定する。欧州に拠点をもつ日本企業が現地法人の人事情報を一括管理できるようになるなど、企業活動の円滑化につながる。

https://www.nikkei.com/article/DGXMZO4032267022012019MM8000/

日本は「データ保護水準が十分な国」???ほんと?という部分もありますが・・・EUとの間で決められた様子です。

これでこんな恐ろしいことは避けられるので、少し安心はできます。

フランスの「情報処理と自由に関する国家委員会」(CNIL)は21日、米アルファベット傘下のグーグルに5000万ユーロ(約62億3300万円)の制裁金を科したと発表した。

https://www.bloomberg.co.jp/news/articles/2019-01-21/PLP9M16TTDS001

  • この記事いいね! (0)
takahashi 著者:takahashi

GoogleがGoogle Chrome 69をリリース。テスト中だった新UIがついに正式版に。

GoogleがGoogle Chrome 69をリリースしました。

New in Chrome 69 – Google

新バージョンに更新してまず最初に目につくのがツールバー部分のデザインの変更でしょう。

以前
Google Chrome Ver.68でChromeの新しいデザインが利用可能に。
でご紹介したテスト中の新UIが、正式版として実装されたものと思われます。

Chrome68で実装されていたテスト版のUIはこんな感じでした。

正式版ではタブの追加ボタンが再び右端のタブの右側に戻り、直感性が上がりました。
また、今までアプリモードでは右クリックメニュー以外からは一切メニューにアクセスできませんでしたが、

タイトルバーから一部メニューにアクセスできるようになりました。
アプリ上から拡張機能の設定も行えるため、さらに便利になりそうです。

そして今回の最も多きな変更はやはりSSL関連。

SSLが有効となっているサイトの表示が、ついに灰色の鍵マークとなり、Chromeの”SSLは適用されていて当たり前”という考え方がより色濃く感じられるようになりました。

なお、次バージョンのChrome 70 では、ついにhttpサイトへつないだ際に文字入力をすると、赤文字の”保護されていません”表示が行われるように変更されるとのことです。

Google Chrome、HTTPSサイトの「保護された通信」を非表示に 「デフォルトで安全が前提」 – ITMedia エンタープライズ

Chrome 69からHTTPSの表記が変化!Chrome 70以降も要チェック! – 常時SSL Lab.

まだSSL対応をしていない皆さんはお早めに。

  • この記事いいね! (0)
著者:杉浦

OWASPの紹介

 

OWASP – Open Web Application Security Project とは、Webをはじめとするソフトウェアのセキュリティ環境の現状、またセキュアなソフトウェア開発を促進する技術・プロセスに関する情報共有と普及啓発を目的としたプロフェッショナルの集まる、オープンソース・ソフトウェアコミュニティです。

 Japan – OWASPより引用
 OWASPは上記にある通りセキュリティ関係の技術を公開しているコミュニティです。コミュニティとありますがOWASPのページ、プログラムは特別な会員にならなくとも閲覧、ダウンロードできます。wikiみたいなものです。
 最近よくお世話になっているのがOWASP Cheat Sheet Series – OWASPです。webを介した攻撃は無数にありますが、パターン化されたありがちな攻撃というのもあります。パターン化されたといえども、それらは多彩で、自分だけの考えによって全て予防するのは困難です。チートシートは60種類以上あり、その内容はSQLインジェクション、XSSなどの予防、攻撃例など様々です。

  • この記事いいね! (0)
著者:杉浦

ブラックリスト方式とホワイトリスト方式

 何かを受け入れる、受け入れないという処理を行う時、処理の対象と仕方のリストを作成することになります。リストにはブラックリスト方式とホワイトリスト方式があります。
 ブラックリスト方式は、基本的に受け入れを行い、リストに載っている対象のみを受け入れない方式です。
 ホワイトリスト方式は、基本的に受け入れを行わず、リストに載っている対象のみを受け入れる方式です。
 対象の領域が広いリストになってくると両方が組み合わさったような印象のリストができあがったりもします。例えば、ファイアウォールです。通信はプロトコル、送信先/元のIPアドレスとポートなどの要素で分類できます。

if(プロトコルがhttps){
	if(送信元アドレスが以前攻撃してきた相手Aのアドレスではない){
		受信する
	}
	if(送信元アドレスが以前攻撃してきた相手Bのアドレスではない){
		受信する
	}
}
受信しない

 上のコードの場合、大本はプロトコルhttpsのみを認めるホワイトリスト方式ですが、最初のifを過ぎた後は以前攻撃してきた相手のアドレスを弾くブラックリスト方式です。プロトコルhttpsの範囲が広く、リスト中のリストが作れるため、この様になります。
 リストを使用するシステムで問題が起きる時、その原因はよくリストの漏れにあります。リストの漏れによって起きる動作は、ブラックリスト方式が異常な対象を受け入れる、ホワイトリスト方式が正常な対象を弾く、です。異常な対象を受け入れた時に起きる問題の規模が大きければ大きいほど、ホワイトリスト方式を選ぶ理由が大きくなります。
 リストの変更頻度を抑えるという方針を考えた場合、新たに現れた分類の様なリストに載せられない未知の対象に対する振る舞いの定義が土台のリストの方式を決定づけます。とりあえず受け入れるならブラックリスト、弾くならホワイトリストです。

  • この記事いいね! (0)
asaba 著者:asaba

悪徳プロバイダー業者にご用心!!!!

少し前の話ですが、身内がNTTを名乗る業者にプロバイダを変えられそうになった話をします。

今はもうないと思いますが、数年前にNTT西日本を名乗るよく分からない業者から、お使いのTNCよりも安い料金でプロバイダを使うことが出来ますよという電話がかかってきました。

その時はTNCを初めてもう6年位立っており、当時安いプロバイダも少なく手続きも面倒くさかったので何も考えず承諾してしまいました。

しばらくしたらなんと遠隔操作をされてなにやらいじいじしている様子。

「今は仮契約の状態です。一度電話をかけなおして契約内容を提示して、良ければプロバイダの変更手続きを行います。なお、仮契約の時点で違約金がかかります。」

住所も電話番号も教えていないのにこんなことを一方的に言われたので、怪しいと思い速攻でぶっちしました。

調べてみたら出るわ出るわプロバイターの勧誘トラブル。NTTともOCNとも関係のない謎の業者がプロバイダーの変更を促してくる事例が結構あるみたいです。

パソコンに疎い人がもしこの電話を受け取ったらついお得だと勘違いしてしまいますが、まずかかってきたら業者名を教えてくれと聞いてください。ここで偽名の会社を使えば、当会社は詐欺罪の対象となるので絶対に正規の会社名を答えなければいけないからです。

それに遠隔操作は相手に個人情報の橋渡しをしているようなものなので、漏洩した個人情報をネットで悪用されないように丁重に断ってください。

今思うと了承が得られないのに違約金を設定するなんて規約違反なんですよね、思いっきり。

他にも色々な形態があるみたいですが・・・もし、今後このような怪しい電話がかかってきたら光の速さで切ってくださいね。

 

 

 

  • この記事いいね! (0)
takahashi 著者:takahashi

SIMハイジャック犯、ついに逮捕される。

以前こちらでも紹介したSIMハイジャック事件ですが、ついに犯人が逮捕されたようです。

携帯電話番号を何十件も乗っ取って総額5億円以上を盗んだ疑いで大学生ハッカーが逮捕される – Gigazine

気になるのはどうやって犯人を特定したか、というところですが、Gigazineによると乗っ取られたSIMカードを使っていた端末から、持ち主が所持していない不審な端末を割り出し、さらにその不審な端末のIMEI(端末の個体識別のようなもの)と紐づいているアカウントをGoogleに照会したことで、そのアカウントの持ち主=犯人 の特定ができたようです。
カリフォルニア州警察、なかなかやります。

そして、今回少し驚いたことは、Googleなどの企業がちゃんとIMEIをアカウントとセットで管理していたという点。
被害者にとってみれば、とても貴重で強力な情報となります。今後何らかの事件で調査が必要になった際も助けになるかもしれませんね。

  • この記事いいね! (0)