ぶるーたるごぶりん

UI, UX, セキュリティとか😘

GitHub を狙った Reverse Proxy 型フィッシングサイトの探索と報告

Security Phishing

GitHub の Reverse Proxy 型フィッシングサイトの発見と報告

こんにちは、でじこだにょ

今回は GitHub を狙った Reverse Proxy 型のフィッシングサイトを探していこうと思います。 （長いので、Reverse Proxy 型のことをプロキシ型と略しちゃいます） 結論から書くと、２４件のフィッシングサイトを新規に発見して報告しました。

今回はそれらのフィッシングサイトの探し方のほか、フィッシングサイトの検出方法や、 セーフブラウジングなどの話をしつつ、 今回見つけたフィッシングドメインに対して、簡単ではありますが、調査と考察を行ってみたいと思います。

探そうとしたきっかけ

数日前、 Twitter を見ていたところ、こちらのツイートが流れてきました。

画像を見る限り、対象ドメイン 520liyan[.]xyz は GitHub を模したフィッシングサイトで、 いわゆる Reverse Proxy を用いたフィッシングサイトのように見えます。

プロキシ型フィッシングサイトは、一般的なフィッシングサイト （ログインページなどを真似て配置する形式のフィッシングサイト）と違い、Reverse Proxy を用いてページを構成しています。

このタイプの厄介なところは、 本家となるターゲット（今回のものだと GitHub)のコンテンツをそのままミラーリングする点にあります。

つまり、ページコンテンツが本物のと全く同じになり、しかも（おそらく大抵の）リンクやページURLが正常に（悪性ドメイン上で）表示されます。 そのため、ログインページへのボタンをクリックしたり、パスの書き換えで「ユーザーが google のリポジトリ一覧 (/google) 」という感じで URLを書き換えても正常に動いてしまいます。

このようにして、手間のかかった分より悪質な形式でフィッシングサイトを構築する例がたまにあります。 （例えば Evilginx2 などを用いた例です。余談にて少しだけ書きます。）

さて、話を戻します。 先程のツイートをみた時に「わー プロキシ型だ、珍しい」と興味深く見ておりました。 というのも、 Phishing の主流はやはりログインページをコピーした攻撃が中心であり、 プロキシ型をわざわざ設置するケースは（自分の体験上は）珍しいからです。

しかも GitHub という、被害者の中でもとびきり引っかかりにくい（警戒心が強い & 2FA をしてる）タイプのユーザーしかいない サービスなので、攻撃を仕掛けても成功率はそれほど高くないと思われます。 更に更に、フィッシングハンターたちが報告しているフィッシングサイトに、 GitHub は滅多に入ってこない印象なので、 とりわけ珍しく思えます。

（報告されるフィッシングについてはツイート検索でいっぱい見れます） #phishing - Twitter Search

さて、こうも珍しいとフィッシングページとなると、色々な点が気になってきます。

  • Server のミドルウェアは何を使っているんだろうか？
  • フィッシングサイトの生存期間はどの程度だったのだろうか？
  • 証明書はどこのを使っているのだろうか？やはり Let's Encrypt?

こうなってきたらもう調べずにはいられません。レッツハンティング！

証明書を調べる

では、まず証明書から見ていきましょう。 証明書情報の検索には CT Log (Certificate Transparency Log, 証明書透過ログ) を利用します。

CT Log は、証明書の発行を第三者監査ログとして残し、そのログを監査することで証明書の誤発行などを検出することができる仕組みです。 これにより、ドメインを検索のキーとして、証明書の検索などが行えたりします。

より具体的な話は、こちらの資料が大変わかりやすいのでおすすめです。

https://www.jnsa.org/seminar/pki-day/2016/data/1-2_oosumi.pdf

この CT Log の検索システムとして有名な物としては crt.sh, censys などがあります。

今回は crt.sh で、フィッシングドメインの証明書ログを検索してみましょう。

https://crt.sh/?q=520liyan.xyz

すると、対象ドメインの最初の証明書ログが 2021-07-18 、最後のログが 2022-01-14 に登録されていることがわかります。 これはフィッシングサイトとしては、かなりの期間（半年程度）生存しているケースで珍しいです。 （ただ、この段階ではフィッシングサイト自体が稼働していたかどうかは不明）

