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).
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.
In Part I, the following steps will outline how to:
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.
In your Mac terminal, record the IP address and subnet mask of vmnet1, 172.16.127.1/24 in my case.
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
ip address 172.16.127.127 255.255.255.0
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.
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
subject-name CN=mitm.domain.int,O=MyCompany,C=US,St=Texas,L=San Antonio
crypto ca enroll mitm-trustpoint noconfirm
ssl trust-point mitm management
|Export Keypair (From Global Config)|
(config)# crypto ca export mitm-trustpoint pkcs12 abc123!
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
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
Preferences --> Protocols --> SSL --> RSA Key List --> Edit --> Browse to your key.pem file
IP 172.16.127.127, Protocol HTTP, Port 8443
5. Start Your Capture on the vmnet1 Interface
6. Fire Up ASDM
If you are decrypting the SSL session properly, you should see some green highlighted lines with HTTP GET statements.
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
You will learn a lot by simply analyzing the HTTP headers, requests, and responses.
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.
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.
Again, right click and follow the SSL stream to see the HTTP request and response.
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>
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.