つかの間のマルウェア

私はフリーランサーであり、主な専門分野はアスタリスクベースのIPテレフォニーソリューションです。



先日、私はかなり古いクライアントの1人にアプローチされました。そのクライアントは昨年、オンラインストアのコールセンターに電話を導入しました。 そこで、関連パッケージのみを使用してアスタリスクのみをインストールおよび構成し、ローカルシステム管理者はサーバーとOS（Ubuntu）のインストール、および実装後のシステムのサポートに従事しました。ダイヤルプランのコンテキストの編集。 今回は、受信したコールの統計の観点から、CDRのロジックを順番に変更する必要がありました。



コストとタイミングについて合意したので、仕事に取り掛かりました。 CDRで不完全なコールのロギングをオンにした後、「UNKNOWN UNKNOWN」というステータスの「FAILED」というレコードのストリームが開始されたとき、私は驚きました！ さらに、ダイヤル試行は、コード+370のいくつかのリトアニア番号に向けられました。



外部からアスタリスク自体に接続するというアイデアは、検証後に直ちに拒否されたため（すべてのセキュリティ推奨事項は実装段階で実装され、fail2banがあり、sipアカウントには厳密なIP制限がありました）、AMIが切断されたため、1つのオプションしかありませんでした-ファイルを呼び出します。 そしてそれが判明した。 私はクライアントに説明しました：彼らはこの技術を使わず、さらにリトアニアに電話しませんでした。 道徳？ そう、些細なハックです。



呼び出しファイルを削除すると、しばらくしてから再び現れました。 予想どおり、cronには余分なものは見つかりませんでした。 頭をひっかいた後、私はlsofを周期的に開始しましたが、彼は発信で興味深いものを見つけることができませんでした。 次に、短いグーグルの後、重砲-inotify_tools-が戦闘に入りました。 不思議な絵が浮かびました：毎秒数個の悪名高いファイルが常に生成されていました。 スケジュールされたタスクではなく、プロセスまたはデーモンを扱っていると結論付けました。



その後、より簡単になりました：topとpsを通じて、「バックアップ」と呼ばれるかなり疑わしいプロセスがすぐに検出され、/ var / tmp / bkb.dにありました。 これは最も単純なスクリプトであり、さまざまなリトアニア番号への国際通話の開始を含む、/ var / spool /アスタリスク/発信の同じ場所にある数十の通話ファイルを常にコピーします。 同時に、最も興味深いのは、存在しないトランクを介してコール（またはダイヤル試行）が行われ、コールファイルに他の誰かとダイヤルした後の接続の指示が含まれていないことです。



マルウェアを切り取り、CDRロジックに必要な変更を加えた後、ハッキングの推定時間をクライアントに通知し、この事実を発見したことに対する別の材料感謝の意を期待しました。 彼がこれでさらに何をするのか-私は知りません、ハッキングが可能になった穴を見つけるタスクは私の前ではありませんでした。 http-authorizationによって閉じられたSIP、SSH、および統計のみがそこに突き出ていましたが（もちろん、Apacheはアスタリスクのようにルートから実行されませんでした）、選択肢は小さいです。



おそらく、マルウェアを検索するためのよりシンプルで迅速なソリューションがありましたが、それでも私は自分自身をLinuxの広範な管理者とは考えず、思いついたものを適用してグーグルで検索しました。 しかし、誰が、なぜ、そして最も重要なことには、彼がそのような無意味なハックをしたのか、私はまだ理解していません。