STE WILLIAMS

A data dump containing over 1.4 billion email addresses, passwords, and other credentials, all in clear text, has been found online by security shop @4iQ.

The 41-gigabyte file was discovered on December 5 and had been updated at the end of last month, indicating the data is both current and being used by third parties. The identity of the collator isn’t known but the miscreant left Bitcoin and Dogecoin wallet details for donations.

“None of the passwords are encrypted, and what’s scary is that we’ve tested a subset of these passwords and most of the have been verified to be true,” said Julio Casal, founder of @4iQ. “The breach is almost two times larger than the previous largest credential exposure, the Exploit.in combo list that exposed 797 million records.”

The Exploit.in list is included in this dump, as are records reported stolen before, but a lot of this data is new. It has even all been indexed for easy searching and search tools are also included in the archive.

Disturbingly the archive also shows that years of advice on choosing strong passwords is still being ignored. The top password is, depressingly, still 123456, followed by 123456789, qwerty, password and 111111, and the history of some accounts shows the minor variations that would make other passwords for the account easier to guess.

It’s hardly rocket science to guess the possible permutations

When the firm contacted some of the recipients, the email addresses of many proved to be still active, although in most cases the passwords were no longer in use. That said, those passwords may well have been used on other accounts, making the job a lot easier for hackers. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/12/12/archive_of_14_beeelion_credentials_in_clear_text_found_in_dark_web_archive/

Ian Beer of Google’s Project Zero bod has followed up on a “coming soon” Twitter teaser with a jailbreakable iOS and Mac OS vulnerability.

Beer went public after Apple worked out a fix for the kernel memory corruption bug.

He even launched a Twitter account for the occasion:

If you’re interested in bootstrapping iOS 11 kernel security research keep a research-only device on iOS 11.1.2 or below. Part I (tfp0) release soon.

— Ian Beer (@i41nbeer) December 5, 2017

(For non-programmers: tfp0 stands for “task for pid 0” – the kernel task port, and therefore the vector for pwnage.)

iOS 11.1.2, now with more kernel debugging: https://t.co/PIKbD3Gwx9

— Ian Beer (@i41nbeer) December 11, 2017

tfp0 should work for all devices, the PoC local kernel debugger only for those I have to test on (iPhone 7, 6s and iPod Touch 6G) but adding more support should be easy

— Ian Beer (@i41nbeer) December 11, 2017

The release is designed to let others take their own toolkits to Apple devices, ultimately to improve their security: if you don’t need to jailbreak a device, Apple had already patched the bugs last week.

The issue Beer found starts with Apple’s Mach kernel implementation, and the Mach interface generator (MIG). Beer was already familiar with MIG’s behaviour, having turned up CVE-2016-7612 and CVE-2016-7633 last year, and in September 2016 wrote: “Exploitability hinges on being able to get the memory reallocated in between the two vm_deallocate calls, probably in another thread.”

A second bug detailed in Beer’s proof-of-concept provided the vector to attack MIG. He writes that he took advantage of “a recent addition to the kernel, presumably as a debugging tool to help enumerate places where the kernel is accidentally disclosing pointers to userspace. The implementation currently enumerates kqueues and dumps a bunch of values from them.”

Beer’s step-by-step explanation is in the readme file of his PoC (linked in the Project Zero post):

• First, he used a proc_pidlistuptrs bug to disclose the address of arbitrary ipc_ports;
• Second, he triggered an out-of-bounds read for “various kalloc sizes” to identify “the most commonly-leaked kernel pointer”;
• Next, he sent Mach messages to gather “a pretty large number of kalloc allocations;
• With enough Mach port allocations, Beer gathered a page “containing only my ports”. The port address disclosure provided “a port which fits within particular bounds on a page. Once I’ve found it, I use the IOSurface bug to give myself a dangling pointer to that port”;
• ”I free the kalloc allocations made earlier and all the other ports then start making kalloc.4096 allocations (again via crafted mach messages);”
• Careful reallocation (1 MB at a time) made garbage collection trigger and “collect the page that the dangling pointer points to”.

Beer continued that “the bsdinfo-pid trick” let him build an arbitary read to find the kernel task’s vm_map and the kernel’s ipc_space, allowing him to reallocate the kalloc.4096 buffer with a fake kernel task port.

