Exploiting Ammyy Admin – developing an 0day

Background

For the past few years, a number of groups of scammers have been cold-calling thousands if not millions of people in what’s been referred to as the “Ammyy Scam” or the “Microsoft Tech Support Scam” among other names. The scammers pretend to be from Microsoft or another official group and claim to have detected errors on the users’ computers. They have the victims pull up internal logs that show errors, and convince them to download and run the Ammyy Admin software to allow them to remotely control the system. After that point, they may install backdoors or other malware, or simply ask for hundreds of dollars to “fix” the problem. The phone scammers have prompted numerous responses from Microsoft as well as warnings from Ammyy itself on its website. Even though at least two groups have been prosecuted, many more continue to operate. Ammyy Admin is one of many remote control software programs; it is not inherently malicious. The scammers just use it because it’s an entirely self-contained executable that runs without any installation, it’s the easiest to use for an ad hoc connection.

The internet is also full of technical users who have trolled the scammers, wasting their time, making fun of them, or forcing them to see disgusting images. Like most of us in the security industry, I was amused, but thought little about it until the scam hit closer to home when I discovered one of these groups had managed to scam my grandparents and leave their computer an infected mess for me to clean up. So I set out to find out if I could counter an attempted scam with a full fledged remote exploit, and turn the tables on the scammers.

The Challenge

This was also a very interesting challenge, because most of the time, exploiting software begins with fuzzing the network protocol or file formats used based on format specifications like HTTP or FTP, modifying samples of legitimate files or network traffic, and/or examining source code for vulnerabilities. Exploiters often take advantage of debug symbols, which Microsoft provides for their binaries, or other public documentation. For example, for some targets, finding an exploitable vulnerability is as easy as throwing a long string in the protocol and watching a stack overflow give you control of the instruction pointer. And if your target is like that, awesome for you! But it gets harder for widely-used software (Ammyy claims that the software is used by over 36 million personal and corporate users) especially if it wasn’t selected for being a weak target.

In this case, Ammyy Admin not only did not have publicly described protocols, source code, traffic samples, or debug symbols, as I found out, its traffic was also incomprensible. The first thing I did was to set up an Ammyy Admin connection between two virtual machines and capture the network traffic. I started comparing it against other well-known remote desktop protocols, such as VNC and RDP, but quickly discovered that Ammyy uses a completely proprietary network protocol. Not only is the protocol not well known, but all the network traffic was encrypted, making it impossible to reverse-engineer or even replay and reproduce with network traffic alone:



Latar belakang

Selama beberapa tahun terakhir, sejumlah kelompok dari scammers telah ribuan dingin-menelepon jika tidak jutaan orang di apa yang telah disebut sebagai "Scam Ammyy" atau "Microsoft Tech Support Scam" di antara nama-nama lainnya. Scammers berpura-pura menjadi dari Microsoft atau kelompok pejabat lain dan mengklaim telah terdeteksi kesalahan pada komputer pengguna. Mereka memiliki korban menarik log internal yang menunjukkan kesalahan, dan meyakinkan mereka untuk men-download dan menjalankan perangkat lunak Ammyy Admin untuk memungkinkan mereka untuk jarak jauh mengontrol sistem. Setelah saat itu, mereka dapat menginstal backdoors atau malware lainnya, atau hanya meminta ratusan dolar untuk "memperbaiki" masalah. Scammers ponsel telah mendorong banyak tanggapan dari Microsoft serta peringatan dari Ammyy sendiri di situsnya. Meskipun setidaknya dua kelompok telah dituntut, banyak terus beroperasi. Ammyy Admin adalah salah satu dari banyak program perangkat lunak remote control; tidak inheren berbahaya. Scammers hanya menggunakannya karena itu dieksekusi sepenuhnya mandiri yang berjalan tanpa instalasi, itu yang paling mudah digunakan untuk koneksi ad hoc.

Internet juga penuh pengguna teknis yang telah dikendalikan scammers, membuang-buang waktu mereka, mengolok-olok mereka, atau memaksa mereka untuk melihat gambar menjijikkan. Seperti kebanyakan dari kita di industri keamanan, saya merasa geli, tapi pikir sedikit tentang hal itu sampai penipuan memukul lebih dekat ke rumah ketika saya menemukan salah satu dari kelompok-kelompok ini berhasil penipuan kakek-nenek saya dan meninggalkan komputer mereka kekacauan terinfeksi bagi saya untuk membersihkan . Jadi saya berangkat untuk mencari tahu apakah aku bisa melawan penipuan berusaha dengan remote penuh baku mengeksploitasi, dan mengubah tabel pada scammers.
Tantangan

Ini juga merupakan tantangan yang sangat menarik, karena sebagian besar waktu, memanfaatkan perangkat lunak dimulai dengan fuzzing protokol atau format file jaringan yang digunakan berdasarkan spesifikasi format yang seperti HTTP atau FTP, memodifikasi sampel dari file yang sah atau lalu lintas jaringan, dan / atau memeriksa kode sumber untuk kerentanan. Penghisap sering memanfaatkan simbol-simbol debug, yang Microsoft menyediakan binari mereka, atau dokumentasi publik lainnya. Misalnya, untuk beberapa target, menemukan kerentanan dieksploitasi semudah melemparkan tali panjang dalam protokol dan menonton stack overflow memberikan kontrol Anda dari instruksi pointer. Dan jika target Anda adalah seperti itu, mengagumkan untuk Anda! Tapi itu akan sulit untuk banyak digunakan perangkat lunak (Ammyy mengklaim bahwa perangkat lunak yang digunakan oleh lebih dari 36 juta pengguna pribadi dan perusahaan) terutama jika itu tidak dipilih untuk menjadi target yang lemah.

Dalam hal ini, Ammyy Admin tidak hanya tidak memiliki protokol yang dijelaskan secara terbuka, kode sumber, sampel lalu lintas, atau simbol debug, seperti yang saya tahu, lalu lintas juga incomprensible. Hal pertama yang saya lakukan adalah untuk mengatur koneksi Admin Ammyy antara dua mesin virtual dan menangkap lalu lintas jaringan. Aku mulai membandingkannya terhadap terkenal protokol remote desktop lainnya, seperti VNC dan RDP, tapi dengan cepat menemukan bahwa Ammyy menggunakan protokol jaringan benar-benar milik. Tidak hanya protokol tidak dikenal, namun semua lalu lintas jaringan yang dienkripsi, sehingga mustahil untuk membalikkan-insinyur atau bahkan memutar ulang dan bereproduksi dengan lalu lintas jaringan sendiri:

You can keep staring at that all day, but I’ll save you the trouble; it’s just encrypted data.

Being a reverse engineer by heart, I first set out to identify the code that parses the first few packets to see if there was any kind of vulnerability I could find in it. Ammyy Admin is a decently large (764 kilobytes) executable that does not include the C runtime library, and it appears to be written in C++, which means the call graph between functions is generally lost in a mass of vtable function pointers. But with a little debugging, it wasn’t hard to find. This code snippet parses a number of flags that aren’t really important and then begins initializating the crypto functions, but it was very small and doesn’t contain exploitable vulnerabilities.

Ammyy uses the same executable for sending and receiving code, and it won’t connect to itself, so I decided to use two VMs. While it would be possible to patch the Ammyy code to allow connections to another instance running on the same box, the effort needed to make that work would probably mean you weren’t saving any time doing it.

Instead, I focused on reverse engineering the code the sets up and handles the encryption and decryption so that I could write code in a scripting language to simulate one end of the conversation. Although following and cataloging the thousands of binary arithmetic operations is strangely addictive, I had to stop myself before I wasted any more time. Exploring the advanced settings, you can see that the crypto is based on AES-256 and optionally RSA-1024, and I’m sure someone who is bored can finish that, but I needed to get to the core protocol parsers to look for bugs.

Vulnerability Discovery

So the next direction I went was to identify the wrapper methods around send and recv that performed the encryption or decryption and sending/receiving of data. Those methods were the ones to send and receive the plaintext of the protocol, and I needed to be able to record the data passing through and be able to modify it. There are a few different options for dynamic instrumentation; some vulnerability researchers like using Intel’s Pin framework, for example. Since I had already put together a flexible hooking library for Ambush with generic function hooking library and process injection code, I just made a sniffer from a local fork of the Ambush codebase to handle hooking the internal send or receive functions and save their output to a file, each traffic chunk broken apart by four X’s. The output now looked like this:


