cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2768
Views
17
Helpful
2
Comments
aaron.hackney
Level 1
Level 1

In my BRKSEC-2031 session at the Orlando Cisco Live 2018, I talk about how to leverage the XML(ish) API that ASDM uses to communicate with an ASA (both legacy and NGFW ASAs).

Introduction

Part 1 of this blog post will be a short "how to" on performing an man-in-the-middle (MiTM) on an ASDM session to gain insight into how to write python code to "act like an ASDM session". Part II will focus on some sample Python code to take advantage of the programmability that becomes available to legacy and NGFW ASAs as a result of this knowledge.

Disclaimers:

  • These thoughts are my own and do not represent my employer or Cisco and Cisco offers no endorsement or support, implied or otherwise for this article.
  • NEVER run a production ASA with weak SSL/TLS encryption
  • Yes, I know there is an ASA API, but it is not available for legacy ASAs that are not capable of running 9.3.2+. And, I have a fleet of both legacy ASAs (9.1) and NGFW ASA-X (9.8) devices to manage, and I would prefer to use ONE method to manage them ALL.

Materials

  • VMWare Fusion running on MacOS X
  • ASAv Software (Evaluation, unlicensed available here)
  • ASDM Software (Available here)
  • Wireshark (Available here)

Overview

mitm.jpg
In Part I, the following steps will outline how to:

  • Configure the ASAv management interface
  • Create and export a keypair used for ASDM management on the ASAv
  • Extract the private key from the keypair
  • Load the private key into Wireshark for TLS session decryption
  • Examine some ASDM payloads

1. Configure the ASAv Management Interface

On MacOS, there are 2 vmnet interfaces that are installed and configured by default. Per this article, these interfaces are:

vmnet1 = Host Only Adapter

vmnet8 = NAT network adapter

We are using the vmnet1, host only adapter ("Private to my Mac"), which should be what the first network adapter should be set to in the VM settings.

Screenshot 2018-05-30 07.51.45.png

In your Mac terminal, record the IP address and subnet mask of vmnet1, 172.16.127.1/24 in my case.

Screenshot 2018-05-30 07.54.26.png

Once you have installed the OVF of ASAv and started the virtual machine, log into the ASAv via the VMWare Fusion console and configure the management interface and local HTTP (ASDM) server listening on port 8443.

Configure ASAv for ASDM Management

int management 0/0

nameif management

ip address 172.16.127.127 255.255.255.0

no shut

!

enable password sanjose

!

http server enable 8443

http 172.16.127.0 255.255.255.0 management

!

aaa authentication ssh console LOCAL

aaa authentication http console LOCAL

aaa authorization exec LOCAL auto-enable

!

username cisco password sanfran priv 15

!

ssl cipher default custom "AES128-SHA"



Once you have this configured, the vmnet1 interface should now be reachable from the ASAv and the ASAv should be reachable from the Mac terminal, so you can SSH to the ASA and get out of the VMWare console.

Screenshot 2018-05-30 08.11.50.png

2. Create and Export a Keypair on the ASAv

Create an Exportable Keypair

crypto key generate rsa label mitm-keypair modulus 2048

!

crypto ca trustpoint mitm-trustpoint

enrollment self

fqdn mitm.domain.int

subject-name CN=mitm.domain.int,O=MyCompany,C=US,St=Texas,L=San Antonio

keypair mitm-keypair

exit

!

crypto ca enroll mitm-trustpoint noconfirm

!

ssl trust-point mitm management


Export Keypair (From Global Config)

(config)# crypto ca export mitm-trustpoint pkcs12 abc123!

Screenshot 2018-05-30 08.23.23.png

3. Extract the Private Key from the Keypair

Copy all of the text, including the  -------BEGIN------- and ------END----- lines into a plain text document and save it as "keypair.b64". This is a Base64 encoded binary. We will need to decode the Base64, ASCII encoded file back to a binary and then convert that binary to a PEM file, where we will be able to see our private key in clear text. We will accomplish this using utilities from the OpenSSL package. Note that the following is accomplished in the Mac Terminal and not on the ASA.

Decode the Base64 Encoded Keypair

openssl base64 -in keypair.b64 -d -out keypair.bin

Convert the PKCS12 Binary to PEM and Print

openssl pkcs12 -in keypair.bin -out keypair.pem -nocerts -nodes

Screenshot 2018-05-30 08.34.46.png

Copy the private key, including the -------BEGIN------- and ------END----- lines into a plain text document and save it as "key.pem". We will use this file in the nest step when we configure Wireshark.


4. Load the Private Key into Wireshark

In Wireshark,

Preferences --> Protocols --> SSL --> RSA Key List --> Edit --> Browse to your key.pem file

IP 172.16.127.127, Protocol HTTP, Port 8443

Screenshot 2018-05-30 13.48.52.png


5. Start Your Capture on the vmnet1 Interface

Screenshot 2018-05-30 13.50.59.png

6. Fire Up ASDM

If you are decrypting the SSL session properly, you should see some green highlighted lines with HTTP GET statements.

Screenshot 2018-05-30 13.55.23.png


7. Follow the SSL Stream and Examine the HTTP Request and the HTTP Responses

Find one of the HTTP GET requests where the URL starts with GET /admin/exec/

Right click the HTTP Get line select Follow --> SSL Stream

Screenshot 2018-05-30 13.58.29.png


You will learn a lot by simply analyzing the HTTP headers, requests, and responses.

Screenshot 2018-05-30 14.02.49.png

By analyzing the above output, we can infer that show commands are made using HTTP GET actions and multiple show commands can be strung together with a slash separating the commands. Furthermore, we can deduce that spaces are represented by a plus symbol.

GET /admin/exec/show+version/show+curpriv/perfmon+interval+10/show+asdm+sessions/show+firewall/show+mode/changeto+system/

Now, make a change to the ASA, like setting the interface name of Gig 0/0.

This time, look for an HTTP POST method in your Wireshark capture. I used the handy "Find Packet" and "string" filter looking for POST in my captures to locate the SSL stream that I want to examine.

Screenshot 2018-05-30 14.20.09.png

Again, right click and follow the SSL stream to see the HTTP request and response.

Screenshot 2018-05-30 14.22.10.png

This time, we see that we have an XML structure in the data payload for the HTTP POST request.

<?xml version="1.0" encoding="ISO-8859-1"?>

<config-data config-action="merge" errors="continue">

<cli id="0">Interface GigabitEthernet0/0</cli>

<cli id="1">nameif INTERNET</cli>

</config-data>

So, we can conclude that the configuration commands are executed in order based on the <cli id="x"> payload, where x is the numeric order of the commands. (0, 1, 2, 3.....n)

Conclusion of Part I

We now have enough information to begin to reconstruct what ASDM is doing to manipulate the ASA. In Part II, we will cobble together a simple script that executes some actions on the ASA, get the returned output from the ASA and use that data to construct some meaningful information.

2 Comments
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: