DEV Community: Ruheza, NS

Story of SSRF from Stored XSS in PDF generator application

Ruheza, NS — Tue, 19 Dec 2023 16:18:39 +0000

Introduction

PDF generator libraries, particularly those implemented using JavaScript, often face vulnerabilities to cross-site scripting (XSS) attacks, posing a challenge to the security of web applications. One primary reason for this lies in the dynamic nature of JavaScript itself. Many PDF generator libraries heavily rely on client-side scripting to manipulate and generate PDFs, allowing attackers to exploit vulnerabilities in the code. In this write-up, I will show you how I exploited the server side issue (SSRF) from the front-end interface (XSS)

The finding

Basically, the application helps you to generate invoice online by just filling in the data and download the pdf file of it.

I started by doing a recon on the target to identify few things including the stack used to build this application (well, Wappalyzer plus review the minified client code on the browser) and the cloud used to deploy this application (which was AWS).

Story short, instead of filling intended fields and data, i tried to add JS code to see if the code will be interpreted and executed (XSS).

Surprisingly, the app responded with the output of my JS code <script>document.write(document.domain)</script> printing the domain name of the application. Now we have our stored XSS. A journey to increase an impact ...

Next i wanted to try if i can exploit any server side issue (stealing cookies wasn't enough for me) for that i tried to use iframe, testing if the application can fetch resources remotely. Since i've already knew that AWS is used, i tried to fetch internal meta-data of the instance with <iframe src="http://169.254.169.254/latest/meta-data/">

As how i was expecting, the application gave me what i requested ...

Up to this point as an attacker, you can do alot on this application. I chose to read access keys of the this server so that i can completely take over the server. In AWS cloud-world, if you can have "Access Key ID" and "Secret Access Key" then you can run command remotely in the server and even play around with some connected services. I wanted this!

First in order to know and read these credentials, you must know the IAM role used in this particular instance. So i added <iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/">

I got the IAM role and next step was just to append it on the same endpoint so that we can read these credentials.

Voila! Now we have a full control of the instance remotely.

Final thought

As we have seen above, the integration of third-party libraries in PDF generators can introduce additional vulnerabilities. Although this is most known issue and well fixed in most of the JS libraries but some libraries especially new ones are still prone to this kind of attacks.

It is advised to double check the library you want to use in your application and ensure that it is free-from pursing issues result to XSS. Also sanitization should always be implemented on all input fields and forms as a preventive measure.

Disclaimer: The researched target mentioned (anonymized) in this write-up was successful patched and remediated. Kudos to the team!

Originally wrote this article here Thanks for reading !

Send Linux commands to a remote PC(or server) from WhatsApp

Ruheza, NS — Sat, 05 Feb 2022 15:37:14 +0000

Inspiration

Some years back, I wanted to link two systems talking to each other through Linux commands. It was just a project out of curiosity, and wasn't even a serious one. I didn't know Twilio or Plivo or any other platform related. I tried to die hard, but guess what! it was hard indeed :) I learnt about Twilio and built many other related projects. You can do the same, or even start building your very own next Twilio. Yes! It's possible. Hell, yess !

You can learn from this project, going further and building something tremendous! From the concept of this project (of-course you need to improve and add few other things) you can:

Deploy your docker replicas just by sending WhatsApp text
You can monitor your IoT devices remotely
Send commands to your K8's engine for some orchestration processes

In fact you can do a lot, the sky is not a limit :) Let's set up our project.

Setup a project in Twilio

In this article, we will focus more on how to interact these technologies and accomplish what we want. Our focus won't be more on Twilio.

To setup a sandbox and obtain a WhatsApp number (sender id) follow this link
Obtain ACCOUNT_SID and AUTH_TOKEN from the platform. Click here
Now let's proceed with the project.

Flow of our project

Building a server in Python

Now that we have already setup our project in Twilio platform and obtained ACCOUNT_SID and AUTH_TOKEN its time to build our server. We will use Flask for this project.

Create a file, name it command.py. This is the file where we will write our server-side application to and establish a connection between the machine (which will receive the commands) and WhatsApp through Twilio.

Install the required packages and make them available in the requirements.txt file.

$ pip install flask, twilio
$ pip freeze > requirements.txt

In the file command.py import the libraries:

import os
from flask import Flask, request
from twilio.twiml.messaging_response import MessagingResponse

From the import, Flask will help us to setup the server, request will enable us to send requests from WhatsApp via the Twilio sandbox to this server we're building.

MessagingResponse
is the Twilio Python class whose object helps to manage responses, that is incoming and outgoing messages or even calls. In short, MessagingResponse helps to starts the TwiML

