morethankradio

T’is the season to be backposting 🎅

“Improve your security skills, and then show them off!” 🤔

I’d like to take this,

chance to wow [you] with... [my] ability to correctly crack ciphers.

Specifically Puzzle Baron’s substitution ciphers. As you can see, not only can I correctly crack these ciphers, but after some astute training in early June, I am now able to crack them in Above Average time 😉

ETAOIN SHRDLU and two letter words aside, I’m pretty sure the fastest way to crack these is to Google the quote author 😅

May have become too dependent on the puzzle cracking tooling provided by Mr. Baron as it was significantly harder to get out the quote in the midsem without letter frequency suggestions.

Okay, we’ve seen more than a few attacks that can be performed when someone clicks a link or navigates to a website.

Cryptojacking

Cross Site Request Forgery

Drive-By Attacks

Zoom 0day

But it’s time to pay homage to the attack that’s hidden in plain site. 

tldr; head over to https://fingerprintme.herokuapp.com/ for some fun.

Passive Data Theft

I hesitate to call it theft when in fact we are giving all of this data to every website we visit like a little gift. 

Please, accept this bundle of quasi-identifiers as a token of my appreciation.

Many internet users have no idea just how much data is available to websites they are visiting, so it’s worth exploring just what is in our present.

IP Address and Geolocation API

Like any good gift giver, we better write on the tag. 

To: <website server> From: <your IP address>

Your IP (Internet Protocol) address is a little 32-bit (now possibly 128-bit) number that uniquely identifies your device on the Internet. This is by design; people need to be able to address you to be able to send you any packets. A static 1:1 mapping of devices to IPs is definitely a massive exaggeration today as as we use technologies to let multiple devices share one IP, dynamically acquire an IP for each session, and our ISPs (Internet Service Providers) may also dynamically assign our IP address.

Nonetheless, IP addresses have (again by design) another function; location addressing. This is because when you’re internet traffic is propagating through the Internet (a global network of routers) it needs to know where it physically needs to go, and fast. Owing to this, the internet has taken on a hierarchical structure, with different ISPs servicing different geographical regions. These ISPs are tiered such that lower tier ISPs service specific subsets of the upper level tier’s region, providing more geographical specificity. It is this property of IP addresses that allows anyone with your IP address to get a rough idea where you are in the world. Moreover, IP addresses from specific subnets like AARNet (for Australian Universities) can be a giveaway for your location.

Try Googling “my ip” or “where am i”. There are many IP to Geolocation API services available. I have made use of https://ipgeolocation.io/, which has a generous free tier 🙏.

User Agent

Every request your browser makes to a server is wrapped up with a nice little UserAgent String bow, that looks a little like this,

User-Agent: Mozilla/<version> (<system-information>) <platform> (<platform-details>) <extensions>

Oh how sweet 😊 it’s our Operating System, our browser and what versions we of each we are running, and if the server is lucky, perhaps a few extra details.

Here are a few examples from MDN:

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0

Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Why might this be a problem? Allow me to direct you towards my earlier post on Drive-By Attacks. Vulnerabilities are often present in specific versions of specific platforms. If an exploit server detects that your particular version of Chrome for Windows (for example) has a known vulnerability, well then prepare to be infected. 

Navigator

Okay, I think we’ve been polite enough, it’s time to rip this packaging open! Ooh what is this inside? It’s an invitation to our browser of course! 

When we send off a request to a web server complete with our IP and User Agent string, the web server will typically respond by sending us a web page to render. These days a web page can be anything from a single HTML file with a few verses from a dead poet, to a fully fledged JavaScript application. To support this development, browsers are exposing more and more functionality/system information through a special JavaScript interface called Navigator.

From MDN,

The Navigator interface represents the state and the identity of the user agent. It allows scripts to query it and to register themselves to carry on some activities.

...to carry on some activities... I wonder. The list of available properties and methods is pretty comprehensive so I’ll just point out a few interesting ones.

getBattery() (have only seen this on chrome)

connection (some details about your network connection)

hardwareConcurrency (for multithreading)

plugins (another important vector for Drive-Bys)

storage (persisted storage available to websites)

clipboard (requires permissions, goodness plz be careful)

doNotTrack (i wonder who checks this...)

vibrate() (because haptic is the only real feedback)

While I’ve got it in mind, here’s a wonderful browser localStorage vulnerability I stumbled across https://github.com/feross/filldisk.com. There’s a 10MB per site limit, but no browser is enforcing this quota across both a.something.com and b.something.com...

