Hacker's ramblings

Yes!

The best-ever time sink is out again!

I'm a huge fan of the GT-series, have been that since the first Gran Turismo was published for PlayStation in 1997. Because the PSX doesn't support racing wheels, I played the game with a NeGcon-controller. Most of you have never heard of it, because it supported only PSX and was discontinued around the time when PS2 was released in year 2000. PS2 has USB-port, which made generic USB 1.1 wheels available to PlayStation/Gran Turismo -world too. NeGcon is one of the weirdest game controllers anybody has ever seen. Its like a normal game controller with swivel in the middle. Twisting the controller makes it possible to act as a steering wheel. It also had three analog buttons in it making throttle and break control reasonable accurate for race gaming.

Fast forward trough GTs 2-6 to GT Sport, which is the latest, best, brighest and first GT for a PS4. The controller I'm using on my PS4 Pro is a Logitech G29, but I'd definitely like to give my NeGcon a go, if the game would support it somehow. Now I'm wasting space for a Wheel Stand Pro, a NeGcon wouldn't require that!

Of course I have to put some miles to my GT Sport, so, not much happening here in my blogosphere.

Half a year back I posted about moving to Sweden. I built network and router setup to gain access to The Net. One of the obvious use cases for a connection is to playback various streaming media services. I have touced the subject of configuring Squid for YLE Areena earlier.

As an ex-patriate, I like to see and hear some of the media services I've used to consuming in Finland. Those stupid distribution agreements  make that unnecessarily difficult.

Spec

With my current setup, I need to access services:

• directly: Using no fancy routing, direct out of my Swedish IP-address. It's faster and less error-prone. This is majority of my HTTP-traffic.
• from Finland: To access geo-IP blocked services from a Finnish IP. I have my own server there and I'm running Squid on it.
• from my VPN-provider: To access selected geo-IP blocked services from a country of my choosing

Of course I can go to my browser settings and manually change settings to achieve any of those three, but what if I want to access all of them simultaneously? To get that, I started browsing Squid configuration directive reference. Unfortunately that is what it says, a reference manual. Some understanding about the subject would be needed for a reference manual to be useful.

Getting the facts

Luckily I have access to Safari Books Online. From that I found an on-line book called Squid: The Definitive Guide:

That has an useful chapter in it about configuring a Squid to talk to other Squids forming a hierarchy:

© for above excerpt: O'Reilly Media

Now I familiarized myself with Squid configuration directives like: cache_peer, cache_peer_access and always_direct.
... but. Having the book, reading it, reading the man-pages and lot of googling around left me puzzled. In the wild-wild-net there is lot of stumble/fall-situations and most people simply won't get the thing working and those who did, didn't configure their setup like I wanted to use it.

Darn! Yet again: if you want to get something done, you must figure it out by yourself. (again!)

Desired state

This is a digaram what I wanted to have:

Implementation

But how to get there? I kept stumbing with always_direct allow never and never_direct allow always -permutations while trying to declare some kind of ACLs or groupings which URLs should be processed by which proxy.

After tons and tons of failure & retry & fail again -loops, I got it right! This is my home (Sweden) proxy config targeting the two other Squids to break out of geo-IP -jail:

# 1) Define cache hierarchy
# Declare peers to whom redirect traffic to.
cache_peer proxy-us.vpnsecure.me parent 8080 0 no-query no-digest name=vpnsecure login=-me-here!-:-my-password-here!-
cache_peer my.own.server parent 3128 0 no-query no-digest name=mybox default

# 2) Define media URLs
# These URLs will be redirected to one of the peers.
acl media_usanetwork dstdomain www.usanetwork.com www.ipaddress.com
acl media_netflix dstdomain .netflix.com
acl media_yle dstdomain .yle.fi areenapmdfin-a.akamaihd.net yletv-lh.akamaihd.net .kaltura.com www.ip-adress.com
acl media_ruutu dstdomain ruutu.fi geoblock.nmxbapi.fi
acl media_katsomo dstdomain .katsomo.fi
acl media_cmore dstdomain cmore.fi

# 3) Pair media URLs and their destination peers.
# Everything not mentioned here goes directly out of this Squid.
cache_peer_access vpnsecure allow media_usanetwork
cache_peer_access vpnsecure allow media_netflix
cache_peer_access mybox allow media_yle
cache_peer_access mybox allow media_ruutu
cache_peer_access mybox allow media_katsomo
cache_peer_access mybox allow media_cmore
never_direct allow media_usanetwork
never_direct allow media_yle
never_direct allow media_ruutu
never_direct allow media_katsomo
never_direct allow media_cmore
never_direct allow media_netflix