Beer said he had tested the exploit on iPhone 6s, iPhone 7, iPod Touch 6G, and Mac OS 10.13 on a MacBook Air 5.2 ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/12/12/apple_jailbreak_exploit/

The most basic tenet of secure programming is this: don’t trust anything you’re planning to consume.

Why? Because computer programs consume things from the outside world – like files, cookies, voice commands, passwords and a multitude of other data types – and things can go badly wrong if they ingest something they shouldn’t.

Programs can be poisoned accidentally, by glitches in the data they consume, or deliberately by hackers trying to feed them morsels designed to kill them or turn them, zombie-like, into unwitting accomplices.

In either case, life for your computer program is a bit like wandering around in a forest and trying to work out which fungus to eat for breakfast. The ones that kill you stone dead have a nasty habit of looking like the ones that go well with some bacon and grilled tomato.

If your computer program is going to last it needs to be suspicious, and that means assuming that everything is a throbbing, knee-high Death Cap mushroom, until proven otherwise.

Mailsploit

Computers have been “in the forest” and receiving emails for about 45 years now, so your email software ought to be pretty good at seeing every email received as a potential Deadly Dapperling. 

Emails consist of three parts: the message itself, any attachments and a collection of headers that set out (amongst other things) who the email should be delivered to, its subject and who it’s from.

Unlike attachments, where almost anything goes, the headers are governed by pretty strict rules, rules that ought to make identifying an email with a harmful header easier. The From header, for example, is supposed to contain the name and email address of a message’s author (or authors).

It was a surprise them, to learn that somebody has discovered a way to use malicious email addresses, smuggled in through the From header, to bypass anti-spam protections and, in some cases, trigger the running of arbitrary, hostile code.

The discovery was made by bug hunter Sabri Haddouche, who recently published information on a quease-inducing BWAIN (that’s a Bug With An Impressive Name), a coding mistake that seems to have been repeated over and over by dozens of different email applications.

He calls his discovery Mailsploit:

Bugs were found in over 30 applications, including prominent ones like Apple Mail (macOS, iOS and watchOS), Mozilla Thunderbird, various Microsoft email clients, Yahoo! Mail, ProtonMail and others.

How not to eat email addresses

Email, being as old as Prototaxites, only allows characters from the ancient ASCII set to appear in headers. That’s fine if you want to send an email and your name is Andrew but not if your name’s André, because ASCII only supports 128 characters and é isn’t one of them.

With only 128 characters to play with and a world of non-English names to support RFC-1342 was drafted in 1992 to allow exotic things like é, ε, э and tens of thousands of other characters (including latter-day essentials like the Pile of Poo emoji), to appear in theFrom header.

RFC-1342 details a way of using the 128 ASCII characters to represent the hundreds of thousands of non-ASCII characters, using either the Quoted Printable or Base64 encodings (André becomes Andr=C3=A9 in Quoted Printable and QW5kcsOp in Base64).

A header that arrives wrapped this way has to be unwrapped before being shown to the email’s recipient so they can see they have an email from André rather than Andr=C3=A9.

What Haddouche seems to have discovered is mail software that’s entirely too trusting:

Unfortunately, most email clients and web interfaces don’t properly sanitize the string after decoding which leads to this email spoofing attack.

Without that sanitisation, an attacker can try their luck at smuggling all manner of malodorous payloads into the guts of your mail software via the From header, provided it has an RFC-1342 wrapper.

And that’s exactly what Haddouche did.

Attacks

The Mailsploit bug has different consequences on different platforms.

Twelve email clients were found to be vulnerable to code injection attacks smuggled in through RFC-1342 wrappers. Hushmail, for example, allowed the spoofing of email addresses and injection of arbitrary HTML and JavaScript into its web-based client, leaving users at the mercy of XSS (Cross-site scripting) attacks launched from fake emails that bypassed DMARC protections.

Hushmail, to their great credit, fixed that bug the same day it was reported.

Others have not been so quick to act and Haddouche has published a Google Doc detailing affected vendors and their responses to his bug reports.

The most common problem uncovered, and the most talked about, is the attack’s ability to bypass DMARC, an anti-spoofing protection. If an email’s From header contains an address the sender isn’t authorised to use then protections like DMARC are supposed to stop from being delivered.

Mailsploit can be used to wrap an email address an attacker isn’t authorised to use, inside one they are authorised to use.