I have no idea why Chrome thinks it’s useful to expose your battery status to every website you visit... Personally, the clipboard API feels the most violating. It requires permissions, but once given you’re never asked again. Control/Command + V right now and see what’s on your clipboard. I doubt there’s many web pages that you’d actually want to be able to read your clipboard every time you visit.

Social Media Side Channel / CSRF

Okay, now we’re getting a little cheeky. It’s actually possible to determine if a browser has an authenticated session with a bunch of social media platforms and services.

It’s a well known vulnerability (have a laughcry at some of the socials responses), which abuses the redirect on login functionality we see on many of these platforms, as well as the Same-Origin Policy SOP being relaxed around HTML tags, as we saw was sometimes exploited by Cross Site Request Forgery attacks.

Consider this lovely image tag.

<img src="https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Ffavicon.ico%3F_rdr%3Dp">

As you can see, the image source (at least originally) doesn’t point to an image at all, but rather the Facebook login page. Thanks to SOP, we wouldn’t and shouldn’t be able to send an AJAX request to this website and see the response. But this HTML image tag is going to fire off a GET request for it’s source no problem. 

Thanks to redirect on login, if a user rocks up to the login page with the correct session cookies then we won’t have them login again, but rather we redirect them to their newsfeed; or, as it turns out, whatever the URL parameter next points to. What if we point it to an actual image, say the website icon, such that the HTML image tag loads if we are redirected, and fails if not.

Simple but effective. You can try it for yourself here, by opening my codepen in your browser when you’re signed in to Facebook, and when you’re signed out (or just use Incognito).

Fingerprint Me v1.0

Okay, time for a demonstration. I took the liberty of writing my own web page that pulls all this data together, and rather than store it for a rainy day (like every other page on the web),  I present it to the user on a little web dashboard. It’s like a mirror for your browser. And who doesn’t like to check themselves out in the mirror from time to time 🙃

Random technical content: I had to fetch the geolocation data server-side to protect my API key from the client, then I sneak it back into the static HTML web page I’m serving to the user by setting it on the window variable in some inline script tags.

I bust out some React experience, and have something looking pretty (pretty scary I hope) in some nondescript amount of time (time knows no sink like frontend webdev). I rub my hands together grinning to myself, and send it off to some friends.

“Very scary”. I can see straight through the thin veil of their encouragement and instead read “Yeaaaah okay”. One of them admits that they actually missed the point when they first looked at it. But.. but... nevermind. It’s clearly not having the intended effect. These guys are pretty Internet savvy, but I feel like this should be disconcerting for even the most well seasoned web user... 

Like that moment you lock eyes with yourself in the mirror after forgetting to shave a few days in a row.

Fingerprint Me v2.0

An inspired moment follows. I trace it back to the week ?7 activity class on privacy:

It is very hard to make a case for privacy. What is the inherent value of privacy? Why shouldn’t the government have our data, we give it to a million services everyday anyway, and receive a wealth of benefits for it. Go on, have it. I wasn’t using it for anything anyway. 

It is very easy to make a case for privacy, if there is any sense that someone malicious is involved. As soon as there is someone who would wish us ill it becomes obvious that there are things that the less they know the better. 

<Enter great The Art of War quote here.>

~ Sun Tzu

Therein lies the solution. I need to make the user feel victimised. And what better to do it than a green on black terminal with someone that calls themselves a hacker rooting your machine.

DO CLICK THIS LINK (it’s very safe, I promise) https://fingerprintme.herokuapp.com

Some more random technical content: Programming this quite synchronous behaviour in the very async-centric JavaScript was quite a pain. It was particularly tricky to get around the fact that React renders it’s component hierarchy top down, so I needed the parent components to mount empty in order for them to be correctly populated with child components later. It was also a pain to access and render child components conditionally, especially if you want to have sets of child components in different files, as though they aren’t ultimately nested in the DOM, React will treat them as if they are.

Some User Reviews:

“It feels like I should shut the window”

“This is SO RUDE”

“Battery level. I mean. Literally. How.”

Excellent.

Recommendations

Know what’s in your present, and who you’re gifting it to 🎁

To protect your IP address/location consider using a VPN or ToR

Check out NoScript, a browser plugin that will block JavaScript by default, but allow you to enable it for trusted sites.

