Methods to Hack an Online Account

There are many ways how an attacker gain access to our online accounts, depending on the implementation of an application, some methods work better than others:

• Session Hijacking
  • Also known as cookie stealing, where an attacker steal your cookie to gain access to your account.
• Phishing
  • This method sometimes combine with session hijacking to steal your cookies. It can be a forged Facebook site that ask you to login in order to get your password
• Password Reset
  • The intention of this feature is to recover a password that is lost, but some attackers will try to use it to gain access to your account by answering few questions, that's why it is important to set up a difficult questions and answers for recovery.
• Keyloggers
  • Unless your computer is rigged or compromised, this method is less common. A keylogger is a software or hardware that will record all your keystrokes (all the keys you typed on the keyboard).

For the sake of this article, I will only talk about the most common method (Session Hijacking) and the mistakes that many users made that got their cookies revealed.

Session Hijacking

How Sessions Worked

Once you are logged in to an online service such as Facebook or Gmail, the server will create a unique session ID that identify your account, and sends it back to your browser. Once your browser got it, it will store the session ID in the cookies.

Every time a request is sent, your browser will send the cookies back to the server. So, when someone is able to get your cookies, they can login to your account without knowing your password.

Simulating Session Hijack

I will be using Chrome as the primary demonstration here with your logged in Facebook account. It should be applicable to other browsers too:

1. Once you logged in to your Facebook account, open Chrome Developer Tools in Menu > More Tools > Developer Tools
2. From the tabs on the top, select Resources
3. On the left bar, click on Cookies dropdown and select www.facebook.com
4. Now, open a new incognito window (Menu > New Incognito Window) and go to facebook.com, it shouldn't be logged in
5. On the incognito window, open Developer Tools same as step 1, and select Console tab on the top
6. Click on the Console > prompt and enter document.cookie="c_user=<copy value from your logged in Facebook c_user cookie>"
7. Then, enter document.cookie="xs=<copy value from your logged in Facebook xs cookie>"
8. Refresh the page and Voila! You are mysteriously logged in to your Facebook account!

Here, I used Incognito tab to simulate the attack, you can however copy the cookie values of xs and c_user to another computer, and continue from step 6.

How Your Cookies are Stolen?

TCP/IP aren't designed to be secured, nobody predicted that it would grow to what it is today. It was initially designed for communication between few different computers, but the original design was improved overtime to include every single computers in the world. There are 2 ways to get your browser cookies:

1. Remotely - where an attacker try to get your browser to send the cookies to an attacker website such as using a forged login page.
2. Locally - where an attacker try to redirect all traffic to the attacker's computer (A.K.A Man-In-The-Middle attack) and a software will parse the traffic to scan for popular sites session IDs.

Remote attacks for cookie stealing are not very common, reason being that if you can forge a website, why not ask the victim for their passwords instead of stealing their cookies. It is however commonly used in spear phishing attacks, where the attacker got a designated victims and they wanted to simulate certain environments without looking suspicious.

Public WiFi is Evil

The sad truth about WiFi is that it function very similar to a hub. Yeah, it's encrypted and yes it's not easy to get WiFi encryption keys especially WPA encryption method with military grade encryption algorithms. Breaking a military grade encryption take years with brute-force, but who said anything about breaking any keys? Anyone who knows a particular "WiFi Password" literally has the key to decrypt any client's traffic within that network (WEP or WPA personal only, not for WPA enterprise). In other words, all the attacker need to do is to get connected to a particular public WiFi network, and start sniffing/capturing all traffic, AP's hub behavior makes this easy, as the router will broadcast a packet to all clients and each client will check whether the packet is destined for them and discard it if it's not.

To reduce suspicion, the attacker can choose to save the traffic into a file first, then harvest all cookie IDs from that file. Once they got the Session IDs, they gain access to the victim's account without the victim's knowledge, provided that the victim haven't logged out of their account.

SSL (HTTPS) is Not Foolproof

