Cisco Network Registrar Vulnerability

Cisco Network Registrar (CNR) provides highly scalable and reliable DNS, DHCP, and TFTP services, simplifying administrative tasks associated with network and device configuration by centralizing management.

CNR contains a default password for the administrative account.  An attacker could use this knowledge to authenticate with administrative privileges and arbitrarily change the configuration of CNR. This vulnerability is documented in Cisco bug ID CSCsm50627  (registered customers only) and has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2011-2024.  Due to the nature of the vulnerability and its potential impact this vulnerability is rated HIGH.  No known attacks have been noted in the wild, but this one is simple.  All you need is the knowledge.

If you are not a registered Cisco customer, you can implement a simple workaround.  CHANGE THE DEFAULT PASSWORD!

  • To change the password using the web interface, select Advanced -> Administrators -> Admin from the menu.
  • Execute the following command to change the administrator’s password using the command-line interface:
  • admin <admin-name> enterPassword

Access to CNR (TCP ports 8080, 8090, 8443, and 8453) and the host on which it is running should be limited to legitimate IP addresses using Access Control Lists or other means.

It is always a good practice to change default passwords during installation, and user selected passwords periodically.  The change interval should comply with an organization’s security policy but, as a guideline, all passwords should be changed two or three times a year.  This practice applies equally to all products regardless of when they are installed, and to all users, administrators and non-administrators.

Lockheed Martin Breach Update

Jeffrey Carr has done some good research and blogged about what is known so far regarding the Lockheed Martin compromise.  A very good analysis of what appears to have happened using public informaiton sources, and illustrates some of the contradictory information Lockheed has released.  The extent of the RSA SecurID breach appears to be somewhat worse than EMC has reported and EMC still disclaims its role in this attack.

As Jeffrey points out, Lockheed Martin has a history of significant cybersecurity breaches dating back to Titan Rain in 2003, and the F-35 Joint Strike Fighter program in 2009.  They have never publicly acknowledged the F-35 breach and lost a the lawsuit when a jury awarded a multi-million verdict for wrongful termination in the Sandia National Labs incident.

I will continue to watch this situation, and provide links to what I believe are good articles and information.


Change Your Facebook Password

It appears that third parties, in particular advertisers, have accidentally gotten access to Facebook accounts including user profiles, photographs, chat, and the ability to post messages and gather personal information.  Fortunately, they may not have realized that they have these abilities.  According to Symantec, over 100,000 applications can leak access tokens that remain valid for some period of time.  They might  sit in log files of various advertisers just waiting to be abused.

Facebook is planning to move away from access tokens and adopting OAuth 2.0,an open standard co-authored with Yahoo, Twitter, Google, and others, and HTTPS.  Until then, we can do something to invalidate the access tokens:  Change your password!  Do it regularly, unless you don’t care about your Facebook privacy and don’t use the same password anywhere else…

You can change your facebook password by clicking the upper right “Account” menu and choosing “Account Settings”.  The 4th option down allows you to change your password.

New PCI Supplement – Protecting Telephone-Based Card Data

Today, customers can swipe credit cards in POS readers, they can use e-commerce sites online, or quite commonly use the telephone to complete payment transactions.  New guidance has just been issued by the PCI Security Standards Council aimed at securing stored payment card data collected via call centers and over-the-phone payments.  This directive is highly necessary and very timely.  Card data collected over the telephone or by voice-based payment systems are often overlooked as a vulnerable payments channel and have become a targets for criminals.

The PCI Council’s Protecting Telephone-Based Payment Card Data information supplement provides actionable recommendations for merchants and service providers to process payment card data over the phone in a secure manner.  What makes phone-based payments unique and more vulnerable than other payment processing methods is the regulatory requirement to record the calls, and the “card-not-present” capture and storage of sensitive CVV or CVC authentication data.  It is a violation of PCI DSS Requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.  These authentication codes should not be stored in any manner.  Full primary account numbers (PANs) cannot be kept without additional protective controls in place.  PAN data should be encrypted if it must be stored.  Most payments made to call centers or over the phone with service reps are recorded.  Here’s a little PCI compliance secret for you.       ‘If you don’t need it, don’t store it.’

