A proof of concept (for Flash 188.8.131.52) of a heap-based buffer overflow patched on September 9th, affecting Flash 13.0.0.<244, 14.0.0.<=179 15.0.0.<152 was published on September 30th on Packet Storm . Code targeting that CVE is now in Nuclear Pack.
Nuclear Pack :
(I asked for help in analyzing this Flash Exploit - post will be updated)
Spotted on the 2014-10-19 but i thought illustrating it with a top500 worldwide website (owner will explain that it has been abused again...strange timing no ?) would better set things in perspective.
For people thinking i "forgot" to credit Threat Glass for the referer...take a look at the vote timestamp on the payload ;)
|Beeg .com leading to Nuclear Pack and Cryptowall|
Successul CVE-2014-0556 pass in Nuclear Pack 2014-10-20
GET http://axxesopri .ml/305d439amjgij.html
200 OK (text/html) d0806f81d4aaada74228ac352b463c05
Here another fresh Nuclear Pack landing after first deobfuscation pass :
|CVE-2014-0556 related piece of Code in Nuclear Pack|
GET http://axxesopri .ml/e109e3265b7emjgij/1413764940
200 OK (application/octet-stream) 8c5d2ff9417522e909881b6de001d8f3 CVE-2014-0556 (more data to come)
GET http://axxesopri .ml/e109e326mjgij/1413764940/7
200 OK (application/octet-stream) d0806f81d4aaada74228ac352b463c05 - Cryptowall
[Public Mail Reply]
How can I manage the updates for free and in a reliable way ?
You can consider using opensource tools like wpkg to spread the update. Ocs Inventory NG to ensure that the update campaign has been totally successful (and track the glitches).
In a multi-site environment a well thought DFS installation may help pushing the wpkg/update package on all remote sites. Then new flash/java/reader updates can be handled in few minutes (comments welcome)
Files: A pointless : Nothing yet.
Exploiting CVE-2014-0556 in Flash - 2014-09-23 - Chris Evans - Project Zero
Adobe Flash 184.108.40.206 copyPixelsToByteArray() Heap Overflow - 2014-09-30 - Packet Storm