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 “beginner” researcher from Digital Security, mentioned in the article by a Cisco representative.

Strangely, 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 couldn’t or didn’t want to figure out.

Comments on the article

We must immediately say that there is no talk of any kind of vulnerability of network equipment!

The equipment is loaded with “foreign” firmware - no verification of the legitimacy of the image. Is this not a vulnerability? Any attacker will be delighted with this opportunity.

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

Nobody canceled the remote code execution class vulnerabilities, and you can do the same thing without physical access.

You will be surprised if someone tells you that someone, having obtained the login and password of the PC administrator, reinstalled the OS on it or installed malware? Most likely no. This is a fairly obvious threat, often implemented in practice.

Very weak script. Why isn't the NSA script mentioned ?! After all, it is possible so: the transported device on the transport node is removed by a third party. Further, the third party modifies the firmware on the system (KNOWING DEFAULT LOGIN AND PASSWORD), embedding the 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, completely unaware that its firmware is not original, but “stretched”, and under certain conditions the piece of hardware will cease to be its equipment, will fall under the control of the “outsider”.

To identify the SYNful Knock, several fairly simple mechanisms and recommendations were proposed.

The mechanisms and recommendations are excellent, but they already work after the device was under the control of an intruder, and he could dispose of it at his own discretion inside a foreign company. That is, this is all for IDENTIFICATION. This is all POSTFACTUM.

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

The stories about how using a potentially modified image to check it for modification using the verify command look strange to the point of ridiculous. Please note: in a modified image, you can correct the code responsible for checking your checksum.

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

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

Plus, it should be borne in mind 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), having access to the internal network, for example, through any other device or PC infected with “standard” malicious software, has not been covered.

knowingly, Cisco has implemented a digital signature mechanism for ROMMON updates and IOS operating system images, but on previous-generation platforms, verification needs to be activated manually

Our experience with Cisco hardware research shows that not all devices can be upgraded, for example, ROMMON. It is simply not available on the manufacturer’s website. For some "iron", ROMMON was just now being laid out - perhaps this is precisely due to the increase in incidents related to infection. And in order to enable customers to update ROMMON, it was provided for download.

Therefore, when any researcher or company categorically declares that they “hacked iOS”, this is either a sign of incompetence and a misunderstanding that we have many different modifications of our underlying operating system, or a banal desire to embellish and advertise for loud 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 speech with the 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 just a conversation about how the researcher “deals” with the existing variety of hardware platforms, processor architectures and operating systems of Cisco. The study noted that although Cisco IOS binary images can be seriously different, you can always find architectural features that remain unchanged from image to image, a kind of “invariants”. In this case, the “Tcl” subsystem has become such an “invariant”, which is equally designed and functions regardless of the OS version and hardware architecture.

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

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

Let's face it and say that the author is not aware of the content of the report, because he did not attend it. In a study of general vulnerabilities in Cisco equipment were not affected, but only mentioned casually!

The study is devoted to the portable Tcl-based shell code for Cisco equipment, which can be used in conjunction with any binary vulnerability that allows arbitrary code to be executed, and the mentioned vulnerability in the Tcl interpreter has only an indirect relationship to it (perhaps, only Tcl "in the title). We do not doubt that the difference between the terms "vulnerability" and "shell code" is obvious to a specialist.

If we touch upon the issue of privilege escalation, then 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 elevation of privileges.

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

It's like that. However, we did not talk about vulnerabilities. Everyone understands that there are and will be vulnerabilities, and we were not very interested in making a report about a number of common vulnerabilities at the international ZeroNights conference. We talked about what you can do after the exploitation of a vulnerability in Cisco equipment.

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

The key word “constantly”;)

Moreover, when Cisco PSIRT specialists, on their own initiative, contacted Digital Security about a recent report by ZeroNights about an allegedly discovered vulnerability in Cisco equipment, Digital Security representatives could not answer and provide details of their research.

Yes, we contacted after the news and got the answer that no vulnerabilities in the Cisco equipment were considered and the slides will be available for everyone soon.

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

About Cisco device infection

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

How to determine if you have a Trust Anchor, Secure Boot is a separate quest. Some official documents from Cisco say one thing, and other sources ( Cisco Feature Navigator service ) declare another. Who to believe?

Our experience with Cisco equipment, which is now used in companies (and not on shelves in stores), over the past few years shows that in most cases a checksum is used to verify the legitimacy of the image. Naturally, it is very easy to fake (recalculate) the checksum of the modified image. On a number of devices where the image has a digital signature, digital certificates are in the same place, and it is easy for an attacker to add his certificate there.

Also attentive / sophisticated reader may think about 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 out what kind of equipment supports TPM. It turned out that his number is negligible.

Of course, Cisco equipment is evolving, new security mechanisms are being introduced. But the updates concern only the latest models, and the situation with the bulk of "iron", which is actively used in companies, remains the same. It turns out, as with the Android OS: in the latest version, everything is fine, well, let the rest be updated. The problem is that updating the entire fleet of network equipment is not so easy (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, can only be pleased by the fact that our work provokes an active response from Cisco and the publication of security articles. However, I would like to hope that the vendor’s experts will not limit themselves to emotional feedback, but will direct their energy towards improving the safety of their own products.