[aklug] Re: Dumb newbie question - download security

Greg, not a dumb question at all, and not just for newbs. I suspect
that most of us play loose with downloads sometimes. Some random
thoughts:

1. Downloading source from two or more independent mirrors, and making
sure both sets of signatures and checksums are valid and match, is a
good idea. This technique mitigates mirror compromise, but does not
mitigate upstream author compromise. Mirrors that add their own
crapware wrappers (c|net, I'm looking at you) make this impossible and
should be avoided, IMO.

2. Keeping track of the public keys of the projects you track -- such
that you would notice if they change -- is a good idea (and man, do we
need a server-side HTTP header and browser-based PGP/checksum
extensions to automate this!). This technique can help detect author
compromise. Trusting the signature and checksum stored in the same
directory/filesystem/server as the download itself is insufficient,
because these can also be tampered with.

3. Running it through VirusTotal or Malwr probably doesn't hurt,
either. Note that more malware is performing checks to see if it's
virtualized or not, and altering its behavior accordingly (staying
dormant longer, etc.), and so may be resistant to this one. This
technique can help discover unusual library calls and
suspicious/unexpected behavior -- even in unmodified software. (Even
if the software is as intended by the author, it may do things that
you don't want it to do.)

As to the ACS compromise, I have zero knowledge of the actual controls
that ACS had in place (different part of the house), but from the
notification sent to employees (and former employees, of which I am
one) and the KTUU piece [1], it appears that ACS couldn't definitively
tell which information was exfiltrated. They have to assume worst
case. This is a strong argument for having controls in place that
leave a trail of which data went where. Some of the components of
Security Onion [2] -- strongly recommended for the security-minded (or
security-curious) -- can help here. Also, disk is relatively cheap
these days, so saving network flows for a few months (or even full
packet capture for a few rolling days) is probably also a good idea.

Royce

1. http://www.ktuu.com/news/news/personnel-information-may-have-been-compromised-at-local-carrier/24510018
2. http://blog.securityonion.net/

On Tue, Mar 11, 2014 at 1:36 AM, Greg Schmitz <greg@amipa.org> wrote:
>
> A question about security and downloading. What, if any precautions do
> folks on this list take before installing code? I'll use for example the
> "Tree" command (sort of looks like an old MS-DOS Norton utility). The
> website provides no CRCs and no GNUPG signatures. Do most folks just
> download this stuff now days and trust the website? I'm sceptical of
> anything offered without security measures, is it just my paranoia? I would
> note that University files in Indiana may not be tamper proof:
> https://www.privacyrights.org/data-breach-asc?order=field_breach_date_value_1&sort=desc&title=indiana
>
> As a side note this might be of interest to some here:
>
> February 20, 2014 Alaska Communications
> Anchorage, Alaska BSR HACK
>
> Unknown
>
> Alaska Communications informed customers of a potential data breach on
> January 27, 2014. One of the company desktop computers was infected with a
> virus and subsequently sent data outside of their network. Possible personal
> information compromised could have included names, addresses, dates of
> birth, and Social Security numbers. The company stated they did not see any
> evidence of dependent, medical, or banking information that was compromised.
>
> The company is offering 1 year of AllClear ID protection at no cost and can
> be reached at 8-1-866-979-2593 for both AllClear Secure and AllClear PRO
> services.
>
> Any further questions or concerns about the incident there is more
> information at the company's website http://www.alaskacommunications.com/
>
> Information Source:
> Vermont Attorney General
>
>
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Mar 11 03:43:43 2014