Critical Zero-Day Vulnerability in Apache Log4j Java Library: CVE-2021-44228 - Updated Solution

 

Summary

UPDATE, 27 December 2021

 

CISA, along with other security organizations, recently released scanners to identify Log4j vulnerabilities. The open-source tool is derived from scanners created by other members of the security community and is designed to help organizations determine if they have vulnerable web services affected by the critical Log4j vulnerabilities. This scanner is located on CISA's public Github repository , and scans for two major Log4j vulnerabilities, tracked as CVE-2021-44228 and CVE-2021-45046. CISA stated that this scanner supports DNS callback for vulnerability discovery and validation as well.

 

UPDATE, 22 December 2021

 

Today the CISA, FBI, NSA, Australian Cyber Security Centre (ACSC), Canadian Centre for Cyber Security (CCCS), the Computer Emergency Response Team New Zealand (CERT NZ), the New Zealand National Cyber Security Centre (NZ NCSC), and the United Kingdom’s National Cyber Security Centre (NCSC-UK) released a joint alert to provide additional guidance in mitigating vulnerabilities pertaining to Apache’s Log4j software library.

 

This alert expands on previously published guidance by "detailing steps that vendors and organizations with IT and/or cloud assets should take to reduce the risk posed by these vulnerabilities."

 

These steps include:

• Identifying assets affected by Log4Shell and other Log4j-related vulnerabilities
• Upgrading Log4j assets and affected products to the latest version as soon as patches are available and remaining alert to vendor software updates
• Initiating hunt and incident response procedures to detect possible Log4Shell exploitation.

This alert also provides additional guidance for affected organizations with operational technology (OT)/industrial control systems (ICS) assets.

 

UPDATE, 21 December 2021

 

It has been recently discovered that the Log4j vulnerability is now being exploited to infect Windows devices with the Dridex banking Trojan and Linux devices with Meterpreter.

 

Researchers state that threat actors use the Log4j RMI (Remote Method Invocation) exploit variant to force vulnerable devices to load and execute a Java class from an attacker-controlled remote server. Successful execution allows installation of the Dridex Trojan or Meterpreter once the targeted device is identified as running Windows or Linux.

 

Dridex is known for targeting online banking users to steal their credentials. More recent variants of Dridex have additional capabilities such as conducting surveillance activities, uploading additional malware, and propagating to other devices.

 

Successful deployment of either Dridex or Meterpreter could allow attackers to deploy further payloads or remotely execute commands on an affected device.

 

UPDATE, 20 December 2021

 

Another vulnerability in Log4j has been identified. CVE-2021-45105 , rated as high severity (CVSS: 7.5), could allow an attacker with control over Thread Context Map data to cause a DoS condition.

 

While not exploiting the same vulnerability as the initial Log4j vulnerability, CVE-2021-45105 uses Context Map lookups rather than the JNDI lookups to an LDAP server that allows attackers to execute any code that’s returned in the Log4Shell vulnerability. This vulnerability affects all versions of the tool from 2.0-beta9 to 2.16, but only appears to affect non-default configurations.

 

Apache released its newest update, 2.17.0 , to mitigate the newest vulnerabilities.

 

UPDATE, 17 December 2021

 

New details regarding Log4j continue to emerge.

 

Two additional vulnerabilities addressing Log4j have been observed and detailed. As of the time of this writing, there are four vulnerabilities associated with Log4j (also known as LogJam and Log4Shell):

• CVE-2021-44228 is the original Log4j vulnerability, rated as critical (CVSS: 10.0)
• CVE-2021-45046 is a Denial of Service (DoS) vulnerability. Previously considered a low severity vulnerability (CVSS: 3.7), CVE-2021-45046 has been recently updated as critical (CVSS: 9.0)
• CVE-2021-4104 affects the non-default configurations of Log4j 1.x instances and is considered a high severity vulnerability (CVSS: 8.1)
• CVE-2021-42550 is a vulnerability in the Logback logging framework, a successor to the Log4j 1.x library and is rated as medium severity (CVSS: 6.6)

Researchers strongly recommend updating to version 2.16.0, and organizations are urged to continue to monitor Apache's Log4j advisory page for updates.

 

In addition, CISA today issued an emergency directive directing federal civilian executive branch (FCEB) agencies to address Log4j vulnerabilities.

 

While the CISA Emergency Directive applies directly to federal civilian executive branch agencies, it does demonstrate the level of attention CISA is placing on these vulnerabilities and their recommended mitigating actions. For additional details, see CISA’s webpage Apache Log4j Vulnerability Guidance .

 