We will use os to make our WhatsApp text be excuted on the remote terminal (can be your remote Linux machine or the Server) as Linux commands (not just text).

Now lets write our first function to handle incomming commands sent from a phone (via WhatsApp) to the Twilio number we obtained early.

@app.route("/command", methods=['GET', 'POST'])
def command():
    # get the message body which sent to the Twilio number
    body = request.values.get('Body', None)
    # Start our TwiML response
    resp = MessagingResponse()

Now MessagingResponse is well set, we can listen to the response coming to our Twilio number obtained. We can receive and process the message sent from any WhatsApp number (ofcourse, sent to our Twilio number). We can now start the chat, receive the commands and run them on the terminal.

# Determine the right reply for this message
    if body == 'command':
        resp.message('What command do you want to run on your machine?')

    # You can send any command
    elif body == 'init 0':
        resp.message('Shutting down your machine...')
        os.system('init 0')

    elif body != 'command':
        os.system(body)

Here's the command.py file

from flask import Flask, request, redirect
from twilio.twiml.messaging_response import MessagingResponse
import os
from decouple import config

app = Flask(__name__)

@app.route("/")
def home():
    # Just to make sure if flask server runs successfully
    return 'Hello, the server is running...'

@app.route("/command", methods=['GET', 'POST'])
def command():
     """
        Send a dynamic reply to an incoming text message
        Get the message the user sent our Twilio number
     """
    body = request.values.get('Body', None)
    # Start our TwiML response
    resp = MessagingResponse()

    if body == 'command':
        resp.message('What command do you want to run on your machine?')
    # You can send any command
    elif body == 'init 0':
        resp.message('Shutting down your machine...')
        os.system('init 0')
    elif body != 'command':
        os.system(body)
    return str(resp)

if __name__ == "__main__":
    # Run the script on port 5000
    app.run(debug=True, host='0.0.0.0', port='5000')

Send linux commands from your WhatsApp

Finally, we need to send commands and let them be processed by our server. But the server is currently running on localhost. We need to expose the server publicly and use its url as callback url in the Twilio platform. You can choose to deploy the app and continue, but for now i will use Ngrok for this task. Make sure you install ngrok before continue.

On the terminal, run this command:

$ ngrok http 5000

Running this command will expose port 5000 which is the same port where our server is running. Ngrok will return a url (a link) of our running server. Copy this url and fill in the Twilio platform in your project console as a callback url. Check this example below:

If you followed all instructions up to now, then you're on the right track and ready to start sending commands from your WhatsApp.

Happy coding!

References

Posted here

Using Tuya Link SDK to build water level monitoring system.

Ruheza, NS — Tue, 04 Jan 2022 05:22:22 +0000

Hardware devices required

Raspberry Pi
Ultrasonic sensor
Jumper wires

Software required

Tuya IoT platform
Link SDK python package
Tuya Smart app (mobile app)

Getting started with Tuya IoT platform

Create an account in the platform.

If you already have an account, go on login here or if you don't have an account, then create one in this link.

If you are registered or login successfully, then you'll see this dashboard:

Then open Product > Development > Create then scroll down and you'll see Can't find the category? in the left bottom corner. Open up and fill the information like below then Create:

By creating the Product we mean, the project which will exist in the Tuya platform to receive data from the sensors and monitored remotely from the phone or your PC. The information we filled in the platform tries to mimic our hardware devices which we will use in the circuit.

Create custom functions

Here we specify some metrics about the sensor (Ultrasonic sensor) so as it may link correctly as how we want it to be. These metrics including, Data Point (DP), Identifier,Data Transfer Type, Data Type and Value

Open up our Product and then click ** Function Definition** > Custom Function > Add, you'll see the form to fill the metrics above. Go ahead and fill like this:

Obtain credentials for your project

Credentials which are needed in tuyalinksdk are PID, AUTHKEY and UUID. Once you create a Product in the platform, you automatically obtain the PID (aka, Product ID).

But for AUTKEY and UUID, you'll have to apply for a license. The license comes with these two credentials. Follow these steps to get the license. Navigate to Purchase > Material & License then click Buy Now the Generic License 2 free licenses for each developer account, you need to buy when you use up.

Click Buy Now **, another window will open then **Select Product and Delivery Mode as License.
The order process will take some time to complete. Just relax and worry out meanwhile, get a cup of coffee :)

The Circuit (Hardware part)

In this section, we're going to build our circuit. Connect the Raspberry Pi on the power source and the keyboard. Mount Ultrasonic sensor on the Raspberry Pi. We use Ultrasonic sensor to measure the level of water calculating the distance from the sensor to the water surface in the tank.

