Against MiTM Attack

中間者攻撃対策を報告するブログです。ブロックすると良いscam関連のサイトのURLも紹介する他、コラムも公開するブログです。

脆弱性@ウェブサイト男子プロ及び女子プロ を愉快に読む の件 Facebook未公開記事

ハニーポットを不正インストールしやがった手口はもはや私にバレた。

 

次はこのバカの敵の攻撃を良く知ることである。

 

This Metasploit module exploits a arbitrary file upload vulnerability within the Baldr stealer malware control panel.

セキュリティテストツールのメタスプロイトのモジュールと呼ばれるプログラム、つまり、各種のツールがあるのだが、そのツールの1つは、データ窃盗用のマルウェアのコントロールパネルの機能として、被害者の脆弱性を攻撃し、適当に選んだファイルを、窃盗用アップロードストリームを使ってアップロードする攻撃に使うことができる。

 

Attackers can turn this vulnerability into remote code execution by adding malicious PHP code inside the victim logs ZIP file and registering a new bot to the panel by uploading the ZIP file under the logs directory.

攻撃者つまり詐欺師は、騙し用にアップロードした、圧縮ファイルへPHPのコードを追加する小細工をし、脆弱性と間違えるようなバカげた細工を施す。

 

On versions 3.0 and 3.1 victim logs are ciphered by a random 4 byte XOR key.

このマヌケな小細工は、メタスプロイトのツールのバージョン3と3.1で起こる。

犯人によって壊されたログは、バカげているとわかる。暗号を解読するための4バイトの秘密キーを適当に選んで使うからである。

 

This exploit module retrieves the IP specific XOR key from panel gate and registers a new victim to the panel with adding the selected payload inside the victim logs.

狩猟に使われるイヌがIPアドレスを探すストーリーのコミックが無いため、このタイミングでそういうコミックを想像すると良い。なぜなら、アップロードした暗号化されたファイルを解読するキーをログに残して楽をして騙そうとする様子にピッタリの動物がイヌだからである。

 

 

不正にアップロードしておいて、後で自分でイヌのようにアップロードした圧縮ファイルの中のIPアドレスを探しているから、コイツはバカだ、と人類からバカにされるのである。

 

ココまでが意訳。ココからは私の実体験したミスについて書く。

 

自業自得、自爆テロ、と私が呼ぶミスの1ジャンルがある。内部設計を考えすぎ、難しくなってしまって、後からコードを読み直す時に、アッチコッチ読むハメになる。アレを直すとコッチも見ているから影響が大きい、というケースである。

 

共通系クラスを使っているのだが、親子の関係にあるソレらのクラスの親と子を使い分けて、後で多態性を用いて個別のビジネスロジック用のエンティティクラスにデータを取らせてラッパーの先のエンティティに格納して、ソレを戻してビューに渡すだけなのだが、親と子が持つインターフェースクラスのメゾッドの使い分けが詳しく書けないのだが、かなり工夫してしまっており、何がこのインターフェースの先の意味になっているのか難しくなるようなデータをフラグで持たせちゃったりしていたりするので、コレがフィルターからシグネチャに入る、まではまあいいとして、そこから先に何がどうなっているのか読み直さないとわからない。デバッガを使ってみると、よくできているとはいえ、新規に直すためだけにクラスを作る方がまだ早く帰ることが可能だ、という苦境に陥ってしまった。

 

犯人がクラックしても何がなんだか、ぜったいにわからないエンティティには満足していたし、満足されてもいたので、変えるとなると色々会議が必要になるし。ソレは嫌だな、と思ったり。

 

結局、時間切れになったんだっかかな? フラグを増やして終わり。最初からこの方向でやっていれば2時間で終わるものを1週間かけてしまったことがある。

 

バックエンドというか、ビジネス層だけに必要な専用フラグをビューを使わずに1つ追加、後は再利用というかそうではないのだが、すでにあるクラスを変えずにOK、と。そこまでは別に良くても、このフラグをまたBooleanタイプにしたから、その後、またタイヘンな目に遭った人がいるとか。私はチームを移ったのでサポートしただけだが、デキがいい人が後から来たようで、かなり助かったのであった。よくこんなアバウトな説明であるべき方向を聞いてくるけどわかるよなあ、と彼の理解力に驚いた。かなり実装寄りで具体的だったのだが、新規追加機能のための質問だけに、彼も質問しづらかったこともある。

 

オブジェクト型が現れると、必ずそらのオブジェクトは複雑なデザインパターンをソレ用にメモリに抱えることになる、という予感。コレが初見の時のプレッシャー。私の書いた場合は、だが。

 

クリエイトまでは気楽。その後、CPU時間が1秒でも経過したら、ややこしくなるのである。同じ型でも意味が違う! まではさすがに無いものの、なるほど、だからこっちのサブクラスかあ、とか。スーパーがリターン前にしなければならないのは、概要設計の方針のこの行のこの解釈から生まれたこの方針でかあ、とか。かなり愉快だとは思うのだが、新規追加、コストダウン、とかになると、けっこう苦しい。全部の層に新規に作ったら良いんだろうけど工数上無理、とか。

 

StrutsとかSpringを使うとこの手の苦労は無くなる。だが、最適か? と問われると、実はその時のシステムに最適なフレームワークは無い、というのが本当。

