Snapchat source code leaked on GitHub – but no one knows why

By John E Dunn

What just befell a “small” piece of SnapChat’s source code, and should users be concerned?

Things took a turn for the worse earlier this week when Twitter users got wind that the company had filed a takedown request under the Digital Millennium Copyright Act (DMCA) on 2 August 2018 in response to a portion of precious code being posted on GitHub.

Asking GitHub to remove commercially sensitive source code isn’t surprising in the least, although some claimed they detected a note of mild panic in the language used. In answer to the question identifying which copyrighted work had been infringed, Snap’s employee replied in full caps:

SNAPCHAT SOURCE CODE. IT WAS LEAKED AND A USER HAS PUT IT IN THIS GITHUB REPO. THERE IS NO URL TO POINT TO BECAUSE SNAP INC. DOESN’T PUBLISH IT PUBLICLY.

Given the situation, to most observers this will sound perfectly reasonable. The company followed up by confirming to Motherboard that a “small amount” of the source code for its iOS app had leaked in May during an update:

We discovered that some of this code had been posted online and it has been subsequently removed.

However, the company made two further claims that are open to question, the first being that the company was:

Able to identify the mistake and rectify it immediately.

This sounds reassuring and yet clearly someone managed to grab the code and post it to GitHub (not to mention the possibility that the code sat on GitHub for two months before this was noticed).

Read more at https://nakedsecurity.sophos.com/2018/08/08/snapchat-source-code-leaked-on-github/

Facebook wants to be the future of online banking

By Lisa Vaas

Here’s what the Wall Street Journal reported on Monday: Facebook has asked big banks to share their customers’ personal financial data, including card transactions and checking-account balances.

And here, basically, was the response from anybody who’s ever heard of Cambridge Analytica: Hysterical laughter with a bit of “Oh, hell NO. We should trust Facebook with our financial data why!?”

And here, in essence, was Facebook’s response, as it tried once again to convince everybody that it knows how to spell the word “privacy”: No, we aren’t asking for financial data! We just want to insert ourselves between you and your bank and keep you from waiting on the phone so long. Because bots! Chatbots! In Messenger!

Facebook has, in fact, approached big banks, including Wells Fargo, JPMorgan Chase, Citigroup and US Bancorp, with an eye toward partnering. According to the WSJ, this is how it envisions this swap: the banks will give Facebook its users’ banking data, and the platform would give bank customers the ability to conduct business within Facebook itself – specifically, within Messenger.

People familiar with the discussions in the talks told the newspaper that one feature Facebook has talked about would show its users their checking-account balances. It’s also pitching fraud alerts; some insiders have said. The WSJ also reports that the banks have been hit up by Google and Amazon on the data-sharing front: they reportedly want to provide basic banking services on applications such as Google Assistant and Alexa.

A spokesperson for Facebook told The Next Web that no, Facebook hasn’t asked banks for users’ transaction data. Rather, this is all about getting banking chatbots into Messenger to chat us up.

Read more at https://nakedsecurity.sophos.com/2018/08/08/facebook-wants-to-be-the-future-of-online-banking/

Could deliberately adding security bugs make software more secure?

By John E Dunn

The best way to defend against software flaws is to find them before the attackers do.

This is the unshakeable security orthodoxy challenged by a radical new study from researchers at New York University. The study argues that a better approach might be to fill software with so many false flaws that black hats get bogged down working out which ones are real and which aren’t.

Granted, it’s an idea likely to get you a few incredulous stares if suggested across the water cooler, but let’s do it the justice of trying to explain the concept.

The authors’ summary is disarmingly simple:

Rather than eliminating bugs, we instead add large numbers of bugs that are provably (but not obviously) non-exploitable.

By carefully constraining the conditions under which these bugs manifest and the effects they have on the program, we can ensure that chaff bugs are non-exploitable and will only, at worst, crash the program.

Each of these bugs is called a ‘chaff’, presumably in honor of the British WW2 tactic of confusing German aircraft radar by filling the sky with clouds of aluminum strips, which also used this name.

Arguably, it’s a distant version of the security by obscurity principle which holds that something can be made more secure by embedding a secret design element that only the defenders know about.

In the case of software flaws and aluminum chaff clouds, the defenders know where and what they are but the attackers don’t. As long as that holds true, the theory goes, the enemy is at a disadvantage.

The concept has its origins in something called LAVA, co-developed by one of the study’s authors to inject flaws into C/C++ software to test the effectiveness of the automated flaw-finding tools widely used by developers.

Of course, attackers also hunt for flaws, which is why the idea of deliberately putting flaws into software to consume their resources must have seemed like a logical jump.

Read more at https://nakedsecurity.sophos.com/2018/08/08/could-deliberately-adding-security-bugs-make-software-more-secure/