This Week In Security: Terrapin, Seized Unseized, And Autospill

There’s a new SSH vulnerability, Terrapin (pdf paper), and it’s got the potential to be nasty — but only in an extremely limited circumstance. To understand the problem, we have to understand what SSH is designed to do. It replaces telnet as a tool to get a command line shell on a remote computer. Telnet send all that text in the clear, but SSH wraps it all inside a public-key encrypted tunnel. It was designed to safely negotiate an unfriendly network, which is why SSH clients are so explicit about accepting new keys, and alerting when a key has changed.

SSH uses a sequence counter to detect Man-in-the-Middle (MitM) shenanigans like packet deletion, replay, or reordering. That sequence isn’t actually included in the packet, but is used as part of the Message Authentication Check (MAC) of several encryption modes. This means that if a packet is removed from the encrypted tunnel, the MAC fails on the rest of the packets, triggering a complete connection reset. This sequence actually starts at zero, with the first unencrypted packet sent after the version banners are exchanged. In theory, this means that an attacker fiddling with packets in the pre-encryption phase will invalidate the entire connection as well. There’s just one problem.

The innovation from the Terrapin researchers is that an attacker with MitM access to the connection can insert a number of benign messages in the pre-encryption phase, and then silently drop the first number of messages in the encrypted phase. Just a little TCP sequence rewriting for any messages between, and neither the server nor client can detect the deception. It’s a really interesting trick — but what can we do with it?

For most SSH implementations, not much. The 9.6 release of OpenSSH addresses the bug, calling it cryptographically novel, but noting that the actual impact is limited to disabling some of the timing obfuscation features added to release 9.5.

Continue reading “This Week In Security: Terrapin, Seized Unseized, And Autospill”

Phishing With Morse Code

All of us have seen our share of phishing emails, but there are a lot more that get caught by secure email gateways and client filters. Threat actors are constantly coming up with new ways to get past these virtual gatekeepers. [BleepingComputer] investigated a new phishing attack that used some old tricks by hiding the malicious script tags as morse code.

The phishing attack targets Microsoft account login credentials with an HTML page posing as an Excel invoice. When opened, it asks the user to re-enter their credentials before viewing the document. Some external scripts are required to render the fake invoice and login window but would be detected if the links were included normally. Instead, the actor encoded the script links using dots and dashes, for example, “.-” equals “a”. A simple function (creatively named “decodeMorse”) is used to decode and inject the scripts when it runs in the victim’s browser.

Of course, this sort of attack is easy to avoid with the basic precautions we are all familiar with, like not opening suspicious attachments and carefully inspecting URLs. The code used in this attack is simple enough to be used in a tutorial on JavaScript arrays, but it was good enough to slip past a few large company’s filters.

Phishing attacks are probably not going to stop anytime soon, so if you’re bored, you could go phishing for phishers, or write some scripts to flood them with fake information.

Give A Man A Phish, And You Entertain Him For A Day

With millions of phishing attempts happening daily, we’ve probably all had our fair share of coming across one. For the trained or naturally suspicious eye, it’s usually easy to spot them — maybe get a good chuckle out of the ridiculously bad ones along the way — and simply ignore them. Unfortunately, they wouldn’t exist if they weren’t successful enough in the big picture, so it might be a good idea to inform the targeted service about the attempt, in hopes they will notify users to act with caution. And then there’s [Christian Haschek], who decided to have some fun and trying to render the phished data useless by simply flooding it with garbage.

After his wife received a text message from “their bank”, [Christian] took a closer look at the URL it was pointing to, and found your typical copy of the real login form at a slightly misspelled address. As the usual goal is to steal the victim’s credentials, he simply wrote a shell script that sends random generated account numbers and PINs for all eternity via cURL, potentially lowering any value the attackers could get from their attempt.

As the form fields limit the input length of the account number and PIN, he eventually wondered if the server side will do the same, or whether it would crash if longer data is sent to it. Sadly, he’ll never know, because after he modified the script, the site itself returned a 404 and had disappeared.

In the quest against phishing attacks, this should count as a success, but as [Christian] seemed to enjoy himself, he yearned for more and decided to take a look at a similar attempt he saw mentioned earlier on Reddit. Despite targeting the same bank, the server-side implementation was more sophisticated, hinting at a different attack, and he definitely got his money worth this time — but we don’t want to give it all away here.

Rest assured, [Christian Haschek] continues the good fight, whether by annoying attackers as he did with ZIP-bombing random WordPress login attempts or battling child pornography with a Raspberry Pi cluster. Well, unless he’s busy hunting down an unidentified device hooked up in his own network.

(Banner image by Tumisu)

This Week In Security: Zoom (Really This Time), Fingerprints, And Bloatware

You were promised Zoom news last week, but due to a late night of writing, that story was delayed to this week. So what’s the deal with Zoom? Google, SpaceX, and even the government of Taiwan and the US Senate have banned Zoom. You may remember our coverage of Zoom from nearly a year ago, when Apple forcibly removed the Zoom service from countless machines. The realities of COVID-19 have brought about an explosion of popularity for Zoom, but also a renewed critical eye on the platform’s security.