次は本当にこれだけの期間フィッシングサイトが稼働していたのかを調べます。

Web Archive を調べる

これだけ生きているドメインとなると、 Web Archive などでログが残っているかもしれません。 では、 Web Archive にてドメインを調べてみましょう。

http://web.archive.org/web/*/520liyan.xyz

すると、 2021-11-23 に初のアーカイブがありました。

http://web.archive.org/web/20211125204156/https://520liyan.xyz/

さらに、アーカイブを見てみると、やはり Github のページのアーカイブのようです。 以上の点から、「半年程度このフィッシングサイトは生きていた」ということがわかりました。

なぜ長期間生き延びていたのか？

こうなると一つ疑問が浮かんできます。 「なぜこれだけの期間、フィッシングの通報がなかった（テイクダウンされなかった）のだろうか？」

試しにフィッシングハンター御用達の URL Scan （Web Archive + Sandbox みたいなサービス)で、 過去にスキャンされたか見てみましょう。

と言うのも、フィッシングハンターたちは日夜フィッシングページを探したり通報を行っているため、 本物のフィッシングサイトであれば、（結構な確率で） urlscan.io でスキャンが行われていたりします。

ここでヒットすれば、過去に「怪しいサイト」として誰かしらに疑問を持たれた　と言う推測ができます。 （つまり、フィッシングサイトとして通報される可能性が十分あり、今回それが漏れていただけなのかもと推測が立てられる）

しかし、残念ながら検索結果は ０件です（現在出ている２件は両方自分）。 https://urlscan.io/search/#520liyan.xyz

さて、材料も出揃ってきたので、色々と考察ができそうです。

  • リバースプロキシされた Github のページを見ただけでは、一般人は「フィッシングだ！」と判断できないのでは？
    • 入り口のページがログインページだった場合は真っ先に疑うはず
    • 入り口のページが LP ページとかだと「フィッシングだ！」と思い浮かばないのでは？（今回の例）
  • GitHub もおそらくフィッシング対策をやっているが、今回のケースはその検知網に引っ掛からなかったのではないか？
    • 今回はドメインのタイポスクワッティングでは引っ掛からない
    • 悪性IPに紐づいていないとか？（今回調べていない）
  • 1件あるということは潜在的には（長期間動いていおるのが）もっといっぱいあるのではないか？

※ 今回突発的に調べようとしたので、 ISP / ドメインレジストラがどこだとか調べ忘れてました。

（本記事としては）特に重要なのは以下です １件あるということは潜在的には（長期間動いていおるのが）もっといっぱいあるのではないか？

ようやく導入部が終わりました・・・！（長かった...） では、実際にフィッシングサイトハンティングをしていきましょう。

フィッシングサイトハンティング

まずは今回見つけたいフィッシングサイトの特徴をまとめていき、 その特徴に対して、既存のフィッシングハンティング手法が有効かを考えていきましょう。

特徴:

  • ドメインは GitHub に関係がないドメイン名
  • 証明書は取られている
  • ページ内容は豊富（クローリングされている可能性がある）
  • 生存期間が長い (クローリングされている可能性がある)

パッと思いつく点としてはこれらでしょうか。 では、次に主なフィッシング検出の手法をあげ。 （多分私が知らない方法とかニッチな方法とかいっぱいあるので参考程度に。）

  • タイポスクワッティングによる検知
    • CT Log を利用する方法
    • Curl などで定期的にページスキャンをする方法
  • Passive DNS
  • FootPrint 的な Hash ベースによる検索（今回やるやつ）
  • ページ内容による検出 (今回試してだめだったやつ)

タイポスクワッティング

まずタイポスクワッティングですが、これは攻撃対象となるドメインなどの名前を少し変えて配置して釣れるのを待つ攻撃手法です。 例えば、 github.com を少しもじって githubb[.]com などのドメインを取って置き、 GitHub と同じログイン画面をそのページに用意し、放置すると言うステップで攻撃をおこないます。

