証明書あれこれ

2018/07目標でHTTPS化なんてのがチラホラ。
chrome68が「SSL以外危険マークにするわ」に慌てふためくというわけですな。

証明書についてどれを選べばいいんだー、ってのについて
認証局とかに聞くと　EV>OV>DVっていうみたい。EVは(｀・ω・´)ｼｬｷｰﾝとブラウザが緑になるので、
いいやん、って思うかもだけどその企業自体が信頼に値するかは別問題だよなぁ・・。


今日調べたまとめ

証明書は3種類あって、

DV　ドメイン認証
OV　組織認証
EV　実在認証（OVの確認方法を厳密化、認証局を横串して規格化）

現密度は

EV>OV>DV といわれているが、
ユーザーから見れば、ドメインが信頼できるのか、
企業名が信頼できるのか、ということでしかないため、
安全度が違うか、というと別の次元になる。

EVの場合はブラウザが緑マークにしてくれる。
OVとDVの区別には証明書のサブジェクトを確認して、
Oを確認する。
ここがドメイン表記であればドメイン認証（DV）、
企業名であればOVである。
ただ、その企業が信頼に値するかどうかと、そのドメインが
信頼に値するかは別の話なので、OVだから、DVだから、は意味が無い。

世論の流れと認証局の稼ぎ（DV

DHE鍵交換の仕組み

たまにはセキュリティの話でも。

DHE鍵交換の仕組みの式を解説してみる

サーバーは任意の（ｇ，ｐ）を選択する。この時ｐは大きな素数であることが望ましい

作成したｇとｐをクライアントへ送信する（これは非暗号通信なので盗聴される可能性がある）

クライアント、サーバーは任意の数字 a , b を決定する。この数字はお互いに知り得ない情報である。

サーバーがa、クライアントがbを用いて以下の値を計算する（nがa、bに相当）

$A\hspace{0.17em}= g^a mod p$

$B\hspace{0.17em}= g^b mod p$

計算したAとBを送受信する（これも盗聴される可能性がある）

受信したAとBに対して、以下の計算を行う

$K_A\hspace{0.17em}= B^a mod p$

$K_B = A^b mod p$

このとき、$K_A\hspace{0.17em}$　と　$K_B\hspace{0.17em}$は同じ値になるので、これを暗号キーとして用いる

同じ値になる理由についてもっと詳しく説明する

多項式の性質として、以下が成り立つ場合は

$r= a mod p$

次の式が成り立つ。

$a^n mod p = r^n mod p$

二項定理で分解していけば、最後の　$r^n$以外はpの次数が１以上なのでmodでは消せるためである。

とすると、$B^a mod p = g^{ba} mod p$となり、

$A^b mod p = g^{ab} mod p$となるので、同じ値になるわけである。

gとpとAとBは盗聴されてしまうかもしれないけれど、そこからaとbを計算することが難しいので、
成り立っている暗号方式である。例えばある数Xを7で割った余りが3だったとわかっていても、Xは3,10,17,24,..... と無限に可能性があるためです。

ISO規格覚えられん・・・(´・ω・｀)

語呂合わせとかないものかなぁ・・。

中身は覚えられても、番号がきつい。

【ISO/IEC 17788】  クラウドコンピューティングの概要と用語を規定した国際規格
【ISO/IEC 24759】  暗号モジュールの試験要求事項

【ISO/IEC 27036-4】サプライヤリレーションシップの情報セキュリティ−第４部：クラウドサービスのセキュリティの指針
【ISO 22313】      事業継続マネジメントシステム−手引き

【ISO 26000】　SR（社会的責任）、CSR（企業の社会責任)に関する規格

JIS Q 15001     個人情報保護マネジメント（Pマーク認証基準）

JIS Q 27001　 譲歩セキュリティマネジメントシステム（ISMS認証基準）

ほかにもまだまだあるんだよなぁ・・。

情報処理安全確保支援士登録完了

交付からもう１週経っちゃったけど、無事に「情報処理安全確保支援士」に登録されました。😃

試験合格自体はずいぶん前なので、早速集合講習があるみたいです。

場所が遠くなければいいんだけど。

ロゴマーク使えるけど、登録番号も載せないとなので、

ちょっと思案してます。名刺とかに使うにはいいんだけど、

