Cisco IOS shellcode: All-in-one

Hello!

This post is a response to a recent publication on the Habrahabr resource from the Russian representative office of Cisco.

The author is the same “immature” and “novice” researcher from Digital Security, mentioned in an article by a Cisco representative.

Strange, the representation of such a well-known company allows itself to use such a low syllable in the official blog, and also gives comments based on superficial conclusions, and not on technical details. Let's see what our research center did, and what Cisco experts could not or did not want to deal with.

Comments on the article

It must be said right away that there is no question of any vulnerability of network equipment!

The equipment is loaded with “alien” firmware - the lack of verification of the legitimacy of the image. Isn't that a vulnerability? Any attacker will be glad of such an opportunity.

For a successful implementation, an attacker requires a Cisco router administrator account (and not a switch, as some media wrote) or physical access to the equipment.

No one has canceled the vulnerabilities of the remote code execution class, and you can do the same without physical access.

It will surprise you if they tell you that someone, having obtained the login and password of the PC admin, reinstalled the OS on it or installed malware? Probably not. This is a fairly obvious threat, often implemented in practice.

Very weak scenario. Why isn't the NSA script mentioned ?! After all, you can do this: the transported device on the transport unit is removed by a third party. Further, the third party modifies the firmware on the system (KNOWING DEFAULT LOGIN AND PASSWORD), embedding malicious functionality. Then it blows all the settings "to zero", as if the device never turned on. As a result, the customer receives the device, absolutely not suspecting that its firmware is not original, but “wired”, and under certain conditions the “piece of iron” will cease to be its equipment, will fall under the control of a “stranger”.

Several fairly simple mechanisms and recommendations have been proposed for identifying SYNful Knock.

The mechanisms and recommendations are excellent, but they work after the device has been under the control of the attacker for a certain time, and he could dispose of it at his discretion inside a foreign company. That is, this is just for IDENTIFICATION. This is all POST-FAX.

Meanwhile, to this day, you can upload a modified image, and there is no doubt that a new malware will be released. And the manufacturer will just release a new scanner and new signatures.

Stories about how to use a potentially modified image to check it for modifications using the verify command look strange to the ridiculous. Please note: in a modified image, you can correct the code responsible for checking your checksum.

According to currently available information, SYNful Knock did not cause serious damage, and its distribution area (the number of network devices affected) turned out to be limited and amounted to 163 devices on September 20, 2015 according to Shadowserver (out of ten million sold devices of this generation).

An interesting game with numbers. The device is different. It is one thing when a device of this class is in a small company, and quite another if it is used by a major telecom player. That is, in impact and profit, these are completely different stories, as you understand.

In addition, it is worth considering that the published information from ShadowServer describes only those devices to which it was possible to connect from the outside and detect that they are infected. Consequently, the mass of devices controlled by the attacker (s) that have access to the internal network, for example, through any other device or PC infected with “standard” malware, remained unreached.

it’s not for nothing that Cisco has implemented a mechanism for digitally signing ROMMON updates and iOS operating system images, but on previous generation platforms, verification must be activated manually

Our experience with Cisco equipment research shows that not all devices can be updated, for example, ROMMON. It is simply not available on the manufacturer’s website. For some hardware, ROMMON has just begun to be uploaded - perhaps this is precisely due to the growth of infection incidents. And in order to enable customers to update ROMMON, it was provided for download.

Therefore, when a researcher or company categorically declares that they have “hacked iOS”, then this is either a sign of unprofessionalism and a lack of understanding that we have many different modifications of our fundamental operating system, or a banal desire to embellish and make a speaker news.

The author of the article was frightened by the news headlines and did not wait for the publication of technical slides and videos from the performance with ZeroNights 2015 “Cisco IOS shellcode: all-in-one”. This is also stated in the presentation:



As you can see, the slide does not contradict the above. Moreover, the leitmotif of the second part of the study was precisely the conversation about how to “deal with” the researcher with the existing variety of hardware platforms, processor architectures, and Cisco operating systems. The study noted that, although Cisco IOS binary images can seriously differ, you can always find architectural features that will remain unchanged from image to image, a kind of “invariant”. In the case under consideration, the “Tcl” subsystem became such an “invariant”, which is equally designed and functioning regardless of the OS version and hardware architecture.