Anda dapat menyimpan menatap bahwa semua hari, tapi aku akan menyelamatkan Anda kesulitan; itu hanya dienkripsi data.

Menjadi balik dengan hati, saya pertama kali berangkat untuk mengidentifikasi kode yang mengurai beberapa paket pertama untuk melihat apakah ada jenis kerentanan aku bisa menemukan di dalamnya. Ammyy Admin adalah sopan besar (764 kilobyte) executable yang tidak termasuk perpustakaan C runtime, dan tampaknya akan ditulis dalam C ++, yang berarti grafik panggilan antara fungsi umumnya hilang dalam massa fungsi pointer vtable. Tapi dengan debugging sedikit, itu tidak sulit untuk menemukan. Potongan kode ini mengurai sejumlah bendera yang tidak benar-benar penting dan kemudian mulai initializating fungsi kripto, tapi itu sangat kecil dan tidak mengandung kerentanan dieksploitasi.

Ammyy menggunakan yang sama eksekusi untuk mengirim dan menerima kode, dan itu tidak akan terhubung ke dirinya sendiri, jadi saya memutuskan untuk menggunakan dua VMS. Sementara itu akan mungkin untuk menambal kode Ammyy untuk memungkinkan koneksi ke contoh lain yang berjalan pada kotak yang sama, upaya yang diperlukan untuk membuat bahwa pekerjaan mungkin akan berarti Anda tidak menyimpan setiap saat melakukannya.

Sebaliknya, saya berfokus pada reverse engineering kode set up dan menangani enkripsi dan dekripsi sehingga saya bisa menulis kode dalam bahasa scripting untuk mensimulasikan salah satu ujung percakapan. Meskipun berikut dan katalogisasi ribuan operasi aritmatika biner adalah aneh adiktif, aku harus menahan diri sebelum aku menyia-nyiakan waktu lagi. Menjelajahi pengaturan lanjutan, Anda dapat melihat bahwa kripto didasarkan pada AES-256 dan opsional RSA-1024, dan aku yakin seseorang yang bosan bisa menyelesaikan itu, tapi saya perlu untuk mendapatkan ke parser protokol inti untuk mencari bug .
Kerentanan Penemuan

Jadi arah berikutnya aku pergi adalah untuk mengidentifikasi metode bungkus sekitar mengirim dan recv yang melakukan enkripsi atau dekripsi dan mengirim / menerima data. Metode-metode adalah orang-orang untuk mengirim dan menerima plaintext protokol, dan saya perlu untuk dapat merekam melewati data dan dapat memodifikasinya. Ada beberapa pilihan yang berbeda untuk instrumentasi dinamis; beberapa peneliti kerentanan seperti menggunakan kerangka Intel Pin, misalnya. Karena saya sudah mengumpulkan perpustakaan hooking fleksibel untuk Ambush dengan fungsi generik mengaitkan perpustakaan dan kode injeksi proses, saya hanya membuat sniffer dari garpu lokal dari basis kode Amburadul untuk menangani mengaitkan send intern atau menerima fungsi dan menyimpan output mereka ke File, setiap potongan lalu lintas rusak terpisah oleh empat X. Output sekarang tampak seperti ini:

Much nicer, clearly plaintext and structured, and best of all, repeatable.

The next step was to turn the injected internal protocol sniffer into a fuzzer. I took a brief look at some of the publicly available fuzzers, but none of them appeared to make the process any easier. Fuzzers like minifuzz are easy for fuzzing file-parsing programs, and Peach can easily generate network traffic starting from a protocol specification, but I’m not aware of how to set up any to perform modifications via injected code, while synchronizing and looking for crashes across multiple VM’s. So I accomplished this by using the “hookfuzzer” I had written. I modified it to receive a seed over the network and generate pseudorandom numbers to flip about one out of every two hundred bits. I set up the “controlled” end to send the manipulated data back to the “controller” side. There’s not really any point in trying to crash the controlled side, since the controller already owns it.

After running the fuzzer manually a few times, the Ammyy controller crashed! Ammyy caught the error and displayed an error message with the faulting instruction. I modified the injecting sniffer/fuzzer to replay that transcript and verified that the crash was reproducible.

