Information Security News
Federal prosecutors have charged a previously convicted hacker with illegally accessing millions of records sent by Twitter users requesting technical support. The allegations shed new light into the hijacking of Burger King's Twitter account 17 months ago, a case many assumed had gone cold.
Cameron Lacroix, a 25-year-old resident of New Bedford, Massachusetts, agreed last month to plead guilty to a hacking spree that targeted computer networks around the country, some belonging to law enforcement organizations that stored sensitive data. He was also reportedly one of several hackers to steal racy pictures stored on Paris Hilton's poorly secured cell phone in 2005.
On Wednesday, federal prosecutors in San Francisco alleged that from February 16 to 19 in 2013, Lacroix hacked into Zendesk, a provider of customer support services, and used his illegal access to download millions of records belonging to Twitter, one of the many companies that used Zendesk. The support tickets included users' e-mail addresses and contact information. He then used the information to breach at least two high-profile Twitter accounts, according to charging papers filed in US District Court in San Francisco. Prosecutors wrote:
When PF Changs published an update about it's breach earlier this week, a few readers asked about the use of "encrypted terminals". Aren't all credit card transactions "encrypted"? The quick answer is: yes. But not all transactions are encrypted all the time.
To answer some of these questions, I figured I will use this diary as a TL;DR edition to credit card processing. There are a number of terms that are often confused when it comes to credit cards, and how they are processed.
If you enter a credit card on a web site, the process is typically pretty straight forward if implemented correctly: The credit card reaches the web server via SSL. The web server then typically hands the card to a payment processor (again: via SSL) and receives a confirmation code back that can later be used to identify the transaction. The confirmation code is often shared with the customer and doesn't require an specific safeguarding. It may be used to void the transaction. But this would also require the merchants credentials in addition to the code, so the customer can't void it without the merchant's approval.
The merchant does not need to store the credit card number. As should not store it at all. However, the credit card number is still exposed in memory while it is being processed and careless coding often leads to data like credit card numbers being logged. So while the card can't be read off the wire, it can still be read off the server if the server is compromised.
Now what about repeat billing? Does your phone company need to store the number so it can charge your credit card once a month? No. In addition to a confirmation number, the credit card processor can hand a token back to the merchant. The merchant can now use this token to apply additional charges to the card. This token is only good for a particular merchant. If it is stolen, an attacker could charge the account, but any funds would go to the merchant the token was stolen from, not to the attacker. More interesting: The token is linked to your account, not your credit card number. If you receive a new credit card number (e.g. after your card was compromised), the merchant is still able to charge the account. This is very convenient for recurring payments like utility bills.
Where things get actually more interesting these days is retail scenarios. Many people still think that handing your card to a clerk is more secure then typing it into a website. However, what happens is essentially the same thing as when you type it into a website, with the exception that the clerk swipes the card at a PoS system, that may be compromised (just like your PC may be compromised when you type in the number).
The best defense against a compromised PoS system is to encrypt the number in the reader, before it hits the PoS system. Some readers support this feature, and it requires that the reader be used with a specific processor who holds the decryption key. You (as owner of the PoS system) have no idea what card was used, neither has the pw0n3r of the PoS system. A popular implementation of this technique is the Square reader that can be plugged into the audio jack of a cell phone to turn it into a credit card reader. Since the phone is considered un-trusted, the CC data is encrypted inside the reader and then passed encrypted to Square.
Why doesn't everybody do that? Two reasons: Some merchants like to "see" the CC track data to identify the customer and use it for purchase tracking. Secondly, this option is a bit more recent and older systems don't support it.
Where does "Chip-and-Pin" fit in? Chip and Pin does not encrypt any data. It just authenticates the terminal. In this case, if the card is stolen, an attacker can not produce a fake card that could be used at a chip and pin terminal, and skimmers will have a harder time reading the information. But a card number stolen from a compromised Chip-and-Pin PoS system can still be used online or to create a non Chip-and-Pin card.
I hope this clears up some of the questions regarding recent breaches.
by Sean Gallagher
The National Security Agency’s attempts to keep track of people outside the US who use encryption and anonymization software from the Tor Project also apparently captured the traffic of anyone reading a wide range of articles on Linux Journal, according to documents published by the German public television broadcaster ARD and provided by security researchers (and Tor contributors) Jacob Appelbaum, Aaron Gibsom, and Leif Ryge. The documents—which include what appears to be search rules for the NSA’s XKeyscore Internet surveillance system, indicate that the NSA also gathered up data on visitors to articles on the Linux Journal website.
In the Das Erste article, Appelbaum et al wrote that the rule “records details about visits to a popular Internet journal for Linux operating system users called ‘The Linux Journal—the Original Magazine of the Linux Community’" and called it an "extremist forum."
Included in the code is the following block of instructions:
Posted by InfoSec News on Jul 03http://www.computerworld.com/s/article/9249540/PF_Chang_39_s_says_breach_was_39_highly_sophisticated_criminal_operation_39_
Posted by InfoSec News on Jul 03http://arstechnica.com/security/2014/07/order-restored-to-universe-as-microsoft-surrenders-confiscated-no-ip-domains/
Posted by InfoSec News on Jul 03http://www.bloomberg.com/news/2014-07-02/bae-says-hedge-fund-attack-on-hedge-fund-wasn-t-real.html
Posted by InfoSec News on Jul 03http://www.zdnet.com/ancient-vulnerabilities-are-geddon-in-the-way-of-security-7000031192/
Posted by InfoSec News on Jul 03http://www.sfgate.com/business/article/Hacked-companies-face-SEC-scrutiny-over-5596541.php