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

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)
takahashi 著者:takahashi

Google Chrome Ver.68がついにリリース。非SSLサイトにすべて”保護されていません”メッセージが表示されるように

ついに来てしまいました…

「Google Chrome 68」公開、HTTPサイトには容赦なく警告を表示する仕様に – INTERNET Watch

以前から予告されていたGoogle Chromeで非SSLサイトに接続した際に”保護されていません”メッセージが、先日リリースされたChrome Ver.68からついに表示されるようになりました。

いままでは非SSLサイトにアクセスした際はiアイコンが表示され、フォームなどに何か文字を入力したときだけ”保護されていません”と表示されるだけでしたが、今後はすべての非SSLサイトには”保護されていません”と表示されるようになります。

もっとも、事情を知っている人にとってはメッセージが変わってもさほど行動が今までと変わることはないように思えますが、インターネット業界の事情にあまり詳しくないユーザーが見たら驚いてアクセスしなくなってしまう可能性は十分に考えられます。

自分でサイトを運営している場合は、Let’s Encryptを利用することで、無料のSSL証明書の取得も可能となっています。

まだ対策されていない方はお早めに…

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

恐ろしすぎる”SIMハイジャック”の恐怖

ネットニュースの記事で、こんなニュースが流れてきました。

電話番号が奪われてしまうSIMハイジャックの脅威とは? – Gigazine

によると、アメリカではある日突然、SIMカードが”乗っ取られて”しまう”SIMハイジャック”なるサイバー攻撃が増加しているようです。

上記の記事によると、アメリカのMNOであるT-Mobile社を利用するユーザーの端末のもとに、ある日突然SIMカードが更新されたというメッセージが届き、それ以降その端末がモバイルネットワークへ接続不可能となってしまったとのこと。
ユーザーの家族がユーザーの番号へ電話をかけたところ、全く知らない人物が電話に出て、SIMをハイジャックしたことを暴露した…という流れ。

被害にあったユーザーは電話番号で認証情報を連携していたSNSや各Webサービスのアカウントをごっそり乗っ取られてしまったそうです。

そしてこの原因が驚くことにキャリアの本人確認不足。
その気になればだれでも手に入ってしまう情報のみで本人を断定し、まったくの第三者に対して、SIMを再発行して渡してしまったようです。

こちらの記事も、同様の被害にあい、仮想通貨を奪われてしまったユーザーのケースです。

ハッキングで仮想通貨を盗まれた海外の投資家がTモバイルを告訴!なぜ仮想通貨取引所ではなく携帯電話会社を訴えたのか、詳細まとめ! – やさしいビットコイン入門講座

こちらの記事では何故か訴訟した側を叩くような流れになっていますが、本人確認を怠った時点で明らかにT-Mobile側の落ち度であり、多数の被害者がいるにも関わらず今のところ対策が注意喚起のみという、通信事業者としてあり得ない事態となっています。

最近のサイバー攻撃は、システムからそれを管理する”人”を対象としたものにシフトしています。システムの技術的な”あら”を探すより、それを管理する管理者を騙した方がはるかに簡単だからです。
管理者が”クラッキング”されている現状が続く以上、どんなに堅牢なシステムを築いたところで全くの無意味となってしまうでしょう。

ちなみに、日本国内では法律で厳密な本人確認が義務付けられており、手続きを行う際は必ず身分証の原本が求められるようになっているなど、しっかりとした個人認証が行われています。

携帯電話の犯罪利用の防止 – 総務省

失敗を犯した存在に後ろ指を指すのは簡単です。
モバイルネットワーク事業者に限らず、何らかのサービスを提供している立場に自分自身がいる場合は、本人確認は厳密に行うように心がけていきたいですね。

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

クラックされてしまったWPA2の改良版、WPA3策定が完了

Wi-Fiは物理的な接続である有線LANと違い、電波が届く範囲内であればどこにいても接続が可能です。
そのため、物理的なケーブルであれば、不正につないでいる人を見つけることは大抵は難しいことではありませんが、無線であるWi-Fiの場合は電波が届けば接続出来てしまうので、誰かが不正に接続していても気づかないことがあります。

そういった場合を防ぐために、Wi-Fiには”パスワードがわかる人しか繋げられない”ようにする機能があります。
この機能、つまりWi-Fiの認証と暗号化の機能はいくつか規格があるのですが、いままで破られにくいとされていた”WPA2″が主流として使われていました。

ところがこのWPA2の認証を突破できてしまう”KRACKs”という攻撃方法が発見され、その堅牢性は崩れることになりました。

WPA2の脆弱性「パッチで対応可能」 Wi-Fi標準化団体が見解 – ITMedia

WPA2は業界共通の”標準規格”のため、簡単にアップデートすることは難しく、当面はパッチで対応する形でしのいていました。

そして今回、WPA2のアップデート版であるWPA3がついに策定されました。

新しいWi-Fiセキュリティ規格「WPA3」登場 – ITMedia

WPA3は、WPA2との互換性を維持しつつもKRACKsなどへの対策もされているとのこと。

 WPA3では、WPA2デバイスとの相互運用性を維持しながらPMF(Protected Management Frames:管理フレーム保護)を必須とした。また鍵確立手法を従来のPSK(Pre-Shared Key:事前共有鍵)から新しいSAE(Simultaneous Authentication of Equals:同等性同時認証)に変更。ハンドシェイクの手順や認証の再試行回数を変更して各種攻撃への耐性を上げた。

今後発売される機器にはWPA3が搭載されることになりそうです。
また、ファームウェアアップデートが可能な機種でも、もしかすると利用可能になるかもしれません。

今後の動きに注目していきたいですね。

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

Twitter Yubikey security

Twitter がログイン時の認証として、物理的な USB キーの認証に対応をしたようです。

Twitter Safety(@TwitterSafety)さん – Twitter

Google 認証アプリはやめて、最近は IIJ ワンタイム生成アプリを使うようにしているので、機種変更したときでも以外とスムーズに移行はできているけど、そろそろ、指なUSBキー、YubiKeyも使い始めようかな。

USBだけじゃなくてNFC 対応品が良いとか考えると、結構高いんですよね。

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

[間もなくGoogle ChromeでSSL必須化。確認しておくべきこと。] WebサイトSSL化の際に潜む罠

前回の記事では、WebサイトのSSL化に必要な証明書について説明をしました。今回は証明書に加えてサイトのSSL化に必要なこと説明します。

実は、サイトのSSL化を行うためには、単にSSL証明書をインストールして”https://”でアクセスする…だけではダメな場合があります。

例えば、httpsのサイトにアクセスした際に画像の赤枠のような盾のアイコンが出てくることがあります。

実はこれ、Chromeによって、セキュリティ上の問題でサイトの一部のコンテンツをブロックした際に表示されます。

なぜブロックされたのかは”開発者ツール”を開いてみるとわかります。
F12を押してみてください。

画面の端に、赤枠のような部分が出てきます。
これが開発者ツールです。

たとえば、このページの1行目のエラー。
内容を簡単にいうと”このサイトはhttpsでアクセスしているのに、同サイト内にhttpでアクセスしているリンクが混ざっている。”

といった感じになります。
実は、サイト自体へのアクセスはhttpsになっていても、サイト内に含まれている画像、css、javascriptなどへのリンクがhttpになっていると、基本的にブロックされてしまいます。

これは、リンクされているコンテンツが不正に乗っ取られた場合、アクセス先のサイトがたとえhttpsであったとしても表示を改変されたり、入力した情報が盗まれてしまう場合があるためです。

こういったセキュリティ上の問題も確実に防止するために、Chromeをはじめとする最近のブラウザでは、httpsサイト内にあるhttpリンクをブロックする様になってきています。

ではどのように対策すればいいのか、というところですが、先ほど書いたようにjavascript、css、画像などへのリンクがhttp://で書かれてしまっていることが原因なので、それらをすべてhttps://で始まるように書き換えてしまえばOKです。

ただし、リンク先がSSLに対応していないと、httpsに書き換えただけでは利用できません。その場合はまずリンク先のサイトをSSLに対応させる必要があります。
また、もし自分で触ることのできないリンク先がSSLに未対応の場合、残念ながらSSL対応させたサイトでは利用できません。

代替えの方法を用意する必要があります。

少しでも参考になりましたら幸いです。

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