# 4) end. Done!
request_header_access X-Forwarded-For deny all

Simple, isn't it!
Nope. Not really.

Notes / Explanation

Noteworthy issues from above config:

• On my web browser, I configure it to use the home proxy for all traffic. That simply makes my life easy. All traffic goes trough there and my local Squid makes the decisions what and where to go next, or not.
• In above configuration:
  • I declare two peers (cache_peer), how and where to access them.
  • I declare ACLs by URL's destination domain (acl dstdomain). It's fast and easy!
  • I associate ACLs with peers (cache_peer_access) to get HTTP-routing
  • I make sure, that any traffic destined to be routed, does not exit directly from Sweden (never_direct allow). Slipping with that will be disastrous for geo-IP checks!
  • I don't declare my traffic to be originating from a HTTP-proxy (request_header_access X-Forwarded-For deny). Some media services follow up to the real client-address and do their geo-IP checks on that.
• The VPN-service, I'm using is VPNSecure or VPN.S as they like to be called nowadays. Two reasons:
  1. No mandatory softare installation needed. You can just configure your browser to use their proxy with proxy authentication. And if you are using Google Chrome as your browser, there is an VPN.S extension for super easy configuration!
  2. Price. It's very competitive. You don't have to pay the list prices. Look around and you can get ridiculous discounts on their announces list prices.
• My Finnish proxy is just out-of-the-box Squid with ACLs allowing my primary proxy to access it via Internet. Other than default settings, has request_header_access X-Forwarded-For deny in it.
• For testing my setup, I'm using following display-your-IP-address -services:
  • https://www.ipaddress.com/
  • https://www.ip-adress.com/
  • http://whatismyipaddress.com/
• Finnish services C More and MTV Katsomo are pretty much the same thing, share user accounts and in future are merging more and more. To have C More working, both ACLs need to declared.
• YLE Areena is using Akamai CDN extensively and they tend to change.
• Ruutu is using external service for geo-IP for added accuracy. They compare the results and assume the worst! Redirecting both is necessary to keep their checks happy.
• Netflix is using their own state-of-the-art CDN, which is very easy to configure. Regardless what Mr. Hastings publicly, they only care that the monthly recurring credit card payment passes. Using different countries for Netflix produces surprising results for availability of content.

Finally

This is working nicely!

Now moving from one media service to another is seamless and they can run simultaneously. Not that I typically would be watching two or more at the same time, but ... if I wanted to, I could!

Mathy Vanhoef and Frank Piessens are both decorated security researchers from KU Leuven, Belgium. On an otherwise slow Sunday, 15th October 2017 Alex Hudson dropped a bombshell: Mr. Vanhoef and Mr. Piessens figured out a way to bend the authentication envelope, making WPA2 broken. Authors coined this as a Key Reinstallation AttaCK. Whaat?! Darn!

Looks like the release was planned carefully. OpenBSD had the fix on 1st March 2017. That's over 6 months earlier. Also Microsoft had a whiff of this flaw in the early phase as they managed to release a patch already. The complete vendor list can be seen @ cert.org. Its a sad read, that.

The information is at https://github.com/kristate/krackinfo and contains a very simple message:

Unless a known patch has been applied, assume that all WPA2 enabled Wi-fi devices are vulnerable.

Ok, that sounds really bad. To cut all the FUD and blah blah out, what's the big deal?

• This is a Wi-Fi client attack
  • Explanation: The entire KRACK thing works by spoofing as your router to your client. After the attacker manages to lure your laptop or cell phone into connecting to a fake network, it acts as a man-in-the-middle reading your transmissions.
  • You cannot hide your network information. If you transmit or read transmissions, somebody can read that. That's the bad part about radio transmissions, they travel to everyone.
  • The only way to hide your radio transmissions is to turn Wi-Fi off.
• Anybody attacking YOU needs to be in same physical area than you
  • Explanation: A random guy from The Net cannot attack you. They need to travel to where you are.
• Regardless of what, attacker will not gain your WPA password
  • Explanation: This attack is about fooling your laptop/cell phone/refridgerator to talk to a malicious wireless router. It does not extract your Wi-Fi network password while doing it.
  • So, this is almost as bad as the WEP weakness back in 2001. In that particular incident any random body could just crack their way to your network by figuring out what your password is. And then it was possible to read any captured past or future transmission. KRACK works only forwards, your historical transmissions are safe.
