STE WILLIAMS

Military, Government Users Just as Bad About Password Hygiene as Civilians

New report comes out just as group of US senators chastise Secretary of State Mike Pompeo for not using multifactor authentication.

Military and government users aren’t engaging in password hygiene any better than their brethren in less sensitive, private-sector positions, according to a new study out this week, which shows both sides creating weak passwords at about the same rate. 

The examination of password strength came by way of WatchGuard Technologies’ Q2 2018 “Internet Security Report,” which analyzed a data dump of 117 weakly encrypted credential pairs protected only with SHA-1 hash functions from a 2012 breach at LinkedIn. The study showed that credential pairs associated with .mil and .gov accounts were easily crackable — within a week — about 50% of the time. This was only slightly less than the rate of weak passwords in pairs associated with civilian accounts, which were at about 52%.

Among the sample of cracked government passwords were plenty of common doozies that typically make it into bad password hall of shame lists. The top two bad passwords in government-associated accounts were, respectively, “123456” and the ever-present “password.” 

“We didn’t find many surprises in that the most commonly used bad passwords remained largely the same,” wrote WatchGuard researchers. “However, it should be quite surprising that government and military entities use such horrible password practices. We can only hope that these were all dummy accounts that weren’t used for anything of consequence.” 

Clearly, the sample set wasn’t among credentials for government systems, so the results need to be taken with a large grain of salt here. But the prevailing point remains that these government and military users should probably know better than to use bad passwords anywhere they set up an account. The fact that many of them don’t heed hygiene best practices can probably be extrapolated to at least some degree across the rest of their digital footprints. When government agencies don’t account for this universally weak human factor of passwords, there’s bound to be rampant insecurity of accounts.

“For our federal government, no amount of budgetary pressures or other excuses should be tolerated when it comes to failing to have utilized a basic cybersecurity technique, such as MFA — especially since ‘user convenience’ is not the overriding concern,” says Todd Shollenbarger, COO of Veridium, who adds that NIST’s update of its Digital Identity Guidelines has done the hard work of outlining what needs to be done to shore up credentials. “What’s now needed — obviously — is for our federal government agencies to use it.”

And in separate but related news, this week a group of US senators chastised Secretary of State Mike Pompeo for lack of multifactor authentication (MFA) adoption within the Department of State.

“We urge you to improve compliance by enabling more secure authentication mechanisms across the Department of State’s information systems,” wrote Sens. Ron Wyden, Cory Gardner, Edward Markey, Rand Paul, and Jeanne Shaheen, referencing a General Service Administration (GSA) that showed the agency had only deployed MFA across 11% of required devices. “This password-only approach is no longer sufficient to protect sensitive information from sophisticated phishing attempts and other forms of credential theft.” 

 

Black Hat Europe returns to London Dec 3-6 2018  with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Article source: https://www.darkreading.com/endpoint/authentication/military-government-users-just-as-bad-about-password-hygiene-as-civilians/d/d-id/1332819?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

EternalBlue Infections Persist

Indonesia, Taiwan, Vietnam, Thailand, Egypt, Russia, China, among the top 10 nations with the most machines infected with the exploit.

The infamous EternalBlue exploit used in the game-changing WannaCry and NotPetya cyberattacks just won’t die: new research shows 300,000 machines around the globe suffering repeat infections of the attack code.

EternalBlue, pilfered from the NSA and leaked by the mysterious Shadow Brokers group, abuses a flaw in Microsoft’s Server Message Block, SMB1, protocol. Researchers at Avira found a large number of machines – mainly running versions of Windows that don’t get updates and the older SMB2 protocol getting infected over and over with EternalBlue.

“There are still significant numbers of repeatedly infected machines more than a year after the big WannaCry and Petya attacks,” said Mikel Echevarria-Lizarraga, senior virus analyst in the Avira Protection Lab, which is currently deactivating some 14,000 computers per day with the vulnerable SMB1 protocol.

“Once the SMB1 protocol is deactivated, we don’t see the same machines affected again and again with this problem,” Echevarria-Lizarraga said. According to Avira, most of the infected machines are in Indonesia, Taiwan, Vietnam, Thailand, Egypt, Russia, China, Philippines, India, and Turkey.

Read more here.

 

Black Hat Europe returns to London Dec 3-6 2018  with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/analytics/eternalblue-infections-persist/d/d-id/1332820?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

You didn’t buy ‘your’ iTunes movies; Apple can delete them anytime

Do you feel lucky? Well, do ya, punk?

Then go right ahead and hit the “buy” button to pick up a movie on iTunes. Then, be ready to kiss that movie goodbye if Apple loses the rights to distribute it.

Yes, it turns out Apple’s iTunes shop is more of a “store front” than a “store,” as it explained to Anders G. da Silva recently. After Apple whisked away three of his purchased movies, the aggravated, de-movified man tweeted about the exchange this week, noting that Apple offered him two free rentals to make up for it.

Hmph! he said. That’s kind of like walking into a store, buying a “stereo,”, bringing the supposedly stereo-holding box home, opening it up to find a bunch of rocks, bringing it back to the store, and being told that hey, sorry, we can’t help, da Silva said. We’re just a storefront. But how about this: you can rent a stereo from us!

Apple explained to da Silva that the problem is that he’s in Canada. For whatever reason, the content provider decided to pull the movies out of the Canadian iTunes store:

The content provider has removed these movies from the Canadian Store. Hence, these movies are not available in the Canada iTunes Store at this time.

The legally helpless trillion-dollar company didn’t even offer da Silva a refund. Instead, he got two credits for renting movies on iTunes – priced up to $5.99 USD, that is.

He wasn’t in the market for rentals, da Silva responded, and would just like the movies he purchased, please.

We totally get it, Apple said, and proceeded to prove it totally didn’t get it by trying to appease him with two more rental credits.

This is a clear-cut lesson of the importance of reading that which is never read: the Ts and Cs!

After all, the iTunes Store’s Terms of Service do address this kind of incident:

You may be able to redownload previously acquired Content (“Redownload”) to your devices that are signed in with the same Apple ID (“Associated Devices”). You can see Content types available for Redownload in your Home Country at https://support.apple.com/en-us/HT204632. Content may not be available for Redownload if that Content is no longer offered on our Services.

This isn’t the first time that content “store fronts” have pulled a disappearing act with what people thought was “their” content. In 2009, Amazon did it with George Orwell books – “Animal Farm” and “1984” – reaching out to erase the books from customers’ Kindles.

No, you don’t own your Kindle books, Amazon reminded another customer in 2012. It shuttered the account of a Norwegian woman, who lost 43 purchased books, after determining that her account was “directly related to another which has been previously closed for abuse of our policies.” Which policies? What other account? Amazon wouldn’t say. Though it did send this glob of legalese:

Per our Conditions of Use which state in part: Amazon.co.uk and its affiliates reserve the right to refuse service, terminate accounts, remove or edit content, or cancel orders at their sole discretion.

Please know that any attempt to open a new account will meet with the same action.

In short, as da Silva came to find out, we never really “buy” digital content. It’s at best a rental, given the legal control that content sellers keep to themselves and the ease of getting at – and deleting – cloud-stored data. You’re better off buying a DVD, he noted: at least it’s a physical thing that Apple can’t get at unless it sends armed iMilitia.

But remember, this is a two-way street. Apple can not only make things disappear without your say-so; it can also make things appear without your say-so! …like it did with U2’s album back in 2014.

The compulsory download of Songs of Innocence was yet another reminder that our iTunes libraries, just like Kindle libraries, aren’t walled gardens solely for our enjoyment, unchanging for perpetuity. They’re more like sponges that can get squeezed to suck up or discharge what the store fronts want to – or are legally compelled to – have in there.

So, remember, next time you want to spend your hard-earned money on content, and you’re hovering over that “buy” button, just do your own mental translation: swap “buy” for “rent,” and see how valuable “your” content feels after that.


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

Review that! Fake TripAdvisor review peddler sent to jail

The owner of a fake-review factory is going to get a chance to write a review about his trip to the inside of an Italian jail.

TripAdvisor announced (PDF) on Wednesday that, in one of the first cases of its kind, the criminal court of the Italian city of Lecce has ruled that writing fake reviews, under a fake identity, is criminal conduct.

In a decision handed down in June, the court sentenced the owner of PromoSalento – a business that sold fake review packages to Italian hospitality businesses – to nine months in prison and ordered him to pay about 8,000 Euros (USD $9300) in costs and damages. He hasn’t been named.

Understandably enough, given that its business model relies on disseminating authentic reviews by actual patrons, TripAdvisor is pretty stoked about the decision:

We see this as a landmark ruling for the internet. Writing fake reviews on TripAdvisor has always been a violation of the law in many jurisdictions… However, this is the first time we have seen the laws being enforced to the point of securing a criminal conviction.

Businesses are hungry for good reviews: as in, those that come from customers and which are stripped of marketing speak. A Harvard Business School study recently determined that a one point improvement in a restaurant’s score on Yelp could increase its revenue by as much as 5-9%.

With that much business at stake, you can see how dishonest entrepreneurs would be happy to step in and fill the need by cooking up and selling rave reviews.

That’s why, in 2015, Amazon sued over 1,000 people for posting fake reviews on its marketplace. Also in 2015, a number of diners, critics and restaurateurs, frustrated by what they saw as a plethora of fake reviews on TripAdvisor, took to Twitter to campaign under the #noreceiptnoreview hashtag.

It was all about asking the popular review site to insist on screenshots of receipts before approving new reviews. The campaign didn’t go anywhere, for some good reasons: as TripAdvisor pointed out, a group of individuals who eat out together all have a right to leave a review, even if the table only gets one receipt.

You can see why the idea was compelling, though: Supporters thought such a move would help restore trust in TripAdvisor, as well as other similar sites that rely on the accuracy of their reviews to maintain and build their traffic.

TripAdvisor says that it first heard about PromoSalento in 2015, when its fraud investigators identified a new illegal business in Italy that was offering to write fake reviews for hospitality businesses to boost their profile on TripAdvisor. Several Italian businesses forwarded the emails to TripAdvisor, which launched the investigation that would ultimately see the unidentified person behind PromoSalento sent to jail.

TripAdvisor says it supported the prosecution of PromoSalento as a civil claimant by sharing evidence from an extensive in-house fraud investigation and providing support from its Italian legal counsel.

In an investigation spotlight, the company described how it used digital forensics to identify and analyze links between PromoSalento and attempted submissions to its site. It found that the bogus-review seller had attempted to submit more than 1,000 reviews on hundreds of properties – reviews that were either blocked or removed.

PromoSalento tried to skirt TripAdvisor’s blocks by regularly changing usernames and email addresses, but the review site’s fraud detection processes sussed out the IP addresses, browser types and even the screen resolution of a reviewer’s device to weed them out.

Based on that analysis, we were able to see a trail of digital and behavioral ‘breadcrumbs’ that led our team straight back to PromoSalento.

Busting the fake-review factory was only half of the equation, though. TripAdvisor also went after the businesses that were buying the bunk. It wound up linking several hundred businesses to fake reviews submitted by PromoSalento, notified those businesses, and penalized them by demoting their positions in its rankings.

If that didn’t slap some sense into a given business, TripAdvisor then issued them a red badge: a notice displayed on a business’s TripAdvisor listing page warning travelers that the business has been trying to manipulate reviews and outlining the type of fraud it spotted.

In most cases, a fake-review business is rarely heard from again once it realizes that TripAdvisor is wise to its tricks. But in the case of PromoSalento, the Italian Postal and Communications Police were already on to them. They’d been tipped off by a restaurateur from Trieste who had received advertising emails from the fake-reviewer. The police investigation into PromoSalento sealed the deal, delivering enough evidence of criminal conduct to send the case to court.

The news of the resulting prison sentence and fine for the owner of PromoSalento was well received by TripAdvisor:

This is the first time we have seen the laws being enforced to the point of securing a criminal conviction. The judgment makes clear that writing fake reviews constitutes criminal conduct under laws relating to impersonation fraud.


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

Major US mobile carriers want to be your password

If password-only security is reaching its end of days, what will replace it?

For years, many have assumed that some form of new authentication must be the answer without being able to agree on which.

Now an alliance of big US mobile carriers – Verizon, ATT, Sprint, and T-Mobile – has added a new possibility to the mix under the banner of Project Verify.

Using Project Verify, users will access a supported website simply by clicking on a special icon which will verify them by communicating with a mobile app on their device.

The impressive bit is that’s it – no passwords, no usernames, no special codes – just one click on an icon. Alternatively, users will still enter passwords but use Project Verify as a second factor for two-factor authentication.

The eagle-eyed will have spotted that this sounds a bit like the push verification technology already offered by Google through its codeless Prompt system for Android and iOS.