Let’s say you controlexample.org but you want to fake an email as if it’s come from example.com.

Your maliciousFrom header looks something like this, before it’s encoded:

From: [email protected]([email protected])@example.org

After you’ve encoded it, you send the email and the receiving Mail Transfer Agent (MTA) interprets what arrives like this:

From: some RFC-1342 encoded [email protected]

DMARC checks show that you are allowed to use example.org, so the email isn’t treated as spam (this is the correct behaviour). It delivers the mail to your victim’s inbox and later they view it using their email client of choice.

The RFC-1342 encoded data is then decoded and, if you’ve formatted your malicious payload correctly (the correct formatting varies slightly across different applications), the receiving email client is fooled into using the address fake@example.com in the victim’s from field.

Attacks typically exploit mail clients by including null characters (the in the example above), newline characters, or a combination of the two, that causes the client to discard everything in the header that follows them.

The crack the attack slips through then, is that MTAs authenticate using one domain and email client software can be fooled into displaying another.

What to do?

The DMARC bypass is interesting, real, and being used in the wild but should be spotted easily by anti-spam engines.

It’s worth bearing in mind too that while DMARC makes things better, it was never an impenetrable forcefield. It depends on both SPF and DKIM, and plenty of unknown mail can’t be properly judged because of casual settings like SPF records with a ~all default, while plenty of bogus mail also passes DMARC tests unmolested because it comes from fraudulent or hacked accounts on real servers like Gmail.

Email users should update their software as soon as updates become available.

Programmers, don’t rely on other parts of the system to feed your code properly, and if your inputs can be wrapped, zipped or encoded be sure to sanitise them after they’ve been unpacked.

Follow @NakedSecurity
Follow @MarkStockley

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/b3vvXzQtAKs/

Security researchers have lifted the lid on a gang of Russian-speaking cybercrooks, dubbed MoneyTaker.

The group has conducted more than 20 successful attacks on financial institutions and legal firms in the USA, UK and Russia in the last two months alone, according to Russian incident response firm Group-IB. MoneyTaker has primarily targeted card processing systems, including the AWS CBR (Russian Interbank System) and purportedly SWIFT (US).

In addition to banks, MoneyTaker has attacked law firms and financial software vendors. In total, Group-IB has confirmed 20 companies as MoneyTaker victims, with 16 attacks on US organisations, three on Russian banks and one against a Brit IT company.

By constantly changing their tools and tactics to bypass antivirus and traditional security solutions, and most importantly carefully eliminating their traces after completing operations, the group has largely gone unnoticed. “MoneyTaker uses publicly available tools, which makes the attribution and investigation process a non-trivial exercise,” said Dmitry Volkov, Group-IB co-founder and head of intelligence. “In addition, incidents occur in different regions worldwide and at least one of the US banks targeted had documents successfully exfiltrated from their networks, twice.”

The first attack in the US that Group-IB attributes to this group was conducted in the spring of 2016: money was stolen from the bank by gaining access to First Data’s “STAR” network operator portal. In 2016, Group-IB identified 10 attacks conducted by MoneyTaker; six on banks in the US, one attack on a US service provider, one attack on a company in the UK (providing financial software) and two attacks on Russian banks. In 2017, the number of attacks has remained the same with eight US banks, one law firm and one bank in Russia targeted. The geography, however, has narrowed to only the US and Russia.

Group-IB identified connections in the 20 attacks not only in the tools used, but also the distributed infrastructure, and exfiltration tactics used to siphon off data from compromised organisations. “Another distinct feature of this group is that they stick around after the event, continuing to spy on a number of impacted banks and sending corporate emails and other documents to Yandex and Mail.ru free email services,” Group-IB added.

MoneyTaker’s attacks on bank ATM cards have followed a pattern, the firm said.

The first attack on card processing that Group-IB specialists attribute to this group was conducted in May 2016. Having gained access to the bank network, the attackers compromised the workstation of First Data’s STAR network portal operators, making the changes required and withdrawing the money. In January 2017, the attack was repeated in another bank.

The scheme is extremely simple. After taking control over the bank’s network, the attackers checked if they could connect to the card processing system. Following this, they legally opened or bought cards of the bank whose IT system they had hacked. Money mules – criminals who withdraw money from ATMs – with previously activated cards went abroad and waited for the operation to begin.

