Blog: Security

The Federal Financial Institutions Examination Council (FFIEC) issued statements today notifying financial institutions of the risks associated with cyber-attacks on Automated Teller Machines (ATM) and car authorization systems and the continued distributed denial of service (DDoS) attacks. [more]

To read the Press Release, visit http://www.ffiec.gov/press/pr040214.htm

To view the Joint Statement, Cyber-attacks on Financial Institutions' ATM and Card Authorization Systems, visit http://www.ffiec.gov/press/PDF/FFIEC%20ATM%20Cash-Out%20Statement.pdf

To view the Joint Statement, Distributed Denial-of-Service (DDoS) Cyber-Attacks, Risk Mitigation, and Additional Resources, visit http://www.ffiec.gov/press/PDF/FFIEC%20DDoS%20Joint%20Statement.pdf


 

The Federal Financial Institutions Examination Council (FFIEC) jointly issued a statement to alert financial institutions Microsoft will discontinue extended support for Windows XP effective April 8, 2014.  After this date, Microsoft will no longer provide secruity patches or support for the Windows XP Operating System.  To read the Joint Statement, visit http://ithandbook.ffiec.gov/media/154161/final_ffiec_statement_on_windows_xp.pdf 

 

When working on a compromised system, it's always good to have a "toolkit" available on read-only media (in case built-in utilities, like netstat, have been replaced on the compromised machine to hide the attackers activities).  However, you also need to know how to USE the tools in your toolkit.  At my training last week I was working to recover a compromised web server.  After doing some cleanup and removing some clearly malicious software, I tried to use netstat to verify the current listening ports/services on the machine (along with associated processes).  The local netstat on the machine had been hacked to return no output, but thankfully the netstat EXE on my "toolkit" CD was working.  I quickly combed through the list of ports that were labeled "LISTENING".  I didn't see anything listening that was out of the ordinary.  However, when the following prompt popped up I knew the attacker still had remote access to my machine. [more]

Upon a closer look at the netstat output, I noticed there was an "ESTABLISHED" connection to TCP port 23 on my host (typically used for telnet).  P0wn3d!

Lesson learned… verify ESTABLISHED sessions in addition to actively LISTENING services.


 

A review of more than 200,000 4-digit PINs used on mobile phones revealed the following as the most common (in order):

  1. 1234 (used by more than 4% of the sample group)<
  2. 0000
  3. 2580 (straight down the middle of the keypad)<
  4. 1111
  5. 5555
  6. 5683 (spells LOVE)
  7. 0852 (straight up the middle of the keypad)
  8. 2222
  9. 1212
  10. 1998

The 10 most frequently used PINs represent more than 14% of the total sampled.  Thus, with this distribution of PINs, you have a 1 in 7 chance of guessing the correct one in 10 tries. [more]

Years are always popular when coming up with a 4-digit PIN (see number 10 above).  So, birth year, graduation year, etc. would also be a good guess if these are known

Regardless, it's a very good idea to recommend people NOT use these particular PINs (at least the first 9 plus predictable years).


 

I have received 4 or 5 email this week from a phishing scam that claims that one of my ACH transactions was recently cancelled. These emails are getting through the filters and landing in my Inbox. If you or anyone you know gets an email similar to the one below, delete it. I have modified the link in the email below so it won’t work, but you can still see where it was trying to go.

One indication the emails are fake – they purport to come from NACHA, the National ACH Association. However, NACHA does not deal directly with consumers or individual transactions.

If you know someone who works with payroll, purchasing, paying bills, etc., you should warn them about these emails. They are targeting people who work with online ACH transactions. Imagine the horror if the person responsible for payroll at a company received an email saying, “ACH Payroll Cancelled”. They would be very likely to click on the link first and think about security later. [more]

From: admin@nacha.org 
Sent: Friday, September 16, 2011 8:07 AM
To: You
Subject: ACH Payroll Cancelled

 
The ACH Payroll transaction (ID: 2150243623890),
recently initiated from your operating account (by your company), was rejected by the other financial institution.


Cancelled transaction

Transaction ID: 2150243623890
Reason for rejection: See details in the report below
Transaction Report: report_2150243623890.pdf.zip (self-extracting archive, Adobe PDF)