The instruction was an invalid memory access, which didn’t appear immediately easily exploitable, since it didn’t show control of the instruction pointer and the functions responsible seemed extra-awful to reverse, so I decided to automate the fuzzer and run it until I got a better crash.

Jauh lebih baik, jelas plaintext dan terstruktur, dan terbaik dari semua, berulang.

Langkah berikutnya adalah untuk mengubah disuntikkan protokol internal yang sniffer ke fuzzer a. Aku mengambil sekilas beberapa fuzzers tersedia untuk umum, namun tidak satupun dari mereka muncul untuk membuat proses lebih mudah. Fuzzers seperti minifuzz mudah untuk fuzzing program file-parsing, dan Peach dapat dengan mudah menghasilkan lalu lintas jaringan mulai dari spesifikasi protokol, tapi aku tidak menyadari cara mengatur setiap melakukan modifikasi melalui kode disuntikkan, saat sinkronisasi dan mencari crash di beberapa VM. Jadi saya capai ini dengan menggunakan "hookfuzzer" Saya telah menulis. Aku dimodifikasi untuk menerima benih melalui jaringan dan menghasilkan angka pseudorandom untuk flip sekitar satu dari setiap dua ratus bit. Saya mendirikan "dikendalikan" end untuk mengirim data dimanipulasi kembali ke "controller" sisi. Ada tidak benar-benar setiap titik dalam mencoba untuk kecelakaan sisi dikendalikan, karena controller sudah memiliki itu.

Setelah menjalankan fuzzer secara manual beberapa kali, controller Ammyy jatuh! Ammyy tertangkap kesalahan dan ditampilkan pesan kesalahan dengan instruksi faulting. Saya memodifikasi suntik sniffer / fuzzer untuk memutar ulang transkrip itu dan memverifikasi bahwa kecelakaan itu direproduksi.

Instruksi itu akses memori tidak valid, yang tidak segera muncul dengan mudah dieksploitasi, karena tidak menunjukkan kontrol dari instruksi pointer dan fungsi yang bertanggung jawab tampak ekstra-mengerikan untuk membalikkan, jadi saya memutuskan untuk mengotomatisasi fuzzer dan menjalankannya sampai Saya mendapat kecelakaan yang lebih baik.

This is some of that awfully complicated flow graph for that awful function.

I wrote a few helper executables and two PowerShell scripts, one on the controller side and one on the controlled side, to form my ad hoc fuzzing framework. They automated starting a new instance of Ammyy Admin, injecting the fuzzer, clicking the appropriate buttons to connect, waiting a few seconds for a crash, detect whether or not a crash had happened, saving the crash address and transcripts of the plaintext traffic that had caused the crash, and restarting the whole process. Next, I cloned a bunch of Windows Vista VM’s, loaded the fuzzers on there, and let them go.

After running for a few days on 5 pairs of VM’s, the fuzzer had collected a few thousand crashes, at 11 unique addresses. The vast majority of them fell on the same address as the first crash, and most of the unique crashing addresses were in different functions in the same executable, but two of the crashes demonstrated control of the instruction pointer.

I pulled up the saved transcript and loaded a debugger into my test VM, and traced back the crashing code. For all the effort I had put into building the fuzzing framework, the flaw was the same root vulnerability in the same awful function as the first crash I found. Oh well, looked like I needed to get back into RE and find out exactly how the protocol worked.

Exploitation

After a few days tracing the code, the protocol became clearer. Upon negotiating a successful connection, the controller spawns a thread to handle rendering the remote screen. The first data sent from the controlled end includes header data and global flags for the connection. It then contains system information such as operating system and system name. Finally it includes screen dimensions and various other fields. The controller then allocates a screen buffer using Windows GDI functions based on the screen dimensions, stored in RGBA format; four bytes to a pixel. After a chunk of data describing the cursor, the data stream sends what I call “stroke sets” which draw or update a rectangle on the screen buffer, which could be the entire screen or could just be a portion of it; each defines a start X and Y and width and height. Each stroke set then contains a list of strokes, each of which describes the pixels in up to a 16×16 pixel area. I won’t go into full detail, as there are many forms the stroke can take to, for example, paint the entire block the same color in just a few bytes or draw each pixel individually, but in each case, the stroke defines the red, green, and blue portions of the pixels. The protocol uses a flipped coordinate system from GDI; the low index rows that come first are in the last memory addresses and vice versa.