番号は公開されているので、ネットに晒すのは躊躇するというかなんというか。

Cookieの有効範囲と省略時の動作について

結果オーライでdomain無指定がうまく機能している状況を目の当たりにして

どういう動きか説明する資料を作成するために、情報収集したので、備忘録しておこう。

Cookieの仕様とセキュリティ > domain指定

http://www.yunabe.jp/docs/cookie_and_security.html#domain

domain を指定しない場合は、Set-Cookie を送信したホストにのみクッキーは送信されます。 domain 属性なしで、example.com によって設定されたクッキーは www.example.com や docs.example.com には送信されません。 domain を省略した場合と、domainに今接続しているホスト名を指定した場合ではクッキーが送信される範囲が異なる点に注意が必要です。 サブドメインに送信されてはならないクッキーには domain 属性はつけてはなりません。

CookieのDomain属性は *指定しない* が一番安全 〜徳丸浩の日記

http://blog.tokumaru.org/2011/10/cookiedomain.html

    Domain属性を指定しないCookieは、Cookieを発行したホストのみに送信される
    Domain属性を指定したCookieは、指定のホストおよびそのサブドメインのホストに送信される

すなわち、Domain=example.comを指定したCookieは、www.example.comにも送信されます。Domain属性を指定しないCookieは、example.comに送信され、www.example.comには送信されません。
これは、CookieのRFC2965（旧規格）、RFC6265（現規格）には明確に記述されています。

    3.3.1 【中略】
    Domain Defaults to the effective request-host. (Note that because there is no dot at the beginning of effective request-host, the default Domain can only domain-match itself.)
    http://www.ietf.org/rfc/rfc2965.txt

    4.1.2.3. The Domain Attribute
    【中略】If the server omits the Domain attribute, the user agent will return the cookie only to the origin server.
    http://www.ietf.org/rfc/rfc6265.txt

RFCからの引用があるとお偉い方も納得してくださる。RFC偉大。

cipherのマッチング順序制御

デフォルトはクライアント優先

以下のパラメータが有効であると、サーバーが優先（SSLv3、TLS1.0の時）

Apache

SSLHonorCipherOrder 

Nginx

ssl_prefer_server_ciphers

BIGIP

Cipher server preference

IHS

無い。常にサーバーが優先

Does IHS have anything like mod_ssl's SSLHonorcipherorder?

No, IHS always uses the servers preference (acts like 'SSLHonorcipherorder on');

http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhonorcipherorder

https://devcentral.f5.com/articles/ssl-profiles-part-5-ssl-options

http://publib.boulder.ibm.com/httpserv/ihsdiag/ssl_questions.html

うむ、見事にバラバラである。

誕生日攻撃 CVE-2016-2183

誕生日のパラドックスからもじったんだ。

しらんかった。わかりやすいようなわかりにくいような・・・。

https://access.redhat.com/ja/node/2607321

https://okuranagaimo.blogspot.jp/2016/08/sweet32-64.html

我々はブラウザとウェブサイト間を長期間トリプルDESのHTTPS通信を監視できるネットワークの攻撃者が785GBのトラフィック量をキャプチャすることでセキュアなHTTPクッキーを再生できることを示す。

785GBがいまどきの感覚で多いのか少ないのか、議論が分かれそうですな。

https://ja.wikipedia.org/wiki/%E8%AA%95%E7%94%9F%E6%97%A5%E3%81%AE%E3%83%91%E3%83%A9%E3%83%89%E3%83%83%E3%82%AF%E3%82%B9

https://ja.wikipedia.org/wiki/%E8%AA%95%E7%94%9F%E6%97%A5%E6%94%BB%E6%92%83

Dirty COW

ロゴといい、サイトといい脆弱性ビジネスの香りが若干するが・・・。

ローカルユーザーから権限を昇格させたり、ReadOnlyファイルに書き込んだりできる。

外部からは厳しいね。

なにかの脆弱性経由でシェル取られた後なら可能だろうけど。

http://dirtycow.ninja/

http://www.itmedia.co.jp/enterprise/articles/1610/24/news044.html

http://japan.zdnet.com/article/35090987/

https://access.redhat.com/security/vulnerabilities/2706661

https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13

https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails

POC