Note:
If you are sure that this email was delivered to you by mistake, please redirect it to your director or accountant.


..
13450 Sunrise Valley Drive, Suite 100 Herndon, VA 20171 (703)561-1100 2011 NACHA - The Electronic Payment Association


 

This approach is certainly not for everyone, but here is what I have done to mitigate the problem with so many certificate authorities out there.  The Comodo breach of March 2011, for example, allowed some bad guys to use a registration authority to generate valid certificates for Google, Yahoo, Skype, etc.  There are companies that sell boxes with software that will generate a valid certificates on the fly for every secure web site you visit in order to be able to observe your traffic.  With so many CAs, the risk of misuse has increased.  These comments mainly apply to Windows.

I think it was during May 2010, I edited the trust level on the root CA certificates in Firefox to only trust about 10 of them.  I think I have had to trust maybe two more since then.  I started with the list at http://netsekure.org/2010/05/results-after-30-days-of-almost-no-trusted-cas.  There are several links on this page that explain a lot about how Windows handles certificates.  This is one of the major reasons I use Firefox instead of IE.

To change the trust level of certificates in Firefox, go to Options, select the Encryption tab, and then the View Certificates button.  This brings up the Certificate Manger window.  The Authorities tab in the Certificate Manage window is where all the CAs are listed. Select each certificate and then select the Edit Trust button at the bottom.  This is where you can disable trusting each CA’s certificate. [more]