これらを検知する手法としては、タイポスクワッティングっぽい文字列のドメインに対して、実際にスキャンを定常的に行い、 悪性なサイトが出てこないかを見る方法があります。

他にも、先ほど紹介した CT Log 検索サービスなどでドメインの曖昧検索などを行い、 新規に（悪性っぽそうな）ドメインが立ち上がっていないかを検出すると言うやり方もあります。

しかし、今回対象としているドメインは 520liyan[.]xyz と、 GitHub に全く関係がなさそうな文字列なので、このアプローチは適用できなさそうです。

Passive DNS

次に Passive DNS ですが、これは悪名高い悪性IP などを常に監視し続け、DNS の紐付きなどを見て検知するアプローチです。 が、これも今回のケースではあまり有用ではなさそうです。

と言うのも、このアプローチをとっているフィッシングハンターは結構いらっしゃいますし、それらの検知網に引っかかっているのであれば、 既に悪性報告が上がってきているはずだからです。

悪性報告を掻い潜り半年近く生き残っていたとなると、おそらくこの方法は有用に働かないでしょう。

ページ内容を元にした検出

さて、上記二つのアプローチが（おそらく）失敗に終わるだろうと推測が立ったので、残り二つに関して考えていきます。

  • ページ内容による検出
  • FootPrint 的な Hash ベースによる検索

先に書いておきますと、この２つの手法を今回試し、 「ページの内容による検出」は失敗に終わりました。

ただ、「FootPrint 的な Hash ベースによる検索」のアプローチでは 24個のフィッシングサイトを検出できました。

ページ内容による検出

今回見つけたいのは「Proxy型のフィッシングサイト」です。 と言うことは、冒頭に記載したツイートにあるように、 GitHub のトップページ（LPページ）が、 フィッシングサイトのルートパス (/) に設置されている可能性が高そうです。

そして、長期間生き残っているサイトは Google が検索欄に出してくれる可能性があります。

つまり * GitHub 公式サイトのトップページの title と同名のものを探す * URL Path が / になっているものを探す

と言う検索を行えば、もしかするとフィッシングサイトが出てくるかもしれません！！（出てきませんでした。）

では、以下で検索します。

intitle:"GitHub: Where the world builds software"

それなりな数が出てきて、しかもトップには怪しそうなURLが出てきました！！（公式のものでした😭）

github-landing-page[.]netlify[.]app

f:id:kumagoro_alice:20220312141743p:plain
landing-page

が、動的なページ（ログインページ）ではなく、あくまで LP ページだったのと、 netlify.com の管理するドメインのようでした。

https://www.netlify.com/blog/2021/12/20/how-to-add-custom-domains-to-netlify-sites/

So you've finished building that awesome site, you've deployed it to Netlify and tested all the functionalities. Everything is working perfectly and your site is available on Netlify at a URL like the-name-of-your-site.netlify.app.

それなりな数を見てみましたが、このアプローチは失敗に終わりました。

FootPrint 的な Hash ベースによる検索

さて、お次は hash を用いた検索です。

このアプローチは、以下の記事にある内容をそのまま利用しております。 （面白いアプローチなのでぜひ元の記事を読んでいただければと...)

isc.sans.edu

記事にある内容としては、 Shodan を利用して、 favicon の hash をキーとしてページを洗い出すというものです。

shodan については説明は ~面倒なので~ wikipedia のものをそのまま引用します。

Shodan（ショーダン）は、ユーザーがさまざまなフィルターを使用してインターネットに接続されている特定の種類のコンピューター（Webカメラ、ルーター、サーバーなど）を検索できるようにする検索エンジンである。

https://ja.wikipedia.org/wiki/Shodan

要するに、対象の IP でどの Port が空いているだとか、どういう HTTP Header を返すだとか、そういったものを収集している検索エンジンです。

これを利用することで、今回のフィッシングサイトのようなケースは Shodan で検出できるかもしれません。

では、 実際に favicon の hash を用いて調査を行ってみましょう。

元の記事に記載があるコードをそのまま流用します。

import requests,mmh3,base64
response = requests.get('https://github.com/favicon.ico')
favicon = base64.encodebytes(response.content)
hash = mmh3.hash(favicon)
print(hash)