Project in Tuya IoT platform (Software part)

In this section, we're going to setup our project in the Tuya IoT platform. We already have the credentials which we got in the above steps (by credentials i mean, PID, UUID and AUTHKEY). We will use these credentials in the tuyalinksdk to setup a link connection between the circuit and platform.

Link Tuya SDK python library

tuyalinksdk is a Python library which makes the connection between the circuit and the Tuya IoT platform.
We'll install this package in our Raspberry Pi in order to link and upload data from the sensor (in the circuit) to the platform. In the directory of your project in Raspberry Pi, run:

# install the package
$ pip install tuyalinksdk

or install from the github repository:

$ git clone https://github.com/tuya/tuyaos-link-sdk-python.git
$ python3 -m pip install ./tuyaos-link-sdk-python

Next thing is to write the codes which establish connection by using this package.

from tuyalinksdk.client import TuyaClient

client = TuyaClient(productid='PID', uuid='UUID', authkey='AUTHKEY')

def on_connected():
    print('Connected.')

def on_dps(dps):
    print('DataPoints:', dps)
    client.push_dps(dps)

client.on_connected = on_connected
client.on_dps = on_dps
client.connect()
client.loop_start()

on_connected is the method which checks if the connection is well setup. If everything is okay the print statement will run.

on_dps is a method which receives the datapoints (values of the sensor) and upload them to the platform so that we can monitor the process from our devices (phones and PC), ie IoT itself. Data are uploaded through client.push_dps() method.

Write the codes for the Raspberry Pi codes for the ultrasonic sensor alongside the above codes. This is the complete codes:

#!/usr/bin/python
import RPi.GPIO as GPIO
import time
import coloredlogs
from tuyalinksdk.client import TuyaClient
from tuyalinksdk.console_qrcode import qrcode_generate
from time import sleep

GPIO.setmode(GPIO.BCM)
coloredlogs.install(level='DEBUG')

client = TuyaClient(
    productid='44apXXXXXXXXXXX',
     uuid='tuya19dXXXXXXXXXXX',
      authkey='uFjw3VqrrfXXXXXXXXXXXXXX')

TRIG = 2
ECHO = 3
i=0

GPIO.setup(TRIG ,GPIO.OUT)
GPIO.setup(ECHO,GPIO.IN)
GPIO.setup(4 ,GPIO.OUT)

GPIO.output(TRIG, False)
print("Starting.....")
sleep(2)

while True:
   GPIO.output(TRIG, True)
   sleep(0.00001)
   GPIO.output(TRIG, False)

   while GPIO.input(ECHO)==0:
      pulse_start = time.time()

   while GPIO.input(ECHO)==1:
      pulse_stop = time.time()

   pulse_time = pulse_stop - pulse_start
   water_level = pulse_time * 17150
   print(round(water_level, 2))

   time.sleep(1)

   if water_level < 4:
       print("Water will overflow")
       GPIO.output(4, True)
       time.sleep(0.5)
       GPIO.output(4, False)
       time.sleep(0.5)
       GPIO.output(4, True)
       time.sleep(0.5)
       GPIO.output(4, False)
       time.sleep(0.5)
   else:
       GPIO.output(4, False)

def on_connected():
    print('Connected.')

def on_qrcode(url):
    qrcode_generate(url)

def on_reset(data):
    print('Reset:', data)

def on_dps(dps):
    print('DataPoints:', dps)
    dps = {'101':True}
    dps['101'] = data
    client.push_dps(dps)

client.on_connected = on_connected
client.on_qrcode = on_qrcode
client.on_reset = on_reset
client.on_dps = on_dps
client.connect()
client.loop_start()

while True:
    data = water_level
    time.sleep(1)

You can get the starter codes from Tuya's page in Github and edit the codes by adding Raspberry Pi configuration codes. Run these commands:

 $ git clone https://github.com/tuya/tuyaos-link-sdk-python.git
 $ cd examples
# view the starter codes here
 $ cat outlet.py

Reference is here and the codes can be found here

Running the codes at first time will create a connection between your project in Tuya platform and the Tuya mobile application which will enable you to send commands from the application to your Raspberry Pi remotely through the platform. To allow the connection, you'll need to scan the qrcode by using your mobile phone generated once you run the outlets.py.

Now lets design a monitoring dashboard in the platform which will receive data from our sensor and display visuals and monitoring. Then after, we will connect a smartphone to view this dashboard just like how we view in the platform (in the platform, a web based)