Holy moly, this is spicy 🌶. A prime example of how third party integrations add additional attack vectors to link clicking / website based attacks.

A security engineer at Gradle has found a vulnerability in Zoom’s Mac client and everything about it is just so convenience vs. security.

There are many facets to examine here, but the short of it is that any website can forcibly pull a Mac Zoom user (or ex. Mac  Zoom user... more on this) into a video conference complete with their webcam enabled.

💻 🎥 🙃🙃🙃🙃🙃🙃🙃🙃🙃

If you’re not familiar, Zoom is a massive online video conferencing platform that only just had it’s IPO in April this year, valuing at a whopping $17 billion. What Zoom does best is convenience; to quote them,

“Instant sharing.” 

“Meeting face to face is as simple as a single touch.

In order to join a zoom conference, a user need only click a single link like https://zoom.us/j/123456789, which will launch the Zoom Client and pull the user straight into the meeting. This kind of convenience is what sets Zoom apart from its competitors. Intrigued by this functionality, the security engineer started to probe for how it was implemented and... goodness me. 

When a Zoom link, like https://zoom.us/j/conference_id, is clicked... the browser requests the web page there and renders it (no black magic yet 😉). Among other things (idk i haven’t seen it) the web page has a few images on it... except these aren’t just any images (okay black magic inbound 🧙‍♂️),

<img src="http://localhost:19421/launch?action=join&confno=123456789"/>

The images have been given a localhost source... It turns out that Zoom actually runs a web server on your local machine; it just sits there spinning at http://localhost:19421. 

Well that’s never going to work right?? I’ve run little web servers on localhost before, and I’ve never considered that other websites could load my images from them. What about the Same Origin Policy? Keep me safe my sweet little browser sandbox.

The thing is, this doesn’t really look like it’s loading an image at all but rather just some sort of command. Why aren’t they just making an AJAX GET request? I’m not sure about the specifics here but it seems that they’ve tried to use CORS to allow their site to talk to the server, only to find CORS unsupported on localhost. Using an image tag is a workaround for this, perhaps like the way we use images and forms in CSRF.

The best part is that the local server responds to requests with status and error codes by setting the dimensions of the image to predefined values 🌶. The security engineer found the mapping of dimensions to codes in the web page’s code, which revealed that launch is just the beginning. There are also 

client download

client install

client version checks 

commands, as well as a bunch of error codes relating to these.

This is what I hinted at before. Where the user has uninstalled the Zoom client but failed to stop the local server, the Zoom website is capable of re-installing the Zoom client via the local server’s strange API.

Except it’s not just the zoom website... because CORS has been circumvented, any website could launch the client by just including these image tags.

Moreover, Zoom, in offering the utmost convenience to their users, provides an option for meeting hosts to have their participants enter the meeting with their webcam enabled.

Together this is something of a nightmare for Mac Zoom users. Any web page they visit, or as we’ve learned, any advertisement displayed on any web page they visit, could at any moment pull them face-first into a video chat.

Recommendation

https://mashable.com/2018/01/17/webcam-covers-buy-sliding-stickers-internet-privacy/

You can also check out the link below for options to disable this functionality and purge your computer of Zoom’s local web server.

Wrap Up

It’s an excellent story and a very real example of convenience vs. privacy. It is also interesting to explore Zoom’s attitudes and response towards the vulnerability.

To be fair this is probably one of the most benign link/website based attacks...

You’ll find it dressed up like this in media releases like this,

“Right now, your computer might be using its memory and processor power – and your electricity – to generate money for someone else, without you ever knowing. It’s called ‘cryptojacking’...”

~ The Conversation

And that is exactly true. To be fair, there have been some nasty trojan desktop cryptojacking software that will run in the background all day and night, but in the context of websites, it’s for the duration in which you have the web page open and once closed there’s really no harm done. To toy with some innocuous phrasing, it’s basically the most fun an attacker can have in your sandbox. 

When we visit a website, our browser receives HTML and CSS files to render the web page and JS files to run. It’s reasonable for us to presume that these JS files will be doing the processing required to make the web page more interesting, and useful, but really there’s nothing to stop someone sending you a JavaScript file that says 

while(true);

What’s that going to do? Well this code is running in YOUR browser, so it’s going to waste YOUR precious clock cycles and in this case probably crash the tab... 😈😈😈 

A far more inspired person realised that there is another computationally intensive operation that they could send you, that could actually make them money... not satellite image processing, not calculating primes, but mining cryptocurrency!