New studies also show that attackers - from cybercriminals, including newly identified Conti ransomware actors targeting VMWare servers, to nation-state actors - have attempted to exploit log4j vulnerabilities on almost half of global networks.

 

UPDATE, 15 December 2021

 

A second vulnerability in Log4j was recently discovered. Tracked as CVE-2021-45046 with a CVSS score of 3.7, this vulnerability affects all versions of Log4j through version 2.15.0.

 

Apache has released version 2.16.0 in response; it is now recommended organizations apply the latest patch version 2.16.0, as version 2.15.0 was deemed incomplete. Apache stated in this latest advisory that the incomplete patch for CVE-2021-44228 could be abused to "craft malicious input data using a JNDI Lookup pattern resulting in a denial-of-service (DoS) attack."

 

UPDATE, 14 December 2021

 

CISA states that they, along with partners, are tracking and responding to the active, widespread exploitation of this critical RCE vulnerability, thought to potentially affect millions of organizations and hundreds of millions of devices across a variety of enterprises and industries.

 

As a result, CISA created a website devoted to guidance related to the Log4j vulnerability. This website will be actively maintained with a community-sourced GitHub repository of publicly available information and vendor-supplied advisories.

 

Of note, Log4j is now being viewed as 'fully weaponized' and being actively exploited by what at least two security firms suggest are Chinese government hacking groups.

 

UPDATE, 13 December 2021

 

Additional details continue to roll in on the critical zero-day vulnerability affecting several versions of Apache’s Log4j, CVE-2021-44228.

 

Over the weekend, researchers published a blog detailing their observations on how attackers are attempting to exploit this vulnerability, including variations in attack methods and obfuscation methods in attempts to hide within ‘normal’ network traffic.

 

Additional research shows that CVE-2021-44228 is being leveraged to form new botnets. Two have been identified – a Muhstik botnet and a Mirai botnet – both being used to target Linux devices.

 

In addition, coin miners are now attempting to exploit this vulnerability for their purposes.

 

In fact, mass scanning attempts aiming to deploy coin miners or malware for building botnets have been observed. This could be considered 'sophisticated activity,' potentially from an advanced persistent threat (APT) actor or a state-sponsored actor.

 

Again, Apache has released Log4j version 2.15 which contains a fix for this CVE. It is recommended to immediately upgrade to this version once appropriate testing has been completed in your environment.

 

Researchers recommend that, if your organization is unable to apply the patches, you can mitigate this vulnerability as follows:

• For versions 2.0 and before 2.10, Apache recommends removing the Jndi Lookup class from the classpath by running:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

• For versions 2.10 and above, set the system property formatMsgNoLookups to true or set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• If you cannot do any of the above, you can block all outbound LDAP or RMI connections using Application Identity filters. Juniper SRX NG Firewall provides AppID signatures for both protocols.

Some researchers also recommend web application firewalls (WAF) - though these are not considered foolproof - as well as outbound egress filtering and allow listing.

 

Indicators of Compromised (IoCs) and additional mitigation recommendations are available at the research sites mentioned above. In addition, further details regarding known vulnerable software are availble here , and details regarding exploitation detection are available here .

 

Original Content

 

Apache recently released a security advisory to address a vulnerability in its Log4j Java library, an open source logging utility that's used in countless apps, including those used by large enterprise organizations and cloud services.

 

A remote code execution (RCE) vulnerability that does not require authentication, CVE-2021-44228 , dubbed Log4Shell or LogJam, affects Log4j versions 2.0-beta9 to 2.14.1. This vulnerability is considered critical and has been assigned a CVSS score of 10.0.

 

A remote attacker could exploit this vulnerability to take control of an affected system.

 

Researchers initially reported this vulnerability to Apache on November 24, indicating that CVE-2021-44228 also impacts default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others.

 

A proof-of-concept (PoC) exploit was published on GitHub yesterday; threat actors immediately began scanning the internet for vulnerable hosts and networks.

 

Along with Apache and the US CISA, New Zealand Computer Emergency Response Team (CERT NZ) issued a security advisory warning of active exploitation in the wild.

 

Further, other researchers believe that "Similarly to other high-profile vulnerabilities such as Heartbleed and Shellshock, we believe there will be an increasing number of vulnerable products discovered in the weeks to come."

 

It is likely that many threat actors, to include ransomware actors, will begin leveraging this vulnerability immediately.