Under that scheme, when users log in to Google they are sent a message via a mobile app asking them to confirm their action from the registered device.

Of course, unlike Prompt, Project Verify is intended for any website but it also works a bit differently below the surface.

According to early reports, the app carries out authentication by looking at the user’s IP address, physical location (from GPS and perhaps Wi-Fi data), the unique device IMEI, and of course, information from the SIM card such as the telephone number and its unique international mobile subscriber identity (IMSI) number.

This is clever because it turns the smartphone and how it is being used at that moment into a sort of hardware token that would be extremely difficult to spoof.

Project Verify’s USP is that only mobile networks can do this because only they can verify that the SIM chip inside the smartphone is the correct one.

Authentication overdose

A confusing issue with authentication is that there’s already a lot of it around, so how does Project Verify compare?

One alternative – authentication codes sent to users via SMS – is already considered obsolete because it can be defeated by SIM swap attacks. In theory, Project Verify isn’t vulnerable to SIM swaps because changing the registered SIM would immediately show up as a verification change.

A better comparison might be with the W3C’s WebAuthn, which will be integrated inside browsers using an API through which users will authenticate using a range of options, including encryption keys held in its integrated Trusted Platform Module (TPM), a biometric identifier such as a face or fingerprint, or by presenting a physical token such as a YubiKey.

This sounds more involved than Project Verify but as an open standard it might be easier to implement as a universal authentication system.

For both, it’s still early days – Project Verify is barely in the pilot phase yet while WebAuthn is still ironing out reported weaknesses in its underlying cryptographic algorithms.

A possible issue with Project Verify is that it puts authentication in the hands of individual carriers (who reportedly won’t share that with each other). Although this is not that dissimilar to how users can already log in to some sites using their Google or Facebook IDs, it raises a question of trust.

One possible weakness is the process for onboarding users, or when they change handsets or SIMs, typically done in-store or by call centres. Criminals will surely target this link in the chain, which is why Project Verify prospects will require this layer of checking to be tightened up.


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

Blockchain hustler beats the house with smart contract hack

A wily hacker has scored a thousand dollar cryptocurrency jackpot – 24 times – by using their own code to tamper with a smart contract run by a betting company on the EOS blockchain.

EOS is a blockchain-based cryptocurrency launched by Block.one, and it is a competitor to the more established Ethereum.

Unlike Bitcoin, which uses a blockchain to record the transfer of digital currency, EOS and Ethereum both enable people to run computer programs. These programs are called smart contracts, and instead of running in one place they run on many computers connected to the blockchain.

Smart contracts can do similar things to more conventional programs on the regular internet. They can run ecommerce sites, digital currency exchanges, and games. In this case, a Maltese company called DEOS Games was using the EOS blockchain to run a gambling game.

Customers send a quantity of the EOS cryptocurrency over the network to DEOS smart contracts running Lotto, Blackjack or Roulette. A smart contract processes the bet, and if the customer wins, it sends them their winnings and their original stake.

These blockchain betting shops use cryptographic techniques to prove that the contracts are fair and that they’re not just taking your money. In fact, DEOS goes so far as to promise “no house advantage”. That couldn’t have been more true in the case of runningsnail.

Runningsnail is an EOS user who figured out a way to hack a DEOS smart contract, and thanks to the wonder of the EOS block explorer – a system that lets people see transactions on its blockchain – the internet got a front row seat.

On 9 September, the user’s account shows several small transactions in which DEOS Games sent winnings to runningsnail, beginning at 6:24am west coast time. These continued for a few minutes, culminating in a transaction of 16.4 EOS at 6:32am. This was just a warm-up before the fun really started.

Shortly afterward came a series of similar transaction exchanges. Runningsnail would transfer 10 EOS to thedeosgames, and would promptly receive 197 EOS in winnings. This happened 24 times, for a grand total of 4728 EOS, not including the first few exploratory transactions. Given the price of EOS at the time of the heist – around $5.13 – that means runningsnail stole about $24,250.

DEOS Games confirmed the hack the next day:

This highlights a problem with smart contracts. Unlike other software, which deals with symbols representing money, the data that they send around the network is actually money. When it’s sent, no bank has to follow up and settle it later. It’s gone, whisked off to someone’s anonymous account – whoosh – and you don’t get it back. So the stakes are high when dealing with security flaws in smart contracts.

