Uniden customer database compromised

[ndnihil]

Just a heads up to anyone who has signed up with Unidens services for anything. I know that some Uniden affiliated folks frequent the forum, so hopefully this will serve as notice to them as well.

Background: I run my own domains/mail services, and keep a close eye on my logs, particularly those relating to authentication. I also use unique mail aliases for each service/site I sign up to, so that I can keep track of who is spamming and who gets compromised.

I'm seeing email authentication attempts for the username I used as the email alias when I signed up on the Uniden site, originating from a host located in Vietnam. Pruned/sanitized logs and info below. The email alias I used for Unidens site was 'meuniden@mydomain.tld' (creative eh?), and as it's not a legitimate login and only forwards mail, there is zero chance of anyone getting in via the credentials associated with my Uniden account. Unidens site is the -only- place this alias has been used, so it is certainly them who have been compromised. I do not know if credit card info or anything further was also taken.

Stay safe folks. Keep an eye on your accounts and cards, and if you use the same password for anything, change it immediately.

Sep 30 11:17:49 login: Aborted login (auth failed): user=<meuniden>, method=, rip=n.n.n.n, lip=n.n.n.n, secured, session=<sessionID>

Sep 30 11:17:52 Auth: 123.21.208.188:33240->n.n.n.n:993 client-secure=ssl authorisation_id=NONE authentication_id="meuniden" server="n.n.n.n:143" protocol=IMAP4 server-secure= status="failed: Re-Authentication Failure"

myhost$ whois 123.21.208.188

% [whois.apnic.net]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

% Information related to '123.21.0.0 - 123.21.255.255'

% No abuse contact registered for 123.21.0.0 - 123.21.255.255

inetnum: 123.21.0.0 - 123.21.255.255
netname: VNPTinfrastructure-NET
country: vn
descr: Vietnam Posts and Telecommunications(VNPT)
admin-c: NXC1-AP
tech-c: KNH1-AP
status: ASSIGNED NON-PORTABLE
changed: hm-changed@vnnic.net.vn20081016 20081016
mnt-by: MAINT-VN-VNPT
source: APNIC

person: Khanh Nguyen Hien
nic-hdl: KNH1-AP
e-mail: huypt@vnpt.vn
address: Vietnam Datacommunications Company (VDC)
address: Lo IIA Lang Quoc te Thang Long, Cau Giay, Ha Noi
phone: +84-4-3793 0563
fax-no: +84-4-32811506
country: VN
changed: hm-changed@vnnic.net.vn 20090227
mnt-by: VNPT
source: APNIC

person: Nguyen Xuan Cuong
nic-hdl: NXC1-AP
e-mail: huypt@vnpt.vn
address: Vietnam Posts and Telecommunications (VNPT)
address: 57 Huynh Thuc Khang
address: Hanoi, Vietnam
phone: +84-4-37741236
fax-no: +84-4-37741205
country: VN
changed: hm-changed@vnnic.net.vn 20090922
mnt-by: MAINT-VN-VNPT
source: APNIC

% Information related to '123.21.208.0/20AS45899'

route: 123.21.208.0/20
descr: VietNam Post and Telecom Corporation (VNPT)
descr: VNPT-AS-AP
country: VN
origin: AS45899
remarks: mailto: noc@vnn.vn
notify: hm-changed@vnnic.net.vn
mnt-by: MAINT-VN-VNPT
changed: hm-changed@vnnic.net.vn 20100810
source: APNIC

% This query was served by the APNIC Whois Service version 1.88.15-37 (WHOIS-US4)

 

[ndnihil]

Another attempt from the Ukraine:

Sep 30 12:49:48 Auth: 46.227.137.5:59150->n.n.n.n:993 client-secure=ssl authorisation_id=NONE authentication_id="hhuniden" server="n.n.n.n:143" protocol=IMAP4 server-secure=plaintext status="failed: Re-Authentication Failure"

$ whois 46.227.137.5
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '46.227.136.0 - 46.227.140.255'

% Abuse contact for '46.227.136.0 - 46.227.140.255' is 'michael@vinnitsa.com'

