STE WILLIAMS

Two third-party services left Facebook user data exposed online — in one case, 540 million records of user comments — highlighting the ease with which third-party developers can access data and the risk of lax security.

A Mexican media company’s unprotected Amazon S3 container exposed more than 540 million records of Facebook users’ comments and interests, while a defunct integrated Facebook app, At the Pool, left online sensitive information of more than 22,000 users, cloud-security firm UpGuard announced on April 3.

The data, found by the company’s storage-scanning service, had explicitly been saved in two separate Amazon Simple Storage Service (S3) buckets, allowing public downloading, according to a blog post. The larger data set, left online by Mexican media firm Cultura Colectiva, consisted of 146GB of comments and whether other users liked or responded to those posts, says Chris Vickery, director of cyber-risk research at UpGuard.

“In this concentrated mass, 540 million records, this is the same type of data that companies like Cambridge Analytica, or anyone else in the marketing [or] psychographic field, can exploit to develop … profiles and really learn how to control a population,” he says. “In the aggregate, it is scary.”

Third-party developers and corporate users of Facebook’s information have become a large security and public-relations problem for the company. In 2018, a Facebook insider revealed that Cambridge Analytica and its parent company, the SCL Group, had collected data on millions of Americans as a prelude to profiling them and targeting advertising to influence the 2016 presidential election. Soon after, the company revealed that most of its users likely had had their profiles scraped by third-party developers. Multiple lawsuits have since been filed against Facebook.

Yet the leaks have not stopped. In December, an issue with Facebook’s photo API may have given third-party developers access to the photos of 6.8 million users. In June, Facebook revealed that a bug had inadvertently set the profiles of 14 million users to “public.”

The run of privacy and security issues underscores the lack of control Facebook has over the application developers who use the company’s data to create new services. In a statement to Dark Reading, Facebook stressed that the servers exposing the latest data did not belong to the company.

“Facebook’s policies prohibit storing Facebook information in a public database,” a spokesperson said in a statement. “Once alerted to the issue, we worked with Amazon to take down the databases. We are committed to working with the developers on our platform to protect people’s data.”

Often, the leaks are not due to any sophisticated attack but by a misconfiguration on the part of the third-party firms. Amazon S3 instances are secure by default and have to be explicitly set to allow public downloading, according to UpGuard’s Vickery.

“In each case, the Facebook platform facilitated the collection of data about individuals and its transfer to third parties, who became responsible for its security,” UpGuard stated in its blog post. “The surface area for protecting the data of Facebook users is thus vast and heterogenous, and the responsibility for securing it lies with millions of app developers who have built on its platform.”

Such misconfiguration should be easily detected by the firms. Scanning services, automated developer testing tools, and other techniques could be used to detect such issues, says Renaud Deraison, chief technology officer and co-founder of Tenable, a cyber defense firm.

“We continue to see headline-grabbing data leaks and breaches that are the direct result of a simple misconfiguration,” he says. “And we’ll continue to see these issues so long as speed trumps security.”

While the company has pushed much of the responsibility for the data exposures to the third-party custodians of the data, Facebook needs to step up, Mukul Kumar, chief information security officer and vice president of cyber practice at security-management firm Cavirin, said in a statement.

“Facebook and others need to go through their records, and reach out to their various partners to secure any customer data,” he said. “Given that some of these partners may not have the expertise or may no longer exist, Facebook may need to work directly with the public cloud providers, and if they don’t take the initiative, the government should intervene.”

Related Content:

• Facebook: Most Profiles Likely Scraped by Third Parties
• Exposed Consumer Data Skyrocketed 126% in 2018
• Facebook Rolls Out ‘Data Abuse Bounty’ Program
• Financial Firms Scrutinize Third-Party Supplier Risk
• Facebook Bug Sets 14M Users’ Settings to ‘Public’

 

 

 

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry’s most knowledgeable IT security experts. Check out the Interop agenda here.

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT’s Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/third-parties-in-spotlight-as-more-facebook-data-leaks/d/d-id/1334344?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

The maintainers of the world’s most popular web server, Apache HTTP Server, have patched a critical vulnerability that could give an attacker a way to gain full ‘root’ admin control on Unix-based systems.

Named ‘Carpe Diem’ by the researcher who discovered it, Ambionics engineer Charles Fol, techies might prefer to first read his account of what is now identified as CVE-2019-0211 rather than the notification on the Apache Software Foundation’s official site which is light on detail.