Analysis

Affected Versions

 

This vulnerability impacts Log4j versions 2.0-beta9 to 2.14.1, as well as default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink.

 

Potential Impact

 

Successful exploitation of this vulnerability could allow complete system takeover on vulnerable systems.

 

Recommendations

Apache released an update to address this vulnerability.

 

CISA encourages users and administrators to review the Apache Log4j 2.15.0 Announcement and upgrade to Log4j 2.15.0 or apply the recommended mitigations immediately.

 

References

https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://logging.apache.org/log4j/2.x/security.html
https://www.cyberkendra.com/2021/12/worst-log4j-rce-zeroday-dropped-on.html
https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-actively-exploited/
https://protect-eu.mimecast.com/s/7LIkCWnxXIDKZWo5HxkFaf?domain=mail-archives.us.apache.org
https://github.com/tangxiaofeng7/apache-log4j-poc
https://blogs.juniper.net/en-us/enterprise-cloud-and-transformation/apache-log4j-vulnerability-cve-2021-44228-raises-widespread-concerns
https://blog.netlab.360.com/threat-alert-log4j-vulnerability-has-been-adopted-by-two-linux-botnets/
https://isc.sans.edu/forums/diary/Log4Shell+exploited+to+implant+coin+miners/28124/
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
https://github.com/NCSC-NL/log4shell/tree/main/software
https://www.govinfosecurity.com/serious-log4j-security-flaw-race-underway-to-discern-scope-a-18107
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
https://github.com/cisagov/log4j-affected-db
https://nvd.nist.gov/vuln/detail/CVE-2021-45046
https://www.zdnet.com/article/log4j-flaw-nearly-half-of-corporate-networks-have-been-targeted-by-attackers-trying-to-use-this-vulnerability/#ftag=RSSbaffb68
https://nvd.nist.gov/vuln/detail/CVE-2021-42550
https://nvd.nist.gov/vuln/detail/CVE-2021-4104
https://www.cisa.gov/emergency-directive-22-02
https://www.bleepingcomputer.com/news/security/conti-ransomware-uses-log4j-bug-to-hack-vmware-vcenter-servers/
https://nvd.nist.gov/vuln/detail/CVE-2021-45105
https://logging.apache.org/log4j/2.x/download.html
https://heimdalsecurity.com/blog/dridex-malware-installed-with-the-help-of-log4j-vulnerability/
https://www.cisa.gov/uscert/ncas/alerts/aa21-356a
https://github.com/cisagov/log4j-scanner

Microsoft Exchange Y2K22 bug

According to numerous reports from Microsoft Exchange admins worldwide, a bug in the FIP-FS engine is blocking email delivery with on-premise servers starting at midnight on January 1st, 2022.

Security researcher and Exchange admin Joseph Roosen said that this is caused by Microsoft using a signed int32 variable to store the value of a date, which has a maximum value of 2,147,483,647.

However, dates in 2022 have a minimum value of 2,201,010,001 or larger, which is greater than the maximum value that can be stored in the signed int32 variable, causing the scanning engine to fail and not release mail for delivery.

When this bug is triggered, an 1106 error will appear in the Exchange Server's Event Log stating, "The FIP-FS Scan Process failed initialization. Error: 0x8004005. Error Details: Unspecified Error" or "Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long."

Microsoft will need to release an Exchange Server update that uses a larger variable to hold the date to officially fix this bug.

However, for on-premise Exchange Servers currently affected, admins have found that you can disable the FIP-FS scanning engine to allow email to start delivering again.

To disable the FIP-FS scanning engine, you can execute the following PowerShell commands on the Exchange Server:

Set-MalwareFilteringServer -Identity  -BypassFiltering $true
Restart-Service MSExchangeTransport

After the MSExchangeTransport service is restarted, mail will start being delivered again.

Unfortunately, with this unofficial fix, delivered mail will no longer be scanned by Microsoft's scanning engine, leading to more malicious emails and spam getting through to users.

Microsoft has confirmed that they are working on a fix and hope to have more information available later today.

We are aware of and working on an issue causing messages to be stuck in transport queues on Exchange Server 2016 and Exchange Server 2019. The problem relates to a date check failure with the change of the new year and it not a failure of the AV engine itself. This is not an issue with malware scanning or the malware engine, and it is not a security-related issue. The version checking performed against the signature file is causing the malware engine to crash, resulting in messages being stuck in transport queues.

We are actively working on resolving this issue and expect to release details on how to resolve this issue later today. In the meantime, if your organization performs malware scanning of messages outside of your on-premises Exchange servers (for example, by routing mail through Exchange Online, or by using a third-party message hygiene solution), you can bypass or disable malware scanning on your Exchange servers and clear your transport queues. You should use one of these workarounds only if you have an existing malware scanner for email other than the engine in Exchange Server. 

BleepingComputer has also contacted Microsoft about the problem but has not received a response yet.

Disable SSH Root Login

 

To disable root login, open the main ssh configuration file /etc/ssh/sshd_config with your choice of editor.

# vi /etc/ssh/sshd_config

Search for the following line in the file.

#PermitRootLogin no

Remove the ‘#‘ from the beginning of the line.  Make the line look similar to this.

PermitRootLogin no

Disable Root Login in Linux

Next, we need to restart the SSH daemon service.

# systemctl restart sshd
OR
# /etc/init.d/sshd restart

Now try to log in with the root user, you will get a “Permission denied” error.

$ ssh root@192.168.0.102
root@192.168.0.102's password: 
Permission denied, please try again.

SSH Permission Denied Error

So, from now onwards login as a normal user and then use the ‘su’ command to switch to root user.

$ ssh root@192.168.0.102
tecmint@192.168.0.102's password:
Last login: Mon Dec 27 15:04:58 2021 from 192.168.0.161

$ su -
Password:
Last login: Mon Dec 27 15:05:07 IST 2021 on pts/1

SSH User Login

Microsoft Loop is a new collobration tool for hybrid work era

Microsoft Loop has three main elements: 

Loop components, 

Loop pages, and 

Loop workspaces. 

Loop components are live pieces of content that can exist across multiple apps, updated in real time and free for anyone to jump into. That could be a list shared in a Teams channel and also editable in a Loop page, or notes in a calendar entry that are also available to be pasted into Outlook and edited in real time within an email.

 

 

 

 

 

 

 

 

 

 

 

 

 

Microsoft’s new Loop app brings together all of its Fluid component work.

Image: Microsoft

These components can also exist in the main Microsoft Loop hub, inside what Microsoft calls shared Loop workspaces. It’s almost like a project board, where you can see a list of all Loop components and Loop pages and who is currently working on them. Think of it as a modern File Explorer, where everything is live and collaborative.

Loop pages are the individual canvases where people can share and collaborate on Loop components. It’s like a modern version of a whiteboard but far more powerful because you can insert and share components that people have created outside of Loop. Not everyone even needs to be part of the entire Loop page, as the individual components could be edited in real time from other apps.

Microsoft’s Loop components can live across multiple apps.

Image: Microsoft

These collaborative Loop components have been the dream of Microsoft for the past couple of years, and it’s clear the company has been adjusting how Loop works to fit the realities of pandemic life. A central Microsoft Loop hub looks like an improved way to track and organize these components — and a clear response to the new hybrid work era to which many businesses are adjusting and competition like Notion.

Microsoft’s demonstrations of Loop components have been impressive so far, but we’ll need to experience them for ourselves to really understand whether Loop can truly deliver the seamless experience that Microsoft keeps promising. Notion has been challenging Microsoft’s traditional Office way of working with many concepts that are similar to Loop, and Microsoft’s response looks like a more powerful version of Notion.

While Microsoft has been talking about Loop (Fluid) for nearly 18 months, it’s still not something that’s inside Office apps yet. Microsoft Loop components will now arrive in Teams, Outlook, and OneNote this month, and the main Microsoft Loop app will be released at a later date.

SQL注入防御与绕过的几种姿势

一、 PHP几种防御姿势

1. 关闭错误提示

说明：

PHP配置文件php.ini中的display_errors=Off，这样就关闭了错误提示。

2. 魔术引号

说明：