Runningsnail’s smart contract interacted with the DEOS Games contract, but included malicious code that made the DEOS contract do something it shouldn’t.

This isn’t the first time that hackers have used one smart contract to attack another.

The most famous hack hit the Decentralized Autonomous Organization (DAO), a company set up in 2016 to function entirely using smart contracts which would handle all the back office tasks normally taken care of by lawyers and admins. People bought tokens based on the Ethereum network’s cryptocurrency, Ether, that gave them the right to vote as part of the DAO, enabling them to vote to fund different entrepreneurial projects.

Unfortunately, someone exploited a series of vulnerabilities in the smart contract and siphoned off around $55m in Ether into another address. This posed a crisis for Ethereum, which ended up having to break a cardinal blockchain rule and commit to a hard fork so that it could invalidate the transaction. This effectively rolled back transactions on its blockchain, as though they had never happened.

Blockchains are supposed to be immutable, and playing God in this way is a big deal. It split the community, and some people were so sore about it that they set up Ethereum Classic, another version of the network that didn’t acknowledge the hard fork.

There have been many more smart contract exploits since – all easily trackable via block explorers. However, while you can see the hacks taking place, you can’t easily link the account name to who’s behind them. It’s like watching someone rob a bank in disguise and not being able to do a thing about it.

Programming is hard, and programming smart contracts is no exception. Expect to see a lot of this sort of thing in these early days of blockchain-based applications.


 

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/EKRyVjZLp-o/

Kernel sanders: Webroot vuln creates route to root Macs

Details of a locally exploitable but kernel-level flaw in Webroot’s SecureAnywhere macOS security software were revealed yesterday, months after the bug was patched.

panic

Webroot antivirus goes bananas, starts trashing Windows system files

READ MORE

The fact that the memory corruption bug (CVE-2018-16962) is locally exploitable limited its utility to black hats. If it was the only tool in their kit, it would be of little use to your average bad guy. The hacker would have to be either already logged into a vulnerable Mac themselves or have passed the point where they had already tricked a logged-in user into opening an exploit through social engineering or some other ruse.

That said, anyone who managed to successfully exploit the Mac security software bug would be able to execute malware at the “kernel level”, or deeper than root.

It also gives fodder to those who are inclined to argue that security software actually increases the attack surface of computers.

According to researchers who uncovered the flaw at Trustwave, it stemmed from the blind trust of one form of user-supplied input. An arbitrary user-supplied pointer can be “read from and potentially written to”, they said.

This created the potential for a local privilege escalation attack under certain conditions. A would-be hacker could also have found a means to bypass KASLR (kernel address space layout randomisation, operating system-defined memory protection) on the versions of OSX/macOS supported by SecureAnywhere.

Webroot resolved this vulnerability with version 9.0.8.34 and above for SecureAnywhere for MacOS. In a statement, Webroot said:

The security of our customers is of paramount importance to Webroot. This vulnerability was remedied in software version 9.0.8.34 which has been available for our customers since July 24, 2018. We have no evidence of any compromises from this vulnerability.

For any user running a version of Mac not currently supported by Apple (OS 10.8 or lower), we recommend upgrading to an Apple-supported version to receive our updated agent and be in line with cybersecurity best practices on system patching.

The flaw was fixed months ago but Trustwave only published its take on the bug it discovered. Questioned about this delay, Trustwave offered the following justification:

“It is important that the details of our research are accurate and in order. Vendors at times issue a patch faster than we post full details on findings. We often provide users with more time to apply the patch before we release technical details about a vulnerability.” ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/09/14/webroot_macos_vuln/

You’ll never guess what you can do once you steal a laptop, reflash the BIOS, and reboot it

Video If you can steal someone’s laptop, leave it switched on in sleep mode, crack it open, hook up some electronics to alter settings in the BIOS firmware, restart it and boot into a custom program… you can swipe crypto keys and other secrets from the system.

When computers are restarted, the motherboard firmware can wipe the RAM clean to remove any lingering data. It is possible to, while a stolen machine is still in sleep mode, reprogram the firmware’s settings to disable this memory zero’ing, and then reboot it into a custom operating system on a USB stick or similar that then scans the RAM for any sensitive information. This information can be used to decrypt encrypted hard drives, and so on.