Assigned a CVSS vulnerability score of 8.8, the flaw affects Apache HTTP Server (‘Apache’ to its friends) versions 2.4.17 (9 October 2015) to 2.4.38 (1 April 2019), the official notification states:

With MPM event, worker or prefork, code executing in less-privileged child processes or threads (including scripts executed by an in-process scripting interpreter) could execute arbitrary code with the privileges of the parent process (usually root) by manipulating the scoreboard.

Windows servers aren’t affected but a large number of mainly recent Linux distributions are caught up in the alert.

The vulnerability

At heart, the flaw is an issue of privilege escalation triggered when Apache executes a graceful restart – jargon for allowing existing server threads to complete what they’re doing on a live website, which might happen once a day. (This also explains the ‘diem’ – day in Latin – part of the nickname Fol gave it.)

When restarting, Fol discovered an opportunity arises for a low-privilege process to elevate itself to root via a script, for example via PHP or CGI.

Who is affected?

Doing this requires having local access but that would be the case where Apache is being run in shared hosting environments, a routine way of packing large numbers of separate websites on to one server under a single IP address.

For an attacker, having local access would simply mean paying a few dollars for a cheap web hosting account (or taking one over).

Anyone in this category should make applying version 2.4.39 an urgent priority: Tweeted Mark J. Cox of the Apache Software Foundation:

Flaw in Apache HTTP Server 2.4.17 – 2.4.38 allows anyone you allow to write a script (PHP, CGI,..) to gain root. G… twitter.com/i/web/status/1…

—
Mark J Cox (@iamamoose) April 02, 2019

One scenario is that the flaw could be used in conjunction with a second flaw such as a remote code exploit (RCE) in which CVE-2019-0211 is then used to elevate privileges. Cox responded to such a suggestion:

Flaw in Apache HTTP Server 2.4.17 – 2.4.38 allows anyone you allow to write a script (PHP, CGI,..) to gain root. G… twitter.com/i/web/status/1…

—
Mark J Cox (@iamamoose) April 02, 2019

Version 2.4.39 also patches five other less serious flaws: CVE-2019-0217, CVE-2019-0215, CVE-2019-0197, CVE-2019-0196, and CVE-2019-0220.

Naturally, Apache gets the same periodic security patches as any software, including one for the serious Optionsbleed flaw in 2017.

On a related theme in the same year, Equifax made another flaw in the Apache Struts add-on famous (CVE-2017-5638) after it was blamed for a huge data breach suffered by the company. In that incident, the company later admitted it had failed to apply a patch made available months before the attack.

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

Facebook isn’t going to ask new users for their email password anymore, it said on Tuesday after a furious backlash.

A Twitter user called out the practice on Sunday, calling it “a HORRIBLE idea from an #infosec point of view.”

What Facebook called a “very small group of people” were getting prompted to enter the password for their personal email when they tried to verify new accounts, rather than the typical verification email or code sent to new-users’ phones.

As The Daily Beast first reported, small print below the password field promised that “Facebook won’t store your password.”

You can certainly see why people might not have been reassured by that small text: passwords are supposed to be a secret you share with the service you create them for, and nobody else.

Besides which, Facebook has shown itself to be untrustworthy when handling passwords: one example is the passwords we use in two-factor authentication (2FA).

Another example is what Facebook admitted, a few weeks ago, are potentially hundreds of millions of places where it saved users’ passwords to disk in raw, unencrypted form.

Facebook dropped the request for email credentials like the hot potato it is, sending out this statement on Tuesday:

We understand the password verification option isn’t the best way to go about this, so we are going to stop offering it.

Swear an OAuth

Facebook didn’t name a specific number of people who got the request for email logins, but it did clarify why they were singled out: namely, the alternative verification was originally designed for people signing up on a web browser and using email providers that don’t support OAuth, an open-source protocol that acts as a key for logins.

OAuth is commonly used as a way to give websites or applications access to information on other websites but without handing over passwords. If you’ve ever signed into a website using Facebook, Google or Twitter, you’ve used OAuth.

Which email providers don’t use OAuth? I couldn’t find any corresponding list, though you can find a smattering of discussion online around whether Thunderbird does (it does support OAuth, though a few months ago, a Mozilla moderator noted in a support forum that the developers had recently changed the code related to OAuth, which may or may not have led to a cluster of people experiencing OAuth authentication failures).