• If you are using TKIP or don't know if you are using it - you're doomed!
  • Explanation: TKIP, or Temporal Key Integrity Protocol is weak anyway. You shouldn't be using that in the first place!
• If you are using Android or Linux - you're most certainly doomed!
  • Explanation: The implementation in Linux (Android is a Linux, you know) is especially flawed! Attacker has easy means of forcing any client to fake router and then force your encryption key to something the attacker can predict, thus being able to read your traffic in real-time or introduce new data packets and spoof them to originating from your Linux/Android. That's bad, really bad!
• If you are not using Linux, and are using AES-encryption - you're doomed!
  • Explanation: Yes, if attacker can lure you to use the faked router, your transmissions can be read.
  • Examples of non-Linux clients include, but are not limited to: Windows, macOS, iOS.
• My router has Linux or I got my router free when I got my Internet connection and I don't know what operating system it has - you're doomed!
  • Explanation: This is not about your router. This is about attacker faking to be your router. Your router won't be attacked, but attacker will spoof traffic to it.
• If a random attacker can read all my traffic and can inject new transmissions spoofing as you, is that bad?
  • Explanation: Yes it is. Attacker can attempt to stop you from using SSL/TLS and there are number of scenarios where that can happen, so all your precious passwords, credit card numbers and other secrets can leak. However, there are number of scenarios where that is not possible. Still, if attacker has your encrypted traffic, other means of decrypting it exist.

As you can see from the above list, there are quite a few scenarios which end you in the 'you're doomed!' -state. So, assume that you are or will be!

The relevant question remains: Is there anything that can be done?
Answer is: Not really

Just wish/pray that your particular vendor releases fixed firmware sometimes soon. Most Android vendors won't.

Somebody at Apple really knows how to confuse users. I'm looking at Wikipedia article List of Apple operating systems:

• OS X Yosemite - 10.10
• OS X El Capitan - 10.11
• macOS Sierra - 10.12
• macOS High Sierra (Not to be confused with Sierra) - 10.13

Well ... too late! I'm already confused. Why the hell they had to use the same name again. To keep me confused, I guess the next macOS will be Low Sierra?

Further details about the creation process can be found from my previous blog post about macOS Sierra, here.

Get macOS High Sierra installer

Go to your Mac's app store, it should be there clearly visible. Start the installation and wait for the download to complete.

Option 1: Create your USB-stick from command line

You can always create your USB-stick from Terminal, as I've descibed in my previous posts:

Prepare USB-stick:
$ sudo diskutil partitionDisk /dev/disk9 1 GPT jhfs+ "macOS High Sierra" 0b
...
/dev/disk9 (external, physical):
  #:                  TYPE NAME               SIZE     IDENTIFIER
  0: GUID_partition_scheme                   *30.8 GB  disk9
  1:                   EFI EFI                209.7 MB disk9s1
  2:             Apple_HFS macOS High Sierra  30.4 GB  disk9s2

Create installation media:
$ cd /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/
$ sudo ./createinstallmedia \
  --volume /Volumes/macOS\ High\ Sierra/ \
  --applicationpath /Applications/Install\ macOS\ High\ Sierra.app/ \
  --nointeraction

Option 2: Create your USB-stick with GUI app

Many people shy away from Terminal window and think the above (simple) commands are too complex. There is a nice solution for those people: DiskMaker X 7.

Download the .dmg, install the app and kick it on. You should see something like this:

Next question is about type of disk to create (choose USB) and which USB to use:

Then get past couple of warnings. Yes, you are about to destroy all data on the USB-stick:

The actual process will take a while and during the creation, plenty of notifications will flash on your sccreen:

At this point, you're done:

After the long wait is over, your USB-stick is ready to go!

Go upgrade your macs

With your fresh USB-stick, you can continue the installation to any of your Macs.

Meanwhile, check What's new in High Sierra @ Apple.

Troubleshooting

I lost the High Sierra installation files, where can I get them?

Yup, that happened to me too. I had my Macs upgraded, but was requested to do a favor. Obviously my USB-stick was already overwritten with a Linux-image and I had to re-do the process. But whattahell!? The image files were gone! Only old OS X files were remaining. So, looks like after a successful upgrade, this one cleans up its own mess.