Whether or not it’s easier than smacking the laptop owner with a two-by-four until they give up their login password is, well, an exercise left to our more sociopathic readers.

F-Secure’s Olle Segerdahl and Pasi Saarinen this week detailed their memory-slurping technique, effectively bringing cold boot attacks out of the deep freeze from 2008 and putting them back into play. The pair reckon the approach will work against nearly all modern laptops, including Apple Macs.

The hack is tricky, though once mastered, it can be replicated on any purloined machine. Below is a video demo’ing the attack.

Youtube Video

F-Secure shared its research with Microsoft, Intel, and Apple. The security biz helped the Windows maker update its guidance on Bitlocker to mitigate against this type of data theft. According to Cupertino, Macs fitted with an Apple T2 chip are not at risk, and older machines can be protected by setting a firmware password.

Chilling reality of cold boot attacks [source: F-Secure]

Cold boot attack variant might be used to steal encryption keys from laptops

“It takes some extra steps compared to the classic cold boot attack, but it’s effective against all the modern laptops we’ve tested. And since this type of threat is primarily relevant in scenarios where devices are stolen or illicitly obtained, it’s the kind of thing an attacker will have plenty of time to execute,” explained Segerdahl, principal security consultant at F-Secure.

“A quick response that invalidates access credentials will make stolen laptops less valuable to attackers,“ he added.

F-Secure further advises companies to configure laptops so that hackers attempting this or similar variants of cold boot attacks will be left with nothing to steal:

Olle and Pasi recommend that IT departments configure all company computers to either shut down or hibernate (not enter sleep mode) and require users to enter their Bitlocker PIN whenever they power up or restore their computers. This is especially important for company executives (or other employees with access to sensitive info) and employees that travel (who are more likely to leave their laptops in hotel rooms, taxi cabs, restaurants, or airports).

An attacker could still perform a successful cold boot attack against machines configured like this. But encryption keys aren’t stored in the RAM when a machine hibernates or shuts down. So there’s no valuable info for an attacker to steal.

Segerdahl and Saarinenare are due to present their research at the SEC-T conference in Sweden this week, and at Microsoft’s BlueHat v18 in the US on September 27. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/09/14/cold_boot_attack_reloaded/

Browser security hole on Macs and iPhones – just how bad is it?

We’ve seen quite a few articles out there telling you to Beware! if you use the Safari browser, because Attackers Can Spoof URLs!

This sounds like a serious issue, worthy of the boldfaced exclamation points we’ve used above, and here’s why.

A spoofed URL is where the address bar at the top of your browser shows a website name that is deliberately and misleadingly different from the web page displayed in the browser itself.

That’s not supposed to happen.

The content served up by a website can display pretty much anything it wants in the main browser window, including fraudulent text and other people’s logos, but the address bar itself is supposed to be sacrosanct.

By carefully keeping the address bar under its own control, your browser aims to help you spot bogus content.

Crooks can present you with a fake bank login page, for example, but they can’t rewrite the address bar to claim that the site really is your bank’s – at least, they’re not supposed to be able to.

In fact, if you take a careful look at the address bar before you enter personal data, you’ll be able to detect and avoid the vast majority of phishing attacks, because the address bar is the one part of your browsing experience that the crooks can’t easily manipulate.

Because of this, these widespread warnings about an unpatched URL spoofing hole in Safari piqued our interest, and we decided to dig into the story a bit.

Safari may be a minority desktop browser these days – it’s only available on the Mac, where it faces stiff competition from Google Chrome and Mozilla Firefox – but it’s widely used on the iPhone and iPad, where it’s the default, pre-installed system browser.

The bug turns out to be a really simple one, and here’s how it works.

Imagine you have a simple web page like this, hosted at the site ns.example:

A visitor will see something like this, with the website name clearly denoted in the address bar:

If we add some scripting, we can load our content first, and then tell the browser to jump to a new page using the JavaScript location.assign() function.

Here, we’re redirecting to the web page other.test immediately after displaying the “here is some content” text:

As you can see, when the location.assign happens, the browser correctly updates the address bar with the name of the new location, other.test:

But if we tweak the URL to which we’re redirecting so that it specifies a bogus network port (HTTP servers use port 80 by default; HTTPS uses port 443), the browser will try to connect to a port that isn’t listening, and after a fairly lengthy timeout period, will report an error.