inetnum: 46.227.136.0 - 46.227.140.255
netname: VNTPNET
descr: Vinteleport company network
country: UA
admin-c: MY900-RIPE
tech-c: SV900-RIPE
status: ASSIGNED PA
mnt-by: VNTPNET-MNT
created: 2011-05-18T14:13:01Z
last-modified: 2011-05-18T14:13:01Z
source: RIPE

person: Michael Yakorev
address: 14 B Kievskaya st.
address: Vinnitsa, 21032, Ukraine
phone: +380 432 554101
fax-no: +380 432 554110
remarks: Please send abuse notification to abuse@vinnitsa.com
nic-hdl: MY900-RIPE
mnt-by: VNTPNET-MNT
created: 2002-07-29T16:48:58Z
last-modified: 2002-07-29T16:48:58Z
source: RIPE # Filtered

person: Svetlana Chernysh
address: 14 B Kievskaya st.
address: Vinnitsa, 21032, Ukraine
phone: +380 432 554107
fax-no: +380 432 554110
remarks: Please send abuse notification to abuse@vinnitsa.com
nic-hdl: SV900-RIPE
mnt-by: VNTPNET-MNT
created: 2002-07-29T16:48:58Z
last-modified: 2002-07-29T16:48:58Z
source: RIPE # Filtered

% Information related to '46.227.136.0/21AS24945'

route: 46.227.136.0/21
descr: Vinteleport Delegated Block
origin: AS24945
mnt-by: VNTPNET-MNT
created: 2011-01-31T12:18:52Z
last-modified: 2011-01-31T12:18:52Z
source: RIPE

% This query was served by the RIPE Database Query Service version 1.89.2 (HEREFORD)

 

[phask]

Which Uniden - site? The one where one registers items, ordering, parts & service, or the forums?

I know I have different email on several of them.

 

[ndnihil]

Which Uniden - site? The one where one registers items, ordering, parts & service, or the forums?

I know I have different email on several of them.

The only one I have with them is from when I ordered the ProVoice and DMR keys, so the ordering one I'd imagine.

 

[jonwienke]

All you've proved is that the existence of your unique email was disclosed. There are any number of ways that could have happened other than a data compromise at Uniden, such as any device between you and Uniden being compromised. If someone was running a sniffer on a server or router between you and Uniden, the existence of your unique address could have easily been logged when Uniden sent you the confirmation email with your upgrade key.

Emails are not typically transmitted with end-to-end encryption between source and destination. That would make the NSA's job much harder.

 

[milcom_chaser]

The only one I have with them is from when I ordered the ProVoice and DMR keys, so the ordering one I'd imagine.

Your login to Uniden's site for upgrade keys, etc., should look like this:

https://my.uniden.com/Login.cfm

We run the app in Chrome called, "https everywhere" and you can set it to "Block all unencrypted requests"
It will force an SSL browser session on a SSL compliant site.

You can get it here: https://www.eff.org/https-everywhere

The first time we logged into Uniden it did not contain "https" in field. Luckily, we caught it before passing
credentials in the clear...

Seems the Vietnam authentication requests were denied.

 

[ndnihil]

All you've proved is that the existence of your unique email was disclosed. There are any number of ways that could have happened other than a data compromise at Uniden, such as any device between you and Uniden being compromised. If someone was running a sniffer on a server or router between you and Uniden, the existence of your unique address could have easily been logged when Uniden sent you the confirmation email with your upgrade key.

Emails are not typically transmitted with end-to-end encryption between source and destination. That would make the NSA's job much harder.

I guess infosec/network operations has only been paying my bills for the last 20+ years, so I still have some stuff to learn, but I generally don't raise alerts unless the odds are quite good something has transpired.

- Had the address been snarfed in-transit, these auth attempts would have started around a year ago, as that was the last time said address was transmitted over public wire.

- The auth attempts are testing against the password I used for the Uniden account. Easily sniffed in a plaintext environment, but again, the timing is way off, and they're banking on the target having used the same password for personal email as they did for Uniden.

- Uniden email services are hosted through Microsofts Outlook cloud services, which despite being MS, does follow best practice and try encrypted transactions before falling back to unencrypted comms, as my own servers do. This doesn't account for traffic between Uniden and the MS cloud of course, but go with what you've got eh?