Although the direct research subject was Cisco IOS (PowerPC), the proposed approach to implementing shell-code portable between images can be extended to a different processor architecture or to another Cisco IOS XE family of OS.

But let's face it. The vulnerability itself in the Tcl interpreter has been known for a long time and even has its own CVE identifier. That is, a statement about the vulnerability found is a blatant lie made only for its own PR.

Let's face it and say that the author is not aware of the contents of the report, since he was not present at it. In the study, generally, vulnerabilities in Cisco equipment were not affected, but were only mentioned in passing!

The study focuses on Tcl-based portable shellcode for Cisco equipment, which can be used in conjunction with any binary vulnerability that could allow arbitrary code execution, and the mentioned vulnerability in the Tcl interpreter has only an indirect relation to it (perhaps only the word “ Tcl ”in the title). We have no doubt that the difference between the terms “vulnerability” and “shell code” is obvious to a specialist.

If you touch upon the issue of escalation of privileges, it should be noted that the shell code has direct access to physical memory and can modify both the Cisco IOS code itself and various control structures, including raising privileges.

In other words, from the point of view of a security specialist who works at an enterprise and is interested in information about the security of his network equipment, it’s worth studying not only the press releases of researchers, but also the information on the elimination of the hole and the restrictions on its use that the manufacturer provides .

It's like that. However, we did not talk about vulnerabilities. Everyone understands that there are and will be vulnerabilities, and it was not very interesting for us to make a report on a number of common vulnerabilities at the international ZeroNights conference. We talked about what can be done after exploiting a vulnerability in Cisco equipment.

If you go to it, you can see constantly updated information about various vulnerabilities in various products of different versions.

The keyword is “constantly”;)

Moreover, when Cisco PSIRT experts on their initiative contacted Digital Security regarding a recent report on ZeroNights about allegedly discovered vulnerabilities in Cisco equipment, Digital Security representatives were unable to respond and provide details of their research.

Yes, they contacted us after the news came out and received the answer that no vulnerabilities in Cisco equipment were considered and that slides will be available to everyone soon.

Here is a presentation of the study (video will be available later):

About infecting Cisco devices

We did not raise this topic at all in our study - this is a separate topic. The only thing I want to note: when talking about vulnerabilities, the manufacturer concentrates on a huge amount of equipment, OS and architectures, but when it comes to protection against modifying the firmware image, it immediately forgets about it, mentioning Trust Anchor, Secure Boot technologies, which are far from everywhere.

How to determine if you have Trust Anchor, Secure Boot is a separate quest. Some white papers from Cisco say one thing, while other sources (the Cisco Feature Navigator service ) declare a different one. Who to believe?

Our experience in researching Cisco equipment that is now used by companies (rather than standing on shelves in stores) over the past few years shows that in most cases a checksum is used to verify the legitimacy of an image. Naturally, faking (recounting) the checksum of a modified image is very simple. On a number of devices where the image is digitally signed, digital certificates are in the same place, and it is not difficult for an attacker to add his certificate there.

Also, an attentive / sophisticated reader may think of TPM (Trusted Platform Module). But Cisco does not transport it to a number of countries because of cryptography, including Russia. And we honestly tried to find what equipment supports TPM. It turned out that its amount is negligible.

Of course, Cisco equipment is developing, new security mechanisms are being introduced. But the updates concern only the latest models, and the situation with the bulk of the "iron", which is actively used in companies, remains the same. It turns out like with the Android OS: everything is fine in the latest version, but let the rest be updated. The problem is that updating the entire fleet of network equipment is not so simple (and not cheap). This is not an OS on the phone. And we clearly see such a problem with our customers.

Conclusion

Of course, we, as researchers, are only pleased with the fact that our work provokes an active reaction from Cisco and the publication of security articles. However, I would like to hope that the vendor’s specialists will not limit themselves to emotional reviews, but will direct their energy to improving the safety of their own products.