This all came about in the last couple of years. September 2017 marked the release of Coinhive, a service that allowed websites to serve a JavaScript based Monero miner to their visitors to generate revenue. This was with all of the right intentions, with hopes that mining could be a less invasive alternative to the advertising currently financing many free web services, or even to finance charities like UNICEF.

But ?of course there were issues. It has proven difficult to effectively throttle the mining process, particularly when being performed by multiple sites, resulting in degrading performance for users. Some sites that did not disclose their latest revenue raising techniques which broke user trust. But the most malicious cases have to do with malvertising, and script insertion. This was rampant for a time, with someone going so far as planting a cryptojacking script on the Make-A-Wish foundation page...

Recommendations

Check your CPU usage with your system’s process monitor (Window’s Task Manager, Mac’s Activity Monitor, or even Chrome’s Task Manager).

Download one of the many browser extensions that block cryptocurrency mining scripts including No Coin, minerBlock or AdBlockPlus.

Then check out https://cryptojackingtest.com/, a fun little website from the Opera team that tries to load a mining script to see if you’re protected.

But if it’s UNICEF, then maybe think about letting that one just run.

Real World Examples

[2018] Make-A-Wish, through Drupal vulnerability

[2018] Nova Scotia university, network shutdown for 4 days.

Perhaps you’ve heard of the infamous Cross-Site Scripting (XSS) exploit, where an attacker injects a script into a website through an unsanitised user input. The idea is that if this user input is for some user generated content like a comment that is then displayed on the site, then this script will be run by future visitors. 

Today we’re going to take a look at the (possibly, I’m not quite sure yet) related Cross-Site Request Forgery (CSRF or XSRF for consistency) attack. Wikipedia says,

...unlike XSS, which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. 

I’ve also just discovered another seemingly related attack Cross-Site History Manipulation (XSHM), and so at this point I really want to know what is this Cross-Site (XS) business all about. If you google for the keywords “Cross-Site” you just turn up a heap of XSS related content, but thankfully the OWASP site on XSHM mentions a Same Origin Policy (SOP) that it claims is 

...the most important security concept of modern browsers.

Well then… let’s start there.

Same-Origin Policy (SOP)

Wikipedia paraphrased again,

A browser permits scripts contained in a web page to access data in a second web page, but only if both web pages have the same origin (read: url[1]).

Malicious scripts on one page, can’t access sensitive data (including HTTP cookies) on another web page through that page’s Document Object Model (DOM) or global JavaScript object. We’re trying to achieve client-side separation of content provided by unrelated sites. It only applies to scripts, and not images, CSS and dynamically loaded scripts (OH OKAY, was wondering how CDNs work...). Apparently CSRF exploits the fact that the same origin policy does not apply to HTML tags? Really? Okay?

Why Do We Need SOP?

A user has just finished an online banking session and leaves the site without logging out. This likely means that whatever was being used to authenticate the user’s requests to the bank’s servers (let’s say session cookies) is still around in the users browser. The user then goes to another site which sends them a JavaScript file to run in their browser. JavaScript is a Turing complete language, which is essentially capable of doing anything a user can do in a browser. What happens when that script decides to revisit the bank website and craft a few new transactions to someone. Note that the script doesn’t need direct access to the session cookies to use them. Since the script is running in the user’s browser, any requests it makes to the banks site will be automatically equipped with the relevant session cookies for that site. This is what the Same Origin Policy is meant to prevent. Simply, we say that if the script isn’t from the bank’s site, then we won’t allow it to do things the user could do on the bank’s site.

Cross-Site Request Forgery

Okay then, so now that web pages from different origins cannot communicate with each other thanks to SOP, let’s get back to CSRF; or by it’s cooler names, Sea Surfing/Session Riding. Believe it or not, Cross-Site Request Forgery, is centered around a forged request. Specifically a request is made from the user’s browser to a server with which a user is authenticated. The request arrives with the appropriate session cookies, and the server is none the wiser that this request was not the user’s intention.

How is this request made?

The simplest way… you guessed it, a link click. Give the user a disguised link that fires off a GET request to the server the user is authenticated with. Importantly, to do anything meaningful here, we need that server is using GET parameters to allow the user to perform some state changes. If your bank’s server is accepting requests like this, it’s most definitely time to get a new bank...

GET http://bigbank.com/transfer?acct=AttackerA&amount=$100 HTTP/1.1

Can we do this automatically with JavaScript? Well we know the SOP prevents this script from accessing data on other origins. But there’s a very ambiguous word here, access. To my best knowledge, SOP will prevent the script reading data returned from other origins, but doesn’t necessarily prevent the request itself! So a GET request fired from JavaScript will nonetheless have the desired effect, even if the script can’t read the response.

Okay, but what self respecting server is going to let the user do anything meaningful with a GET request. This leads us back to “CSRF exploits the fact that the same origin policy does not apply to HTML tags”. There is in fact an HTML tag that is very capable of making POST requests, an HTML form. Moreover, JavaScript is perfectly capable of submitting a form on behalf of a user. Once again, SOP prevents the script from reading the response, but does that matter when the server has gone ahead and made the transfer… no.

This is a take-home point, CSRF specifically attacks changes in state because it can’t see the response.

Recommendations

As a user, the recommendations look a lot like all my other posts with one notable emboldened suggestion:

Check your links before you click them.

Avoid manually typing URLs into your browser.

Sign-out of authenticated applications before browsing the internet.

The last is, of course, not something that anyone but the most cautious internet user will actually do in the age of convenience. So let’s just hope that applications have taken it upon themselves to defend against CSRF attacks. The most common approach to this is to use a CSRF token. This token is cleverly hidden in the cross-site script unreadable DOM (thanks SOP) and alongside the relevant session cookies, is required in sensitive requests from the user.

Real World Examples

[2006] Netflix, way back when, “adding a DVD to the victim's rental queue, changing the shipping address on the account, or altering the victim's login credentials.”

[2008] ING Direct, “open additional accounts on behalf of a user and transfer funds from a user's account to the attacker's account.”

[2015] MyBB, “adding administrator user”.

This week’s activity class was something of a debate, albeit a little hard to debate in teams of nine. I was blessed with a spot in the pro privacy team... I thought. But when it comes down to it, it turns out that it is quite hard to pinpoint the value of privacy.

First things first, let’s consider that,

The government needs data to prevent terrorism and crime. 

To which we questioned whether you can prove effectiveness? Current systems have a high rate of false positives to which we can either respond by picking-up more people incorrectly, wasting time and resources. Or we calibrate to be not very sensitive, at the risk of missing legitimate targets. Type I/II Errors again. We tend to optimise for the latter, but the issue is that we haven’t lost our sense of security that we get from using these technologies. They make us complacent.

But there are bigger issues at play here. 

Big issue #1: Once data is collected, you can’t get rid of it. 

Big issue #2: No-one, can guarantee data security.

Even the NSA has been subject to data breaches. There was a US defense biometrics leak; you can’t just go out and change your biometrics once they’ve been compromised.

And yet these issues aren’t issues, unless I can convince you that privacy (or alternatively scoped, that only the right people having access to your data) is important. And herein lies the challenge in our post-privacy world. Because we incessantly project our data out into the public sphere, and receive a wealth of convenience and opportunity for it.

And so it is that it is hard to make a case for privacy in and of itself, until someone or something is out to get you, at which point it’s too late. 

Yet another low probability, high impact risk that we are at the mercy of our DNA to evaluate incorrectly.

Some pre-reading notes follow:

Format Strings

Look, if there’s one thing I want to take away from the lectures this week it’s format string errors.

c has a crazy way of printing information in a structured way... it’s called printf ~ gold from Richard.

Contrary to popular belief, printf’s first argument isn’t really meant to be the string you want to print. It is a format string, which tells you what to do with all the other arguments, however (and convenience trumps sense once again) non control symbols are just printed literally.

printf("%s\n","Hello world"); // intended usage printf("Hello world\n"); // real world usage

So what? 

Well format strings have a special property that is not afforded to other strings. They can demand arguments.

printf("Stack dump: %s"); // Inside printf, %s demands a string

Of course, as any proficient c programmer can see, we didn’t pass a second string argument to printf. And yet the format string demands, “GIVE ME THE STRING THAT WAS PUT ON THE STACK AFTER ME!”. The ever obedient c function printf does as it is told and yields whatever is on the stack after the format string... then it proceeds (business as usual) to print it out in ASCII until it finds an NUL terminator. 

* ASCII dump of stack acquired *

Never fear, if ASCII is not your thing then you’ve got a whole world of type interpretations to play with.

printf("%x%x%x%x%x...%x"); // print out the stack in hex