- As per the posted log entries, the auth attempts are to an IMAP service, and (unknown to you as I did not post full log context), are coming in singles rather than a brute force flood, indicating that the other end of said session believes they have a legitimate password and is looking to further compromise accounts rather than just use it to blast out spam/malware emails via authenticated SMTP as is the standard behavior.

- If the compromise were on my end, the suspicious traffic would reach a much broader scope than the one site-specific email alias and password.


I do appreciate a good bit of skepticism, but I did consider most/all possibilities before making the initial post.

 

[ndnihil]

Your login to Uniden's site for upgrade keys, etc., should look like this:

https://my.uniden.com/Login.cfm

We run the app in Chrome called, "https everywhere" and you can set it to "Block all unencrypted requests"
It will force an SSL browser session on a SSL compliant site.

You can get it here: https://www.eff.org/https-everywhere

The first time we logged into Uniden it did not contain "https" in field. Luckily, we caught it before passing
credentials in the clear...

Seems the Vietnam authentication requests were denied.

HTTPS Everywhere is a great browser extension, and is also available for Firefox as well as Chrome. Another good EFF extension is "Privacy Badger". Both of those get installed by default whenever I spin up a new browser instance on any device, along with NoScript, ABP, and a few others.

And yes, all auth attempts are being denied as it is not an actual account (just an email forwarding alias). Even if it were an actual account, I do not use the same password across multiple sites, it's very poor practice.

I personally am not at any risk from this with the minor exception of my CC info possibly being taken from Unidens services, if in fact they do retain such info. I posted it for the benefit of others, and so there would be some publicly documented acknowledgement of such an event in case people need it for their CC companies to dispute charges or fraud claims.

 

[jonwienke]

I guess infosec/network operations has only been paying my bills for the last 20+ years, so I still have some stuff to learn, but I generally don't raise alerts unless the odds are quite good something has transpired.

I have a similar amount of time paying my bills doing IT work. Keep in mind that people stealing data often sell it to a wholesaler, who then resells it to other individuals who actually attempt to exploit it. So there can be a significant time delay between the time the data was compromised and the first attempt to exploit it. This arrangement makes it much more difficult to connect the dots between the original thief and the end user hacker.

I'm not saying you're wrong, just pointing out that there are other possibilities besides Uniden being compromised.

 

[ndnihil]

I have a similar amount of time paying my bills doing IT work. Keep in mind that people stealing data often sell it to a wholesaler, who then resells it to other individuals who actually attempt to exploit it. So there can be a significant time delay between the time the data was compromised and the first attempt to exploit it. This arrangement makes it much more difficult to connect the dots between the original thief and the end user hacker.

I'm not saying you're wrong, just pointing out that there are other possibilities besides Uniden being compromised.

We can nerd back and forth at each other all day long, but it's not likely to be productive in any way. In my experience, and in trading/wholesaling/etc.. circles, the longer such data has been sitting around, the less valuable it becomes, so folks tend to move quickly on it.

That's not to say it hasn't been sitting around for a year, just that the odds are heavily in favor of it being a fresh event. At the end of the day, even in the unlikely event it has been sitting around that long, it's pretty clear it came from Uniden or a source very near Uniden (third party hosting provider, etc..), and that it's data that should not have gotten out under any circumstances.

Better safe than sorry. I was just trying to give folks a heads up as this is something they may not have otherwise been aware of.

 

[pinballwiz86]

Thanks for taking the time to make the thread. Hopefully there hasn't been a data breach.

 

[uniden9]

Did you change that email address? I don't see it in the MyUniden database, but I do see another that looks like yours.

I would like to follow through on this. We do not store credit cards.

-David (webmaster@uniden.com)

The email alias I used for Unidens site was 'meuniden@mydomain.tld'

 

[ndnihil]

Did you change that email address? I don't see it in the MyUniden database, but I do see another that looks like yours.

I would like to follow through on this. We do not store credit cards.

-David (webmaster@uniden.com)

I changed the actual address before posting, but if you see something like xxuniden@somethingresemblingmymoniker, that's probably me. I'll PM it to you if you'd like to check that one specifically.

Thanks for taking the time to address this, it's good to know that you don't store CC info, that makes me feel a lot better. If I can be of any assistance just let me know.

 

[troymail]

It's good to see Uniden seems to be taking your observations seriously - even if as only a precaution - though others might want to question the information...... better safe than sorry.