https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs

small WindowSize DOS

攻撃手法としては古めかなー。

大抵のFW製品やIPSは検知してくれるだろうしね。

slowlorisとか懐かしいな。めがねサルだかリスの画像が出てくるんだよね。

個人鯖とかだとmod_antilorisとかmod_security2をコンパイルビルドして、バーリアッ！しなきゃならんが

エンタープライズな環境だと、専用の防御サーバーが居るだろうしそっちに任せるが

役割分担的にもいいんでないかなー。両方守っておけばそりゃいいけどさ。

備忘録としてメモ

http://www.acunetix.com/blog/articles/slow-http-dos-attacks-mitigate-apache-http-server/

https://www.npa.go.jp/cyberpolice/detect/pdf/20151216.pdf

https://www.npa.go.jp/cyberpolice/topics/?seq=17339

http://news.mynavi.jp/news/2015/12/28/347/

https://blog.qualys.com/securitylabs/2012/01/05/slow-read

https://security.radware.com/ddos-knowledge-center/ddospedia/naptha-attacks/

https://kc.mcafee.com/corporate/index?page=content&id=KB60305&locale=ja_JP&viewlocale=ja_JP

http://www.cs.northwestern.edu/~akuzma/rice/doc/shrew.pdf

http://code.google.com/p/slowhttptest/

Nprton WiFi Privacy

iPhone7が発表されて、各キャリアからも20GBとかのプランが出だしたから、
WiFiを利用しないという手も取れるけれども、それでもYoutubeやニコ動を1時間も見れば
パケットは1GBぐらいいくわけなので、やっぱり公衆WiFi使いたいよねぇ。
とはいってもセキュリティ的にアカンやつとかもあるので、自衛したい。
自分の情報を狙われるというより、踏み台にされることが怖い気がするね。

そこで、安心安全信頼のノートン先生のVPN
https://itunes.apple.com/jp/app/id1095519285
アンドロイド版もあるみたいよ。

ちょっと検証してみたけど、テザリングしているとVPNにならない。
（WiFi接続、USBやBlueToothは未検証だし、仕様なのかどうかも未確認）