By all means, as a C programmer, you can have lots of fun with this in the privacy of your own machine. BUT PLEASE DON’T LET YOUR USERS DO THE SAME.

printf(name); // this is crazy talk if name was user input.

The icing on the poisonous cake of convenience is “%n”. This sickly sweet little argument demands a memory address to which it can write, YES WRITE, the integer count of how many characters have been written by printf so far. Whilst it is certainly challenging to use “%n” to do do something particular, we know all to well that sometimes the holes in the swiss cheese align. And when they do, let’s hope it’s not for someone malicious trying inputs into your program.

A less inspired dump of other lecture content follows:

This attack has me double guessing every link I click on right now (how long will that last 😅). The risks associated with clicking links seemed relatively benign until I discovered drive-by attacks. This class of attack is built around exploiting link clicks, browsing compromised websites, and malvertising (malware through advertising).

tldr; purge Flash and keep your everything up to date.

I have always felt pretty safe browsing the web. I thought of my browser as a little sandbox, and as long as I don’t download and open dodgy looking files or put my details into spurious web pages then I should be fine. And (to my best knowledge) for the most part this is true. But, like all software, ever, this sandbox is only as secure as the human written lines of code that it is made of, i.e. it’s not secure.

Our browsers get even less secure when we consider them as part of a bigger system. Now we depend on the security of the underlying operating system, as well as any browser extensions we add on, both of which provide additional vectors to exploit. To give you an idea of what this space looks like, check out the ever growing Common Vulnerabilities and Exposures (CVE)  list. Here’s perhaps a more relevant subset of these. Suddenly, we do not feel we’re standing on the backs of giants, but rather we’re getting piggybacked by some people on stilts.

Okay, that part was important, because we have to have a sense that we could be compromised to appreciate the (low-probability but high impact) risk of a drive-by attack. Now let’s look at the anatomy of a drive-by attack. 

Heimdal Security propose 9 steps, but I’ll try distill them here:

You, as a user, unwittingly browse a compromised or malicious website.

Malicious JavaScript files are downloaded on your system.

The browser runs the infected JavaScript files, which initiate a connection with an exploit server.

An exploit kit (hosted on the exploit server) probes your operating system, web browser, browser extensions, and other software such as your pdf reader or video player, for a range of known software vulnerabilities.

On finding a vulnerability, it uses it to gain access to your PC’s functions.

With elevated privileges it may proceed to download and execute additional malware.

Gif source.

The scariest part is that this took little to no user interaction, happened incredibly quickly, and happened without the user noticing anything.

Okay, now that we’re properly scared, we offer a couple of recommendations:

Don’t use Flash. Get rid of it. Bin it. Now.

Use an established actively developed browser (for goodness sake, don’t use IE) and always keep it up to date!

Review your browser extensions. Recognise each of them for the security dependency it is, and consider whether its utility really outweighs its risks. Keep them up to date!

Review your default viewers and players. Keep them up to date!

Before we wrap up, let’s look at a few drive-bys in the wild:

[2017] Issaquah, employee visited and opened a .pdf file that had been compromised on a grant coordination site run by a non-profit.

[2013] Dalai Lama’s Chinese Site, automatically drops viruses on Windows and Macs by exploiting security bugs in Java software.

Okay, we’re starting to peel back the layers on the dangers of link clicking (or website visiting) and I’m starting to get scared 😨

Drive-By

The technique of having users connect to a server (just a link click or compromised website away) that checks for vulnerable client browsers, extensions and OSs and exploits them is known as a “drive-by” attack; presumably because you get it unknowingly as you drive by, though I more commonly associate the phrase with a hit-and-run mechanic which doesn’t seem quite right. It is a well documented, and well resourced technique; there are commercially available exploit kits for performing this kind of attack. I will post again when I have read up more on this, but a preliminary look is far from comforting.

CSRF

Next stop, Quora.

Can I get hacked only by clicking on a link without downloading anything?

Okay, so if you look past the people flexing, there’s actually some important points to take away from some of the answers here: 

When you visit any webpage, you are downloading an HTML / CSS / JS / whateverelse file that gets stored temporarily in your computer.

Of course! Any web page is really a download. The web is essentially just downloading files from remote servers...

A payload can be delivered with or without user interaction but it does require you to come in contact with the code that will begin the exploitation process. 

Well this seems about right. Browsing the internet may essentially just be be downloading files, but we’re going to have to try open the file for an exploit.