In Firefox, for instance, you won’t see anything misleading while the browser is waiting for the location.assign, but after it’s tried and failed you’ll see the new location in the address bar plus an error message in the main window:

So far, so good.

But Safari’s bug is that it updates the address bar as soon as the redirect attempt starts, showing the name of the new website, but leaving the old content visible in the main window until the redirect fails.

For a minute or more, therefore, you’ll see content from ns.example but an address bar identifier saying that the site’s name is other.test:

It turns out that Safari won’t let you type anything into the web form shown above while the location.assign() function is trying to do the redirect, so even though you can click the [Submit] button, you can’t directly leak any data thinking you’re on a different website.

A crook could, however, present a JavaScript dialog that asked for input, such as a login password, and your input would end up getting sent to the original website (ns.example) rather than to the site declared in the address bar (other.test).

There you have it: URL spoofing.

On an iPhone, the bug is a bit more troublesome – to save space on the screen, mobile Safari shows only the website name, without the telltale text :8000 (or whatever the port number is) at the end:

Sure, you might not pay attention to the bogus port number even if it were displayed, but it is a handy giveaway in the desktop version of Safari.

What to do?

According to the researcher who reported this flaw, both Edge and Safari used to have this “display new URL’s name before the content is ready” bug, but Microsoft patched Edge back in August.

Edge now behaves like Firefox: while the ns.example content is on the screen, the address bar shows ns.example; only after the browser has tried and failed will the new URL be shown, at the same time that the error message pops up.

Apple, however, hasn’t yet changed the behaviour of Safari. (We’re wondering if the soon-to-be-released iOS will quietly include a fix for this?)

You can spot this spoofing trick, however, even on the mobile version of Safari where the giveaway port number is suppressed:

  • The thin blue progress line under the address bar stops moving half-way. This shows that the page named in the address bar hasn’t actually loaded yet, so it’s a useful indicator that the address bar denotes what’s still to come, not what is currently on the screen.
  • There’s no padlock in the address bar. The redirect isn’t going to succeed because the URL is dud, so Safari can’t display an HTTPS certificate because there isn’t one, and never will be.

You really ought to be looking out for the HTTPS padlock these days, even for sites where you don’t intend to login or fill in any forms.

A plain old HTTP site is just too easy for crooks to impersonate, so our recommendation is to stay away from non-HTTPS content entirely – a precaution that will handily protect you in this case, too.


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

Former Detroit IT boss sent down 20 months for bathroom bung bonanza

The former head of IT for the US city of Detroit will spend the next 20 months behind bars for taking bribes while he was in office.

Charles Dodd had served as director of the city’s Departmental Technology Services (DTS) from 2014 to 2016, during which time he bagged nearly $30,000 in bungs from tech companies. He pleaded guilty to one count of federal bribery back in 2016, but was only formally sentenced on Tuesday this week.

Dodd, a long-time city employee, admitted to taking payments from potential contractors as far back as 2009. In exchange, he would use his influence to push the city to award lucrative service contracts to his benefactors.

“Dodd held numerous supervisory positions with the City of Detroit, culminating with his appointment as Director of DTS in 2014,” the DOJ said in announcing the 20-month prison term.

Detroit skyline

City of Detroit’s IT boss took payola from tech suppliers, now faces jail

READ MORE

“In those positions, Dodd exercised supervisory authority over a staff of dozens of city employees and contractors, and held substantial influence over the administration of multi-million-dollar contracts between the City of Detroit and private information technology companies.”

One of those making the payments was Parimal Mehta of FutureNet Group. Mehta, who also copped to bribery charges, said that he would often slip Dodd envelopes of cash in restaurant bathrooms during lunch meetings.

In addition to the roughly $15,000 in cash payments over seven years ($6,500 of that while Dodd was running the DTS), Mehta said that he also paid for a trip for Dodd to North Carolina, gifted him expensive bottles of Cognac and arranged jobs at FutureNet for members of Dodd’s family.

In exchange, Mehta was given inside information about the city’s IT budget and the inside track on being awarded multi-million dollar contracts to provide services for various city departments. A second, unnamed company, was said to have paid Dodds around $14,500 in cash in a similar arrangement.

On top of the 20 months behind bars, Dodds will be he also face two years of supervised release and an $8,500 asset forfeiture. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/09/13/detroit_bribe_sandal/