In face-to-face and e-commerce environments, risk-mitigating technologies have helped significantly reduce fraud rates, resulting in a shift of card fraud towards the Mail Order / Telephone Order (MOTO) space.  Until now, these phone-based transaction records have fallen outside the scope of the PCI standards.  The response to those merchants concerned enough with compliance to have asked, have heard the response from the PCI  council; If there is no way to extract the card data from the audio, PCI rules do not apply.  With the emergence and general acceptance of digitally recorded files for call recording, these records can now be easily be searched and extracted.  More merchants are using audio recordings, but are not encrypting or destroying the data.

Key points:

  • Explains how the PCI-DSS applies to card holder data stored in call recording systems.
  • Recommendations for assessing risk and applicable controls of call center operations.
  • Specific guidance around storage of sensitive authentication data, which includes suggested methods to meet PCI-DSS requirement 3.2.
  • Guidance on some of the key considerations faced by call centers when implementing PCI-DSS requirements.

Beware Fake Google Android Update

Symantec is reporting that Google’s latest update for its Android mobile OS appears to already have been subverted by hackers.  Symantec found an application called the “Android Market Security Tool” that is a repackaged version of the legitimate update by the same name that removed the DroidDream malware from infected devices.  They are calling the malware BGserv.

The fake security tool sends SMS’s to a command-and-control server, according to Symantec.  The company is still analyzing the code, found on a third-party application market targeted at Chinese users.  The fake security tool shows that hackers are taking an interest in the fastest growing mobile OS.  More than 67 million Android devices were sold last year according to Gartner.  It used two exploits called “exploid” and “rageagainstthecage” to infect phones.  Google has patched the vulnerabilities in Android versions above 2.2.2, but many Android users do not have the latest version of the software.

Google forced the “Android Market Security Tool March 2011” onto devices last week to remove DroidDream after more than 50 applications in Google’s Android Market place were found to contain DroidDream.  The malware steals information such as the phone’s International Mobile Equipment Identity (IMEI) number and the SIM card’s International Mobile Subscriber Identity (IMSI) number, and sends it to a server located in Fremont, California, and allows the malware distributor to install other code onto the phone.  Normally, phone manufacturers and operators are responsible for issuing updates to devices, not Google.

The Joy OF Pa$$w0rdz

Passwords.  They are the most common access control mechanism in use today.  They’ve been around for centuries as a means to restrict access.  They allow only those that know the correct combination of signs, symbols or whispered word to access some special resource or content.  They are everywhere, from your brick and mortar ATM pin, to almost every website on the internet.  And, they are a high risk pain in the Kester.  Why is that, exactly?

Passwords by their very nature are risky. They rely on the keeping secrets to be effective.  The problem with secrets is that a secret is only a secret until more than one person knows it.  In order to keep them secret, there are certain – apparently conflicting – rules that must be followed in their design.  


  • They need to be short enough that we can type them in accurately.
  • They need to be long enough to present a challenge when someone tries to use them without authorization.
  • They need to be simple enough that we can remember them.
  • They need to be complex enough that they cannot be easily guessed.
  • They need to be unique, because there are so many places that we use them.
  • They need to be unassociated with the place or subject that we are protecting them against.
  • They need to be unrelated to the person that created them. 
  • They need to remain memorable, or they will be forgotten.

Since the password is the key to the vault, restrictions on using the wrong key should be put in place to prevent someone from just typing in every possible key combination.  That means that if you use the wrong password more than say, three times, some type of lockout should take place.  This delays the ability to “brute force” a password, extending the time from a few hours to a number of days or weeks.  An alert should be generated to the registered owner’s email as well as to the administrator of the resource that is being protected so that they can change the password or temporarily suspend the account.

Continue reading

iPad, iPhone Security By-passed

Researchers have devised a method for by-passing passwords stored on locked iPhones and iPads that doesn’t require cracking of the device’s passcode.  The technique, disclosed on Thursday by members of the Fraunhofer Institute for Secure Information Technology, requires physical access to the targeted iPhone or iPad, for less than six minutes, and the after effects are easy to conceal, making it ideal to carry out on devices that are lost, stolen, or temporarily unattended.

Keep an eye on that iPad, and don’t lose sight of your iPhone.  If not, aLl yOu dAta arE bElong tO us.

The Register