（１）iPhone　　（VPN-ON）
（２）iPad(WiFi版）をiPhoneへテザリング

この状態で確認くんしてみると（１）はちゃんと西海岸なりドイツなりになるが
（２）はSoftBank（筆者はSoftBankキャリア）になる。
中国に出張をよくする友達に聞かれて確認してみた。
行ったことないけど、中国のネットはやっぱ怪しいらしい。
研究職だからかすごい気にしていたね。

【セキィリティ】日本語版はどういう感じでくるんだろうか・・。

いや、この記事の件だけどね

”話す” ランサムウェアを確認
http://blog.trendmicro.co.jp/archives/6446

ランサムウェアってのは過去にも何回か取り上げたことあるけど、
身代金要求型ウイルスな。

弊社では、「TROJ_REVETON.HM」として検出する新たなランサムウェアを確認していますが、これは、氷山の一角でしょう。近い将来、歌うランサムウェアといった、更に改良が施された不正プログラムが登場するといっても過言ではないかもしれません。

歌うは無いやろ・・・(;´Д｀)
「カネハラエー、イマースグ、ドーナッテモシランゾー♪」てか？

後、英語やロシア語で語りかけられてもわからんぞ、というかもしれない。
だが、分析によると稼働しているPCの位置から、その地の言語で話すらしい。

トレンドマイクロは、警察を装う新たな不正プログラムの亜種が、罰金を吊り上げるために「声」を備えたと報告を受けました。この亜種（「TROJ_REVETON.HM」として検出）は、感染したコンピュータを動作不能にしますが、ユーザに支払いを促すために単にメッセージを表示するのではなく、音声でもこの支払いを強いるのです。感染ユーザは、不正プログラムが何を言っているのかを知るために翻訳する必要はありません。不正プログラムは、感染ユーザが位置する国の言語を喋ります。

流暢な日本語でくるのか、ゆっくりボイスでくるのか、河内弁なのか広島弁なのか、丁寧語なのかヤクザ風なのか、
どうでもいい方面が気になってしまうなぁ。

【セキュリティ】Samsungの最新CPU搭載端末に脆弱性 遠隔操作される恐れ

サムスン、モバイル端末向けプロセッサ「Exynos 4210/4412」に全ての物理メモリーに
アクセスできる脆弱性がある可能性

全ての物理メモリにアクセス≒なんでもできる　ということですな。
いやはや。恐ろしいですねぇ。

公式発表はまだないので、対策としてはぁゃιぃアプリを入れない、ぐらいしかないですね。
まぁ、私はAndroid端末一つももっとらんので、対岸の火事なんですけれども。

詳しくは参考情報先へ。
該当機種としてはこれららしい。

■ 日本国内で Exynos 4210 または Exynos 4412 を搭載してる端末

Galaxy S2 SC-02C -NTTドコモ
GALAXY Tab 7.0 Plus SC-02D – NTTドコモ
Galaxy Note 2 SC-02E – NTTドコモ
Galaxy S3 alpha SC-03E – NTTドコモ
Galaxy S2 WiMAX ISW11SC – KDD au


参考情報
http://gpad.tv/develop/samsung-exynos-4210-4412-exploit-root-full-access/
http://gigazine.net/news/20121217-samsung-galaxy-malware/
http://forum.xda-developers.com/showthread.php?t=2048511

Ram dump, kernel code injection and others could be possible via app installation from Play Store. It certainly exists many ways
to do that but Samsung give an easy way to exploit. This security hole is dangerous and expose phone to malicious apps.
Exploitation with native C and JNI could be easily feasible.

JNIって聞くとなんかﾑｯﾊｰってしませんか。しませんか。そうですか('A`)

[セキュリティ] ２０１２／１０のJDK/JRE脆弱性を利用した攻撃の存在を確認

まぁ、健全な皆様は普段はJavaアプレットオフにして、アップデートは毎日チェックが
当たり前なので、問題ないかもしれませんがね、
将棋倶楽部２４に熱中しすぎてJavaアプレットオフを忘れてしまうとかいう失態を行うことも
あるわけですよね。
まぁ、俺なんだが。（攻撃コードは踏んでないよ）

https://www-304.ibm.com/connections/blogs/tokyo-soc/entry/java_20121112?lang=ja_jp

これに出てくるランサムウェアってのは身代金要求型マルウェアのこと。
分かりやすく言うと
「きさまの大事な大事な彼女（嫁でも子供でも大事なものと置き換えてくれ）の写真はロックした！
返して欲しくば金はらえ！」
的な極めて姑息な攻撃をする。

しかし、普段Javaで飯喰わして貰ってる俺が言うのもなんだが、
アプレットって本当にまだ要る技術なのかなぁ・・・(´-ω-`)
確かにmake at once , do any ware の効果は大きい。
いろんな環境で使われることが想定されるようなものを各バージョン毎に用意するのはナンセンスだしね。
しかしローカルアプリならまだしも、アプレットである必要が本当にあるのかな。
WEBサーバー機能だけ持たせておいて、jarのダウンロード、あとは起動方法のリンクだけ書いておくとか。
でもそうすると、クリック一つで管理コンソールが起動する、というメリットが消えてしまい
いちいちダウンロード＋コマンドという手間が必要になる。これを受け入れがたい現場とかも確かにあるんだろうなぁ。一度普及してしまったものはそう簡単には無くせない。

一方Appleはjavaのサポートを見限った。
http://developer.apple.com/library/mac/#releasenotes/Java/JavaSnowLeopardUpdate3LeopardUpdate8RN/NewandNoteworthy/NewandNoteworthy.html

意訳
appleはもうしらん。oracleから勝手にダウンロードしてやれ。

まぁ、何にせよJREを消せない人は、
　(1)普段はアプレットオフ
　(2)こまめなアップデート
　(3)大事なファイルが有る（それへアクセスできるも同じ意味）マシンでぁゃιぃサイトへ行かない

これぐらいの古典的対策しか無いのが現状。
ゼロデイもあるので、ノートン先生やマカフィーがあればおｋとはいかないんだなぁ。

不正監視によってブロックされました！俺自身が俺の手によって！

ウイルスバスターのアップデートが！

(1)パターンファイルの自動更新が始まる
(2)システムに変更を加えようとしています！でブロック
(3)アップデート中です。中断しないでください。　でフリーズ
(4)スタート-ファイル名を指定して実行-tistool から「全ての製品を停止」
(5)停止する前にアップデートを終了させてください
＼(^o^)／オワタ
(6)無視して再起動する
(7)(1)へ
本格的に＼(^o^)／オワタ／

いまどきサポートも切れてる2010（パターンの更新は大丈夫）を愛用していたのがダメだったのか。
覚悟を決めて「くらうど」とやらに更新した。
ファイアウォールも無いし、毛嫌いしていたんだが更新されなくなったサードベンダーのものよりも
更新されているMSのがよいか、という解釈で。

まぁ、結果解ってたことだけど、PCがモッサリ化した。
タスクリストからはバスター関連プロセスが原因とわかっているけどね！

もうT42限界かなぁ。

[ｾｷｭﾘﾃｨ]Slow read Dos

英語で言えばかっこいいがな。
牛歩戦術というかなんというか。

興味があれば
http://www.computerworld.jp/topics/563/%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%83%BB%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88/201426/%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E7%A0%94%E7%A9%B6%E8%80%85%E3%81%8C%E6%96%B0%E3%81%9F%E3%81%AAHTTP%20DoS%E6%94%BB%E6%92%83%E6%89%8B%E6%B3%95%E3%82%92%E8%80%83%E6%A1%88%E2%80%95%E2%80%95%E6%A4%9C%E7%9F%A5%E3%81%97%E3%81%AB%E3%81%8F%E3%81%84%E7%89%B9%E5%BE%B4%E3%82%82

hashdos

いろんなこと考える人居るなぁ･･･。(´-ω-`)

アルゴリズムそのものに対する攻撃なので対策は無いというのがまた。
エントリー数を減らしてしまえば問題ないし、改ざんされるわけじゃないみたいだが。

CPUの処理速度が早くなれば成り立たなくなる攻撃でもあるのかな。

http://blog.tokumaru.org/2011/12/webdoshashdos.html
http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html
http://cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos/

POCのリンクもあったんだけど、やめとこ。

[ｾｷｭﾘﾃｨ]ランサムウェア

名前はかっこいいシリーズ。
なんか久々だな。

ランサムウェアとは・・・？
http://internet.watch.impress.co.jp/docs/news/20101203_411460.html
http://www.symantec.com/connect/blogs-138
http://www.keyman.or.jp/3w/prd/21/30002321/
http://blog.trendmicro.co.jp/archives/2899

身代金要求型ウイルスとでもいうのかな。
本当にRSA4096暗号とかかけられたら分子コンピューターとかもってこない限り無理である。
RSAて輸出規制なかったっけ・・・。4096ビットとかいいんだっけ・・？
うーむ、ソースでてこんな。

[ｾｷｭﾘﾃｨ]httponly ねぇ

ちょっと考えればわかるじゃろ。
scriptからアクセスできないからってブラウザにデータが来てないわけじゃない。

ということは、余裕で突破される。相手の方が絶対上手なんだよ。
小手先でどうにかしようとしてもダメ。王道的対応が必要

以下のリンクが一刀両断していて気持ちいい。
http://itpro.nikkeibp.co.jp/members/NBY/Security/20040809/148386/?ST=tech_dev

U+202E

Unicodeは便利だが便利過ぎて怖い面もある。
切れすぎる包丁というかナイフというか。

U+202E (RIGHT-TO-LEFT OVERRIDE）という制御コードを用いれば
拡張子偽装が簡単にできてしまう。
アイコンや、説明文も合わせて改ざんされていると
はっきり言って区別できない。
（中身を見るとかはあるだろうけど）



※これは説明やアイコンは偽装していません

例の様なファイル名だと突然exeが名前に出てくるのでぁゃιぃと
感づくかもしれないが、英語名などに混ぜ込まれるとわかりにくくなる。

対策としては、windowsの標準機能にてブロックしてしまうことが
考案されている。

U+202E (Right-to-Left Override;RLO)使用の拡張子偽装法を防ぐには：拡張子を表示させる設定でも危険！
http://d.hatena.ne.jp/famnet/20090408/1239193335

[SECURITY] Unicodeで拡張子を偽装された実行ファイルの防御方法
http://d.hatena.ne.jp/hasegawayosuke/20061222/p1

1. メモ帳を開いて、"**"と入力する(前後の引用符は不要)。

2. "*"と"*"の間にキャレット(カーソル)を移動させる

3. 右クリックで「Unicode 制御文字の挿入」から「RLO Start to right-to-left override」「RLO Start of right-to-left override」を選択

4. Ctrl-A で全て選択、Ctrl-C でクリップボードにコピー。

5. ローカルセキュリティポリシーを開く

6. 画面左側の「追加の規則」を右クリック

7. 「新しいパスの規則」を選択

8. 「パス」欄で Ctrl-V をして、メモ帳の内容を貼り付ける。

9. セキュリティレベルが「許可しない」になっていることを確認して「適用」

以上で、this-(U+202E)txt.exe(表示は this-exe.txt) のような、拡張子が偽装されたファイルの実行を禁止できる。


※5　ｺﾝﾄﾛｰﾙﾊﾟﾈﾙ-管理ﾂｰﾙ-ﾛｰｶﾙｾｷｭﾘﾃｨﾎﾟﾘｼｰ
※6　ソフトウェア制限のポリシー-右ｸﾘｯｸ-新しいポリシーの作成
　　 追加の規則…（以下同じ）

windowsのシステムも例によって逆に読まれてしまうので、
１ファイルぐらいならDELを押してみると・・・



このようにファイル名中にRLOが入っているため、

「'秘密[RLO]gpj.exe'をごみ箱に移しますか？」
↓
「'秘密？かすまし移に箱みごを'exe.jpg」

と謎の日本語になる。
怖いですなぁ・・。

レジストリ破損から復活するには

いつものようにwindowsの電源をいれてら、
「
次のファイルが存在しないかまたは壊れているため、Windows を起動できませんでした: \WINDOWS\SYSTEM32\CONFIG\SYSTEM
」
というメッセージと共に懐かしいDOS画面が出てきて
ｶﾞ━━(ﾟДﾟ;)━━━ﾝ!!　とかなった人も居るだろう。

まぁ、賢いみんなはﾊﾞｯｸｱｯﾌﾟからｼｽﾃﾑ戻して終了。
ﾃﾞｰﾀなんて別保管だから痛くもかゆくも無いはずだよネ。

後学のために、強引に治す方法は
・回復コンソールで頑張る
　Repairフォルダからバックアップを戻す方法
http://www.e-joy.co.jp/supp/faq/winxp/00014.htm
http://support.microsoft.com/kb/307545/ja
http://qanda.rakuten.ne.jp/qa3506122.html

などだが、ﾌﾟﾘｲﾝｽﾄｰﾙ機などで、Repairフォルダにバックアップなんか
ねーよ！！な場合、（*.bakはあるかもしれない）
さらに酷いことになりかねない。（コンソールすら無理になったり）

そんなことになっても、我らがknoppix様ならなんとかなったりする。
　knoppixでシステムドライブをマウントし、System Volume Informationから最新のバックアップを戻す方法

「System Volume Information」に感謝。
http://ymch.jp/blog/?mode=all&no=2380
http://totoro0306-lj.hp.infoseek.co.jp/60/VAIO.htm
KNOPPIXでsystemファイルを修復
http://mogg.blog.ocn.ne.jp/mogg/2008/08/knoppixsystem_0ae7.html
http://www.rcis.aist.go.jp/project/knoppix/
http://pasokoma.jp/44/lg447999.html

こっちの方法がGUIでサクサクとパスワードもなんにも無しで
できてしまうので、っていいのかそれ・・(;´Д｀)

こういう方法でダメなら物理破損を疑ったほうがいい。
それよりknoppix超便利だけど、怖い。windowsｾｷｭﾘﾃｨが
まったく役に立っていない。最近のものはUSBﾒﾓﾘからもﾌﾞｰﾄできるし、
そのUSBﾒﾓﾘの容量も16GBとかあるのでぶっこぬきもできてしまう。

対策として考えられることは物理的にﾃﾞﾊﾞｲｽをロックしておく、
BIOSパスワードをかけておき、外部ブートできなくする、
HDDを暗号化する、などなど。

しかし、これを施すと逆に今回のような症状のときに治せないという
ことになるので、バックアップは大事ですぜ。