当php.ini里的magic_quotes_gpc=On时。提交的变量中所有的单引号(')、双引号(")、反斜线(\)与 NUL(NULL 字符)会自动转为含有反斜线的转义字符。

魔术引号(Magic Quote)是一个自动将进入 PHP 脚本的数据进行转义的过程。(对所有的 GET、POST 和 COOKIE 数据自动运行转义)

PHP 5.4 之前 PHP 指令 magic_quotes_gpc 默认是 on。

本特性已自PHP 5.3.0 起废弃并将自 PHP 5.4.0 起移除，在PHP 5.4.O 起将始终返回 FALSE。

参考：

《magic_quotes_gpc相关说明》：

http://www.cnblogs.com/qiantuwuliang/archive/2009/11/12/1601974.html

3. addslashes

说明：

addslashes函数，它会在指定的预定义字符前添加反斜杠转义，这些预定义的字符是：单引号(')、双引号(")、反斜线(\)与 NUL(NULL 字符)。

这个函数的作用和magic_quotes_gpc一样。所以一般用addslashes前会检查是否开了magic_quotes_gpc。

magic_quotes_gpc与addslashes的区别用法：

1)对于magic_quotes_gpc=on的情况

我们可以不对输入和输出数据库的字符串数据作addslashes()和stripslashes()的操作,数据也会正常显示。

如果此时你对输入的数据作了addslashes()处理，那么在输出的时候就必须使用stripslashes()去掉多余的反斜杠。

2)对于magic_quotes_gpc=off 的情况

必须使用addslashes()对输入数据进行处理，但并不需要使用stripslashes()格式化输出，

因为addslashes()并未将反斜杠一起写入数据库，只是帮助mysql完成了sql语句的执行。

参考：

《addslashes函数说明》：

https://secure.php.net/manual/zh/function.addslashes.php

《对于magic_quotes_gpc的一点认识》：

http://www.phpfans.net/bbs/viewthread.php?tid=6860&page=1&extra=page=1

4. mysql_real_escape_string

说明：

mysql_real_escape_string()函数转义 SQL 语句中使用的字符串中的特殊字符。

下列字符受影响：

\x00 
\n 
\r 
\ 
' 
" 
\x1a 

如果成功，则该函数返回被转义的字符串。如果失败，则返回 false。

本扩展自 PHP5.5.0 起已废弃，并在自 PHP 7.0.0 开始被移除。

因为完全性问题，建议使用拥有Prepared Statement机制的PDO和MYSQLi来代替mysql_query，使用的是mysqli_real_escape_string

参考：

《 PHP防SQL注入不要再用addslashes和mysql_real_escape_string了》：

http://blog.csdn.net/hornedreaper1988/article/details/43520257

《PDO防注入原理分析以及使用PDO的注意事项》：

http://zhangxugg-163-com.iteye.com/blog/1835721

5. htmlspecialchars()

说明：

htmlspecialchars()函数把预定义的字符转换为 HTML实体。

预定义的字符是：

& （和号）成为 & 
" （双引号）成为 " 
' （单引号）成为 ' 
< （小于）成为 &lt; 
> （大于）成为 &gt; 

6. 用正则匹配替换来过滤指定的字符

preg_match 
preg_match_all() 
preg_replace 

参考：

《preg_match说明》：

http://php.net/manual/zh/function.preg-match.php

《preg_replace说明》：

https://secure.php.net/manual/zh/function.preg-replace.php

7. 转换数据类型

说明：

根据「检查数据类型」的原则，查询之前要将输入数据转换为相应类型，如uid都应该经过intval函数格式为int型。

8. 使用预编译语句

说明：

绑定变量使用预编译语句是预防SQL注入的最佳方式，因为使用预编译的SQL语句语义不会发生改变，在SQL语句中，变量用问号?表示，攻击者无法改变SQL语句的结构，从根本上杜绝了SQL注入攻击的发生。

代码示例：

参考：

《Web安全之SQL注入攻击技巧与防范》：

http://www.plhwin.com/2014/06/13/web-security-sql/

二、 几种绕过姿势

下面列举几个防御与绕过的例子：

例子1：addslashes

防御：

这里用了addslashes转义。

绕过：