At any rate, back to Facebook: on one hand, it’s facing demands that it cut down on fake accounts, be it to fend off Russians tampering with elections or the spread of fake news. On the other hand, people are put off by the notion of having to hand it the information it says it needs for authentication purposes.

What’s a poor, wildly popular, widely government-poked, admittedly privacy-fumbling platform to do?

Not THIS, Facebook said in the statement emailed to news outlets on Tuesday.

We can’t blame users for being suspicious, even if there’s no proof that Facebook was hoovering up their email login credentials. But it’s good that the platform stopped the practice (in favor of what we hope will be an alternative, reliable way to authenticate new users – one that doesn’t make people flinch and clutch their logins).

Asking for credentials is a bad look for Facebook, and it’s not a good habit for users to get into.

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

Many mobile finance apps are littered with bugs that could allow attackers to access users’ sensitive data, a report revealed this week.

The smallest providers of mobile financial apps had the best security practices, while the larger players produced the most vulnerable apps, according to a six-week analysis commissioned by application protection company Arxan.

The report, In Plain Sight: The Vulnerability Epidemic in Financial Mobile Apps, evaluated 30 mobile financial apps spanning eight types: retail banking, credit card, mobile payment, cryptocurrency, health savings accounts (HSA), retail brokerage, health insurance, and auto insurance. It found a range of vulnerabilities in the apps (whose names it redacted), including a lack of binary protections, which allow an attacker to decompile the app.

As the report explains, decompiling an application involves reversing it to reveal its original source code. This provides a treasure trove of sensitive information, potentially including application programming interface (API) keys, private certificates, and URLs hardcoded into the software. The report found that 27% of the apps either hard-coded API keys and private certificates in their source code or stored them insecurely in the device’s file system.

Decompilation can also allow adversaries to better understand the application logic and find flaws in it, or simply to tamper with the software and introduce malicious code before recompiling and distributing it. This translates to some real-world dangers, it said:

All of these threats stemming from the ability to decompile the app may lead to a range of exploits against FIs or their customers, including account takeovers, synthetic identity fraud, credit application fraud, identity theft, gift-card cracking, and credential stuffing attacks.

Other security flaws in these apps included insecure data storage, in which apps stored data in the device’s local file system, in external storage, or copied to the clipboard. The report found that 83% of apps were guilty of this, which could allow attackers to access sensitive data.

Furthermore, 80% of the apps used weak encryption, which could enable attackers to decrypt sensitive financial data, while 70% used insecure random number generation, which can make any secrets produced by the app guessable by a third party.

Some apps shared services with other apps on the mobile devices, creating potential data leakage issues. And 43% of the apps were vulnerable to client-side injection, where a web page displayed directly in the app could force it to execute malicious code.

What’s more, 10% of apps trusted any digital certificates shown to them, enabling someone to impersonate a bank using a man-in-the-middle attack.

Of the 180 critical vulnerabilities discovered across the 30 apps, retail banking apps had the greatest number. Retail brokerages and auto insurance companies ranked next. Cryptocurrency apps fared pretty well, though, implementing the most security controls, the report said.

Financial software isn’t the only category of software that regularly blots its security copybook. The report concluded:

While the findings in this report are specific to these companies, many of them are systemic across all of the mobile apps tested, and other types of companies should use them as a guide for securing their mobile apps

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

We’re sort of accustomed to Google Maps shenanigans, but usually they’re funny, and/or cat-obsessed.

Like, say, the New Zealand map-cat behemoth that was for a time stretching off one side of Auckland’s Hobson Bay Walkway over to where its head was nearly touching the northwestern section of the trail: a full 250 meters of “ha-HA, Google, take THAT with your user-editable maps!”

But there’s lately been some map mischief with a far more serious intent: a German researcher who tried for over a year to get a smartwatch vendor to respond to vulnerability reports has tried to get the vendor’s attention by cyber-vandalizing the tracking maps of hundreds of GPS watches by printing the word “PWNED!” on them.

The researcher, Christopher Bleckmann-Dreher, has been trying to draw attention to over 20 models of GPS-tracking watches, some of which are used by children and the elderly, that he says are vulnerable to attackers.

They’re manufactured by the Austrian company Vidimensio. As Dreher outlines in his “Watchgate” slide deck (PDF), the watches have vulnerabilities that include communications with a backend API that allow eavesdropping and tracking of users, as well as allowing for data stored on the API server to be altered and for strangers to issue commands to users’ watches.

This is the timeline for what the security researcher says is the vendor’s failed fixes:

October 2017: A string of issues with kids’ smartwatches kicked off with the Norwegian Consumer Council’s (NCC’s) report that looked at four models and found that they were giving parents a false sense of security. Some features, such as the SOS panic button and the geofencing alerts to keep track of kids’ whereabouts, didn’t work reliably.

Most worrying of all, the NCC found that through simple steps, strangers could take control of the smartwatches. Given the lack of security in the devices, eavesdroppers could listen in on a child, talk to them behind their parent’s back, use the watch’s camera to take pictures, track the child’s movements, or give the impression that the child is somewhere other than where they really are.

17 November 2017: Germany’s telecom regulator, the Federal Network Agency (BNetzA), called kids’ smartwatches illegal spying devices and banned them.

On the 22nd, a stern TV review of the smartwatches aired. The findings at the time: you couldn’t stop the wiretapping except with a hammer, Dreher said.

23 November 2017: The next day, Dreher went to Amazon to pick up a Paladin smartwatch. No wiretap, he saw on the product listing. Huh, he thought, looking at the timeline to date.

After a decade in hardware security, he knew that there was no way a fix could have been done so fast. He started researching the smartwatches and found that the models all shared a common backend API that works as an intermediary and storage point between the GPS watches and the associated mobile apps.

He discovered flaws in how the GPS watches communicate with the backend API server. As a matter of fact, as he noted in his recent Troopers presentation, the flaws he initially found in Vidimensio’s Paladin smartwatch also affected over 20 other models from the same vendor.

December 2017: Dreher first reports his findings to Vidimensio. The researcher said that the company failed to take action. In spite of the ban, the watches kept selling like hotcakes in Austria and Germany, so Dreher worked with German IT news publication Heise.de to report the security flaws to the manufacturer.

April 2018: Under public pressure, Vidimensio issued fixes. All good? Not so much, given that, according to Dreher, the patches only addressed the eavesdropping threat, but not the other security flaws, including the ability to alter data on the API server and send commands to users’ watches.

Flaws come in handy to send ‘PWNED!’ message

Dreher told ZDNet that he’s been using one of the security flaws to insert fake GPS coordinates into people’s location history. Just like the map-cat hacker, he input fake GPS coordinates to look like the word “PWNED!” when displayed on the location history section map, which is shown inside the mobile app and the watch web dashboard.

He doesn’t feel bad about it. After all, those watches were supposed to have been melted into goo or however you destroy a wiretapping smartwatch, in accordance with the BNetzA’s ban:

I inserted fake GPS coordinates in watches (about 300) that have not been online since early 2018. I assume these watches have been destroyed by their owners as the BNetzA stated in their ban notice.

The exploit relies on changing a simple parameter, and entering another user’s ID. User IDs are sequential: they start at 0 and go up to the number assigned to the latest registered user (which was around 7,000 as of Tuesday, when ZDNet published its writeup).

Dreher tried to get BnetzA to force Vidimensio into fixing the security flaws, but it declined.

Dreher’s presentation featured this list of GPS watch models that he says still suffer from the security flaws.

So much for Germany’s ban on eavesdropping kids’ smartwatches. ZDNet reports that they’re still being sold, people still love them, and authorities aren’t enforcing the ban.

On the plus side, as ZDNet’s Catalin Cimpanu notes, EU authorities in February issued the first-ever product recall over data security issues.

The product? A smartwatch for kids.

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

It’s happened again!

Unsecured personal data found lying around in the cloud!

Unfortunately for Facebook, which has been caught up in numerous “concerned about cybersecurity” stories lately, this isn’t just any old data…

…it’s data that was acquired via Facebook by third-party apps.

It’s a little bit like what happened with Cambridge Analytica – the infamous Facebook app provider that offered so-called psychometric tests to seduce you into giving away a lot of detail about what made you tick, and then turned round and used that data in ways you almost certainly didn’t expect.

Ironically, even though these latest two data spillages, announced yesterday by leak-seeking cybersecurity company Upguard, aren’t quite as scary as the Cambridge Analytica story, they are in some ways even worse.