SSL offer traffic encryption to its users, through PKI, where a traffic is encrypted with the private key can only be decrypted with public key or vice versa, 2 keys are required to complete a cycle. Once the browser got your certificate where it contains all the essential information to communicate with the server in a secure manner, it will check with the issuer whether that certificate is really what it says it is. If something is fishy about the certificate, the browser will warn its user that the certificate is invalid. Most users will ignore the warning, because they have no idea what it is. That is how they expose their supposedly secured traffic.

How SSL Failed

When someone wanted to steal traffic from a secured site, all they need is the private key to decrypt the client's traffic, but it is only available in the server. So how they can get the private key without gaining access to the server?

One way is to create a self-signed certificate, in other words, they make themselves a CA, but since they aren't a CA recognized by the browser, the browser will still warn its user of an invalid CA. Once they created the certificate, they own a private key now.

The problem now is how to replace the original certificate with this self-signed certificate, so the attacker can decrypt their traffic? By replacing the router's ARP cache for all clients with the attacker's MAC address. So now the attacker is everyone, all traffic from the router will go to the attacker's computer.

Once the attacker got the traffic, a tool will check the traffic whether is for a targeted website, if it is, it will replace the certificate with a self-signed version and send it back to the intended client. If it isn't, it send the traffic back to its original client. That is how users' session IDs are exposed if they ignore the certificate warnings.

How to Protect Yourself from Session Hijacking and Cookie Stealing

1. Avoid public WiFi or at least avoid using public WiFi to login to your online accounts, such as Facebook
2. Always logout of your account, your session ID is only renewed when you re-login again, especially after login to any online services
3. DO NOT ignore browser warnings
4. Use a detection tool to detect if there are anything fishy in the network before using it, Blacksheep is a good tool to detect session hijacks
5. Use a VPN or TOR or anything that will encrypt your traffic before using any public WiFi

As an administrator for multiple Linux servers in various location, I find it
hard to manage port forwarding in routers, of course you can configure a
remote GUI login such as RDP and VNC but all these servers only enable
services they need with SSH as their main method of remote administration
to these servers. Then, I found out about SSH tunneling, which is a lifesaver.
There are two main method to tunnel traffic through SSH:

1. Forward a single port through SSH
2. Tunneling through SOCKS

The first method is good for temporary tunneling and the second method is good
for when you want to encrypt your traffic. So, I think first method is more
suitable to my case, but you are free to use the second method as well.

Method 1: Forward a single port through SSH

Make sure you know your router IP before you run SSH command, you can just SSH
into your remote machine to get the default using route command. After you
know your remote router IP, you can configure your tunnel using ssh command:

ssh -p [remote ssh port if changed] -L8080:[remote router IP]:80 [username]@[host]

Make sure that you fill in those variables in square brackets. After entering
your user password, you can open your browser and access your router web management
through 127.0.0.1:8080. Make sure that your firewall/iptables are not blocking port 8080.

Method 2: Tunneling through SOCKS

This method forward ports according to the port you specified in your browser
or application. However, it is more complex and usually used to encrypt your
traffic. You create a SOCKS tunnel using ssh command:

ssh -TND 4711 [username]@[host]

Make sure that you fill in those variables in square brackets. After entering
your user password, you need to configure your browser to use SOCKS proxy, you
can find more information on how to configure web browser for SOCKS proxy
here.
Once configured, you need to enter the router's IP to access the router's web
management interface.

BlueProximity is a great addition to Linux, it adds a little of extra security
for you Linux machine. For those who don't know what it is, here's an excerpt
from BlueProximity:

BlueProximity helps you add a little more security to your desktop. It does so
by detecting one of your bluetooth devices, most likely your mobile phone, and
keeping track of its distance. If you move away from your computer and the
distance is above a certain level (no measurement in meters is possible) for a
given time, it automatically locks your desktop (or starts any other shell
command you want).

