The client had decided for this small isolated environment that implementing a centralised authentication system was inappropriate and costly, and to be fair, I can see that it was a fair decision.

Local authentication, given the scale and scope of the solution was the appropriate option and, in keeping with good security practices the client had disabled Telnet and only permitted SSH access, of the appropriate flavour. Furthermore, access to the management interface was only possible from specific IP addresses. Lovely.

However something sparked our attention: the administrative users would SSH in as level 15. Forgive me for expanding on this: level 15 is privileged EXEC mode, i.e. the superuser. And going straight in as a superuser is bad, kids.

Ordinarily for systems such as this, we would suggest logging in as a low privilege user (in Cisco terms that would be “level 0″, or user EXEC mode), and then to elevate privileges via the use of secondary authentication.

However we debated the use of a shared enable (level 15 access) password, which in theory could potentially erode security and the ability to audit commands being executed on the devices.

The solution we proposed to the client ended up being the use of the user definable privilege levels (1-14) which can be set up to permit users access to administrator defined commands and configuration options.

So, for instance, in this environment we recommended that, for the 3 users that had access to the Cisco devices, the accounts would be configured as follows with policies that would be put in place to the following effect:

• Each of them would, by default be granted level 0 privilege when SSH-ing in
• Each of them would have individual credentials assigned to custom privilege levels (1,2,3) which would enable commonly used administrative commands consummate with their duties
• In extremis the level 15 privilege mode password would be made available for use, and would then be changed

In essence a kind of clumsy sudoers approach to accessing the devices.

For example user Bob would be configured with level 0 access upon SSH-ing in. And then assign to Bob his level 1 password.

Then we would define the usual commands he would be likely to need to administer the device:

device(config)#privilege interface level 1 ip address
device(config)#privilege configure level 1 interface
device(config)#privilege exec level 1 show running-config
device(config)#enable secret level 1 BobL!kesSecu)ty

In order to elevate to the level 1 privileged account, Bob then simply has to use the following command:

enable 1

The interesting side-effect of this is that if Bob were to show the running configuration, he would only see the configuration of the commands that he has that privilege level to alter.

Which is nice.

The post Accessing Cisco kit politely appeared first on Portcullis Labs.

The intended audience for this is technical/managerial, that is to say, in parts it will be moderately technical, but the key focus will be the provision of information to those planning or evaluating roll outs of iOS based devices in order that they are able to accurately understand the risks associated with this.

iOSinTheWorkplace-WPIOS2011.pdf
April 26, 2013

1.1 MiB
MD5 hash: b36063ebf62406da23afbad2ef455be1
Details

Date:

April 26, 2013

The post Apple iOS In the Workplace appeared first on Portcullis Labs.

Windows Domains use a single sign on system, authenticate to one machine, you can then use that machine to access all of your available resources accross that domain. This is great for users but also for attackers. This presentation covers a number fo techniques and tools that be used to take control of a windows domain without ever needing to run time consuming password cracking.

Windows_Authentication_CrestCon.pdf
April 26, 2013

874.3 KiB
MD5 hash: 0802f2fa846c71001d2653e1798b6137
Details

Date:

April 26, 2013

The post Attacking Windows Domains appeared first on Portcullis Labs.