After getting into the card processing system, the attackers removed or increased cash withdrawal limits for the cards held by the mules. They removed overdraft limits, which made it possible to overdraw even with debit cards. Using these cards, the mules withdrew cash from ATMs, one by one. The average loss caused by one attack was about $500,000 USD.

MoneyTaker uses a combination of commercial (e.g. the Metasploit pen-testing tool), cybercrime underground and its own self-written tools.

MoneyTaker’s toolkit [source: Group-IB]

MoneyTaker’s hacking kit included privilege escalation tools compiled from codes presented at the Russian cybersecurity conference ZeroNights back in 2016. In some incidents, the crooks called the infamous Citadel and Kronos banking Trojans into play. Kronos was used to deliver Point-of-Sale (POS) malware, dubbed ScanPOS.

In an attack on a Russian bank through the AWS CBR, hackers used a tool called MoneyTaker v5.0, which the group has been named after. Each component of this modular program performs a certain action: searches for payment orders and modifies them, replaces original payment details with fraudulent ones before erasing traces of the changes.

After infection, the group normally erases malware traces. However, when investigating an incident in Russia, Group-IB managed to discover the initial point of compromise: hackers penetrated the internal network by gaining access to the home computer of the system administrator.

Exfiltrated documents associated with attacks include: admin guides, internal regulations and instructions, change request forms, transaction logs, etc. A number of incidents featuring documents that describe how to make transfers through SWIFT. “Their contents and geography indicate that banks in Latin America may be targeted next by MoneyTaker,” Group-IB said.

Group-IB has turned over its MoneyTaker research dossier to Europol and Interpol as part of its recently signed cooperation in fighting cybercrime. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/12/11/russian_bank_hackers_moneytaker/

Banks in Latin America appear to be next big target, Group-IB says.

A Russian-speaking cybercrime group has stolen millions of dollars from more than 20 banks in the US and Russia since at least May 2016 and appears poised to strike financial institutions across Latin America next, Moscow-based Group-IB warned Monday.

According to the security vendor, the so-called MoneyTaker group’s modus operandi has been to break into a targeted bank’s network and then manipulate its card processing systems in order to enable fraudulent ATM withdrawals. The group’s victims have included banks in 10 states, including California, Illinois, and Florida. On average, the banks have lost around $500,000 each in these attacks.

The MoneyTaker group primarily has been targeting card processing systems such as SWIFT and STAR in the US and AWS CBR in Russia. It has stolen extensive documentation from its bank victims — such as admin guides, change request forms, and internal rules and regulations — in apparent preparation for future attacks via these systems.

The stolen documents include those pertaining to money transfers via the SWIFT network. Last year, hackers believed to be from North Korea stole tens of millions from banks worldwide by exploiting the interface between a bank’s systems and the SWIFT network.

Dmitry Volkov, Group-IB’s co-founder and head of intelligence, says one reason why MoneyTaker has avoided detection so far has been its use of publicly available tools. That has made it hard to attribute attacks to the group.

For example, MoneyTaker has tended to use the Metasploit penetration-testing tool to look for and exploit vulnerabilities in target bank networks. Once on a network, it also has been using Metasploit to conduct all network reconnaissance, to search for other vulnerabilities to exploit and to escalate privileges. A lot of the malware the group has been using is fileless and exists in system memory only, making it hard to detect. In some cases, MoneyTaker has shown the ability to change code midstream during an attack. 

MoneyTaker’s habit of switching between targets in the US, Russia, and, in one case, the UK may have helped it hide the fact the attacks were connected, Volkov says. In fact, it is quite likely that the group has broken into banks in other regions as well, but because of the geographically distributed nature of the victims it is possible that no one has connected the dots yet, he says.

Group-IB said it analysis shows MoneyTaker’s preferred approach for stealing money is to break into a bank’s network and then try and connect to its card processing system. If successful, members of the group then open legitimate accounts at the compromised bank or buy prepaid cards from it. Once the accounts are activated, group members use their access to the bank’s card processing network to increase or remove withdrawal and overdraft limits on their accounts in order to steal money via fraudulent ATM withdrawals.