Once away your computer awaits its master back - if you are nearer than a given level for a set time your computer unlocks magically without any interaction (or starts any other shell command you want).

The problem I found when configuring BlueProximity on my Linux machine is the commands, if you are on Gnome, nearly no configuration is needed, but I am on KDE 4.x. So, here's the command I used to get it working on my machine:

• Lock command: qdbus-qt4 org.kde.screensaver /ScreenSaver Lock
• Unlock command: qdbus-qt4 | grep kscreenlocker_greet | xargs -I {} qdbus-qt4 {} /MainApplication quit
• Proximity command: qdbus-qt4 org.freedesktop.ScreenSaver /ScreenSaver SimulateUserActivity

If you are not using qdbus-qt4, substitute it with qdbus.

The first I got my hands on a raspberry pi, I wanted to update its OS to the latest, but the problem is that my RPi is connected to my laptop (using OpenSuse) and I am using SSH to access it (I don't have access to any displays).

Preparation##

First, prepare your SDCard for RPi, there are plenty of resources on how to prepare your SDCard. Then, follow this guide to configure your RPi for SSH access from your machine.

IP Addressing###

For this guide, I am using the following addressing scheme:

• RPi eth0 => 192.168.10.2/24
• Laptop eth0 (connected to RPi) => 192.168.10.1/24
• Laptop wlan0 (connected to router, default gateway) => 192.168.1.6/24
• Router (Internet access) => 192.168.1.254/24

Fixing Default Gateway on my Laptop##

When I connected to my RPi, Network Manager replaced my default gateway to eth0, so I am not able to access the Internet after connected to RPi. You verify it by using route command without parameters, if the default line points to eth0, it means your default gateway is overwritten, if it's not, it means you can skip this section, you can verify it by ping-ing www.google.com. To fix this problem, I deleted the default gateway and added a new default gateway that points to my router:

$ sudo /sbin/route del default
$ sudo /sbin/route add default gw 192.168.1.254 dev wlan0

Verify that your default gateway now points to wlan0 using route command without parameters. Try to ping www.google.com to make sure that your laptop have access to the Internet, your RPi won't be able to access the Internet if your laptop does not.

Adding Default Gateway to RPi##

Using the route command add a default that points to eth0 interface:

$ sudo route add default gw 192.168.10.1 dev eth0

The Problem##

Out of the box without masquerading, once a packet sourced from 192.168.10.0/24 network (my RPi <==> laptop subnet) reaches the router on subnet 192.168.1.0/24, depends on the configuration, it will route or drop the packet. Even if the router successfully routed the packet to the Internet, it will definitely drop the packet, because it does not know where to route the packet for network 192.168.10.0/24 network. So, masquerading seems to be the only solution here.

Masquerading and Configuration##

Masquerading is like that Linux version of NAT, it translates your internal network to external network (e.g. for Internet access). What it does is that any packets bound for any network from 192.168.10.0/24 subnet will be translated to 192.168.1.0/24 subnet, so my router knows where to route my 192.168.10.0/24 packet.

Since I am using OpenSUSE, I will configure masquerading through its own firewall using YaST.

1. Open up firewall configuration in YaST and select Interfaces
2. Double click eth0 interface and change it to External Zone
3. Select Masquerading on the left and click Masquerade Networks
4. Add 80 to requested port
5. Add 192.168.1.6 (or your wlan0 IP) to Redirect to Masqueraded IP
6. Add 81 to Redirect to Port or any ports you want your traffic to be translated to, but make sure you are not using any servers on that port
7. Click Add
8. Select Startup on the left and click Save Settings and Restart Firewall Now
9. Try to ping www.google.com from your RPi, you should get be able to at this point

REFERENCES##

1. Using your desktop or laptop screen and keyboard with your Pi

I have bought a VCD movie recently to find that it was not playable on my OpenSUSE, CD2 works fine but not CD1. Then I go back for a replacement disc on the shop and came back to watch it but unfortunately, the problem persist. The problem is that CD1 comtains multiple tracks that most Mediaplayer doesn't support (tried VLC and Kaffeine). So I started to dive into the problems and found a thread that provides useful information on playing VCD on Linux (Refer to references).

Basically there are two ways to work around this problem:

1. Use MPlayer to play your disc
2. Rip your VCD using vcdxrip

1. Use MPlayer to play your dics##

MPlayer was quite new to me actually, it is launched through the console, and it is does not appear in the menu. Here is the command to play VCD using MPlayer (install if you haven't already):

mplayer vcd://<track number> -cdrom-device /dev/<your cd rom device>

Of course, you have to substitute <track number> and <your cd rom device> with the track number and your cd rom device. On my machine, it's on track 3 and my cd rom device is either dvd or sr0 (dvd is a symlink to sr0). So my complete command is:

mplayer vcd://3 -cdrom-device /dev/sr0

Refer to mplayer's manpage for controls and details: man mplayer.

2. Rip your VCD using vcdxrip##

This has not personally worked for me because it keeps stopping at certain points, it just doesn't copy the whole VCD. But it is still good to know if MPlayer does not work. The command is very easy and straight forward. Remember to change to a directory for your ripped files before executing this command:

vcdxrip -C

And there will be multiple files present on your currect directory, where you could play using VLC or whatever media player you may wish.

REFERENCES##

1. MPlayer with VCD
2. Forums discussing issues with VCDs

When I was supporting a company that uses Juniper VPN with my colleague, I found that Juniper VPN is only supported in 32-bit version of Linux (though it was supported in 64-bit Windows and Mac machine, should ask them why they don't compile it for 64-bit Linux). I have spent hours finding solution to this situation and found one particular solution that just works. Tried Mad Scientist's JNC (Juniper Network Connect) but it didn't work for some unknown reasons.

This solution is based on Dominique Leuenberger's blog on 'Juniper VPN on openSUSE x86_64', all credits goes to him/her.

Requirements##

To use Juniper VPN, JRE or JDK with web plugins is a must (Download Here), it does not work with IcedTea and openJDK. We are not using any third party solution, so we have to comply to the Juniper VPN's system requirements.

Steps##

1. Download Juniper VPN through the software provided by the company. Once the applet is loaded, it should ask you for your root/su password, just press [Enter] twice. It will create .juniper_networks in your home directory.

2. Change directory to $HOME/.juniper_networks

cd $HOME/.juniper_networks

3. Remove network_connect directory

rm -rf network_connect

4. Extract ncLinuxApp.jar

unzip ncLinuxApp.jar

5. Use ldd to find out required libraries for network_connect/libncui.so and zypper wp <library> or yum provides <library> to find out the libraries.

6. Make a binary out of the library

gcc -m32 -Wl,-rpath,`pwd` -o network_connect/ncui network_connect/libncui.so

7. Set permission and owner/group

sudo chown root:root network_connect/ncui
sudo chmod 6711 network_connect/ncui

8. Get the certificate

sh network_connect/ncui <your Juniper VPN host> <certificatename>.cer

9. Make sure that you are still logged into you VPN host, and find your DSID by browsing though your browser's cookie of your VPN site. Search for the cookie named DSID

10. Connect to Juniper VPN

network_connect/ncui -h <you Juniper VPN host> -c DSID=<value obtained in step 9> -f <certificate obtained in step 8>.cer

11. (Optional) To ease future VPN connections, copy and paste the following script to $HOME/bin/vpnConnect

#!/bin/bash

if [ $# -lt 1 ]; then
        echo -e "Usage:\t$0 <DSID>"
        echo -e "\n\tNOTE: DSID can be found in the cookie after you logged into your VPN site"
        exit 0
fi

# Connect to your VPN
~/.juniper_networks/network_connect/ncui -h <your vpn host> -c DSID=$1 -f ~/.juniper_networks/<cert from step 8>.cer

12. (Continue step 11) Add executable bit chmod +x $HOME/bin/vpnConnect

13. (To connect after step 12) Use vpnConnect <your DSID as in step 9> to connect

Alternative ways for shortening##

Personally I prefer to use a script to shorten my commands, because it allow me to specify usage notes and comments when the usage is not right, but if you are not like me, you can use Linux aliases to shorten it, refer to man alias for usage or Google it =)

REFERENCES##

1. Mad Scientist's JNC (Juniper Network Connect)
2. Dominique Leuenberger's blog on 'Juniper VPN on openSUSE x86_64'

1. Unplug or switch off your AC to your laptop
2. Enter sudo /usr/sbin/powertop in a terminal

To reduce the power consumption, I have installed laptop-mode-tools, as its name suggest, it is a tool for laptops. Once installed, I found that my wireless driver (ath5k) does not support power saving mode yet, so I have to disable it. Edit /etc/laptop-mode/ and change WIRELESS_BATT_POWER_SAVING=1 to WIRELESS_BATT_POWER_SAVING=0, this step is optional, nothing might happen if you don't do anything to it.

To enable laptop-mode:

$ sudo systemctl enable laptop-mode.service

Next, I created a custom script for laptop-mode-tools to enable certain power saving not included in laptop-mode-tools modules:

1. Edit $HOME/bin/powersaving_on and add the following lines:

#!/bin/sh

# ATI Radeon power saving
echo profile > /sys/class/drm/card0/device/power_method
echo low > /sys/class/drm/card0/device/power_profile

# Audio power saving
echo 1 > /sys/module/snd_hda_intel/parameters/power_save
echo Y > /sys/module/snd_hda_intel/parameters/power_save_controller

# Writeback time
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs

2. Edit $HOME/bin/powersaving_off and add the following lines:

#!/bin/sh

# ATI Radeon power saving
echo profile > /sys/class/drm/card0/device/power_method
echo default > /sys/class/drm/card0/device/power_profile

# Audio power saving
echo 2 > /sys/module/snd_hda_intel/parameters/power_save
echo N > /sys/module/snd_hda_intel/parameters/power_save_controller

# Writeback time
echo 500 > /proc/sys/vm/dirty_writeback_centisecs

3. Add executable bit to both scripts:

$ chmod +x $HOME/bin/powersaving_on; chmod +x $HOME/bin/powersaving_off

4. Create symbolic links for laptop-mode-tools:

$ sudo ln -s /home/<username>/bin/powersaving_on /etc/laptop-mode/batt-start/powersaving_on;\
sudo ln -s /home/<username>/bin/powersaving_on /etc/laptop-mode/lm-ac-stop/powersaving_on;\
sudo ln -s /home/<username>/bin/powersaving_off /etc/laptop-mode/batt-stop/powersaving_off;\
sudo ln -s /home/<username>/bin/powersaving_off /etc/laptop-mode/lm-ac-start/powersaving_off;\
sudo ln -s /home/<username>/bin/powersaving_off /etc/laptop-mode/nolm-ac-start/powersaving_off;\
sudo ln -s /home/<username>/bin/powersaving_off /etc/laptop-mode/nolm-ac-stop/powersaving_off

Explanation and Notes:
Step 1: Enable some powersaving features to reduce power usage (require root permission), see the script's comments. You can change echo low > /sys/class/drm/card0/device/power_profile to echo mid > /sys/class/drm/card0/device/power_profile if you need more power

Step 2: Disable powersaving features by setting all its values to default

Step 3: Make both scripts executable

Step 4: I have wrote it in a way that you can cut and paste into your terminal emulator in one step, just replace <username> with your username. laptop-mode-tools provide a way for users to execute certain scripts when on AC or battery by placing your scripts in its corresponding directories:

• /etc/laptop-mode/batt-start: Executed when laptop enters battery mode
• /etc/laptop-mode/batt-stop: Executed when laptop exits battery mode
• /etc/laptop-mode/lm-ac-start: Executed when laptop-mode is enabled AND laptop enters AC mode
• /etc/laptop-mode/lm-ac-stop: Executed when laptop-mode is enabled AND laptop exits AC mode
• /etc/laptop-mode/nolm-ac-start: Executed when laptop-mode is disabled through /etc/laptop-mode/laptop-mode.conf AND laptop enters AC mode
• /etc/laptop-mode/nolm-ac-stop: Executed when laptop-mode is disable through /etc/laptop-mode/laptop-mode.conf AND laptop exits AC mode

Other Tips:
1. Disable bluetooth: sudo rfkill block bluetooth
2. It seems that monitor used up most power (11-18 watts depending on brightness on my machine), reduce brightness to save more power
3. Another power killer is WiFi, (more than 6 watts on my machine), so turn it off if you don't use it

REFERENCES:
1. Great ArchWiki Article on Power Saving
2. ATI Radeon Power Management Guide
3. Linux Journal Article on laptop-mode-tools
4. Using ATI Radeon Power Management with laptop-mode-tools

If you have any issues to suspend your laptop e.g. suspend command doesn't work on your laptop, try changing the default sleep module to uswsusp:

1. Edit /etc/pm/config.d/module and add the following line:
   SLEEP_MODULE=uswsusp

2. Edit /etc/pm/config.d/defaults and add the following line:
   S2RAM_OPTS="-f"

3. Reboot and try to let her sleep.

References##

• OpenSuse Documentation on Suspending
• AskUbuntu Thread

When I install a Linux distro to my VAIO notebook, I found that there is an annoying bug with the lid switch. It does not get updated whenever I suspend on lid close, it means cat /proc/acpi/button/lid/LID/state will output state: close. When I close the lid again, it won't suspend, instead, it will change the state to open. So in order for it to suspend again on lid close after the first suspend, I have to close it, reopen the lid and close it again.

I have tried installing Linux Mint, Fedora, Fuduntu and Xubuntu, but it is not fixed in any of the distros. So, I don't think it is distro problems. While researching this issues (which I spent two full days), I found that Linux got an amazing feature that enable users to dynamically loading DSDT at boot time, there is no need to update the BIOS. So here's the instuctions:

1. Install iasl using yum, apt-get or whatever package management you are using.

2. Extract DSDT:

$ sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml

3. Disassemble dsdt.aml using the following command, this should create a new file dsdt.dsl:

$ iasl -d dsdt.aml

4. Compile it using:

$ iasl -tc dsdt.dsl

5. Fix any compiler errors, warnings and remarks. On my machine, the output is:

dsdt.dsl  1352:                         And (CTRL, 0x1E)
Warning  1106 -                                 ^ Result is not used, operator has no effect

dsdt.dsl  1584:                     0x00000000,         // Length
Error    4122 -                              ^ Invalid combination of Length and Min/Max fixed flags

dsdt.dsl  2443:                                 Name (_T_0, 0x00)
Remark   5111 -            Use of compiler reserved name ^  (_T_0)

dsdt.dsl  2521:                                 Name (_T_0, 0x00)
Remark   5111 -            Use of compiler reserved name ^  (_T_0)

a. The first one is on line 1352 can be fixed simply by changing And (CTRL, 0x1E) to And (CTRL, 0x1E, CTRL).

b. The second one is on line 1584, the length should be Range Maximum - Range Minimum + 1, on my machine, so fire up a hex calculator and start subtracting. On my machine, it's 0xE0000000 (0xDFFFFFFF - 0x00000000 + 0x00000001).

c. The third and fourth line is on line 2443 and 2521, because it uses a reserved name, simply replacing all instances of _T_0 to T_0 will stop the complaints. In vim, it is as simple as issuing :%s/_T_0/T_0/g in command mode.

6. Once everything is fixed (no errors, warning or remarks), add the following line to _WAK method, simply search for _WAK in dsdt.dsl:

If (LNotEqual (0x00, LIDS))
    {
        Store (0x00, LIDS)
        Notify (\_SB.LID, 0x80)
    }

NOTE 1: You might need to change \_SB.LID to match your path to LID method or on some machine LID0. Method name is preceded by an _ (underscore), so you can search for _LID in dsdt.dsl. After you found it, you have to determine the scope, scroll up until you found Scope keyword that your LID or LID0 method belongs to, inside the bracket is the scope name. It may be in more than one scope, so, it might be \_PCI0.SB.LID. If you specify an incorrect path to LID method, you will receive the following error:

dsdt.dsl   300:             Notify (LID, 0x80)
Error    4068 -                       ^ Object is not accessible from this scope (LID_)

NOTE 2: What this function does is just to update the lid state once it is resumed from sleep. According to the ACPICA documentation, _WAK method is called by AcpiLeaveSleepState() function of ACPI. If the lid is open, the LIDS variable is 0x00, or 0x01 otherwise. So these few lines translate to "if lid state is not open (closed), change lid state to open and call LID method".

7. Compile it using iasl -tc dsdt.dsl.

8. If no errors, warnings or remarks, add the following lines to /etc/grub.d/01_acpi:

# Uncomment to load custom ACPI table
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"


# DON'T MODIFY ANYTHING BELOW THIS LINE!


prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib


. /usr/share/grub/grub-mkconfig_lib
#. ${libdir}/grub/grub-mkconfig_lib


# Load custom ACPI table
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \
	&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then
    echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2
    prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/  /"
    cat << EOF
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`
EOF
fi

9. Add executable bit to it:

$ sudo chmod +x /etc/grub.d/01_acpi

10. Copy the new dsdt.aml to /boot:

$ sudo cp dsdt.aml /boot

11. Regenerate grub.cfg:

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

12. Reboot

References##

1. Archwiki on DSDT
2. Redhat's Bug Report
3. Ubuntu's Bug Report 1
4. Ubuntu's Bug Report 2
5. Somebody's blog on fixing DSDT errors, remarks and warnings
6. ACPICA Documentation

DNS settings in Linux are usually stored in /etc/resolv.conf file, you could basically just edit this file to change the DNS settings in any Linux systems. However, the change is not permanent, it will be overwritten by Network Manager when u reconnect or reboot. So, to make the change permanent, there are two methods:

• Network Manager’s dispatcher script method
• Immutable attribute method

Method 1: Network Manager’s Dispatcher Script Method

This method will just replace copy /etc/resolv.conf with /etc/resolv.conf.googledns everytime NetworkManager connect to the network.

1. Run sudo /etc/resolv.conf.googledns

2. Add the following lines, I'm using Google DNS here, you can change to any DNS you want:

    nameserver 8.8.8.8
    nameserver 8.8.4.4
   

3. Create and edit the file /etc/NetworkManager/dispatcher.d/12-dns_server and add the following line:

    sudo cp -f /etc/resolv.conf.googledns /etc/resolv.conf
   

4. Make /etc/NetworkManager/dispatcher.d/12-dns_server executable:

    sudo chmod +x /etc/NetworkManager/dispatcher.d/12-dns_server
   

5. Restart NetworkManager service: sudo systemctl restart NetworkManager

Method 2: Immutable Attribute Method

The immutable attribute is part of extended attribute added since ext2. Since resolv.conf file is automatically regenerated every time Network Manager connects, you can set the file as immutable so that it will never be replaced. You can set resolv.conf as immutable using the chattr utility as follows (Remember to edit the file and add all the DNS before setting the attribute):

sudo chattr +i /etc/resolv.conf

Whenever you wanted to change the DNS, the attribute have to be removed from the file using the following command (similar to previous command, except the +i and -i option which indicates add or remove the attribute):

sudo chattr -i /etc/resolv.conf