> 1848946384

ハッシュがわかったので、お次は shodan で検索してみます。 https://www.shodan.io/search?query=http.favicon.hash%3A1848946384

すると、結構な量の結果が出てきました。

f:id:kumagoro_alice:20220312141845p:plain
shodan-search-result

この中から、フィッシングサイトの場合、どういった傾向が出てくるかを手動でぽちぽち見ていきます。 すると、フィッシングサイトが引っかかってきて、 Shodan 上での表示の仕方がわかりました。

（少なくとも） 301 Moved Permanently のレスポンスが帰ってくる物の中に、GitHub のフィッシングサイトが混ざっているようです。

f:id:kumagoro_alice:20220312141902p:plain
shodan-phishing

f:id:kumagoro_alice:20220312141951p:plain
phishing-page

では、検索結果ダウンロードし、 301 Moved Permanently を返すURLのみにフィルターしてみましょう。

すると 757 -> 92 ドメインにフィルターできました。

あとは手動による温かみのある確認を 92 URL にしていき、 結果として以下の 24 URLが悪性（っぽそう）であるとわかりました。

www[.]mvlxdk[.]cf
tz[.]liuqiufeng[.]com
vir2[.]codymax[.]win
vps[.]aipod[.]tech
www[.]mvlxdk[.]cf
node[.]fumill[.]tk
andon[.]gq
ws[.]qqwee[.]xyz
github[.]innominds[.]com
usa3[.]whysix[.]space
hellogithub[.]tk
lovelycoffee[.]fun
yfiiii[.]net
bb[.]wxhfut[.]com
12345pro[.]vip
168[.]235[.]92[.]95
216[.]24[.]176[.]26
149[.]28[.]169[.]249
101[.]133[.]171[.]225
119[.]28[.]6[.]62
65[.]49[.]193[.]168
192[.]3[.]213[.]187
146[.]56[.]157[.]211
47[.]57[.]190[.]210

あとは　https://support.github.com/contact/report-abuse?category=report-abuse&report=other&report_type=unspecified から、 GitHub へ Abuse の通知を行って終わりです。

悪性ドメインの生存期間の調査

ちょっと踏み込んで、実際に検知されたプロキシ型のフィッシングサイト（と思わしき Domain たち）の証明書等などを見ていきましょう。

以下のフォーマットで記載します。

Domain:
    - 証明書: 日付 - 日付
    - Web Archive: ある・なし
    - urlscan.io: ある・なし (+ いつ頃か)

証明書の欄は、証明書が登録された 最初の登録日 - 最後の登録日　、 Web Archive の部分は web.archive.org に対象ドメインがあるかどうか、 urlscan.io は、（自分がスキャンした記録以外が）あるかどうかを示しています。

www[.]mvlxdk[.]cf: 
    - 証明書: 2021-12-10 - 2022-02-08, 
    - Web Archive: なし
    - urlscan.io: なし

tz[.]liuqiufeng[.]com:
    - 証明書: 2020-04-22 - 2022-02-25
    - urlscan.io: 2ヶ月前にあり
    - Web Archive: なし
     
vir2[.]codymax[.]win:
    - 証明書: 2020-12-19 - 2020-12-19
    - Web Archive: なし
    - urlscan.io: なし
    
vps[.]aipod[.]tech:
    - 証明書: 2020-07-26 - 2021-11-28
    - Web Archive: なし
    - urlscan.io: なし
    
www[.]mvlxdk[.]cf:
    - 証明書: 2021-12-10 - 2022-02-08
    - Web Archive: なし
    - urlscan.io: なし
    
node[.]fumill[.]tk
    - 証明書: 2022-01-14 - 2022-01-14    
    - Web Archive: なし
    - urlscan.io: なし

