Tag Archives: data security

More on Heartbleed

Posted on by

This is a pretty serious problem so I’ll devote more space to  another collection of tidbits from various sources.

EDITED TO ADD (4/9): Has anyone looked at all the low-margin non-upgradable embedded systems that use OpenSSL? An upgrade path that involves the trash, a visit to Best Buy, and a credit card isn’t going to be fun for anyone.

via Schneier on Security: Heartbleed.

From: https://news.ycombinator.com/item?id=7548991

The fact is that no programmer is good enough to write code which is free from such vulnerabilities. Programmers are, after all, trained and skilled in following the logic of their program. But in languages without bounds checks, that logic can fall away as the computer starts reading or executing raw memory, which is no longer connected to specific variables or lines of code in your program. All non-bounds-checked languages expose multiple levels of the computer to the program, and you are kidding yourself if you think you can handle this better than the OpenSSL team.

We can’t end all bugs in software, but we can plug this seemingly endless source of bugs which has been affecting the Internet since the Morris worm. It has now cost us a two-year window in which 70% of our internet traffic was potentially exposed. It will cost us more before we manage to end it.

Ironic how the above link uses https.  The Ars Technica article below has interesting screenshots.

From: Critical crypto bug exposes Yahoo Mail, other passwords Russian roulette-style

For an idea of the type of information that remains available to anyone who knows how to use open source tools like this one, just consider Yahoo Mail, the world’s most widely used Web mail service. The images below were recovered by Mark Loman, a malware and security researcher with no privileged access to Yahoo Mail servers. The plaintext passwords appearing in them have been obscured to protect the Yahoo Mail users they belong to, a courtesy not everyone exploiting this vulnerability is likely to offer. To retrieve them, Loman sent a series of requests to servers running Yahoo Mail at precisely the same time as the credentials just happened to be stored—Russian roulette-style—in Yahoo memory.

A First Look at the Target Intrusion, Malware

Posted on by

Target has yet to honor a single request for comment from this publication, and the company has said nothing publicly about how this breach occurred. But according to sources, the attackers broke in to Target after compromising a company Web server. Somehow, the attackers were able to upload the malicious POS software to store point-of-sale machines, and then set up a control server within Target’s internal network that served as a central repository for data hoovered by all of the infected point-of-sale devices.

via A First Look at the Target Intrusion, Malware — Krebs on Security.

Starbucks Mobile App Vulnerability Puts Data At Risk

Posted on by

According to Wood, the file, which can be found at /Library/Caches/com.crashlytics.data/com.starbucks.mystarbucks/session.clslog, contains more than just the user’s login information.

In re-testing the vulnerability last night Wood discovered that the user’s full name, address, device ID and geolocation data are all being stored in clear text as well. This information popped up after Wood reinstalled the app and monitored the session.cslog file during user signup.

via Starbucks Mobile App Vulnerability Puts Data At Risk | Threatpost – English – Global – threatpost.com.

Hackers Take Limo Service Firm for a Ride

Posted on by

It’s understandable why the company would decline to comment: Inside the plain text archive apparently stolen from the firm are more than 850,000 credit card numbers, expiry dates and associated names and addresses. More than one-quarter (241,000) of all compromised card numbers were high- or no-limit American Express accounts, card numbers that have very high resale value in the cybercrime underground.

via Hackers Take Limo Service Firm for a Ride — Krebs on Security.

Reporters use Google, find breach, get branded as “hackers”

Posted on by

Call it security through absurdity: a pair of telecom firms have branded reporters for Scripps News as “hackers” after they discovered the personal data of over 170,000 customers—including social security numbers and other identifying data that could be used for identity theft—sitting on a publicly accessible server. While the reporters claim to have discovered the data with a simple Google search, the firms’ lawyer claims they used “automated” means to gain access to the company’s confidential data and that in doing so the reporters violated the Computer Fraud and Abuse Act with their leet hacker skills.

via Reporters use Google, find breach, get branded as “hackers” | Ars Technica.

Goldman Sachs employees concerned Bloomberg news reporters are using terminals to snoop

Posted on by

Goldman later learned that Bloomberg staffers could determine not only which of its employees had logged into Bloomberg’s proprietary terminals but also how many times they had used particular functions, insiders said.

via EXCLUSIVE: Goldman Sachs employees concerned Bloomberg news reporters are using terminals to snoop – NYPOST.com.

I doubt this will end well for some people.

Dodging 5 Dangerous Database Default Settings

Posted on by

Because database configurations can make all the difference between safeguarding data stores and leaving them dangerously vulnerable to big data breaches, security experts recommend taking a look at all of your database’s default settings for weakness. But, in particular, the following defaults pose the biggest risks.

via Dodging 5 Dangerous Database Default Settings – Dark Reading.

  1. Default Passwords And Accounts
  2. Allowing Direct Table Access
  3. Keeping Default Stored Procedures
  4. Encryption Keys Stored With Database
  5. Unnecessary Services and Applications

IOS Developer Cheat Sheet – OWASP

Posted on by

In general, an app should store locally only the data that is required to perform its functional tasks. This includes side channel data such as system logging (see M8 below). For any form of sensitive data, storing plaintext data storage in an app’s sandbox (e.g., ~/Documents/* ) should always be avoided. Consumer-grade sensitive data should be stored in secure containers using Apple-provided APIs.

via IOS Developer Cheat Sheet – OWASP.

Cloud Security: What You Need to Know to Lock It Down

Posted on by

“The most important thing to remember when you’re storing or processing sensitive data in the cloud is that you are still fully responsible for the security of the data, and you are fully accountable if that data is lost or stolen,” Shaul concluded. “Even if your cloud provider offers some security services or indemnifies you for losses resulting from a breach, if your data is stolen, it’s still your problem.”

via Cloud Security: What You Need to Know to Lock It Down.