大まかに概要レベルから内部設計あたりまで、このフレームワークに合わせなきゃ、という逆ニーズ現象発生、と。コレ、単なる失敗だと思うのだが、なぜか日本のほぼすべてのシステムがコレやね。大失敗ではないけど、大きな視点で見れば、である。オブジェクト指向、レゴブロックみたいに、とか考えると、親クラスが決まるとどうしようと無くなるわけで。私がフレームワークを嫌う理由は、現場のニーズに合うようにカスタマイズしてくれないからなのである。ハンバーガーと同じ発想だと困るわけで。

 

汎用的なWebアプリケーション、とか、クラウドアプリとかのフレームワークですっ、と謳うなら、OracleJavaのベースパッケージぐらいまでしてくれれば嬉しいね。業務層なら、どうせどこの会社のシステムも同じだから、と考えているらしいので、ソレなら個々の業務ロジックまで作れば良いのである。親クラスやクリエイト線を支配する立場がフレームワーク。ソレなら、全世界の企業システムを作れば良いのである。フレームワークメーカーやオープンソースで。自動車業界用の職種が営業店の日報、とかもうわかる筈だ。ソレなら作っちゃえ、と。こうすると合わない、という企業は使うな、までreadmeに書いておくと良いのではないか? このフレームワークで儲かる企業はこういう感じの手順がまとまっている企業で、そうでない場合は儲からないから使わない方が良い、とか。

そのかわり、絶対に一番儲かるカタチをクラスで表して、フレームワークとして完成していなければならないのは当たり前。さらに、この儲かるカタチは最先端のビジネスの手順を表しているから、ダメなら倒産しろ、無理だ、とか主張してもOK。

 

ここまでフレームワークという静的なライブラリ群のまとまりになっていれば、当然、バカの犯人の手口が限定されてくる。そこでJavaの強みである、そうきたらこうするようになってんだけどわかんねーだろうなあ、が発揮されるのである。マップとリストとイテレーターばっかりなうえにインナークラスとか。メモリをダンプするとアドレスばっかりだし、ハッシュテーブルだし、キーもバリューもリストだし、どこまでいけばIDとパスワード? とか探していくと、String型で、アクセサーばっかりに囲まれたラッパーの中だった、と。またアドレスかよ、とか思って探していくと、またストリングを編集している処理がラップされたインターフェース型にぶつかり、どこでデータベースに格納したのかわからなくなる、と。モデル層からして分かりにくくい、とか。コレでプロクシの先からEJBだったりソレもどきだったりして、ブラウザの中がアプレットだったりすると、もう嫌になると思うね。中間者攻撃で途中で先に盗んでも、同じだからなあ。盗む意味が無い。コレがわからんバカの犯人は、東京湾や横浜湾で税関と通信している船舶と税関の通信をDoS攻撃で切断するぐらいしかやりようが無いこともわからん、と。

 

ソープリクエストとか使いたいね。ここまでは書いてある! とか喚く犯人の姿が丸わかり。コッチだってリアルタイムにわかんねーからなあ。ここの中のどれか、まではわかるけど、とか。ソープレスポンスもどこからプロクシまでなのかは、ハッキリ断言できないし、とか。

 

いまのところ、Javaは圧勝的。とはいえ、マヌケない脆弱性を残すこともあるから、油断はできない。

 

ダークウェブだとJavaは見かけないね。PHPとかPerlとかCGIとかばっかりだ。

 

こうして、脆弱性を突けば儲かる、というバカげて古びたマヌケで低脳ない思考を持つ通信盗聴バカの犯人は、時代から取り残されている。事実、わたしが犯人の手口をチョビッとしか研究してなくても圧勝。なのに日本のネットでは、やたらにマルウェアとかウイルスを恐れる、恐怖を煽るのが多すぎる。シマンテックのブログなんか、うちのを買えばOK、で終わり。当該企業が何を言おうとして書かないでいるのかは、私がいま代弁しておいた。

 

たくさんあるなか、マカフィーがいい感じなのである。カリ リナックスとか使いこなしてそうだ。ペネトレーションテスト環境を仕掛けまくる作戦かな? わからんけど。

 

私のルータのメモリに偽Linkedinとか偽Gmailとか偽Apple IDサイトとか偽Facebookとか偽Twitterとか偽Googleアカウントサイトとかを不正にインストールしてパスワードと IDを盗んでいるバカな奴があるみたいなので、騙された人がそもそも何にもできないように私がさっきしておいた。通信妨害だから情け容赦しない。犯人に騙された無実の市民だろうがなんだろうがマルウェア化するのみ。いまのところ迎撃がうまくいっていない、と私はみている。つまり、コレからはもっと残酷で卑怯で臆病な日本人と同じレベルの脆弱性狙いのマルウェアに飛ばすつもりだ、と。このマルウェアはメタスプロイトのツールをいじった程度のモノではない。まさに、一流セキュリティシステム企業が相手にしている高度なマルウェアであるので、バカげたマルウェアは無いようになる。

 

したがって、

犯人に騙されたら誰かに殺される、と思うと良い。私のルータにアクセスしてきた場合は、ソレを力強く保証できるように努力を重ねるつもりだ。ホントに邪魔。犯人もだし、犯人に騙された奴もだし。まもなく、Facebookはどっちのが犯人だ、までわかりそうだ。Appleも。したがって、IBMも。

 

本物ソックリのフェイクサイト、という文を読んだら、まずは殺されないように、と必死で思うと良いであろう。

 

いま、同じ被害者だけは救うべきだ、という恐怖のメッセージを受け取っているので、そういうビジネスをやらないから神に呪いの夢を与えられるのだ、と理解している。楽しい仕事をしていた時は、こんなことは無かったからなあ。