• 将字符串转为16进制编码数据或使用char函数(十进制)进行转化(因为数据库会自动把16进制转化)
• 用注释符去掉输入密码部分如“-- /* #”

payload:

http://localhost/injection/user.php?username=admin-- hack 

(因为有的SQL要求--后要有空格，所以此处加上了hack)

http://localhost/injection/user.php?username=admin/* 

(escape不转义/*)

http://localhost/injection/user.php?username=admin%23 

(这里的%23即为#，注释掉后面的密码部分。注意IE浏览器会将#转换为空)

http://localhost/injection/user.php?username=0x61646d696e23 

(admin# -->0x61646d696e23)

http://localhost/injection/user.php?username=CHAR(97,100, 109, 105, 110, 35) 

(admin# -->CHAR(97, 100, 109, 105, 110, 35))

关于编码原理：

因为一般前端JavaScript都会escape()、encodeURL或encodeURIComponent编码再传输给服务器，主要为encodeURL，如下，所以可以利用这点。

JavaScript代码如：

拦截请求：

1)escape( )

对ASCII字母、数字、标点符号"@* _ + - . /"不进行编码。在\u0000到\u00ff之间的符号被转成%xx的形式，其余符号被转成%uxxxx的形式。(注意escape()不对"+"编码，而平时表单中的空格会变成+)

2) encodeURL

对" ; / ? : @ & = + $ , # ' "不进行编码。编码后，它输出符号的utf-8形式，并且在每个字节前加上%。

3) encodeURIComponent

用于对URL的组成部分进行个别编码，而不用于对整个URL进行编码。

常用编码：  

@ * _ + - ./ ;  \ ? : @ & = + $ , # ' 空格 

转码工具可用：

http://evilcos.me/lab/xssor/

参考：

《URL编码》：

http://www.ruanyifeng.com/blog/2010/02/url_encoding.html

例子2：匹配过滤

防御：

绕过：

关键词and,or常被用做简单测试网站是否容易进行注入攻击。这里给出简单的绕过使用&&,||分别替换and,or。

• 过滤注入： 1 or 1 = 1 1 and 1 = 1
• 绕过注入： 1 || 1 = 1 1 && 1 = 1

关于preg_match过滤可以看参考文章，文章里讲得很详细了。

参考：

《高级SQL注入：混淆和绕过》：

http://www.cnblogs.com/croot/p/3450262.html

例子3：strstr

防御：

strstr ()查找字符串的首次出现，该函数区分大小写。如果想要不区分大小写，使用stristr()。(注意后面这个函数多了个i)

绕过：

strstr()函数是对大小写敏感的，所以我们可以通过大小写变种来绕过

payload:

http://localhost/injection/user.php?id=1uNion select null,null,null 

例子4：空格过滤

防御：

绕过：

1)使用内联注释。

2)使用换行符代替空格。注意服务器若为Windows则换行符为%0A%0D，Linux则为%0A。

http://localhost/injection/user.php?id=1/**/and/**/11=1 
http://localhost/injection/user.php?id=1%0A%0Dand%0A%0D1=1 

例子5：空字节

通常的输入过滤器都是在应用程序之外的代码实现的。比如入侵检测系统(IDS)，这些系统一般是由原生编程语言开发而成，比如C++，为什么空字节能起作用呢，就是因为在原生变成语言中，根据字符串起始位置到第一个出现空字节的位置来确定字符串长度。所以说空字节就有效的终止了字符串。

绕过：

只需要在过滤器阻止的字符串前面提供一个采用URL编码的空字节即可。

payload:

例子6：构造故意过滤

防御：

绕过：

文件的63行开始可以看到，此处将传入的%27和%2527都进行删除处理，也就是还没传入数据库前就已经被该死的程序吃了，但是在67行看到他还吃了*，这样我们就有办法了，我们构造%*27，这样程序吃掉星号*后，%27就会被传入。

payload:    

http://localhost/injection/user.php?id%3D1%*27%*20and%*20%*271%*27%3D%*271 

(id=1' and '1'='1-->id%3D1%*27%*20and%*20%*271%*27%3D%*271)

Microsoft Security Bulletin Advance Notification for July 2013

This advance notification provides a number as the bulletin identifier, because the official Microsoft Security Bulletin numbers are not issued until release. The bulletin summary that replaces this advance notification will have the proper Microsoft Security Bulletin numbers (in the MSyy-xxx format) as the bulletin identifier.
The following table summarizes the security bulletins for this month in order of severity.
For details on affected software, see the next section, Affected Software.

Bulletin ID	Maximum Severity Rating and Vulnerability Impact	Restart Requirement	Affected Software
Bulletin 1	Critical Remote Code Execution	May require restart	Microsoft .NET Framework, Microsoft Silverlight
Bulletin 2	Critical Remote Code Execution	Requires restart	Microsoft Windows
Bulletin 3	Critical Remote Code Execution	May require restart	Microsoft Windows, Microsoft Office, Microsoft Visual Studio, Microsoft Lync
Bulletin 4	Critical Remote Code Execution	Requires restart	Microsoft Windows, Internet Explorer
Bulletin 5	Critical Remote Code Execution	May require restart	Microsoft Windows
Bulletin 6	Critical Remote Code Execution	May require restart	Microsoft Windows
Bulletin 7	Important Elevation of Privilege	Does not require restart	Microsoft Security Software