MoneyTaker’s arsenal of tools includes some it has developed on its own. One of them is for spying on a bank’s activities and includes features to capture screenshots and keystrokes at timed intervals. Another one contains multiple components, each one designed for different functions such as searching for payment orders and modifying them and replacing original payment details with fraudulent details. The tool includes one module capable of making a payment order that has been fraudulently modified appear unchanged to the bank after it has been executed. According to Group-IB, the tool was used in an attack against a Russian bank.

MoneyTaker has shown a tendency to use different infrastructures to carry out its attacks. For example, it might use Russia-hosted servers for an attack on a US bank and US-based servers and equipment for an attack on a Russian bank. One unique feature about the group’s infrastructure is its use of a server that delivers attack payloads only to IP addresses on a whitelist of bank IPs.

Nicholas Palmer, director of international business development at Group-IB, says that despite the MoneyTaker’s apparent sophistication, it does not appear to be state-sponsored. “We have spent a lot of time researching this group. We have checked and rechecked the technical indicators we could find for connections with other groups,” he says. “There is nothing to suggest nation-state activity.”

Banks and financial institutions need to pay close attention to third-party intermediaries with whom they interoperate, such as vendors of card processing services, he says. This is especially true for institutions in Latin America, which appears to be MoneyTaker’s next big target, he says.

Related content:

• Malware At Root of Bangladesh Bank Heist Lies to SWIFT Financial Platform
• Symantec Warns of Second Group Targeting SWIFT Network
• 8 Notorious Russian Hackers Arrested in the Past 8 Years

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/russian-speaking-moneytaker-group-helps-itself-to-millions-from-us-banks/d/d-id/1330608?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Thought the warrantless surveillance legally enabled by FISA Section 702 was due to go belly up if not reauthorized by New Year’s Eve? Think again, say President Trump’s lawyers: you’re stuck with it until the spring.

For the past year and a half, national security officials in the US have been begging Congress to extend the legal basis for the National Security Agency’s (NSA’s) warrantless surveillance.

That legal basis is the legislative hot potato we know as Section 702 of Title VII of the Foreign Intelligence Surveillance Act (FISA) – a hot potato that was due to grow cold if not renewed in a few weeks, at year’s end.

According to its numerous critics, Section 702 has allowed government intelligence agencies – the NSA, CIA, FBI and the National Counterterrorism Center – to collect and sift through vast troves of information on an unknown number (intelligence agencies won’t say how many) of American citizens, all because it is “incidentally” collected during surveillance of foreign targets. They’ve been able to do it without probable cause, a warrant or any evidence of criminal activity.

As of late last month, there were five proposals in Congress to curb the warrantless surveillance powers granted by Section 702.

So where are we at, with three weeks left before Section 702 was supposed to bite the dust?

It’s not biting any dust, according to the Trump administration’s lawyers – at least not until 26 April 2018, which is what they’ve determined is the real expiration date.

Brian Hale, a spokesman for the Office of the Director of National Intelligence (DNI), says that even if Congress fails to reauthorize the law by New Year’s Eve, the administration believes that a legal wrinkle makes it OK to keep it going for a few more months. Namely, according to the New York Times, the secretive Foreign Intelligence Surveillance Court (FISC) sets rules for the program and authorizes it to operate for 12 months.

Not that the DNI isn’t expecting the law to be reauthorized by year’s end, mind you, Hale said:

We fully expect Congress to reauthorize this critical statute by the end of the year. Not doing so would be unthinkable in light of the considerable value Section 702 provides in protecting the nation.

But it wouldn’t matter either way, given that the last time FISC reauthorized Section 702 was on 26 April 2017. Add one year, and there you have it: the new shelf life is therefore up on 26 April 2018, as far as the executive branch’s lawyers figure it.

On the plus side, if the lawyers’ argument holds up, it will mean more time to hash out what limits, if any, lawmakers can agree to impose on the information on Americans that gets swept up into surveillance dragnets that are supposed to only target foreigners.

At any rate, extension of Section 702 may be intelligence agencies’ top priority, but that doesn’t mean it’s top of mind for Congress: rather, lawmakers have had their hands full with pushing through a tax plan.

The intelligence agencies have made Section 702 reauthorization to be a matter of vital importance, but as Senator Ron Wyden explained to the New York Times, that’s just what they do: they wait “until the last minute” to object to an expiration date, and then they spook us with the specter of dire consequences if they don’t get their way. That’s why he’s fine with the prospect of having more time for thoughtful consideration of Section 702:

We’ve seen this movie before: wait until the last minute, and then say, ‘crowded congressional calendar, dangerous world, we’ve just got to go along with it.’ Anything now that creates an opportunity for several months of real debate, I’ll listen to.

Follow @LisaVaas
Follow @NakedSecurity

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/FQQ9K2VDugo/

Lil Bub has two origin stories.

Either she’s a one-of-a-kind magical space kitty who climbed into a flying saucer to explore the dark reaches of the galaxy and subsequently wound up here on Earth, as told in a Lil Bub documentary created by Vice’s cuteness channel.

…or she’s the runt of a feral litter, found in the corner of a tool shed in Bloomington, Indiana, who was born with extreme feline dwarfism and has permanently stubby legs, a lower jaw significantly shorter than her upper jaw, and teeth that never grew in (good thing they didn’t; they’d jab her in the roof of her mouth).

The sum of all her misshapen parts – which has grown yet worse with the onset of an exceptionally rare bone condition called osteopetrosis – is that her tongue is always hanging out, her limbs stick out at odd angles, she wobbles, and she’ll will always look like a wide-eyed, surprised cat.

As you can imagine, Lil Bub has been making the internet squeal in glee for about 5 years now – amassing some 1.7 million Instagram followers in that time.

But wait. It gets more heart-melty.

You might imagine that her loving owner could make a bit of money from this adorable, sad-sack golden goose of a cat. And you’d be right. But to make Lil Bub matters even more I’m-not-crying-it’s allergy-season, owner Mike Bridavsky has donated 100% of the funds from the Lil Bub online store to an American Society for the Prevention of Cruelty to Animals (ASPCA) fund to help special needs pets.

Oh. My. GOD!!!!! How have you lived without Lil Bub this far in your life??!!!

At this point, you’re either blubbering into your keyboard or you’re tearing your hair out, wondering what in the furball-saturated, herring-scented online universe does any of this have to do with cybersecurity? Well, I’ll tell you: those 1.7 million Lil Bub Instagram addicts were rudely subjected to life without Lil Bub last week, when somebody crawled out from under a rock and hacked Lil Bub’s “I Am Lil Bub” Instagram feed.

The horror happened on 6 December, Bridavsky said on Lil Bub’s Facebook page.

According to Bridavsky, the account was hacked while he and his family were on a business trip and Lil Bub was safe at home. Mashable reports that the account’s avatar and bio were suddenly changed.

Whoever took it over – someone claiming responsibility emailed Mashable and sent screenshots that appear to show admin access to Lil Bub’s Instagram account – had control of the account for about an hour, during which they posted selfies demanding things like “if u want ur ig back call me daddy.”

Bridavsky said that a teen had taken it over. Not quite, said the person claiming responsibility:

I am not a teen, I am 11 years old.

Some reactions from Lil Bub’s sad fans:

 

…. I follow a cat named lil bub on Instagram and someone hacked it and I’m sad… um pic.twitter.com/Wl5kfwPcGv

— vicious (@ayyophoe) December 7, 2017

The adorable Lil Bub Instagram account got hacked and I’ve never been genuinely so upset and outraged

— Baylee (@Baylee_Shaffer) December 7, 2017

…while some pointed fingers at Instagram’s failure to protect the space kitty’s security:

Ohhh, good old @Instagram failing at keeping users safe, again! Lil Bub’s account has been hacked for ages now. Sort it out.

— Catriona (@macrae_catriona) December 7, 2017

…and others expressed a desire to see the hacker burn in the unquenchable fires of the deepest levels of Hades:

Whoever hacked Lil Bub’s instagram has a one way ticket to hell.

— ❄️Mikayla❄️ (@OneEaredWeasley) December 7, 2017

Well. Where to start in this maelstrom of emotion?

Let’s start with the notion that Instagram failed to protect the account. That’s quite a leap. It’s not that social media accounts don’t get hacked, but frequently, it’s because account holders use really bad passwords. Or they reuse passwords. That’s why many online companies pore over lists of stolen credentials: they look for stolen passwords that, when put through their hashes, match the hashes they have for their users’ passwords.

(No video? Watch on YouTube. No audio? Click on the [CC] icon for subtitles.)

