We bypass protection management-plane
A couple of days ago, my boss gave me a task - to run through all the devices in our network and see how you can improve the security of the network as a whole. I am a person far from security, routing & switching - our everything. But nevertheless, I got down to business. My workmates suggested that it is worthwhile to google ways to protect the management plane (the name means, of course, MPP ), I accidentally googled “MOP cisco” and it’s good that I didn’t immediately realize that I was wrong ...
In the distant past, when DEC was still engaged in networking, they wrote a stack of protocols under the general name DECnet. About most of them, humanity has successfully managed to forget. But not Cisco. One of the protocols in this stack is called the MOP (Maintenance Operation Protocol). He had many functions, but one of them is still relevant today. I'm talking about RC (Remote Console). With this feature you can get remote access to the device.
But because Cisco is not only enough to include this protocol in all IOS (up to the 15th), it also includes it by default on all interfaces! “So what?” - you say. Nothing revolutionary, telnet and SSH know everything. What is special about this sub-protocol is that it runs completely on the second (channel) level. And this means that the access list we love for all of us on the VTY will not save this hole.
')
So, armed with GNS and VMware Player, I set to work.
All I needed was to raise Linux on a virtual machine and connect it to at least a virtual tsiska in GNS. I used the Ubuntu Server 12.04 LTS distribution and the IOS image c7200-jk9s-mz.124-21a. The only thing that had to be added to the server was, in fact, LAT Daemon itself ( apt-get install latd ).
For starters, I picked up on a vty router without any restrictions just to check that MOPRC works in principle:
Great success!
In short, I was able to connect with the following configurations:
1) With an access-list that prohibits absolutely everything (deny any) strung on a vty.
2) With no login under VTY.
3) With transport input none under VTY (and this is in the presence of mop in the list of possible protocols).
The only thing that blocks this protocol is no mop enabled under the physical interface.
There is a reservation - to connect to the device through this protocol, you need to be with him in the same segment. In addition, it will not be possible to connect from another network device (or I didn’t find how to do it on Cisco), you need to have a host with Linux (although if you think about it, I don’t see why you can’t put a latd on Juniper). In addition, we fail only in user-mode, and in order to go further, you still need to know the password. But nevertheless - in my opinion, this hole is worth mentioning.
A bit of history
In the distant past, when DEC was still engaged in networking, they wrote a stack of protocols under the general name DECnet. About most of them, humanity has successfully managed to forget. But not Cisco. One of the protocols in this stack is called the MOP (Maintenance Operation Protocol). He had many functions, but one of them is still relevant today. I'm talking about RC (Remote Console). With this feature you can get remote access to the device.
Why does this interest me today?
But because Cisco is not only enough to include this protocol in all IOS (up to the 15th), it also includes it by default on all interfaces! “So what?” - you say. Nothing revolutionary, telnet and SSH know everything. What is special about this sub-protocol is that it runs completely on the second (channel) level. And this means that the access list we love for all of us on the VTY will not save this hole.
')
So, armed with GNS and VMware Player, I set to work.
We are testing
All I needed was to raise Linux on a virtual machine and connect it to at least a virtual tsiska in GNS. I used the Ubuntu Server 12.04 LTS distribution and the IOS image c7200-jk9s-mz.124-21a. The only thing that had to be added to the server was, in fact, LAT Daemon itself ( apt-get install latd ).
For starters, I picked up on a vty router without any restrictions just to check that MOPRC works in principle:
Great success!
In short, I was able to connect with the following configurations:
1) With an access-list that prohibits absolutely everything (deny any) strung on a vty.
2) With no login under VTY.
3) With transport input none under VTY (and this is in the presence of mop in the list of possible protocols).
The only thing that blocks this protocol is no mop enabled under the physical interface.
There is a reservation - to connect to the device through this protocol, you need to be with him in the same segment. In addition, it will not be possible to connect from another network device (or I didn’t find how to do it on Cisco), you need to have a host with Linux (although if you think about it, I don’t see why you can’t put a latd on Juniper). In addition, we fail only in user-mode, and in order to go further, you still need to know the password. But nevertheless - in my opinion, this hole is worth mentioning.
Source: https://habr.com/ru/post/157785/
All Articles