To re-load the installation, go to app store, search for "macos high sierra":

After the lenghty (re-)download, the installed will kick on:

Like always, that's your que to quit the installer:

Done!

Finally

As the pre-released information from Apple indicated, the "upgrade" is kind of letdown. It really doesn't provide much important stuff. The most critical update is the new APFS filesystem. This is a no-brainer, as HFS+ is nearing its 20 year mark. Like ext2 filesystem on Linux (ext3, ext4), HFS+ had its upgrades, but now its simply time to break free into something completely different.

After upgrade, I took a look at the partitions.

MacBook Pro, SSD, encrypted:

$ diskutil list
/dev/disk0 (internal, physical):
   #:                  TYPE NAME             SIZE       IDENTIFIER
   0: GUID_partition_scheme                 *251.0 GB   disk0
   1:                   EFI EFI              209.7 MB   disk0s1
   2:            Apple_APFS Container disk1  250.1 GB   disk0s2

/dev/disk1 (synthesized):
   #:                  TYPE NAME             SIZE       IDENTIFIER
   0: APFS Container Scheme -               +250.1 GB   disk1
                            Physical Store disk0s2
   1:           APFS Volume Macintosh HD     156.0 GB   disk1s1
   2:           APFS Volume Preboot          20.6 MB    disk1s2
   3:           APFS Volume Recovery         520.0 MB   disk1s3
   4:           APFS Volume VM               2.1 GB     disk1s4

On the pysical disk note the APFS container. On the synthesized disk, note how all macOS partitions have APFS type in them.

iMac, fusion drive,  no encryption:

$ diskutil list
/dev/disk0 (internal, physical):
 #:                  TYPE NAME          SIZE     IDENTIFIER
 0: GUID_partition_scheme              *121.3 GB disk0
 1:                   EFI EFI           209.7 MB disk0s1
 2:     Apple_CoreStorage Macintosh HD  121.0 GB disk0s2
 3:            Apple_Boot Boot OS X     134.2 MB disk0s3

/dev/disk1 (internal, physical):
 #:                  TYPE NAME          SIZE     IDENTIFIER
 0: GUID_partition_scheme              *1.0 TB   disk1
 1:                   EFI EFI           209.7 MB disk1s1
 2:     Apple_CoreStorage Macintosh HD  999.3 GB disk1s2
 3:            Apple_Boot Recovery HD   650.1 MB disk1s3

/dev/disk2 (internal, virtual):
 #:                  TYPE NAME          SIZE     IDENTIFIER
 0:             Apple_HFS Macintosh HD +1.1 TB   disk2
                          Logical Volume on disk0s2, disk1s2
                               Unencrypted Fusion Drive

As announced, fusion drives won't have APFS yet. In the partition info, SSD and spinning platter are nicely displayed separately, forming a virtual drive.

Worthless update or not, now its done. Like a true apple-biter, I have my gadgets running the latest stuff!

In Finland and Sweden, all major movie theaters are owned by Bridgepoint Advisers Limited. In Finland, the client-facing business is called Finnkino.

Since they run majority of all viewings of moving pictures, they also sell the tickets for them. When a superbly popular movie opens for ticket sales, the initial flood happens online. What Finnkino is well known is their inability to do capacity planning for online services. Fine examples of incidents where their ability to process online transactions was greatly impaired:

• 2015: Star Wars: The Force Awakens 
• 2016: Rogue One: A Star Wars Story
• 2017: Star Wars: The Last Jedi

The sales of movie tickets happens trough their website. I'd estimate, that 100% of their sales, either eletronic or physical points-of-sale, is done via their sales software. The system they're using is MCS, or MARKUS Cinema System, which according to their website "can be deployed both on premise and on Microsoft Azure". Out of those two options, guess which mode of deployment Finnkino chose!

Quick analysis indicates, that their site is running on their own /28 IPv4 network. Nice!
Based on eyewitness reports, their entire system is heavily targeted to serve the local points-of-sale, which were up and running, but both their online sales and vending machines were down. So, I'm speculating, that  their inability to do proper capacity planning is fully intentional. They choose to throw away the excess requests, keep serving people waiting in queue for the tickets and sell the tickets to avid fans later. That way they won't have to make heavy investments to their own hardware. And they escape from this nicely by apologizing in Twitter: "We're sorry (again)." And that's it. Done!

Hint to IT-staff of Finnkino: Consider cloud and/or hybrid-cloud options.