These breaches happened through plain old carelessness – databases hosted in the cloud and apparently almost casually left open to the world.

That’s like running your own servers in your own server room, but leaving the server room door unlocked with a big sign on it saying, “Free admission. Please don’t be naughty.”

In fact, it’s like copying critical data from your own servers onto a whole boxful of unencrypted USB drives and walking round a Dark Web convention handing them out to all and sundry.

What leaked?

According to Upguard, the latest leaky buckets it found belong to:

• Cultura Colectiva, a Latin American social networking collective that spilled a giant database of more than 500 million entries, probably covering millions of users (the site itself claims 45 million subscribers). The data apparently included Facebook IDs, likes, friends and more.
• At the Pool, a Facebook app that seems to have died out back in 2014, leaving its collected data orphaned and exposed. This data apparently included names, email addresses, Facebook IDs and passwords (not Facebook passwords, but stored in plaintext).

In other words, even though this isn’t “a Facebook breach”, because no one broke into Facebook itself, it is “a breach of Facebook data”, made possible by the enormous reach and influence that the Facebook platform enjoys.

Where to go?

It’s almost exactly eight years since we wrote an open letter to Facebook, saying:

We would “like”: Privacy by default, Vetted app developers, Https for everything.

To our very pleasant surprise, Facebook was one of the first big cloud operators to bite the HTTPS bullet, encrypting and authenticating its traffic everywhere, all the time.

At the time, many other companies were complaining that it would be too hard, too expensive, too slow and mostly pointless to encrypt everything, but Facebook proved them all wrong.

But not much has happened in respect of our second “like”, namely greater control over app developers.

The reason for keeping tighter reign on app developers is that they have a privileged position in a rich and sprawling kingdom.

Facebook apps essentially knit themselves into the Facebook ecosystem for free, almost instantly enjoying the imprimatur and reach of the world’s biggest social networking company.

And with freedom comes responsibility – whether that’s the duty not to do sleazy things with data shared in good faith, or simply the duty not to leave collected data lying around insecurely.

Let’s hope that Zuck’s recent company-wide bulletin about getting more serious about privacy brings results – we’re hoping to see fewer apps of higher quality from more reliable developers.

Facebook pulled off a security revolution when it reinvented its transaction security by rapidly adopting HTTPS everywhere-and-all-at-once…

…so let’s hope it can transform itself again, and get rogue apps under control, too.

What to do?

• Review your Facebook apps and their permissions right now. Go to https://www.facebook.com/settings, choose Apps and Websites from the left-side menu, and use the list of apps and websites, if any, to view and update the info they can request or to remove the apps and websites you no longer want.
• Review your privacy settings more generally while you’re about it. Use the Privacy menu item on the Settings screen to access the Privacy Settings and Tools page.
• Turn on 2FA if you haven’t already. Because you can. Use the Security and Login page to set yourself up. You can hand over your mobile phone number for SMS login codes, use an authenticator app, or set up a login token like a Yubikey if you have one.

While we’re handing out advice, here are some general thoughts for the many app prdoucers and consumers out there:

• If you’re an app developer, whether of Facebook apps, Google Play apps or software for any other platform, stop seeing security as a cost to be driven down. Make it a value that you can use to establish your trustworthiness.
• If you’re an app user, learn to be selective. Choose apps from companies that have earned your trust rather than simply claiming it. Avoid apps just because they’re fun or cool. Less is more.
• If you’re an app enabler like Facebook, regardless of the scale of your operation, remember our plea from April 2011, “We would like: vetted app developers”. Rapid signup procedures for developers may be egalitarian and convenient, but they seem so often to end in tears.

---

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

A government survey of British businesses has praised those who read El Reg to keep up to date with security news – while claiming to have revealed that fewer firms have spotted cyber attacks against them over the past 12 months, when compared to last year.

The government, which used data drawn from surveys to make its conclusions, would have us believe that 32 per cent of British companies and charities spotted a cyber attack in the last 12 months, down from 43 per cent in 2017/18.

The report partly put this down to the EU GDPR law introduced in May last year, arguing that some of its survey respondents “made changes to their cyber security policies or processes”.