That’s a good thing. It would be even better if we could convince everybody to create unique, hard-to-guess passwords and to never use them on more than one account. But given that so many people fail to do that, it’s helpful that many companies – Facebook is one – keep an eye out for user account security like that.

Now, about the “see you in Hell, you rotten 11-year-old hacker” thing: Kid, if you really are a kid, there are laws against what you did. And there are people called prosecutors and the FBI who are in charge of sending people to Hell, which is a place we also call prison.

Would they do it to an 11-year-old? Probably not. But if you keep this up, they’ll come looking for you.

So next time, before you go picking on an internet cat celebrity and emissary to special needs pets – as in, those creatures who make us feel like it’s OK to be different, that you can be as ugly and awkward as a mud pie and still be loved – think twice.

Follow @LisaVaas
Follow @NakedSecurity

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/AQkY-JCfXD8/

For the second time this year, HP has had to patch its laptops after a security researcher found a driver-level keylogger – and this time, other laptop-makers might have to check their own products.

The debug trace was in the Synaptics Touchpad driver used almost across-the-board in HP laptops, and while it is turned off by default, a registry entry could turn it on. While few home users would be likely to turn it on, it would be a tasty exploit for RAT (remote access trojan) herders.

The bug was disclosed by “ZwClose”, who was looking through the driver to see if they could adjust the backlighting of HP laptop keyboards.

A line in the SynTP.sys keyboard driver caught ZwClose’s attention:

The revealing text: “uLScanCode=0x%02X, bKeyFlags=%X"

More digging showed that the driver “saved scan codes to a WPP trace” (Windows software trace preprocessor).

HP acknowledged the issue, and issued updates for more than 173 commercial products and over 293 consumer products.

ZwClose wrote that a fix would also land in Windows Update.

Consumer items still awaiting a fix include eight HP Envy variants, an HP Stream series, as well as an HP x360 11 convertible.

HP’s advisory stated that the vulnerability “impacts all Synaptics OEM partners”, so we can expect a rash of driver updates to be released in the future. HP added: “Neither Synaptics nor HP has access to customer data as a result of this issue.”

Back in May 2017, security researchers from Swiss outfit Modzero found a keylogger in HP laptops’ Conexant audio drivers. As with the latest discovery, the logging was in debugging code the developers forgot to remove from production models. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/12/11/hp_synaptics_keylogger/

Security researchers from the University of Birmingham last week went public about security shortcomings in mobile banking apps that leave millions of users at a heightened risk of hacking.

The researchers developed a tool called “Spinner” to perform semi-automated security testing of mobile phone apps. After running the tool on a sample of 400 security critical apps, they were able to identify a serious flaw in many banking apps – including those offered by HSBC, NatWest and Co-op as well as Bank of America’s Health account app.

The researchers found that although banks had been diligent in building security into their apps, one particular technology used – so-called “certificate pinning” – which normally improves security, meant that standard tests failed to detect a serious vulnerability that could let attackers take control of a victim’s online banking.

Dr Flavio Garcia, one the the researchers, explained: “Certificate Pinning is a good technique to improve the security of a connection, but in this case, it made it difficult for penetration testers to identify the more serious issue of having no proper hostname verification.”

The security weak spot created a possible mechanism for an attacker – providing they are connected to the same network as the victim (eg, a Wi-Fi hotspot) – to perform a so-called “man in the middle attack” and retrieve the user’s credentials, such as username and password/PIN code. Other potential avenues for attack were also found, including the possibility for a wrong-un to do some “in-app phishing” in software offerings from Santander and Allied Irish bank.

These attacks would have allowed the rogue take over part of the screen while the app was running and use this to phish for the victim’s login credentials.

All the fixings

The University of Birmingham researchers worked with the banks involved, and the UK government’s National Cyber Security Centre to fix all the vulnerabilities, and the current versions of all the apps affected by this pinning vulnerability are now secure.

Banking customers using the same old Apple device that the researchers used (probably a 1st generation iPad, which is limited to iOS 5.1.1) should probably think about using something else for their banking, according to app security firm Arxan.

Winston Bond, technical director EMEA at the firm, urged banks to review the research and push updates to their customers.

“Banks should fix vulnerabilities as quickly as they can and push updates to their customers,” Bond said. “One of the issues highlighted by this research is that users of older Apple devices, [which] are restricted to older iOS versions, can’t pick up any updates once the app developer moves the minimum OS version for the app beyond their version. They are stuck on the last compatible version, with whatever bugs and vulnerabilities that includes.