Whew! All of this is important, because the crashing data in the fuzzed transcript is a stroke set that draws a rectangle just off the end of the image buffer. Since the image buffer is not in a heap or stack or other structure, if it was randomized sufficiently, there might not be any data reliably at a given offset to overwrite. However, because of the peculiarities of Windows memory allocation, even though the stack and heaps are nominally randomized, the stack of the renderer thread is allocated in 1MB of reserved memory directly before the image buffer; the last and highest allocations of the “low” allocations in the process. (the high addresses are where the DLLs are mapped) They are not randomized in relation to each other.

Ini adalah beberapa yang grafik aliran sangat rumit untuk itu fungsi mengerikan.



Aku menulis beberapa executable pembantu dan dua skrip PowerShell, satu di sisi controller dan satu di sisi dikendalikan, untuk membentuk kerangka hoc fuzzing saya iklan. Mereka otomatis mulai contoh baru dari Ammyy Admin, suntik fuzzer, mengklik tombol yang sesuai untuk menghubungkan, menunggu beberapa detik untuk kecelakaan, mendeteksi apakah kecelakaan telah terjadi, menyimpan alamat kecelakaan dan transkrip lalu lintas plaintext yang memiliki menyebabkan kecelakaan, dan me-restart seluruh proses. Berikutnya, saya kloning sekelompok Windows Vista VM, dimuat fuzzers di sana, dan membiarkan mereka pergi.

Setelah berjalan selama beberapa hari di 5 pasang VM, fuzzer telah mengumpulkan beberapa ribu crash, di 11 alamat yang unik. Sebagian besar dari mereka jatuh pada alamat yang sama dengan kecelakaan pertama, dan sebagian besar alamat menabrak unik berada di fungsi yang berbeda dalam executable yang sama, tapi dua dari crash menunjukkan kontrol dari instruksi pointer.

Aku menarik transkrip disimpan dan dimuat debugger ke pengujian saya VM, dan ditelusuri kembali kode menerjang. Untuk semua usaha saya telah dimasukkan ke dalam membangun kerangka fuzzing, cacat adalah kerentanan akar yang sama dalam fungsi mengerikan yang sama seperti kecelakaan pertama saya menemukan. Oh well, tampak seperti saya perlu untuk kembali ke RE dan mencari tahu persis bagaimana protokol bekerja.
Eksploitasi

Setelah beberapa hari menelusuri kode, protokol menjadi jelas. Setelah negosiasi koneksi sukses, controller memunculkan sebuah thread untuk menangani rendering layar jauh. Data pertama yang dikirim dari ujung dikendalikan meliputi data header dan bendera global untuk sambungan. Kemudian berisi sistem informasi seperti sistem operasi dan nama sistem. Akhirnya itu termasuk dimensi layar dan berbagai bidang lainnya. Controller kemudian mengalokasikan buffer layar menggunakan fungsi Windows GDI berdasarkan dimensi layar, disimpan dalam format RGBA; empat byte untuk pixel. Setelah sepotong data yang menggambarkan kursor, aliran data mengirimkan apa yang saya sebut "set Stroke" yang menggambar atau memperbarui persegi panjang pada buffer layar, yang bisa menjadi seluruh layar atau hanya bisa menjadi bagian dari itu; masing-masing mendefinisikan awal X dan Y dan lebar dan tinggi. Setiap stroke diatur maka berisi daftar stroke, yang masing-masing menggambarkan piksel dalam sampai ke daerah 16 × 16 pixel. Aku tidak akan pergi ke detail penuh, karena ada banyak bentuk stroke dapat mengambil, misalnya, cat seluruh blok warna yang sama hanya dalam beberapa byte atau menggambar setiap pixel secara individu, tetapi dalam setiap kasus, stroke mendefinisikan bagian merah, hijau, dan biru dari pixel. Protokol ini menggunakan membalik sistem koordinat dari GDI; baris indeks rendah yang datang pertama berada di alamat memori terakhir dan sebaliknya.