In fairness, UK.gov also admitted that GDPR had, for some organisations, reduced security discussions to the level of “avoiding personal data breaches” instead of actual security, a negative side-effect of a well-intentioned law. The survey doc (PDF, 66 pages) authors said: “These organisations were less focused on other kinds of breaches or attacks, and typically had a narrower set of technical controls in place.”

An anonymously quoted large business (surprise!) agreed with UK.gov, saying: “Cyber security is one in a long list of costs of doing business, so no one’s going to get excited about it unless you have regulatory focus.”

Our wise overlords also praised those with the good eyesight, insight and foresight to read The Register and keep themselves up to date with all the important snippets coming out of the IT security industry:

Well done, readers. Click to enlarge

Not everyone who read the survey was impressed by its methodology or conclusions. Justin Coker, veep of Skybox Security, opined: “Although these latest numbers imply that businesses are identifying fewer breaches and attacks, the reasoning behind this drop is extremely nuanced. According to the report, only 33 per cent of businesses have cybersecurity policies in place. This suggests that there might not actually be a reduction in the volume of hacking attacks, rather that more are slipping through the net and unknowingly causing huge damage.”

Mark Nicholls of threat detection biz Redscan chipped in to say: “Interpreting the results is also clouded by the fact that half of organisations surveyed were micro businesses with fewer than 9 employees.” He added: “As to the statistic that two-thirds of businesses can identify a breach instantly, this is patently false. Real-world data from the ICO suggests it takes closer to 60 days on average.”

The clunking fist of British bureaucracy clearly needs to learn to tickle those it hopes to serve, even as it praises their reading habits. ®

Sponsored:
Becoming a Pragmatic Security Leader

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/04/04/cyber_essentials_survey_ukgov/

As the tax year rolls over into 2019/20, cybercrims have started belching out phishing emails and tax-themed malware, according to infosec researchers.

Proofpoint, one of those companies which keeps a close eye on the world of online badness, “observed the expected seasonal increase in tax-themed campaigns” as Q4FY19 clicked over into Q1FY20, with this year seeing ever more remote-access trojans (RATs) being deployed in the hope of stealing finance-related login details from unwitting marks.

“Actors utilized social engineering techniques in subject lines, spoofed emails addresses, and ‘decoy’ links that led to the websites of legitimate government tax offices, many of which were outside of the US,” the American infosec firm said in a statement.

Observed attacks target taxpayers in the UK, US, Australia, France, and Canada, among others, using items such as the old-fashioned booby-trapped Word document as well as forged emails appearing to be from tax authorities and offering juicy links to click.

“Taxpayers should be wary of convincing-looking emails from cybercriminals, which use social engineering in subject lines, spoofed email addresses, and ‘decoy’ links to convince victims to disclose tax information,” warned Proofpoint.

Kevin Epstein, the company’s veep of threat ops, sighed: “This year we observed a seasonal increase in a tax-specific trend that Proofpoint first identified in 2018, the distribution of a variety of remote access Trojans (RATs) including Orcus Rat, Remcos RAT, and NetWire. And they aren’t limited to the United States; we’ve recently observed threat actors targeting taxpayers in the UK, Australia, France, and Canada with these lures as well.”

The best advice going is to contact your local friendly tax office directly if you’re trying to give them money (or claw back what’s rightfully yours). Avoid clicking links in emails or talking to anyone over the phone who rings you up out of the blue. And, for pity’s sake, don’t open random Word documents and start following “decryption” instructions or executing macros. ®

Sponsored:
Becoming a Pragmatic Security Leader

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/04/04/new_tax_year_old_tax_phishing_scams/

British university admin folk are alarmingly easy to phish, according to an academic support body which claims a 100 per cent success rate “within two hours”.

Jisc, the artists formerly known as the Joint Information Systems Committee, claimed to have secured a “100 per cent track record” when securing illicit access to “high value data”.

Published today in a short report (PDF, 6 pages) titled “How safe is your data? Cyber-security in higher education”, Jisc’s security operations centre chief, Dr John Chapman, reckoned that his people succeeded every single time they spearphished a higher education institution.

He wrote: “Alarmingly, when using spear phishing as part of its penetration testing service, Jisc has a 100 per cent track record of gaining access to a higher education institution’s high value data within two hours.”

The sample size was 50 universities, with some having been pen-tested multiple times.