“For banks and other organisations to protect themselves from outdated apps, every major app developer has to balance the relentless pressure to adopt the latest iOS features against the need to keep updating the users of older devices,” he added.

More robust cryptographic technology deployments by banks would also guard against attacks even in cases where users are connecting into services from ageing or not fully patched devices.

“Certificate pinning is a way to make sure that a mobile app will only talk directly to the server that it is meant to,” Bond explained. “All the communications traffic is strongly encrypted and it can only be understood when it gets to the right place. In this case, it stops anyone getting between you and the bank and seeing how much money you have in your account or changing the details when you tell the bank to pay someone.

“There are several ways to implement certificate pinning, with some trade-offs between flexibility and security,” he added.

It’s also worth noting that the University of Birmingham team managed to carry out these attacks while following the app store licence agreement rules – which prohibit reverse-engineering or modification of apps. Real attackers won’t play so nicely.

Mark James, a security specialist at anti-malware firm ESET, added: “Using financial services through your mobile device, either a smartphone or tablet, should ideally be done through your cellular [mobile] connection if possible, or if not, then through a VPN to minimise the chances of your connection being hijacked.”

Some initial results were given in the paper A Security Analysis of TLS in Leading UK Banking Apps presented at the Conference on Financial Cryptography and Data Security in January. The full results were given in the paper Spinner: Semi-Automatic Detection of Pinning without Hostname Verification which was presented last week at the 33rd Annual Computer Security Applications Conference in Orlando, Florida in the US. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/12/11/mobile_banking_security_research/

Qatar has agreed its long-awaited order for 24 British-built Eurofighter Typhoon fighter jets and a billion pounds’ worth of missiles assembled in the UK to go with them.

The £5bn Qatari order for the jets, built by BAE at its Warton and Samlesbury bases in Lancashire, will not, however, save all of the thousands of jobs set to go over the next few years.

BAE confirms it is slashing 2,000 jobs

READ MORE

On top of that comes a £1bn order for Brimstone and Meteor missiles from French-headquartered defence conglomerate MBDA, which is one-third owned by BAE Systems and incorporates the formerly BAE-owned bits of the UK’s guided missile industry.

Although the Eurofighter is nominally a multinational EU effort, in reality it is a mostly British aircraft built mostly in Britain by a mostly British firm. The Qatari order has been on the cards for years and a letter of intent was signed by former defence secretary Sir Michael Fallon in September this year.

Qatar also intends to buy a handful of Hawk jets, also made by BAE Systems. The Hawk is famous as the jet flown by the RAF’s Red Arrows aerobatic team; it also equips RAF fast jet training units as well as a score of air forces around the world, plus the US Navy (with the licence-built T-45 Goshawk).

“We are delighted to begin a new chapter in the development of a long-term relationship with the State of Qatar and the Qatar Armed Forces, and we look forward to working alongside our customer as they continue to develop their military capability,” said a clearly chuffed Charles Woodburn, chief exec of BAE Systems.

New defence secretary Gavin Williamson chipped in, also in a canned quote: “These formidable jets will boost the Qatari military’s mission to tackle the challenges we both share in the Middle East, supporting stability in the region and delivering security at home.”

The deal is good albeit belated news for British industry: the Typhoons won’t be delivered until “late 2022”, BAE said, while the Hawk element of the deal has yet to be decided at all. MBDA isn’t struggling for work, thanks in part to the RAF’s consumption of Brimstone air-to-ground guided missiles in the Middle East, but a fresh order for those and Meteor missiles keeps the order books nicely swelled.

The UK and Qatar will also form a joint squadron to provide aerial security during the 2022 football World Cup, which the Gulf state is hosting.

While Williamson was crowing about the deal securing thousands of jobs (one of the key tenets of Ministry of Defence public relations is that actually defending the nation comes a very distant second to job creation schemes), it isn’t saving all that many; hundreds of the planned redundancies are still going ahead. Nonetheless, it’s a few billion added to UK plc’s bottom line.

BAE Systems is expecting to sign a deal with Saudi Arabia for 48 Typhoons at some point in the near future. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/12/11/bae_systems_qatar_typhoon/