Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

01 June 2012

Snooping Mobile Security Apps!

Have you notice how snoopy mobile security apps have become in recent months?

NOTE: the products listed below were chosen at random from Google's Play store.  [don't even get me started on why someone would call an app market a "PLAY" store!]


Let's start with Norton's mobile product.  Norton can:
  • add and modify calendar events and sent e-mail to guests
  • read your browser's history and bookmarks
  • read your calendar events, read contact data, read sensitive log data, wrote browser's history and bookmarks and write contact data.
  • intercept outgoing calls - allows applications to process outgoing calls and change the number to be dialed.
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • modify SD card contents
  • create Bluetooth connections because it allows the phone to make and accept connections with paired devices.
  • allow Bluetooth to discover and pair with remote devices
  • create its own network sockets because it must have full network access at all times
  • modify global system settings and modify the systems settings data.
  • access course location sources like the cellular network database to determine an approximate the approximate location of your phone
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages
  • change your audio settings
  • access extra location provider commands

How about BITDEFENDER?  Bitdefender can:
  • add and modify calendar events and sent e-mail to guests
  • read your browser's history and bookmarks
  • read your calendar events, read contact data, read sensitive log data, wrote browser's history and bookmarks and write contact data.
  • intercept outgoing calls - allows applications to process outgoing calls and change the number to be dialed.
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • modify SD card contents
  • create Bluetooth connections because it allows the phone to make and accept connections with paired devices.
  • allow Bluetooth to discover and pair with remote devices
  • create its own network sockets because it must have full network access at all times
  • modify global system settings and modify the systems settings data.
  • access course location sources like the cellular network database to determine an approximate the approximate location of your phone
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages
  • change your audio settings
  • access extra location provider commands

TOPJOY MOBILE SECURITY.  Topjoy Mobile Security can:
  • modify your SD card contents
  • disable keylock and prevent your phone from sleeping
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • create its own network sockets because it must have full network access at all times
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages

MOOBILA ANTIVIRUS FOR ANDROID:
  • modify your SD card contents
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • create its own network sockets because it must have full network access at all times
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages
  • control the vibrator on your phone

MOBILE CLOUD SOLUTIONS - Andriod AntiTheft Security
  • modify your SD card contents
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • create its own network sockets because it must have full network access at all times
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages
  • discover known accounts
While I am an avid supporter of both mobile antivirus programs and encryption software being installed on any mobile device, whether it be a smart phone, laptop, tablet, or any other mobile device, I feel we all need to be aware of what these applications we are installing have access to.

In some cases, as shown by the very limited number of examples I have listed below, I also believe they go a bit too far.  Since when does a mobile protection application need to detect and log the telephone number of a call you are connected to?  If there is a name associated with the call, and you are a doctor or nurse, this could potentially be a violation of the HITECH portion of the HIPAA laws.

My point is, before you download ANY application, make certain you have read the information on what the product has access to, how it has access and try to find out WHY it must have that access.

It's user beware when it comes to applications.  While protecting our mobile devices is a critical part of the security which we must now endure, we also need to make certain we are dealing with a reputable vendor who doesn't snoop too much in the wrong places in the name of "protecting" us.

================================================

If you have any questions, or are looking for hosted solutions, please feel free to contact me.


Copyright © 2012, Bruce Barnes, ChicagoNetTech Inc, All Rights Reserved



06 February 2012

Anonymous vs the FBI . . .

When the hacker group, Anonymous, found out that Scotland Yard and the FBI were planning a conference call to discuss how to deal with Anonymous, and several other groups considered to be nefarious, the e-mail, setting up and giving conference call meeting instructions, was intercepted by someone from the group Anonymous.

Anonymous then used this information to their advantage to turn the tables on the FBI and Scotland Yard by recording the scheduled call and posting it on YouTube.


