web-dev-qa-db-ja.com

マタサノはどのようにしてハッキングされたのですか？

差出人： http://seclists.org/fulldisclosure/2009/Jul/0388.html

私がそれを以下からの投稿から最もよく理解しているなら： http://news.ycombinator.com/item?id=723798 Matasanoの人たちはsshdインターネットにアクセスできるようにしました-これに対する提案された解決策（プログラミングの点から） -of-view）？

securityvulnerabilitieshacking
10
user14898

マタサノはどのようにしてハッキングされたのですか？

フルディスクロージャーへの投稿の情報から答えることは不可能です。しかし、彼らは少しの情報を提供するので、推測することは常に興味深いです-

＃。/ th3_f1n4l_s0lut10n www.matasano.com 
 [-] 69.61.87.163:22に接続しています。
 [/]有効な非rootユーザーを探しています。adam
 ******** R3D4CT3D h4h4h4h4 ********

彼らは、sshポートに接続するMatasanoのサーバーに対してバイナリ「th3_f1n41_s01ut10n」を実行します。なんらかの未知の手段で有効な非rootユーザーを見つけ、残りの出力は編集されます。

＃。/ th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com 
 [*] 209.112.118.10:3338の接続バックリスナー.. 
 [！] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4。 5p1、OpenSSL 0.9.8g 2007年10月19日]

バイナリは、見つかったユーザー名を使用して再度実行されます。このユーザー名は、ログインしてポート3338でサーバーに接続し直します（名前に登録されていないことを願っています...）。

 adam_at_www：〜$ uname -a 
 Linux www 2.6.20.1-1-686＃1 SMP Sun Mar 4 12:44:55 UTC 2007 i686 GNU/Linux 
 ** ** h4h4h4hh4h4h4 l3tz us3 m0r3！0D4Y！ H4H4H4H4H4H4H4 ****

彼らは、このカーネルに対してゼロデイ攻撃を行っていることを示唆している可能性があります。これは、この会社の株式を考えるとかなり古いものです。

 adam_at_www：〜$ cd /tmp
 *********** B0R1NG *********** 
 root_at_www：〜＃cat/etc/shadow

おっと-突然、ユーザーはrootになりました。/tmpには、参照した0日である可能性のあるローカル権限昇格エクスプロイトがあります。

したがって、ここでは少なくとも2つのエクスプロイトが発生しています。システムで有効な非rootユーザーを取得し、そのユーザーとしてログインしてから、ローカル権限昇格を行うOpenSSHエクスプロイトです。

OpenSSHには、バージョン4.5以降にいくつかの既知のセキュリティ問題があることを考慮してください。

差出人 OpenSSHのセキュリティページ ：

  • バージョン5.2より前のOpenSSHは、CPNI-957037「SSHに対するプレーンテキスト回復攻撃」で説明されているプロトコルの弱点に対して脆弱です。ただし、入手可能な限られた情報に基づくと、この説明されている攻撃はほとんどの状況で実行不可能であるように思われます。詳細については、cbc.advアドバイザリおよびOpenSSH5.2リリースノートを参照してください。
  • OpenSSH 4.9以降は、コマンドがsshd_config（5）ForceCommandディレクティブでオーバーライドされたセッションに対して~/.ssh/rcを実行しません。これは文書化されていますが、安全ではない動作です（OpenSSH 4.9リリースノートで説明されています）。
  • OpenSSH 4.7以降では、OpenSSH 4.7リリースノートで説明されているように、信頼できないCookieの生成が失敗した場合（意図的なリソースの枯渇など）、信頼できるX11認証Cookieの作成にフォールバックしません。

私は、この古いLinuxカーネルと古いSSHデーモンを持っていることが彼らのためにしたと思います。また、インターネットで利用できるwwwサーバーで実行されていたので、自信を持って実行できると思います。侵入した人々は明らかに彼らを当惑させたかった。

これらの攻撃を防ぐ方法は？

これは、予防的な管理によって防ぐことができた可能性があります。インターネットに接続するサービスにパッチが適用されていることを確認し、どこからでも接続できるようにするのではなく、接続できる人の数を制限します。このエピソードは、安全なシステム管理が難しいという教訓をさらに複雑にし、ITがパッチを適用し続けるための時間を提供するために、ビジネスからの献身が必要です。実際には、少なくとも中小企業では簡単に起こることではありません。

ベルトアンドブレースアプローチを使用するのが最善です-公開鍵認証、sshデーモンのホワイトリスト、2要素認証、IP制限、および/またはVPNの背後にあるすべてのものを使用することは、VPNをロックするための可能なルートです。

私は明日仕事で何をするか知っていると思います。 :)

34
Cawflands

人々はその上でFUDを作成するのが大好きですが、ユーザーadamがすでにそこにいて、彼のパスワードも知っているようです（おそらくブルートフォースまたは他の方法で）。しかし、彼らはかっこよく見えて、この騒ぎをいたるところに作りたいと思っています。

注意すべきもう1つの興味深い点は、ユーザーadamが1年以上そのボックスにログインしていないことです。

（lastlogの出力）

 adam             pts/1    ool-4350ab48.dyn Sat Jul 26 20:45:18 -0400 2008

したがって、彼はおそらくそのパスワード（おそらく悪いパスワード）をしばらく保持していました。

* SSH経由でユーザー名を検出するツールが本当にあれば、他のすべてのユーザーを使用してリモートアクセスを取得できたはずですが、そのボックスで最も一般的なユーザー名を使用していました（簡単に推測できます）。

3
sucuri

そのマシンにシェルを持っているユーザーが非常に多いことに驚かされます。それは彼らが確かに所有された方法です、他のすべては気を散らすことを意図した赤いニシンです。そのうちの1人は、sshクライアントを他のShellマシンにバックドアで接続した可能性が高く、ゲームオーバーでした。全員にシェルアカウントを与え、sshdの世界にアクセスできるようにすることは、怠惰で愚かです。

2
Alex

なぜプログラミングの観点からこれを解決しようとするのですか？

代わりに、smart-server-administratorの観点から解決する必要があります。ホワイトリストの使用など、投稿したリンクのコメントにはいくつかのすばらしい提案があります。

また、ここで質問しているので、セキュリティの専門家ではない可能性が高く、書きたいと思うものはすべて穴を追加するだけです。これは実際にはプログラミングの質問ではありません。

2
Sneakyness

ソフトウェアをゼロデイ攻撃から保護します...これは不可能です。

たぶん、1つの良いアプローチは、ソフトウェアがハッキングできないと主張することです。これにより、ホワイトハットがそれを試してすべてを完全に開示し、穴を少なくすることができます。 Oracle 10はこの主張を持っていましたが、翌日、9つの新しい穴が見つかりました。今ではかなり安全です。

おそらく、ハッカーは完全に優れたソフトウェアの構成を悪用しました

2
Eric