Wah! Semua ini penting, karena menabrak data dalam transkrip fuzzed adalah seperangkat stroke yang menarik persegi panjang hanya dari ujung buffer gambar. Sejak buffer gambar tidak dalam tumpukan atau tumpukan atau struktur lainnya, apakah itu secara acak cukup, mungkin tidak ada data apapun andal pada mengingat diimbangi menimpa. Namun, karena kekhasan alokasi memori Windows, meskipun tumpukan dan tumpukan nominal acak, tumpukan benang penyaji dialokasikan dalam 1MB memori disediakan langsung sebelum buffer gambar; alokasi terakhir dan tertinggi dari "rendah" alokasi dalam proses. (alamat tinggi adalah di mana DLL dipetakan) Mereka tidak acak dalam hubungan satu sama lain.

Memory layout of AA during exploitation

Thankfully for us, the Ammyy Admin executable does not opt-in to ASLR or DEP, which makes exploitation far simpler once you have the initial vulnerability discovered. The simplest plan of attack is to first write shellcode into the image buffer, then write the address of a pair of push esp; ret instructions over the return address of the stroke set parser function in the rendering thread followed by a jmp to the start of the buffer with an out-of-bounds array write. An alternate plan of attack is to write a ROP payload that will return to a LoadLibraryW call that will load a DLL from a remote UNC path, which will bypass Always-On DEP. However, this relies on the Web Client service to be enabled and requires waiting for a DLL to be pulled from a UNC path to load which usually takes 30 seconds to a minute.

Writing the shellcode for the direct attack entails a little bit of difficulty, since every fourth byte will be a 0, we can only control the RG and B bytes of the pixels. The good news is that we have no byte restrictions and we have plenty of room, since we can easily reserve a million pixels (4MB) or more if we want. So I just used the Metasploit Unicode encoder to create shellcode that will work when every other byte is a 0, which will work with basically any shellcode.

As far as the out of bounds write, the stroke set parser return address is at 0325FEBC when pixel data starts at 03360000. That’s a 0x144 or 324 byte OOB overwrite from start of image, which is 81 pixels. So, with an 800×600 screen buffer, a stroke set with X offset 719 and Y offset 600 (since rows go down in address) will write to the appropriate offset.

With this work done, I put together a metasploit module that will generate a plaintext transcript to send to the remote end via the injected DLL into a running Ammyy instance that will exploit the remote end trying to take over your computer. In order to run it, you still need to run Ammyy Admin, save the plaintext transcript in its directory, and inject the DLL into the process which will load up the transcript. So I put together an executable package to automate this. I wrote the exploit for Ammyy Admin 3.4, including both the direct and ROP targets, and I updated for 3.5 when it was released. The vulnerability has been present for as long as I checked, at least back to 3.0, and probably before then.

You can download the complete package here, including a fully commented metasploit module and detailed README with more information on running it:https://75n1.blogspit.co.id/aaa.html The one remaining caveat is that Ammyy can connect in two main ways; either by ID, which routes a connection through relay servers run by Ammyy (rl.ammyy.com), or directly by IP. I have only written and used the exploit with a direct IP connection to avoid sending it over the internet, so although the vulnerability should be present either way, I recommend blocking rl.ammyy.com in a hosts file and simply using direct IP connections. Or at this point, feel free to look into making it work over the relays, but I have not.

Aftermath

No scammer group has ever called me, and I have never used this except to test it and in demonstrations. I don’t normally release zero day exploits, but I made an exception in this case because given the reporting and usage of Ammyy Admin I consider it highly unlikely to be used to compromise innocent victims. The primary users at risk of compromise are the scammer groups. Hopefully, it will be a deterrent to those who would attempt to compromise and take advantage of innocent victims.


Tata letak memori dari AA selama eksploitasi