Monitoring dashboard

In the platform, navigate to Product > Development, it will open the product we've just created in the above steps. Open up that Product (aka, the project) and you'll see something like this:

Open the Device Panel and select a blank screen where it will open up a new page for designing the mobile view screen for your dashboard. Make the UI design of your choice, this is what i came up with:

When you're done with the design, Preview to check if its okay then Save As and finally Release your design. Up to this point, the dashboard is ready. We can visualize this design from the smartphone by using Tuya Smart App

Up to this point, the project is ready for testing and using. You can monitor the water level of your tank remotely from your device (phone for example).

Output

If you follow along up to this point, you should be able to send values directly from your phone remotely to the platform.

Video demo

References

Contribute like a Pro. Git-branching model (Part 2)

Ruheza, NS — Sun, 28 Nov 2021 18:36:30 +0000

Refresh

From Part 1 of this article, we discussed about --no-ff flag when merging. It helps to keep track of log messages of events happened in your sub-branch (feature branch) and you can easily roll back. Now lets look something else...

Releasing process

Like the feature branch, it is a separate branch but created as sub-branch of develop branch. It is a branch which contains all necessary environment, support and features for production of your application. It's the branch you need only during production process. Two main things can be found in this branch:

Meta-data(version number - tags, build dates)
Minor bug fixes

Create a release branch

When do you create a release branch? You should only create a release branch when all targeted features are fully developed and merged back to develop branch ready for release. Divide and Conquer mindset is very important when dealing with your software. I advise you to build your software in feature-wise that is, you release one feature after another until the entire software is complete. If you're building alone, you should not start building another feature before releasing a current feature. Divide and Conquer mindset will save your time and energy too.

For example, say version 0.2 is a current production release (in develop branch) and we have a new release coming up called version 0.3. We will branch off from the current state in develop branch and create a new sub-branch of the develop branch called release-0.3. It's name will point to the coming release, shifting from version 0.2 to 0.3, a new release! This is how you'll do:

#Create a release branch
$ git checkout -b release-0.3 develop

#Bump the version from 0.2 to 0.3
$ ./bump-version.sh 0.3

#Make a commit
$ git commit -m "Bump v0.2 to v0.3"

Note that bump-version.sh is just a custom bash script you'll write to change version of your software (you can also use git actions or CI tools)

You can fix some minor bugs in this branch rather than doing it on the develop branch. But it is not advised to add large new features here.

Release a release branch

Now the software is ready for production. Our sweet feature in a release branch should be merged into the master. Remember in Part 1, master branch will always contain "clean codes" with no bugs at this point in time. After merging our branch, we should tag it, just to mark the branch with a summary of what we've done for the future reference. And finally, updating the develop branch. In summary:

Merge the release branch into master branch.
Tagging the branch for future reference.
Update develop branch with clean codes so that the future development also contain the bug fixes.

#Into master branch
$ git checkout master

#Merge the release into master 
$ git merge --no-ff release-0.3

#Tag it
$ git tag -a 0.3

#Into develop branch
$ git checkout develop

$ git merge --no-ff release-0.3

What about hotfix branch?

As the name suggests, this is the branch which you'll create for the purpose of fixing bugs that maybe found (or arise) in a master branch. But we said, master branch must contain "clean codes" right? So why bugs in a master branch? Well, the answer is - software becomes real when reach to a user. That's when you realize the bugs - Uncaught fish :) Here's the snippet:

#Create a hotfix branch 
$ git checkout -b hotfix-0.3 master

#Fix the bugs and commit
$ ./hotfix-version.sh 0.3
$ git commit -m "Fixed bugs in production"

#Update the master branch
$ git checkout master
$ git merge --no-ff hotfix-0.3

You can also update the develop branch with this fix just to contain the same clean codebase. After the fix, it's your choice to delete the branch or leave it for your reference. Up to this point, your codebase should be stunning with zero conflict !

Congratulations, you're Git ninja now!

Written from here

Contribute like a Pro. A guide for git-branching model (Part 1)

Ruheza, NS — Sun, 21 Nov 2021 11:52:50 +0000

Building a software in a team requires a clear understanding and proper management of the codebase. If the team members only know the "pull-push", you'll soon find yourself in the trap of resolving merge conflicts!

Developing while shipping the software may become tricky if the team is not familiar with version control. Git-flow plays a great role in agile development. I insist you to read every single word in this article, don't skim. Let's start exploring git-branching model.

Git-branching model

Implementing the git-flow, your repo should contain two main branches:

master (or main)
develop