I also run the Firefox Addon Certificate Patrol which saves every certificate and warns me if a certificate has changed.  The primary blogger with the Tor Project, phobos (I don’t know the real name), suggests being your own certificate authority in a manual sort of way and not trusting any external certificate authorities (https://blog.torproject.org/blog/life-without-ca). I decided not to go that far.

If you prefer another browser such as Google Chrome or Internet Explorer, the procedure will be different.   Chrome and IE use the Windows certificate store, so you will have to delete the certificates that you do not want to trust.  Opera has it’s own store, but operates like Windows, downloading additional root certificates behind your back.  You may be able to preload these and remove the trust, but I have not taken the time to look into this.  I know nothing about how Safari handles certificates.

As I mentioned at the begining of the article, this approach is not for everyone.  However, for technical users with a little patience you can greatly reduce the likelihood you'll fall susceptible to a spoofed SSL certificate.


 

When people have cables with combination locks for securing their laptops at their workstation they always remember to turn the tumblers when they secure the laptop. But what happens when they unsecure the laptop? Many people won't turn the tumblers on the opened lock because it is much easier to lock the laptop later if the combination is already set.

In one instance, laptops were stolen by someone who came by when the laptops were not there and noted the combination. They came back later when the laptops were there and used the combination they had noted earlier.


 

Steve Gibson, one of the hosts of the popular "SecurityNow!" podcast, has created a tool that allows the checking of DNS servers for spoofability. This tool works by asking the user's browser to retrieve an image located at a uniquely named subdomain of the type xxxxxxxxxxxxx.dns.grc.com, "where the “xxxxxxxxxxxxx” is replaced with a unique 13-character string of characters that has never been used before."*

Then, in order to know the IP address for this special domain, the browser sends a DNS query to its DNS server, which then forwards this query to a special nameserver located at grc.com. This nameserver tells the DNS server that the location of that image is actually an "'alias' of the real domain name, which is a good deal longer and more complex."* The nameserver instructs the DNS server to look up the name of the "real" location of the image which looks like "...a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.xxxxxxxxxxxxx.dns.grc.com"* (with about 50 preceding 'a''s) [more]

The DNS server sends queries to the GRC nameserver, attempting to resolve the IP address of the given domain name one sub-domain at a time , causing the DNS server to send hundreds of requests which are collected by the GRC nameserver. As the nameserver collects these requests, it creates a scatter plot of both the Source Port and the Query Transaction ID of each request. Then, the data is analyzed to see the randomness of the Source Port and the Query Transaction ID which reveals the spoofability of the used DNS servers.

This tool is quite interesting, and shows that even as vulnerabilities arise on these critical systems, many do not fix the vulnerabilities, leaving the users at risk to visit a malicious web site believing that it is the site they were looking for which potentially places their private data at risk.

*A more thorough and detailed analysis of how this tool works can be found by reading GRC's article on how the DNS Nameserver Spoffability Test works.


 

I think we all know better than to download executable programs (.exe's) from untrusted sources and run them.  Opening a Word document from an untrusted source could be dangerous.  Now, even opening a PDF file on a fully patched Windows machine with excellent, up-to-date anti-virus and malware software could cause your machine to get owned.

Didier Stevens, who has written some great PDF analysis tools, published a disturbing blog post the other day.  He demonstrates how to use an existing feature in PDF to execute a program on someone's computer when they open the document.  Adobe Acrobat Reader displays a message first, but the message can be changed to social engineer someone into clicking the Open button on the message.  And my favorite PDF reader, Foxit, does not even display this message.  Disabling javascript does not help. [more]

Here is the link to his article: http://blog.didierstevens.com/2010/03/29/escape-from-pdf/

I downloaded his extremely simple example and in a few seconds changed it run a batch script instead of cmd.exe.  It looks it would be trivial to make it run any sequence of commands desired.  Depending on the PDF viewer used on other operating systems such as Linux or Mac OS X, this same technique will work there.

When using Google, one might consider clicking on Quick View or View as HTML instead of viewing the actual the PDF file.

UPDATE:  Adobe finally responded to this, explaining simply how to disable this feature.  This sounds like a good thing to do for most users. http://blogs.adobe.com/adobereader/2010/04/didier_stevens_launch_function.html


 

I upgraded from Vista to Windows 7 about three weeks ago.  I decrypted my PGP encrypted drive before the upgrade and, after the upgrade, PGP recognized my disk wasn’t encrypted and prompted me to encrypt my drive.  I started the encryption process but wound up pausing the process because of slow performance, intending to resume it after hours.  I installed some Windows and Lenovo (ThinkDamage…probably my 2nd mistake) updates which required a reboot.  After the reboot, PGP started trying to install itself and produced this error message…

"You cannot upgrade or remove PGP while a whole disk is processing. Installation terminated." [more]

I was unable to access the PGP console in order to resume the encryption, decrypt, etc.  An attempt to uninstall PGP produced the same error.  This was not good since I was scheduled to leave town on an audit within 24 hours and thought I might have to abandon the upgrade to Windows 7, restore a backup and re-encrypt the old Vista image before I left town.

A coworker suggested I log a ticket with PGP.  After doing so, I was poking around their site, searching for various terms from the error message and stumbled across a reference to a command line command.  About that same time, I received an auto-response from PGP which included several links, the last of which (https://pgp.custhelp.com/app/answers/detail/a_id/1850) led me to information about the same command line command, pgpwde.

Here is the relevant section from the page above:

SECTION 2 - PGPWDE Command Line

The following commands will help diagnose and decrypt the disk. Other commands can be listed by typing pgpwde --help.

  1. To begin working with the PGPWDE interface open a command prompt and change to the PGP installation directory (default directory shown) C:\Program Files\PGP Corporation\PGP desktop.
  2. To list all installed hard disks in the system type: pgpwde --enum. Entering this command will give us a list of disks with numbers we will use in the next few steps.
  3. Now type pgpwde --status --disk 1. Substitute the PGP WDE disk number listed in the previous step for the number 1 in the command if different. The output of this command will tell us whether the disk is still encrypted.
    • If the disk is not encrypted, "Disk 1 is not instrumented by bootguard" will be the output.
    • If the disk is encrypted, the output will display:
      • "Disk 1 is instrumented by Bootguard."
      • The total number of sectors.
      • A Highwater value (number of sectors encrypted).
      • Whether the current key is valid.
  4. Type pgpwde --list-user --disk 1. This will tell us the user information contained on the disk. This will help in multi-user environments to determine which user passphrase was used to implement WDE.
  5. Type pgpwde --decrypt --disk 1 --passphrase {mypasswordhere}. This will start the decryption process. To view progress, type the status command listed in step 3 and note the Highwater number, this number will get smaller and smaller as the number of sectors encrypted decreases.

This command line command allowed me to decrypt the partially encrypted disk.  I then uninstalled PGP to be safe, reinstalled PGP and encrypted my disk without further incident.