2020年1月30日
株式会社Doctor Web Pacific
今回の記事では、 Android.Xiny の新種が用いる新たな自己防御方法について、詳しく報告します。
Android 5.1が2020年でも標的か?
本調査の対象となるトロイの木馬は、 Android のバージョン5.1以前のOSを標的にしています。バージョン5.1が2015年にリリースされたことを考えると、まだこのような古いバージョンを狙うマルウェアがまだ存在していることが不思議に思われます。しかし、古いバージョンの利用者は依然として多くおり、Google社が提供するデータを確認すると、2019年5月7日時点では、 Android 5.1以前のバージョンに対応したデバイス数が全体の25.2%を占めていることが分かります。 弊社製品のユーザーを基にした統計データによると、前述の数値を若干上回り約26%となります。結論として、 Android デバイスの約25%がトロイの木馬の標的となる可能性があると言えます。さらに、こうしたデバイスでは、今後パッチが提供されずに脆弱性の影響を受けることを考慮すると、古いバージョンの Android がウイルス作成者に狙われる根拠は明白です。様々な脆弱性を悪用することにより、root権限が取得されると、デバイスは乗っ取られ、犯罪者によってアプリケーションがインストールされることとなります。
Android.Xinyが持つ主なペイロードの概要
以前検出された亜種と同様、トロイの木馬 Android.Xiny の主な目的は、ユーザーの許可を得ずにデバイス上にアプリケーションをインストールすることです。同トロイの木馬ファミリーの作成者は、インストールの都度、料金が支払われる犯罪者間のパートナープログラムに参加しており、これを主な収入源として金銭を得ているといっても間違いではありません。一部の同ファミリーに属する亜種が起動されると、ユーザーにとって全く不要な多数のアプリケーションがインストールされてしまいます。そのほとんどは悪意のないアプリケーションですが、コントロールサーバーから送信されるコマンドによっては、悪意のあるソフトウェアがインストールされる可能性もあります。
今回調査した Android.Xiny の亜種には、非常に興味深い自己防御メカニズムが実装されています。下記は、確認された削除から守るための二つのコンポーネントです。
インストーラー
- sha1 : f9f87a2d2f4d91cd450aa9734e09534929170c6c
- 検出名 : Android.Xiny.5261
root権限を取得した後、このコンポーネントが実行され、システムファイル "/system/bin/debuggerd" および "/system/bin/ddexe" が置き換えられ、自動起動を可能にします。置き換えられた元のファイルには、拡張子として "_server" が付与され保存されます。つまり、事実上のコンパニオンウイルスとして挙動します。さらに、コマンドラインのパラメーターにより転送されたフォルダー内に含まれる複数の実行ファイルをシステムディレクトリにコピーします。その他に、特別なパラメーターを指定して起動した場合には、アップデートされたコンポーネントが保存されるフォルダーが指定されていると、コンポーネントをアップデートすることさえ可能にします。
Android.Xiny.5261 には、ファイルの削除用に大きなリストが格納されており、その中には以前の同ファミリーの亜種に固有なパスやシステムディレクトリにインストールされる競合するトロイの木馬(例えば、 Triada)のパス等が含まれています。
そのほかに、 Android.Xiny.5261 は一部のプリインストールアプリケーションを削除します。その理由としては、恐らく、ストレージの空き容量を増やす目的と考えられます。さらに、root権限の管理用アプリケーションである "SuperSU" や "KingRoot" なども削除するため、ユーザーが、システムディレクトリ上にインストールされたトロイの木馬のコンポーネントを削除するために必要なroot権限を利用できない状態となっています。
改変されたシステムライブラリ"libc.so"
- sha1 : 171dba383d562bec235156f101879223bf7b32c7
- 検出名 : Android.Xiny.5260
弊社では、このファイルを特に興味深いものと考え、今回の調査はこれを対象にスタートしました。同ファイルを hiew で確認すると、 ".data" セクションの終わり付近に実行コードが見られ、これは不審なものです。
次にIDAでファイルを開き、コードをチェックします。
解析の結果、上記のライブラリにより、 mount、 execve、 execv、 execvp、 execle、 execl、 execlp の各ルーチンに変更が加えられたことが確認できます。
変更された "mount" ルーチンのコード :
int __fastcall mount(const char *source, const char *target, const char *filesystemtype,
unsigned int mountflags, const void *data)
{
unsigned __int8 systemPath[19]; // [sp+18h] [bp-1Ch]
bool receivedMagicFlags; // [sp+2Bh] [bp-9h]
int v13; // [sp+2Ch] [bp-8h]
v13 = MAGIC_MOUNTFLAGS; // 0x7A3DC594
receivedMagicFlags = mountflags == MAGIC_MOUNTFLAGS;
if ( mountflags == MAGIC_MOUNTFLAGS )
mountflags = 0x20; // MS_REMOUNT
if ( receivedMagicFlags )
return call_real_mount(source, target, filesystemtype, mountflags, data);
if ( mountflags & 1 ) // MS_RDONLY
return call_real_mount(source, target, filesystemtype, mountflags, data);
if ( getuid_() ) // not root
return call_real_mount(source, target, filesystemtype, mountflags, data);
memCopy(systemPath, (unsigned __int8 *)off_73210 + 471424, 8);// /system
decrypt(systemPath, 8);
if ( memCompare((unsigned __int8 *)target, systemPath, 8) || !isBootCompete() )
return call_real_mount(source, target, filesystemtype, mountflags, data);
*(_DWORD *)errno_() = 13;
return -1;
}
まず、マジックナンバー "0x7A3DC594" の有無を確認するため、 mountflags の値がチェックされます。そのナンバーがルーチンに渡された場合、コントロールが元の "mount" に移行されます。次に、コードはOSブートプロセスの完了をチェックし、 "/system" ディレクトリへ書き込みが許可された状態で再マウントされたかを確認します。前述の条件を満たす場合、実際の "mount" ルーチンは呼び出されず、エラーとなります。こうして、上記のトロイの木馬は、マジックナンバー "0x7A3DC594" の有無を使用して、 "mount" ルーチンを呼び出しますが、 "mount" ルーチンが改変されていることにより、トロイの木馬以外には、 "/system" ディレクトリを再マウント出来るプロセスはありません。
変更された"execve"ルーチンのコード(他の"exec*"ルーチン も同様) :
int __fastcall execve(const char *filename, char *const argv[], char *const envp[])
{
int v3; // r3
if ( targetInDataOrSdcard(filename) >= 0 ) // returns -1 if true
{
sub_7383C();
v3 = call_real_execve(filename, argv, envp);
}
else
{
*(_DWORD *)errno_() = 13;
v3 = -1;
}
return v3;
}
int __fastcall targetInDataOrSdcard(const char *path)
{
char buf[516]; // [sp+8h] [bp-204h]
if ( isDataOrSdcard(path) )
return -1;
if ( *path == '.' && getcwd_(buf, 0x200u) && isDataOrSdcard(buf) )
return -1;
return 0;
}
はじめに、実行されるファイルのパスが "/data/" で始まるか否か、パスの文字列に "/sdcard" が含まれるか否かが確認されます。上記の条件のいずれか一つを満たすと、実行はブロックされます。 "/data/data/" は、アプリケーションのディレクトリのパスであるため、一般のアプリケーションがファイルを作成できる全てのディレクトリからのファイル実行がブロックされることとなります。
システムライブラリ "libc.so" に変更が加えられたことにより、root権限の取得に必要なアプリケーションの動作を妨害することができます。 "exec*" の各ルーチンへの変更により、そのようなアプリケーションは、エクスプロイトを用いて権限を昇格することはできなくなります。一般的に、エクスプロイトは、インターネットから該当アプリケーションのディレクトリへダウンロードされた後に起動される実行ファイルであるためです。仮に、権限の昇格に成功した場合でも、変更された "mount" により、システムディレクトリを書き込み権限で再マウントすることが不可能であるため、システムディレクトリに変更を施すこともできなくなります。
上記のことから、トロイの木馬に用いられる防御メカニズムは、root権限管理アプリケーションを削除するインストーラー、削除済みアプリケーションの再インストールを不可能にする改変が加えられた "libc.so" ライブラリの二つの部分から構成されると言えます。興味深いことに、この防御メカニズムは、競合するトロイの木馬への対策にもなります。それは、ライバルとなる他のトロイの木馬も正常なアプリケーションと同様のパターンでroot権限を取得し、取得後にシステムディレクトリにインストールされるためです。
Android.Xiny.5260への対策
正規のファームウェアが利用可能な場合、ファームウェアの書き換えが、 Android.Xiny.5260 を削除する方法の一つとなります。その他には、複雑ではあるものの幾つかの方法があります。例えば、root権限を取得するには、 "so" ライブラリとして実行されるエクスプロイトを用いることが可能です。 実行ファイルとは異なり、このようなエクスプロトのダウンロードは、トロイの木馬によりブロックされません。また、同トロイの木馬に含まれた他のコンポーネントに対しroot権限を与える、トロイの木馬自体のコンポーネントを使用することが、もう一つの方法となります。このコンポーネントは、 "/dev/socket/hs_linux_work201908091350" のソケット経由でコマンドを受信しています(具体的なパスは亜種により異なります)。さらに、 "mount" によるブロックをすり抜けるには、 mountflags のマジックナンバーを用いるか、該当する syscall を直接呼び出すという方法も考えられます。
ご利用のデバイスがこのトロイの木馬に既に感染している場合には、ファームウェアの書き換えを行うためにデバイスベンダーが提供する正規のOSイメージの利用が推奨されます。この場合、全てのユーザーファイルおよびプログラムが削除されるため、予めバックアップを作成する必要があります。
Tell us what you think
To ask Doctor Web’s site administration about a news item, enter @admin at the beginning of your comment. If your question is for the author of one of the comments, put @ before their names.
Other comments