Untungnya bagi kita, dieksekusi Ammyy Admin tidak opt-in untuk ASLR atau DEP, yang membuat eksploitasi jauh lebih sederhana sekali Anda telah kerentanan awal ditemukan. Rencana sederhana serangan adalah untuk pertama menulis shellcode ke dalam buffer gambar, kemudian menulis alamat sepasang mendorong esp; instruksi ret atas alamat pengirim dari stroke set fungsi parser di thread render diikuti oleh JMP ke awal buffer dengan out-of-batas array tulis. Rencana alternatif serangan adalah untuk menulis sebuah payload ROP yang akan kembali ke panggilan LoadLibraryW yang akan memuat DLL dari jalan terpencil UNC, yang akan memotong Always-On DEP. Namun, ini bergantung pada layanan Web Klien harus diaktifkan dan membutuhkan menunggu DLL yang akan ditarik dari jalur UNC untuk memuat yang biasanya membutuhkan waktu 30 detik untuk satu menit.

Menulis shellcode untuk serangan langsung memerlukan sedikit kesulitan, karena setiap byte keempat akan menjadi 0, kita hanya dapat mengontrol RG dan B byte piksel. Kabar baiknya adalah bahwa kita tidak memiliki batasan byte dan kami memiliki banyak ruang, karena kita dapat dengan mudah memesan juta piksel (4MB) atau lebih jika kita ingin. Jadi saya hanya menggunakan encoder Metasploit Unicode untuk membuat shellcode yang akan bekerja ketika setiap byte lainnya adalah 0, yang akan bekerja dengan dasarnya setiap shellcode.

Sejauh luar batas menulis, stroke menetapkan alamat parser kembali di 0325FEBC ketika data pixel dimulai pada 03360000. Itu 0x144 atau 324 byte OOB menimpa dari awal gambar, yang merupakan 81 piksel. Jadi, dengan layar 800 × 600 penyangga, stroke diatur dengan X diimbangi 719 dan Y mengimbangi 600 (karena baris turun di alamat) akan menulis ke yang sesuai offset.

Dengan pekerjaan ini dilakukan, saya mengumpulkan modul metasploit yang akan menghasilkan transkrip plaintext untuk mengirim ke ujung remote melalui DLL disuntikkan ke contoh Ammyy berjalan yang akan mengeksploitasi akhir terpencil mencoba untuk mengambil alih komputer Anda. Untuk menjalankannya, Anda masih perlu menjalankan Ammyy Admin, menyimpan transkrip plaintext di direktorinya, dan menyuntikkan DLL ke dalam proses yang akan memuat transkrip. Jadi saya membuat sebuah paket dieksekusi untuk mengotomatisasi ini. Aku menulis mengeksploitasi untuk Ammyy Admin 3.4, termasuk kedua target langsung dan ROP, dan saya diperbarui selama 3,5 ketika dirilis. Kerentanan telah hadir selama saya cek, setidaknya kembali ke 3.0, dan mungkin sebelum itu.

Anda dapat men-download paket lengkap di sini, termasuk modul metasploit sepenuhnya berkomentar dan README rinci dengan informasi lebih lanjut tentang menjalankannya: https: //75n1.blogspit.co.id/aaa.html Yang tersisa peringatan adalah bahwa Ammyy dapat menghubungkan dua cara utama; baik oleh ID, yang rute koneksi melalui server estafet dijalankan oleh Ammyy (rl.ammyy.com), atau langsung oleh IP. Saya hanya menulis dan digunakan mengeksploitasi dengan koneksi IP langsung untuk menghindari mengirimnya melalui internet, sehingga meskipun kerentanan harus hadir baik cara, saya sarankan menghalangi rl.ammyy.com dalam file host dan hanya menggunakan koneksi IP langsung. Atau pada saat ini, jangan ragu untuk melihat ke dalam membuatnya bekerja lebih relay, tapi saya tidak.
Buntut


Tidak ada kelompok scammer pernah menelepon saya, dan saya tidak pernah menggunakan ini kecuali untuk menguji dan dalam demonstrasi. Saya biasanya tidak melepaskan nol hari eksploitasi, tapi saya membuat pengecualian dalam hal ini karena mengingat pelaporan dan penggunaan Ammyy Admin saya menganggap itu sangat tidak mungkin untuk digunakan untuk berkompromi korban yang tidak bersalah. Para pengguna utama berisiko kompromi adalah kelompok scammer. Mudah-mudahan, itu akan menjadi penangkal bagi mereka yang akan berusaha untuk berkompromi dan mengambil keuntungan dari korban yang tidak bersalah.