The finding came after a Jisc survey of university IT departments in 2018 suggested that education sector techies, on the whole, reckon their institutions aren’t all that well-defended. Some of the reasons given for that were “a lack of dedicated staff and budgets and a lack of policies, suggesting senior leaders are not taking the issue seriously enough,” according to Jisc.

“Jisc’s own chief executive and Finance Department have been targeted in this way” by criminals, the body’s report stated, adding that it had detected “more than 1,000 DDoS attacks” during calendar 2018 against various higher education bodies.

“Analysing the timings of these attacks has led Jisc to surmise that many of them are ‘insider’ attacks launched by disgruntled students or staff,” it concluded. ®

Sponsored:
Becoming a Pragmatic Security Leader

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/04/04/jisc_uni_pentesting_report/

Ethiopia’s transport minister has said the national carrier’s pilots were following published Boeing procedures immediately before the fatal crash of a 737 Max 8 in March, citing an unpublished government report.

During a press conference this morning, transport boss Dagmawit Moges said: “The crew performed all the procedures repeatedly provided by the manufacturer but was not able to control the aircraft.”

The preliminary report is expected to contain early findings on why Ethiopian Airlines flight ET302 crashed on 10 March, killing all 157 people aboard. International treaties on air crash investigations mean that aviation safety reports do not normally assign blame or liability for a particular incident.

Dagmawit continued, as reported by Reuters: “Since repetitive uncommanded aircraft nose down conditions are noticed… it is recommended that the aircraft control system shall be reviewed by the manufacturer.”

Ethiopian Airlines Aviation Group said in a statement that its pilots “have followed the Boeing recommended and FAA approved emergency procedures to handle the most difficult emergency situation created on the airplane”.

CEO Tewolde GebreMariam added: “We are very proud of our pilots’ compliances to follow the emergency procedures and high level of professional performances in such extremely difficult situations.”

The press conference will turn more attention onto Boeing’s controversial MCAS software system, which is suspected to have played a role in both fatal crashes.

Boeing sends chief exec for a spin

Boeing, meanwhile, issued a press release last night showing chief exec Dennis Muilenberg being flown in a 737 Max 7. Although this is not technically the same model as the 737 Max 8, it is very closely related – and still features the controversial MCAS system.

Dennis Muilenburg, @BoeingCEO, experienced first-hand our MCAS software update performing safely in action during a 737 MAX 7 demo flight today.

More about the proposed MCAS software update here: https://t.co/TJrfcYG4ok pic.twitter.com/OcCiMnc7I5

— The Boeing Company (@Boeing) April 3, 2019

Earlier this week a patch for MCAS was delayed as the American aviation regulator, the FAA, inspected it. In the meantime, Boeing has published a webpage with information about MCAS.

MCAS works by taking its input from one of a pair of angle-of-attack sensors mounted by the aircraft’s nose. If the jet is under manual control (i.e. the autopilot is not switched on) and its flaps are up, and the angle-of-attack is increasing, MCAS automatically adds nose-down trim in 10-second bursts. This pushes the nose downwards, helping avoid a stall caused by climbing at too steep an angle and with too little speed. A fuller explanation is towards the end of this previous Reg article.

According to Boeing, the patch will do the following:

• Flight control system will now compare inputs from both AOA sensors. If the sensors disagree by 5.5 degrees or more with the flaps retracted, MCAS will not activate. An indicator on the flight deck display will alert the pilots.
• If MCAS is activated in non-normal conditions, it will only provide one input for each elevated AOA event. There are no known or envisioned failure conditions where MCAS will provide multiple inputs.
• MCAS can never command more stabilizer input than can be counteracted by the flight crew pulling back on the column. The pilots will continue to always have the ability to override MCAS and manually control the airplane.

Speculation has mounted that the pilots of the crash aircraft failed to notice the trim wheels moving under commands from MCAS because they stopped and started. A graph from the Indonesian crash investigation showed MCAS operating 33 times in seven minutes during the fatal flight, with the crew trying to undo its changes each time it activated.

Ethiopian Airlines’ GebreMariam said: “All of us at Ethiopian Airlines are still going through deep mourning for the loss of our loved ones and we would like to express our deep sympathy and condolences for the families, relatives and friends of the victims.” ®

Sponsored:
Becoming a Pragmatic Security Leader

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/04/04/737_max_ethiopia_press_conference_pilots_followed_boeing_procedures/