andon[.]gq
    - 証明書: 2021-09-07 - 2022-01-08
    - Web Archive: ある ( https://web.archive.org/web/2021*/andon.gq )
    - urlscan.io: なし
    
12345pro[.]vip
    - 証明書: 2021-01-07 - 2022-01-28
    - Web Archive: ある ( https://web.archive.org/web/2021*/12345pro.vip )
    - urlscan.io: 7ヶ月前
    
ws[.]qqwee[.]xyz
    - 証明書: 2022-02-24 - 2022-02-24
    - Web Archive: なし
    - urlscan.io: なし
    
usa3[.]whysix[.]space
    - 証明書: 2021-08-11 - 2022-02-06
    - Web Archive: なし
    - urlscan.io: なし
    
hellogithub[.]tk
    - 証明書: 2019-11-04 - 2022-01-28
    - Web Archive: ある（ https://web.archive.org/web/20211215000000*/hellogithub.tk )
    - urlscan.io: 1年前 
    
yfiiii[.]net
    - 証明書: 2021-10-01 - 2022-01-28
    - Web Archive: ある ( https://web.archive.org/web/20211215000000*/yfiiii.net )
    - urlscan.io: なし
    
bb[.]wxhfut[.]com
    - 証明書: 2021-08-27 - 2022-02-22
    - Web Archive: あり ( https://web.archive.org/web/20211215000000*/bb.wxhfut.com )
    - urlscan.io: なし
        
lovelycoffee[.]fun
    - 証明書: 2021-10-22 - 2022-02-15
    - Web Archive: あり ( https://web.archive.org/web/20211215000000*/lovelycoffee.fun )
    - urlscan.io: なし

github[.]innominds[.]com
    - 証明書: 2013-12-20 - 2022-03-06 
      (これだけ、 full domain だと検知できないので、`innominds.com` で検索 )
    - Web Archive: ある ( https://web.archive.org/web/20211215000000*/github.innominds.com )
    - urlscan.io: 4ヶ月前

最後の github[.]innominds[.]com に関しては、通常運用されているドメインに github. のサブドメインが生えており、 今回の中では外れ値になっているのかなと思いました。 （もしかしたら侵入されてから生やされたドメインと言う可能性もあるかもしれません）

その他に関しては、一番古い証明書の登録日が 2019-11-04 で、 大体は 2020年頃に登録が多いのかなという印象です。

なので、これらが同じ脅威アクターによる代物であれば、大体 2019 年あたりからこの攻撃を始めたのかなと思います。 （もしかしたらそれより古いものはテイクダウンされたとかあるかもしれませんが）

終わりに

はちゃめちゃ疲れました。

少し余談

なぜ プロキシ型のフィッシングを行うのか？

ここに突っ込むと長くなるので殆ど端折りますが、

プロキシ型のフィッシングは、2FA のバイパスをする際に利用されるテクニックの一つです。 なので、標的型攻撃といった高度な攻撃で利用されるケースがそれなりにあります。

有名なツールとしては Evilginx2 などが挙げられます。

https://camo.githubusercontent.com/ac8d71bfda7eb05e579ef7c78322b7520d865468a7176c79556f5e6934482923/68747470733a2f2f6d727475727665792e636f2e756b2f77702d636f6e74656e742f75706c6f6164732f323032302f31322f5068697368696e672d4279706173732d3246412d2d31303234783537362e6a7067

github.com

今回の GitHub のケースも、多くのGitHubユーザーは 2FA を行っているため、 このプロキシ型のフィッシングサイトを利用することで、セキュリティ機構をバイパスしようとしていたのではないか？と自分は推測しています。

CT Log 検索サービス crt.sh の posgtgre sql

本当に余談ですが、今回紹介した crt.sh には、 Postgre SQL が提供されているので、気になった方はぜひ。 （国内ブログで言及している記事がないので、この場でちょっと紹介）

ありがとう、 crt.sh ... ありがとう　Sectigo ...

ちなみに crt.sh の検索では、 Postgre SQL の全文検索機構が使われていたり、Wildcard 周りで結構癖があります。

Facebook の Phishing 検知

これもあまり有名じゃないかもしれませんが、 Facebook は CT Log を元にしたフィッシング検知サービスを無料で公開してくれています。 （簡易的なサービスなので、組織で利用する際はあくまで補強的な利用とした方が良い） https://developers.facebook.com/tools/ct/search/

ただ、無料なので最高。

ありがとう Facebook ... ありがとう Meta ...