“Zoombombing”, joining a Zoom meeting uninvited, made national headlines as a result of a few high profile incidents. The US DOJ even released a statement about it. Those incidents seem to have been a result of Zoom default settings: no meeting passwords, no “waiting room”, and meeting IDs that persist indefinitely. A troll could simply search google for Zoom links, and try connecting to them until finding an active meeting. Ars ran a great article on how to avoid getting zoombombed (thanks to Sheldon for pointing this out last week).

There is another wrinkle to the Zoom story. Zoom is technically an American company, but its Chinese roots put it in a precarious situation. Recently it’s been reported that encryption keying is routed through infrastructure in China, even though the calling parties are elsewhere. In some cases, call data itself goes through Chinese infrastructure, though that was labeled as a temporary bug. Zoom was also advertising its meetings as having end-to-end encryption. That claim was investigated, and discovered to be false. All meetings get decrypted at Zoom servers, and could theoretically be viewed by Zoom staff. Continue reading “This Week In Security: Zoom (Really This Time), Fingerprints, And Bloatware”

Social Engineering Is On The Rise: Protect Yourself Now

As Internet security has evolved it has gotten easier to lock your systems down. Many products come out of the box pre-configured to include decent security practices, and most of the popular online services have wised up about encryption and password storage. That’s not to say that things are perfect, but as the computer systems get tougher to crack, the bad guys will focus more on the unpatchable system in the mix — the human element.

History Repeats Itself

Ever since the days of the ancient Greeks, and probably before that, social engineering has been one option to get around your enemy’s defences. We all know the old tale of Ulysses using a giant wooden horse to trick the Trojans into allowing a small army into the city of Troy. They left the horse outside the city walls after a failed five-year siege, and the Trojans brought it in. Once inside the city walls a small army climbed out in the dead of night and captured the city.

How different is it to leave a USB flash drive loaded with malware around a large company’s car park, waiting for human curiosity to take over and an employee to plug the device into a computer hooked up to the corporate network? Both the wooden horse and the USB drive trick have one thing in common, humans are not perfect and make decisions which can be irrational. Continue reading “Social Engineering Is On The Rise: Protect Yourself Now”

You Think You Can’t Be Phished?

Well, think again. At least if you are using Chrome or Firefox. Don’t believe us? Well, check out Apple new website then, at https://www.apple.com . Notice anything? If you are not using an affected browser you are just seeing a strange URL after opening the webpage, otherwise it’s pretty legit. This is a page to demonstrate a type of Unicode vulnerability in how the browser interprets and show the URL to the user. Notice the valid HTTPS. Of course the domain is not from Apple, it is actually the domain: “https://www.xn--80ak6aa92e.com/“. If you open the page, you can see the actual URL by right-clicking and select view-source.

So what’s going on? This type of phishing attack, known as IDN homograph attacks, relies on the fact that the browser, in this case Chrome or Firefox, interprets the “xn--” prefix in a URL as an ASCII compatible encoding prefix. It is called Punycode and it’s a way to represent Unicode using only the ASCII characters used in Internet host names. Imagine a sort of Base64 for domains. This allows for domains with international characters to be registered, for example, the domain “xn--s7y.co” is equivalent to “短.co”, as [Xudong Zheng] explains in his blog.

Different alphabets have different glyphs that work in this kinds of attacks. Take the Cyrillic alphabet, it contains 11 lowercase glyphs that are identical or nearly identical to Latin counterparts. These class of attacks, where an attacker replaces one letter for its counterpart is widely known and are usually mitigated by the browser:

Continue reading “You Think You Can’t Be Phished?”

Shmoocon 2016: Phishing For The Phishers

After years of ignoring the emails it’s finally time to get into a conversation with that Nigerian prince you keep hearing from. Robbie Gallagher — an Application Security Engineer with Atlassian in Austin, TX — wanted to find out where perpetrators of phishing emails actually live. Of course you can’t count on the headers of the emails they send you. A better way to track them down is to actually draw them into a conversations, and this means making yourself a juicy target.

Robbie gave an excellent talk on his project Honey-Phish at this year’s Shmoocon. Part of what made it stand out is his narrative on each step of exploring the social engineering technique. For instance, there is already a vibrant community that specializes in forming relationships with scammers. Those who frequent 419 Eater have literally made it into a sport called Scambaiting. The ultimate goal is to prove you’ve baited a scammer is to get the person to take a picture of themselves balancing something on their head. Now the image a the top of this post makes sense, right?

Writing personal emails to your scammer is a great system if you have a lot of time and only want to track down one scammer at a time. Robbie wants to catalog geographic locations for as many as possible and this means automation. Amusingly, the solution is to Phish for Phishers. By automating responses to phishing emails, and enticing the people originating those phishing scams to click on a link, you can ascertain their physical location.

Continue reading “Shmoocon 2016: Phishing For The Phishers”