1605925372
FluxCloud Frontline — Writeup
The challenge FluxCloud Frontline (web, hard) was part of the amazing Hack.lu CTF. It took a friend and me, both playing for the team FAUST, two evenings to crack the great challenge.
In the following, I describe the plain solution and leave out the many rabbit holes we stepped into.
#websocket #nodejs #hacking
What is GEEK
Buddha Community
1605925372
FluxCloud Frontline — Writeup
The challenge FluxCloud Frontline (web, hard) was part of the amazing Hack.lu CTF. It took a friend and me, both playing for the team FAUST, two evenings to crack the great challenge.
In the following, I describe the plain solution and leave out the many rabbit holes we stepped into.
#websocket #nodejs #hacking
1593368580
ERP PENTEST: Metasploit Writeup
What to do if we happen to be committed with SAP Penetration Test?
#sap #cybersecurity #metasploit #writeup #erp #testing
1594341900
[HTB] JSON — Write-up
Welcome to the JSON box writeup! This was a medium-difficulty box and fun to play with. For the initial shell, you need to identify a vulnerability related to JSON-based deserialization on the website, and by leveraging this issue incorporated with a Bearer: header, you can get a RCE on the box. For the root shell, you can leverage a permissive permission configured for the initial user, SeImpersonatePrivilege, to perform a JuicyPotato exploit to get a SYSTEM shell. Let’s get started.
Recon
Nmap
As usual, let’s start with a basic Nmap discovery scan:
nmap -Pn --open -sC -sV -p- -T4 10.10.10.158
From the scan, we have some interesting ports:
- FTP (21/TCP) —_ *Anonymous login was not allowed_
- HTTP (80/TCP)
- SMB (445/TCP) — *No null session allowed
- WinRM (5985/TCP) — *A default port for Windows Remote Management (WinRM). If we have a user who is part of a “Remote Management Users” group and her credentials, we can gain a remote shell leveraging this service. However, this was not no need to gain an initial shell on this box.
Web Server (HTTP — 80/TCP)
So from the initial scan, it looks like we need to focus on the web server first.
The front page was a login page, and it was configured with weak credentials:
Username = admin : Password = admin
Once logged in as “Admin” user, it was pretty dead end with the website itself. Pages and functions were either static or 404 not found.
Web Server — Dirsearch
When you are targeting a web server, it is recommended to do directory brute-forcing to check if there are any hidden files/folders. I used Dirsearch tool to accomplish this.
/files/password.txt
There was a password.txt file under the /files folder, but it was a troll. -_-
However, an interesting file Account was found under the /api directory.
#hackthebox-writeup #json #json-writeup #juicypotato #hackthebox
1593495960
InjuredAndroid CTF Writeup
In this article, I will be walking through the InjuredAndroid CTF. This is a vulnerable Android application with CTF examples based on bug bounty findings, exploitation concepts, and pure creativity. I have left a link to the creators Github and the GitHub I used to download the APK in the references below for anyone interested in trying out the CTF themselves.
Disclaimer
This writeup will obviously contain spoilers and I encourage readers to attempt this CTF before looking at this article. You will learn more by attempting it yourself first and will gain more satisfaction from solving the challenges yourself.
The author of this CTF has also mentioned that:
Looking at the source code of the applications in the InjuredAndroid directory, InjuredAndroid FlagWalkthroughs.md file, or binary source code in the Binaries directory will spoil some if not all of the ctf challenges.
I must also point out that challenge seven and eight for the release of the APK I used do not function properly and do not have flags. I discovered this after starting the writeup and decided to continue on anyways. With all that said, it’s time to move onto to the writeup!
Initial Setup
For this CTF, I will be using a Kali Linux virtual machine as my host device and a Samsung Galaxy S8 emulator created with Genymotion with the following specs:
To begin the CTF, i connected to my emulator using Android Debug Bridge (ADB) and installed the “injuredandroid.apk” file.
Looking at my emulator, I can see that the application has been installed successfully.
The CTF author also highly recommends decompiling the “injuredandroid.apk”. To accomplish this, I will be using a tool called Mobile Security Framework (MobSF). MobSF automates the process of decompiling the APK, reading the manifest file, identifying issues in the source code and in the Manifest file, extracting the certificate of the application etc. and saves me from having to do this manually. The image below shows the application has been successfully decompiled by MobSF.
With the initial setup out of the way, I can now move on to the challenges.
XSS Test
Opening the application, I am greeted with the following main activity.
There appears to be eight flags in total. According to the author:
XSSTEST is just for fun and to raise awareness on how WebViews can be made vulnerable to XSS.
Looking at the XSSTEST activity, I am presented with a simple input field where I can submit text.
I can enter some simple JavaScript that will create and alert box to demonstrate if the vulnerability exists.
<script>alert('XSS!!')</script>
Entering this input causes an alert box to be generated when the activity used to display our input is loaded.
The challenge recommends looking at the “DisplayPostXSS” activity to determine what makes this activity vulnerable. The source code for the “DisplayPostXSS” activity can be seen in the image below.
Examining the source code, I can see that a new WebView object is created which allows developers to display web content as part of their activity layout. This activity is vulnerable to XSS because the developer has enabled JavaScript execution as seen highlighted in red above. This is a nice, simple example of how developers can leave WebViews vulnerable to XSS.
#mobile-app-security #ctf-writeup #technology #android #mobile-app-testing #android
1595730900
Bypass 2FA like a Boss
Hi, This write-up is about a program that is public but Disclosure policy is enable on this program so we assume the domain is : domain.com
In recon process, I’ve found that there are two websites that are the same :
2FA was enabled on www.domain.com and when you create an account on this domain you can login on beta.domain.com without entering the 2FA code.
By default, the 2FA was disabled. So, I ‘ve decided trying bypass 2FA and enabling it on www.domain.com. After entering username and password you should enter 6 character (digit and chars) and after 5 minutes the code will be expired. Therefore brute force doesn’t work here.
Open Burp and intercept request after entering password and change Host header to: beta.domain.com
Enter 000000 in twofactorcode field
And forward request, BOOOM.
#infosec #bug-bounty #writeup #security