So how was Anonymous able to intercept an e-mail which should have been both encrypted prior to sending and sent via an encrypted network?
The answer lies in the fact that all e-mail is sent as PLAIN TEXT across the Internet.  Unless the message is encrypted, either at the workstation, or via the e-mail server software, it is PLAIN TEXT and can be read by anyone who can capture the data during its journey.


Short answer:  Either someone at the FBI got lazy, and there was no SSL/TLS on the FBI e-mail servers or one or more of the recipients has a very poor password on their e-mail account.


Whether the original sender of the message “forgot” to encrypt, his workstation was not equipped to encrypt, the connection between his workstation was not encrypted, or the FBI is not equipped to encrypt, this incident is unforgivable and, once an investigation has been completed, the responsible parties be should terminated.


In fact, this should not be under the control of the sender of the e-mail at all.  With any government security agency, or even with any business, the process of encrypting e-mail should be fully automatic and transparent to the users.


E-mail, unless encrypted, is sent as plain text over the public Internet, I always advise both my hosted and consulting clients to “never write anything in an e-mail message you would not want to see in the newspaper or on TV.”  They usually laugh when I say that but my concerns are being borne out by both the reports which have so frequently appeared in the new and the fact that there are so many new legal requirements mandating e-mail  encryption in the banking, healthcare, legal, and ever increasing numbers of other business groups.


So, now that the proverbial cat is out of the bag at the FBI, what can you do to prevent your e-mail from getting into the wrong hands?

At ChicagoNetTech we run TLS on our SmarterMail e-mail server product.  TLS is an extension of the SSL encryption protocol which actually allows our clients to both make an SSL connection to the e-mail server to originate their e-mail via POP, IMAP, ActiveSync, or our SSL encrypted web interface if so desire, originate their e-mail message, and send it through the Internet via the TLS security protocol.


TLS is a relatively new encryption capability on many e-mail systems and, as part of the transmission process, encrypts inter-e-mail server data traffic so it cannot be easily intercepted.
Whether or not TLS is supported by an e-mail server is very easily tested.  In the case of e-mail sent to and from Timothy Lancaster, the originator of the conference call intercepted by Anonymous, we see the following results:

The US FAILS:
TestReceiver
CheckTLS Confidence Factor for "Timothy.Lauster@ic.fbi.gov": 0
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
mail.ic.fbi.gov
[153.31.119.142]
10
OK
(85ms)
OK
(786ms)
OK
(74ms)
FAIL
FAIL
FAIL
OK
(1,020ms)
OK
(76ms)
Average

100%
100%
100%
0%
0%
0%
100%
100%


The results in the grid above show that the FBI’s e-mail server FAILS the most basic of Internet e-mail security, TLS.  The e-mail server used for the FBI’s domain, IC.FBI.GOV does not have even the most basic of security enabled.

Repeating this TLS check test for Stewart.Garrick@met.police.uk shows the same thing:

ENGLAND FAILS:
TestReceiver
CheckTLS Confidence Factor for "Stewart.Garrick@met.police.uk": 0
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
mail3.met.police.uk
[212.74.97.198]
15
OK
(180ms)
OK
(167ms)
OK
(169ms)
FAIL
FAIL
FAIL
OK
(682ms)
OK
(163ms)
mail4.met.police.uk
[212.74.97.212]
15
OK
(181ms)
OK
(165ms)
OK
(164ms)
FAIL
FAIL
FAIL
OK
(673ms)
OK
(165ms)
mxbackup.uk.cw.net
[195.92.195.234]
20
OK
(155ms)
OK
(241ms)
OK
(144ms)
FAIL
FAIL
FAIL
OK
(686ms)
OK
(782ms)
Average

100%
100%
100%
0%
0%
0%
100%
100%

The e-mail servers for the domain MET.POLICE.UK FAIL the TLS test and do not have the capability to encrypt inter-domain e-mail messages.
Validating against other domains included in the e-mail message intercepted by Anonymous, we the following results on the part of the e-mail servers used by other high-level security officials in other countries who were invited to participate in the conference call:

FRANCE PASSES:
TestReceiver
CheckTLS Confidence Factor for "olivier.nael@interieur.gouv.fr": 90
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
tigre.interieur.gouv.fr
[212.234.218.76]
10
OK
(172ms)
OK
(337ms)
OK
(162ms)
OK
(161ms)
FAIL
OK
(1,433ms)
OK
(163ms)
FAIL
Average

100%
100%
100%
100%
0%
100%
100%
0%

Note: Cert failures do not affect TLS encryption, but may mean the site isn't who they say they are.

NOTE that the CERT failure means that the TLS test was unable to verify the e-mail address.   They may be because it was changed since being published by Anonymous or that the domain INTERIEUR.GOUV.FR runs Greylisting.  If we test in a few minutes and the CERT OK changes to PASS, then we will know they run Greylisting.

The NETHERLANDS PASSES:
TestReceiver
CheckTLS Confidence Factor for "michel@nhtcu.nl": 90
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
pochta3.nhtcu.nl
[83.149.67.40]
8
OK
(154ms)
OK
(688ms)
OK
(144ms)
OK
(143ms)
FAIL
OK
(1,663ms)
OK
(150ms)
OK
(149ms)
pochta4.nhtcu.nl
[83.149.94.112]
9
OK
(154ms)
OK
(159ms)
OK
(144ms)
OK
(145ms)
FAIL
OK
(1,138ms)
OK
(150ms)
OK
(151ms)
Average

100%
100%
100%
100%
0%
100%
100%
100%

GERMANY PASSES:
TestReceiver
CheckTLS Confidence Factor for "andre.dornbusch@iuk.bka.de": 90
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
smtp.ts-businessmail.de
[217.150.155.10]
100
OK
(209ms)
OK
(696ms)
OK
(174ms)
OK
(175ms)
FAIL
OK
(1,934ms)
OK
(404ms)
FAIL
Average

100%
100%
100%
100%
0%
100%
100%
0%

SWEDEN FAILS:
TestReceiver
CheckTLS Confidence Factor for "peter.ericson@rkp.police.se": 0
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
mail.telia.com
[62.20.233.128]
10
OK
(193ms)
OK
(182ms)
OK
(178ms)
FAIL
FAIL
FAIL
OK
(1,118ms)
FAIL
Average

100%
100%
100%
0%
0%
0%
100%
0%



Getting back to that "what happened" question asked at the top of this posting, it looks like neither the FBI, nor several other high-security installations run TLS!

While I would certainly not consider TLS to be the only security protocol implemented for communications between international security agencies, it should, at the very least, be a jumping off point for any secure e-mail communication.

No matter what kind of e-mail server you are running, or what purpose you are running your e-mail for: personal, business, not-for-profit, whatever the use, always remember that e-mail is transmitted as plain text across the internet and should always be encrypted.


The level of encryption depends on both regulatory requirements and what your business does.  HIPAA / HITECH, Sarbanes Oxley, and government regulations all have similar, and, because of highly publicized incidents like the one outlined above, merging requirements.


Protect yourself now.  Check the status of your e-mail encryption and make certain you are running TLS on your mail servers – as a very MINIMUM requirement.


You can check your e-mail server's TLS capabilities at: http://www.checktls.com/perl/TestReceiver.pl.


Select "CertDetail" from the drop-down box for intensive result reporting.
If you have any questions, please feel free to contact me and we can discuss your e-mail and network security to make certain your business is protected.


Now for the fun part, the actual e-mail intercepted by Anonymous is listed below.


NOTE: Because this has been previously published on the Internet by Anonymous, we decided to keep all of the data exactly as previously published:

======================================
MIME-Version: 1.0
acceptlanguage: en-US
Accept-Language: en-US
Content-class: urn:content-classes:message
Subject: Anon-Lulz International Coordination Call
Date: Fri, 13 Jan 2012 19:21:49 -0000
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: Anon-Lulz International Coordination Call
From: "Lauster, Timothy F. Jr." Timothy.Lauster@ic.fbi.gov To: "Reichard, Gerald A." Gerald.Reichard@ic.fbi.gov,
paul.hoare2@met.police.uk,
Raymond.Massie@met.police.uk,
trevor.dickey@met.pnn.police.uk,
Stewart.Garrick@met.police.uk,
"Gillen, Paul G" paul.g.gillen@garda.ie,
"Gallagher, Colm" colm.gallagher@garda.ie,
pim@nhtcu.nl,
Gea@nhtcu.nl,
michel@nhtcu.nl,
olivier.nael@interieur.gouv.fr,
olivier.moalic@interieur.gouv.fr,
thierry.mezenguel@interieur.gouv.fr,
andre.dornbusch@iuk.bka.de,
peter.ericson@rkp.police.se,
stefan.kronqvist@rkp.police.se,
ulrika.sundling@rkp.police.se,
Jaap.Oss@europol.europa.eu,
valentin.gatejel@europol.europa.eu,
"Helman, Bruce C. Jr." Bruce.Helman@ic.fbi.gov,
"Sporre, Eric W." Eric.Sporre@ic.fbi.gov,
"Buckler, Lesley" Lesley.Buckler@ic.fbi.gov,
"Geeslin, Robert C." Robert.Geeslin@ic.fbi.gov,
"Plunkett, William R." William.Plunkett@ic.fbi.gov,
"Roberts, Stewart B." Stewart.Roberts@ic.fbi.gov,
"Brassanini, David" David.Brassanini@ic.fbi.gov,
"Stangl, Christopher K." Christopher.Stangl@ic.fbi.gov,
"Patel, Milan" Milan.Patel@ic.fbi.gov,
"Ng, William T." William.Ng@ic.fbi.gov,
"Adams, Melanie" Melanie.Adams@ic.fbi.gov,
"Culp, Mark A." Mark.Culp@ic.fbi.gov,
"Arico, Nicholas J." Nicholas.Arico@ic.fbi.gov,
"Tabatabaian, Ramyar" Ramyar.Tabatabaian@ic.fbi.gov,
"Penalosa, Jensen" Jensen.Penalosa@ic.fbi.gov,
"Bales, Will" Will.Bales@ic.fbi.gov,
"Burton, Kevin C." Kevin.Burton@ic.fbi.gov,
"Nail, Michael A." Michael.Nail@ic.fbi.gov,
"Grasso, Thomas X." Thomas.Grasso@ic.fbi.gov,
"Thomas, Christopher T." Christopher.Thomas@ic.fbi.gov,
"Caruthers, John" John.Caruthers@ic.fbi.gov,
"Phoenix, Conor I." Conor.Phoenix@ic.fbi.gov,
"Hunt, Chad R." Chad.Hunt@ic.fbi.gov,
"Willett, Bryan G." Bryan.Willett@ic.fbi.gov,
"Patrick, Kory D." Kory.Patrick@ic.fbi.gov

All, 
A conference call is planned for next Tuesday (January 17, 2012) to discuss the on-going investigations related to Anonymous, Lulzsec, Antisec, and other associated splinter groups 
The conference call was moved to Tuesday due to a US holiday on Monday.

Date: Tuesday, January 17, 2012
Time: 4:00 PM GMT=20
BridgeTN: 202-393-2430
Access Code: 6513211# 
Please contact me if you have any questions.

Regards,
Tim

SSA Timothy F. Lauster, Jr
Federal Bureau of Investigation
202-651-3211 (w)
202-651-3193 (f)
Protect your e-mail server today

- ENCRYPT YOUR COMMUNICATIONS!


======================================
If you have any questions on how to do so, or are looking for hosted solutions, please feel free to contact me.

Copyright © 2012, Bruce Barnes, ChicagoNetTech Inc, All Rights Reserved