Master branch is the main branch which is automatically created once you initialize a repo in a git. It is the origin of the repo and pre-exist. You'll find it written origin/master. This is the branch which must contain "clean codes", the codebase which is ready for deployment. You should not contribute or push codes direct to this repo! I'll tell you where to push your codes.

Develop branch is the branch which you should create. I advice you, to do this even if you're building alone. This is a branch which contains active codebase, the project at development state. Whether the feature is working or buggy, this is the right place for it. This is how you start:

# Create a develop branch and switch it on
$ git checkout -b develop
# Pull the codebase from master branch into your current branch(develop)
$ git pull origin master

Other branches

Apart from the main two branches, there are three other branches. All these branches should be created within develop branch. These branches are:

Features branch
Hotfix branch
Release branch

This is how you create them:

# Created as a sub-branch of develop branch (replace feature-backup with a branch name)
$ git checkout -b feature-backup develop
# Or a hotfix branch
$ git checkout -b hotfix-443 develop

Naming convention and merging

Naming these branches follows the standard way. Such as feature-*,hotfix-* and release-*. So for example; feature-login, or release-1.0.1

After all your implementation in the feature branch (or any other branch apart from main branches) you should merge it back to develop branch then later to master branch (during production). This is how you do it:

# Switch to develop branch
$ git checkout develop
# Merge the feature branch
$ git merge --no-ff feature-backup

Merging with flag --no-ff creates a new commit record. This helps to store historical information of the feature branch even after the merge. Thus, makes it easy to roll back in a particular feature just from the develop branch (even after merging).

Don't miss the next part of this article.

Thanks for reading!

Originally, posted here

How to start as an Open Source Developer (Beginner level)

Ruheza, NS — Thu, 11 Nov 2021 13:41:45 +0000

What's an open source project ?

The tech world is moving according to the economic shift. There’s no company or startup which is ready to risk a lot of funds for the software project while there’s an alternative for that. What a company needs is to get a service up and running regardless if the software was built from scratch or as an open source project.

At an individual level, open source saves time and money too. By the way, what reward do you get after building your project from scratch ? Why build something which already exists and you can get it for free ? Would love to hear your thoughts :)

But what is an open source project ? It is a software project which is publicly free for anyone. That is, you can edit the source codes, change it to how you want. You can build your “big idea project” just on top of open source software. You can also release your sweet project to the community as an open source by allowing other developers to manipulate your codes. Sounds caring, right ?

Jump into open source project as a beginner

Step into open source projects as a newbie might be a challenge at first, however getting the right foot to start with can solve overheads. There are things you should know before starting contributing or building your application on top of an open source project.

Here’s the list of things you should consider first:

Able to use Git and Github comfortably.

You’ll always find these projects in version control (VC) like Github. To access them and alter the change, all need a knowledge of the git. You need to know how to:

Clone a project from Github (or any other VC)
Branching models (master, develop, feature)
Push the project
Raise and resolve issue
Write good commit
Tag and versioning the project.

You can learn the basics from Github documentation but I also wrote deeply about Git and branching models in my article titled Contribute as a pro.

Learn how to write a good “README”.

A README in a Github serves as a brief documentation of a particular project. Writing a precise document about the project helps another developer to jump straight into the project and manipulate on whatever he wishes.

On another hand, learning how to document your own project will help you to easily read and follow along with the docs. of other projects. While writing, there are a number of online tools to heavy-lift the job. I normally use dillinger to write the README before shipping it into Github. It has some placeholders which you can just change to fit your headings and contents. It supports markdown language as that used in Github.

Learn how to write clean codes.

By "clean codes" I mean the codes which are precise and easy to read. Don't just focus on the working codes, but the codes that another developer can read them and scale the project. Write the code while thinking about another person who'll come to read them.

Here are the tips for writing clean codes:

Master the domain language of a given project. That is, if the software is about Health, then the naming convention and your variables will all align to the health context.
Clear naming convention. Be very clean in naming the variables, methods and classes. Don't let your code become unequivocal just for laziness reasons.
Use comments only where required.
Obey DRY principle. Only define once and just reuse it where needed. Don't Repeat Yourself !
Well structured file tree. Your files should be in an organized manner. Don't just write the codes anywhere! Also, specify your main file (entry-point file). This will help another contributor to easily know where your software starts.

What's next ?

If you're comfortable with the tips above then it's a right time for you to try out doing something handy.

Pick one open source project of your choice. I'll write on sample open source projects for beginner.
Read the project codes and documentation
Contribute. I will upload soon the article on how to contribute as a pro.
Or build your software on top of it.

Thanks for reading this!

(It's my first article)

Written from here