Some outdated browsers and add-ons can be exploited, otherwise it’ll require an 0day.

Aye aye aye. I think what we’re getting at here, is that in some instances, a hacker can get there code to run without requiring an opportunistic user to try open their file.

The Dalai Lama's website was recently [?two years prior, 2013] hacked. After which any person visiting the Chinese section of the site got hacked - that included people who received and clicked on a link to that site.

Doesn’t that just sound crazy? But I dug a little deeper and it checks out, 

...malicious software that automatically drops viruses on computers running Microsoft Corp’s Windows and Apple Inc’s Mac operating systems.

They infect machines by exploiting security bugs in Oracle Corp’s Java software 

Seems that some sort of Java 0day was being exploited. 

To click or not to click? Why link safety matters

This government backed article opens with the exact question I want answers to.

We often recommend that people “think before they click” on links; or “click with care” – why is that?

Yes, why is that? Wouldn’t I have to download a file, or enter some user input to be compromised in any way? What’s so dangerous about a link in itself? Surely there are some answers here. tldr; there’s not.

“Malicious links are one of the most effective delivery methods for online scams and threats like malware and ransomware”

Okay... but how?

They then proceed to make a bunch of recommendations:

Hover over links to preview them before clicking.

Use URL expanders to preview minified links.

Google for resources instead of following links to them.

Yeah, okay. But really... I can’t see myself using a URL expander if my machine was riddled with malware, let alone now. Then they come back with,

“If compromised, not only will criminals have access to your private messages and information, your social media account can also be used to further spam messages to your contacts, circumventing many of the platform’s own protection mechanisms.”

BUT HOW DO I GET COMPROMISED?

“If you click a link, always check the website you are on before you interact with it, provide any information or download software.”

This SO answer gave me a little missing perspective on buffer overflows, as I am still to work out exactly who would use them for what. So at the end of the day we can run arbitrary code on a given machine. Not something I want to do on my machine of course, as I could just as well write my own program to do it and execute it. However if we were remoting into another machine, and we had a malicious strain in our personality, we may feel empowered to be able to run arbitrary code on this machine, particularly with permissions that we are not otherwise granted.

Morning Lecture

Good friends don’t let other friends write their own cryptographic systems.  -Richard (lecturing over Skype).

In the morning lecture we were introduced to wonderful world of buffer overflows. It boils down to a few things:

Low level programming languages let us do our own memory management, yay.

Memory is everything in computing, code and control is stored and read from memory much like the rest of our data.

No where is our data closer to our control than the stack

The stack is how the OS can comfortably swap between two processes (context switching). The current state of the process is stored in a frame on the stack, and when the process is ready to run again it is popped off. 

A program which when writing to the stack, writes beyond it's stack frame, would be writing into the stack frame of the process that was interrupted before it... a stack frame which contains return addresses and all sorts of control data.

Evening Lecture

I couldn't attend the second lecture this week, but have found some great notes, thanks Andrew: https://featherbear.github.io/UNSW-COMP6441/blog/post/lec12/! 

Seminars

The first seminar was on Website Security (whoops) and looked at XSS, SQL injection, and CSRF (no idea why cross is now a C and not an X, where's the consistency...). The second seminar was on crypto, (probably less for me to learn here as I did a thesis on crypto networks).

Block Ciphers

Looks like there was a bit of discussion about block ciphers. 

Factors of Authentication

Oooh I’ve been waiting for this to come up since it came up in the Houdini case study. There are three types:

Something you know - ie password

Something you have - ie physical element

Something you are - ie biometrics

Okay, so we’ve identified some threats... what would we recommend Australia do now, to prepare for the possibility of cyberwarfare threats? (Groups again).

As it turns out, it’s quite difficult to come up with 10 sound recommendations in 20 minutes, and so much the joy of this class was hearing the 10th recommendation of any group.

Background check everybody before giving them access to the internet

Segmentation of networks (okay, this is probably a #1 on any other list)

Headhunt potential hackers

Hire Russian hackers

Ditch the entire continent

Public security initiatives

Anyway, this is what we came up with going back to the drawing board:

We’re entering cyber war with Russia, what should we be concerned about? My brainstorm:

Expect some large scale government directed attacks.

They may attempt political influence.

Social network attacks.

DoS of critical/financial infrastructure.

Destroy network infrastructure, including our transatlantic cables.

Attack our datacenters.

Company infiltration.

Bugging.