DEV Community: Alexandre Rousseau

Hack protected WPA/WPA2 Wi-fi

Alexandre Rousseau — Thu, 06 Aug 2020 15:42:54 +0000

I decided to hack my my new router just to try and have a fun. Spoiler : it was really easy.

So to make my tests I tried a famous Linux distribution: Kali Linux. This distribution have many pre-instaled hacking tools who help us.

I installed Kali Linux in dual-boot but you can also use it in Live USB mode or with a virtual machine like VirtualBox.

How it works

Here we will use Aircrack-ng which is an open-source software suite used to monitor wireless networks and "break" the WEP and WPA keys of Wi-fi networks. The attack will take place in several phases:

Preparation of your network card
Analysis of the Wi-fi target
Capturing a WPA handshake (a connection to the Wi-fi network) by disconnecting a device on the Wi-fi
WPA handshake password cracking by bruteforce

Preparation

The first step is to activate the monitor mode of the network card set up. To do this we list the available network cards with airmong-ng. Open a terminal and type:

airmon-ng

If your network card does not display, it is not compatible. You have to buy one (a USB Wi-fi dongle is enough).

In our case we see that we can use our wlan0 network card. So we activate the monitor mode with the following command::

airmon-ng start wlan0

From here, the network card wlan0 is no longer available (you no longer have internet), and a new network card appears. It can be found by doing an ifconfig. In my case, it is wlan0mon..

Analysis

Now we can sniff the network packets that circulate around us with airodump:

airodump-ng wlan0mon

This command will find additional information on Wi-fi including:

the BSSID
the CHannel
the AUTH, the mode of authentication
the ESSID, the name of the router

Among all the lines, my network appears. Remember to write down the information as it will be useful to us.

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 18:D6:C7:85:7E:A0  -45        6        0    0   2  54e  WPA2 CCMP   PSK  TP-LINK_7EA0

Capturing a WPA handshake

A WPA handshake takes place when a device is connected to the Wi-fi. Our goal is to capture one in order to recover the encrypted password.

sniff the Wi-fi and wait for a device to connect to the Wi-fi
sniff the Wi-fi and cause a disconnection and wait for the device to reconnect

In order to test, I will disconnect my Blackberry already connected to it.

Wi-fi Scan

So we scan the network with the airodump-ng command and options:

-c options to specify the channel
--bssid, my router's ID.
w the directory where the output files will be stored

airodump-ng -c 10 --bssid 18:D6:C7:85:7E:A0 -w tplink  wlan0mon

We leave this command in the background, it will produce 3 files, one of which is of type xml. This is the one we are interested in because it contains more details about the devices connected to the wi-fi. By opening this one, we can find very easily the information of my Blackberry. Here is an extract of the file:

<client-mac>94:EB:CD:25:E0:C1</client-mac>
<client-manuf>BlackBerry RTS</client-manuf>

Disconnection

Now that we have all the information, we will send a packet that will request disconnection of my Blackberry. We use aireplay-ng with the parameters:

-0 to send a de-authentication signal.
-a To the BSSID of our Wi-fi.
-c The BSSID of the target
the network card used

aireplay-ng -0 2 -a 18:D6:C7:85:7E:A0 -c 94:EB:CD:25:E0:C1 wlan0mon

The device disconnects and reconnects automatically. The result is a WPA Handshake which is contained in the tplink.cpa file.

Cracking

Now that we have obtained a packet containing the encrypted WPA password, we just have to test several combinations until we find a matching one: this is called a bruteforce.

the dictionary

To find a password we need... passwords! You can find multi-gigabyte text files of the most commonly used passwords. In my case, I know that the password of my Wi-fi contains 8 digits. So I'm going to use the crunch command to generate all the possible combinations. crunch uses several parameters:

the minimum length (8)
the maximum length (8)
the characters to be used (0123...9)

We're sending it all in a passwords.txt file.

crunch 8 8 12345678 > passwords.txt

In a few seconds we get a file of 43046721 lines weighing 369 MB!!!!

The bruteforce

We're taking action. Here we're going to brute force the password. To do this we use aircrack-ng which will encrypt the passwords one by one and check if it matches the password of the network packet we captured (Get yourself a coffee as it can be long).

To do this we use aircrack-ng.

aircrack-ng -a2 -b 18:D6:C7:85:7E:A0 -w /root/Desktop/passwords.txt /root/Desktop/tplink.cap

And after a while::

Conclusion

Through this little test we see that it is very easy to "crack" a Wi-fi with a WPA password. The tools at our disposal are easy to access and no specific hardware is required. However by applying some simple rules we can avoid this kind of risk.

Remember, the password used was only 8 numeric characters. The number of combinations fit into a 380 MB file. If the password had included alphabetic characters, the dictionary would have exceeded the terabyte. The bruteforce would certainly have lasted several weeks.

So by applying a more complex password, we reduce the risk. By changing it regularly, it is not possible to crack the combination quickly enough.

Furthermore it is possible to adapt the wi-fi signal so that it is not visible in the whole building.

As soon as possible, use the Ethernet cable, which is still the most secure solution.

Deploy a fullstack application on Google Cloud Plateform with Gitlab CI

Alexandre Rousseau — Thu, 06 Aug 2020 08:14:05 +0000

I deployed a Fullstack application (i.e. Frontend / Backend) on Google Cloud Platform with Kubernetes. And since developers are lazy, I automated everything with Gitlab CI.

It's a far cry from PHP deployed by hand on an Apache server. If you're interested in moving up a gear and see how it works, read on.

My application

My project I'm currently working on is divided into three parts: Frontend, Backend, Job Queue.

Each part runs in separate containers Docker. So they all have a `Dockerfile':

the frontend uses a Node.js image that builds Angular 9 and then a NGINX image that serves the static files
the backend uses a Node.js image that launches a web server on port 3000
the job_queue also uses a Node.js image that launches a Node.js script that communicates with the Postgres database and performs offline actions.

So my project has the following structure:

├── backend ├── docker ├── docker-compose.yml └── frontend

So I wanted to build these images automatically during a git push and publish it on Google Cloud Platform with Kubernetes. For this, I used Gitlab CI but the logic must be identical with Github's Circle CI.

The Postgres database is independent of Kubernetes and runs on a [Google Cloud SQL for PostgreSQL] service (https://cloud.google.com/sql/docs/postgres). I won't talk about it here..

Automation with Gitlab CI

Gitlab allows you to define a workflow of things to do when you push code through a .gitlab-ci.yml file. This is often useful for launching a pipeline (a sequence of actions) that will run unit tests, linter code, etc...
`
In my case, I created the following actions :

`test': launch unit tests
publish: creation of a Docker image and publication in the GCloud's private image registry
deploy: tells the GCloud to deploy the images previously uploaded.

So the structure of the `.gitlab-ci.yml' file looks like this:

# .gitlab-ci.yml
# ...
stages: [test, publish, deploy]

job:test:backend:
  stage: test
  # ...

job:publish:backend:
  stage: publish
  # ...

job:deploy-develop:backend:
  stage: deploy
  # ...

I only kept the jobs that involve "backend" to simplify.

I'll walk you through the steps. Here we go.

`test`: running unit tests

This is the easiest step. I won't spend too much time on it because a lot of tutorials exist and that's not the subject of this article.

So we start two jobs:

job:test:backend will initialize the application, connect a Postgres database and run yarn test.


job:test:backend:
  stage: test
  services:
    - postgres:12.3-alpine
  variables:
    POSTGRES_DB: database
    POSTGRES_USER: user
    POSTGRES_PASSWORD: password
    POSTGRES_HOST_AUTH_METHOD: trust
  before_script:
    - cd backend
    - cp .example.env .env
    - yarn install
  script: yarn test

job:test:frontend will initialize the application and run yarn test but from an image containing a Chrome driver to emulate navigation.

job:test:frontend:
  image: weboaks/node-karma-protractor-chrome:alpine
  stage: test
  before_script:
    - cd frontend
    - yarn install
  script: yarn test

There you go.

`publish`: creating a Docker image and publishing it in the private image registry of the GCloud.

The publish step will build docker images of the different applications and publish them to GCloud - Container Registry. To do this, we will create a job for each image to be published (frontend, backend and worker).

In order to build the images and publish them, we need to use:

the image google/cloud-sdk which allows to communicate with GCloud and publish the images.
the [Docker-in-Docker] service (https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-workflow-with-docker-executor) which allows you to use Docker commands in a Docker container.

It is then possible to use the :

gcloud auth to connect to Gcloud in the container.
gcloud auth configure-docker to connect Docker to GCloud
docker buil/push to create the image and publish it

One last thing to know: to connect to the GCloud in Gitlab CI, you must first log in. To do so, you need to add the GCloud credentials in the Gitlab CI settings in the "Settings > Variables" section. Once this is done, it is possible to log into the job using the following command:

echo $GCLOUD_SERVICE_KEY > ${HOME}/gcloud-service-key.json
gcloud auth activate-service-account --key-file ${HOME}/gcloud-service-key.json

Bellow the final result for job:publish:backend :

job:publish:backend:
  stage: publish
  image: google/cloud-sdk:latest
  when: on_success
  services:
    - docker:dind
  tags:
    - dind
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - cd backend
    - cp .develop.env .env
    - echo $GCLOUD_SERVICE_KEY > ${HOME}/gcloud-service-key.json
    - gcloud auth activate-service-account --key-file ${HOME}/gcloud-service-key.json
    - gcloud auth configure-docker
  script:
    - docker build --compress -t us.gcr.io/${PROJECT_NAME}/${APP_NAME}-backend:${CI_COMMIT_SHA} .
    - docker push us.gcr.io/${PROJECT_NAME}/${APP_NAME}-backend:${CI_COMMIT_SHA}
    - docker image rm -f us.gcr.io/${PROJECT_NAME}/${APP_NAME}-backend:${CI_COMMIT_SHA}
    - echo "us.gcr.io/${PROJECT_NAME}/${APP_NAME}-backend:${CI_COMMIT_SHA} image build with success and pushed"

I skip over the details of the other two because they're very similar.

`deploy`: ask GCloud to deploy the images previously uploaded.

To use kubectl we will also use the google/cloud-sdk image which contains the Kubernetes utility.

But before we start coding the script, we need to create three deployment :

dpl-my-app-frontend on https://my-app/
dpl-my-app-backend at https://api.my-app/.
dpl-my-app-worker that is not exposed

To create them, you can use the GCloud interface or use kubectl directly on your PC (don't forget to configure cluster access for kubectl).

For the command line version, use kubectl create deployment :

kubectl create deployment dpl-develop-data-frontend --image=us.gcr.io/mazen-158916/data-k8s-frontend
kubectl create deployment dpl-develop-data-backend --image=us.gcr.io/mazen-158916/data-k8s-backend
kubectl create deployment dpl-develop-data-worker --image=us.gcr.io/mazen-158916/data-k8s-worker

We can check that everything went well with kubectl get deployments which should list our three new deployments.

Then, we just have to create the jobs that will update the containers on these deployments and specify the port forwarding.

To do this you also need to use gcloud auth as you saw before. Then, just call the methods :

kubectl set image to update the container image.
kubectl patch deployment to update container information (e.g. change metadata)

Here is the full version for job:deploy-develop:backend:

job:deploy-develop:backend:
  stage: deploy
  image: google/cloud-sdk:latest
  before_script:
    - echo $GCLOUD_SERVICE_KEY > ${HOME}/gcloud-service-key.json
    - gcloud auth activate-service-account --key-file ${HOME}/gcloud-service-key.json
    - gcloud config set compute/zone us-east1-c
    - gcloud config set project ${GCLOUD_PROJECT_NAME}
    - gcloud container clusters get-credentials ${K8S_CLUSTER_NAME}
    - gcloud auth configure-docker
  script:
    - kubectl set image deployment/${APP_NAME}-backend data-k8s-backend=us.gcr.io/${PROJECT_NAME}/${APP_NAME}-backend:${CI_COMMIT_SHA}
    - kubectl patch deployment ${APP_NAME}-backend -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"

There you go.

Then just go to the GCloud interface in the "Kubernetes Engine > Workloads" section, find the corresponding workloads and create the DNS entries on your domain name provider and point them to the corresponding deployments.

Conclusion

For my part I found the Google Cloud Platform approach very confusing but quite well documented. The time invested in learning this technology seems to me well invested because the architecture is really scalable and allows to reduce the infrastructure costs.

The only black point could be that we lock ourselves in a provider but I think that Amazon Web Service or Microsoft Azure share the same terminology because their technology is also based on Kubernetes in my opinion.

Api on Rails 6

Alexandre Rousseau — Mon, 19 Aug 2019 11:48:21 +0000

Dear Ruby community,

I just finished rewriting my API on Rails book for the brand new version of Rails 6 released last Friday. This book discusses of bests practices for building a scalable API with Rails 6.

I didn't just adapt the content, but I also chose to simplify some examples and use tools that seem more current to me, such as:

authentication tokens with JWT
compliance with JSON:API specifications
unit and functional tests with Minitest instead of Rspec

It took a lot of work on my part, so don't hesitate to take a look at Leanpub.

The book is also available in open-source on Github so feel free to fork and suggest improvements. I built the book using Asciidocotr so it's really easy to contribute. You can also translate in your language and sell it on your preferred platform.

Thank you for reading.

DEV Community: Alexandre Rousseau

Hack protected WPA/WPA2 Wi-fi

How it works

Preparation

Analysis

Capturing a WPA handshake

Wi-fi Scan

Disconnection

Cracking

the dictionary

The bruteforce

Conclusion

Links

Deploy a fullstack application on Google Cloud Plateform with Gitlab CI

My application

Automation with Gitlab CI

`test`: running unit tests

`publish`: creating a Docker image and publishing it in the private image registry of the GCloud.

`deploy`: ask GCloud to deploy the images previously uploaded.

Conclusion

Links

Api on Rails 6

DEV Community: Alexandre Rousseau

Hack protected WPA/WPA2 Wi-fi

How it works

Preparation

Analysis

Capturing a WPA handshake

Wi-fi Scan

Disconnection

Cracking

the dictionary

The bruteforce

Conclusion

Links

Deploy a fullstack application on Google Cloud Plateform with Gitlab CI

My application

Automation with Gitlab CI

test: running unit tests

publish: creating a Docker image and publishing it in the private image registry of the GCloud.

deploy: ask GCloud to deploy the images previously uploaded.

Conclusion

Links

Api on Rails 6

`test`: running unit tests

`publish`: creating a Docker image and publishing it in the private image registry of the GCloud.

`deploy`: ask GCloud to deploy the images previously uploaded.