DDOS防御专家-提供超强DDoS高防/CC防护/大流量清洗服务!
当前位置:主页 > CC防护 > 正文

高防IP_cdn防ddos_解决方案

06-29 CC防护

高防IP_cdn防ddos_解决方案

Disclaimer : Since this vulnerability has been made public, here is a small blog post explaining the methodology we used to find and exploit the same vulnerability.

Recap

In the first part of this series, we explained the basics of the debug interface available on ARM chips. Basically, the external debugger talks using the SWD protocol to the Debug Port (DP), which forwards requests to the different Access Ports (AP) available on the internal bus called the Debug Access Port (DAP). In the second part, we showed how access to the DAP allows to use the MEM-AP to access the whole memory space of the core (flash memory, peripherals, internal registers, …).

Debug interface overview

Since this interface allows retrieval of any information stored by the chip, it is quite difficult to protect any IP or secrets. Unfortunately, ARM does not provide a standard way to secure this interface so manufacturers implemented many different ways to restrict access to the DAP, sometimes with flaws in them.

Debug port protection failures

As an example, the nrf51family protection allows access to the DP and the MEM-AP, but only on specific memory regions. Some people found out that it was possible to read and write the CPU registers and step into the code. Using these features, they were able to locate a ldr instruction and instrument it to fetch the flash memory contents four bytes per four bytes.

Another example. On STM32 chips, the most common SWD interface protection is called Readout Protection (RDP). These protections differ amongst chip families, but we can sum up the following :

RDP level 0 : No DAP protection RDP level 1 : DP and MEM-AP access is allowed, but MEM-AP can only fetch specific memory regions RDP level 2 : DP access is disabled

As we saw, in part two, some chips were vulnerable to a race condition, allowing to bypass the protection. There are other examples where the RDP protection was bypassed using glitches.

Here is another example : the nRF52840 uses a different mechanism called APPROTECT, which disables access to the MEM-AP when the APPROTECT register value is 0xFFFFFF00.

nRF52840 debug interface

So what happens once this protection has been enabled ? Let’s have a look.

Mapping DAP bus

As previously seen, the DP SELECT register is used to address a specific AP on the bus. There can be up to 256 possible address values. We have also seen that the AP register 0xFC is usually the identification register (IDR). Using these, we can create a small script to query each AP for its IDR and see the results on the nRF52840 :

12345678910111213import pyHydrabuss = pyHydrabus.SWD() # Initialize the SWD interface and power up the debug power domains.bus_init()s.read_dp(0)s.write_dp(4, 0x10000000) # Scan the DAP busfor x in range(256):    idcode = s.read_ap(x, 0xfc)    if idcode != 0:        print(f"{x:03d} - 0x{idcode:08x}")

000 - 0x24770011 001 - 0x02880000

There are two APs : the standard MEM-AP and the CTRL-AP, which is "a custom access port that enables control of the device when other access ports in the DAP are disabled by the access port protection." It essentially allows to remove the protection (which erases the internal flash memory).

Once we enable the protection mechanism (through openOCD using the command "flash fillw 0x10001208 0x00 1") the DP access is still present, but the previous script shows a different output :

000 - 0x23000000 001 - 0x02880000

Interestingly enough, all registers from the MEM-AP now return 0x23000000 instead of the correct value.

Attacking the AP protection

As we have seen, the DP does not seem to be affected by the protection, but the AP does. Looking at the Reset behavior of the chip, using the pin reset is enough to reset the debug domain and is easily controllable from an external signal. This also has the advantage of keeping the internal power regulators up so the boot time is more consistent.

Being able to query the MEM-AP IDR at a lower level to know if the device is protected or not also helps speeding up the campaign. That way, fewer SWD packets need to be sent to the target in order to validate if the attack was successful or not.

As such, a well timed voltage glitch could alter the register comparison, and keep the MEM-AP enabled despite the APPROTECT register being set. We now have our plan to perform the attack :

Keep the target under reset by keeping the reset pin (P0.18) low Raise the reset pin. This will start the target boot process After a certain delay, inject the glitch Connect on the SWD bus, and query the MEM-AP IDR If IDR == 0x23000000 goto 1. If IDR == 0x24770011 goto 6 Profit

I won’t get into the glitching details, as we used the same crowbar technique used in the original disclosure (I highly recommend reading this article) and the results are similar.

Successful glitch (on the right). Vcore is in yellow, reset signal is in blue.

Conclusions

In this post, we presented some mechanisms implemented by manufacturers to protect access to the debug interface of their chips. These mechanisms do sometimes suffer from logical flaws, but most of the times are vulnerable to glitches. While these protections are helpful as a first barrier, they would never prevent a determined attacker from gaining access to the contents of the chip.

Knowing the inner working of the protocols involved also help a lot when building glitch campaigns. Not only will it give you a deeper understanding of the way things work, but it will also give you a broader range of information available about your target.

We also need to emphasize that none of these general purpose chips provide any protection against fault attacks. What they offer is a "best effort" type of protection, but you should not rely on them to protect keys or IP. Should you need such kind of protection, have a look at secure elements which are specifically made to protect critical assets.

Share:Click to print (Opens in new window)Click to email this to a friend (Opens in new window)Click to share on LinkedIn (Opens in new window)Click to share on Twitter (Opens in new window)Click to share on Reddit (Opens in new window) Related SWD - ARM's alternative to JTAGMay 16, 2019In "Embedded"SWD part 2 : the MEM-APJuly 31, 2019In "Embedded"SWD part 3 - SWO and nRSTApril 15, 2020In "Embedded"

,ddos怎么破防御,阿里巴巴如何防御ddos,ddos云防御平台,免费ddos防御盾,防御ddos攻击云

版权保护: 本文由 DDOS防御专家 原创,转载请保留链接: /ddos/70498.html

DDoS防御专家简介孤之剑
国内资深白帽子二十人组成员,前BAT资深网络安全工程师,知名网络安全站点板块大神,每年提交Google及微软漏洞,原sina微博负载插件开发者,现在整体防御复合攻击长期接受1-4.7T攻击,CC防护自主开发指纹识别系统,可以做到99.9999%的无敌防御。
  • 文章总数
  • 9325065访问次数
  • 建站天数

    QQ客服

    400-0797-119

    X