Jason Gardner's Cybersecurity Research Blog

Independent Replication of CVE‑2026‑0073: A Study in ADB Protocol Authentication Bypass

noreply@blogger.com (iAmTheRealJason) — Tue, 02 Jun 2026 03:22:55 +0000

Abstract

This report documents the independent re‑implementation of an exploit for CVE‑2026‑0073, a critical authentication bypass in the Android Debug Bridge daemon (adbd). The vulnerability arises from a type‑confusion error in the comparison of TLS client certificate public keys, enabling an unauthenticated network peer to obtain an ADB shell. The goal of this work was not to produce a novel attack, but to achieve a deep, practical understanding of the vulnerability through hands‑on reproduction on a physical device. We describe the ADB‑over‑TLS protocol, the logical defect in adbd_tls_verify_cert(), and the practical challenges encountered when targeting a Samsung Galaxy A22 (SM‑A225F). My experience highlights the gap between theoretical vulnerability descriptions and the engineering demands of real‑world exploit development, underscoring the value of independent replication in security research.

1. Introduction

On 5 May 2026, the Android Security Bulletin disclosed CVE‑2026‑0073, a critical‑severity vulnerability in the ADB daemon’s TLS authentication path. The flaw permits a remote, unauthenticated attacker on the local network to bypass ADB host verification and execute arbitrary commands as the shell user. The original discovery and detailed analysis were published by BARGHEST, whose work provided both a lucid explanation of the bug and a functional proof‑of‑concept.

While the public availability of an exploit makes the vulnerability accessible, the educational value of reconstructing such an exploit from first principles is substantial. This report presents our independent effort to replicate the attack against a Samsung Galaxy A22, a mid‑range device running Android 13. We emphasize that no new vulnerability is claimed; rather, we document the protocol intricacies, implementation obstacles, and lessons learned during the replication process. All findings are consistent with the public advisory, and no unpatched devices beyond the tested unit were targeted.

2. Background

2.1 ADB Wireless Debugging

Modern Android devices support wireless debugging, which exposes the ADB service over TCP. The connection process involves several phases:

Plaintext ADB handshake: The client sends a CNXN packet advertising supported features, including tls_auth. The device responds with an STLS packet, indicating that the transport must be upgraded to TLS.
TLS 1.3 mutual authentication: The client initiates a TLS 1.3 handshake and presents a client certificate. The server (adbd) verifies this certificate against the set of authorized host keys stored in /data/misc/adb/adb_keys.
Post‑TLS ADB exchange: Upon successful verification, normal ADB packets flow inside the encrypted tunnel, allowing the client to open service streams (e.g., a shell).

The critical security property is that only a host possessing the private key corresponding to a previously paired RSA public key should be able to complete the TLS handshake.

2.2 The Vulnerability (CVE‑2026‑0073)

The vulnerability resides in the function adbd_tls_verify_cert() within the ADB module’s auth.cpp. The relevant code fragment (prior to patching) is:

if (EVP_PKEY_cmp(known_evp.get(), evp_pkey.get())) {
    VLOG(AUTH) << "Matched auth_key=" << public_key;
    verified = true;
}

EVP_PKEY_cmp() returns an integer with the following semantics:

1 – keys are equal
0 – keys of the same type differ
-1 – key types differ
-2 – operation not supported

In C, any non‑zero value evaluates to true in a conditional context. Therefore, when the function returns -1 (indicating different key types), the condition if (EVP_PKEY_cmp(...)) still succeeds—because -1 is truthy. This allows an attacker who presents a certificate with a non‑RSA key (e.g., EC or Ed25519) against a stored RSA key to satisfy the check and be incorrectly authorized. The fix, distributed in the May 2026 security patch, changes the condition to EVP_PKEY_cmp(...) == 1, so that only an exact match grants access.

3. Methodology

We undertook a from‑scratch implementation of the exploit in Python, using only the cryptography library for certificate generation and Python’s standard ssl module for the TLS handshake. The target device was a Samsung Galaxy A22 (SM‑A225F) running Android 13 with security patch level prior to May 2026. The device had previously been paired via USB, ensuring at least one RSA key in the trust store.

The implementation was broken into three phases:

ADB transport emulation: Implementing the packet framing, checksums, and the CNXN/STLS exchange.
TLS handshake with a cross‑type certificate: Generating a self‑signed EC P‑256 certificate and integrating it into a TLS 1.3 client context.
Post‑TLS service access: Opening a shell stream and reading command output.

4. Implementation Challenges

Despite the conceptual simplicity of the bug, practical exploitation demanded careful attention to protocol details and device‑specific behaviour.

4.1 TLS Version Requirements

The initial development environment utilized the system Python, which was linked against LibreSSL 2.8.3. This library does not support TLS 1.3, which the target device required. The problem was resolved by creating a virtual environment that used a Homebrew‑installed OpenSSL 3.6.2, which provides full TLS 1.3 support.

4.2 Samsung‑Specific STLS Flooding

The most significant obstacle emerged after the TLS handshake. The Samsung A22 emitted a continuous stream of STLS packets before sending the expected CNXN banner. In a naïve implementation, the main thread blocked while waiting for CNXN, causing timeouts. Experiments with background draining threads and manual pre‑drains did not fully resolve the issue.

The key insight came from observing that the device would accept a service OPEN request even before sending its own CNXN. By transmitting the OPEN shell:<command> packet immediately after the TLS handshake—without waiting for any device‑initiated messages—the host elicited both the CNXN (confirming authentication bypass) and an OKAY for the shell in immediate succession. This ordering inverted the intuitive “receive then send” sequence and circumvented the STLS flood entirely.

4.3 Stream Management

Once the shell stream was established, standard ADB flow control was required: acknowledging WRTE packets with OKAY and terminating on CLSE. Stray STLS packets continued to appear during the session, necessitating a filtering loop that discarded them silently. With these final adjustments, command execution became reliable.

5. Results

The final implementation consistently demonstrated the authentication bypass and obtained command execution on the Samsung A22. The following is sample output:

The exploit achieved remote code execution as the shell user in the u:r:shell:s0 SELinux context, consistent with the impact described in the original advisory.

I built out the PoC with a few variations to see the impact and here you can see that I was able to launch chrome and open a link to my website at thejasongardner.com.

6. Discussion

The replication effort illuminated several important aspects of vulnerability research:

Protocol state machines are fragile. The ADB‑over‑TLS handshake is not purely linear; implementations may interleave STLS notifications, requiring adaptive message ordering.
Library dependency management is critical. A mismatch between development and target environments (LibreSSL vs. OpenSSL) can stall progress, underscoring the importance of reproducible build configurations.
Independent replication is a powerful learning tool. While the vulnerability itself is well‑understood, the engineering process of reconstructing the exploit deepened our understanding of both the bug and the Android ADB architecture.

It is noteworthy that the Samsung A22 exhibited the STLS flooding behavior, which was not detailed in public write‑ups. This device‑specific quirk does not constitute a new vulnerability, but it illustrates the diversity of real‑world implementations and the challenge of creating universally robust exploits.

7. Conclusion

We have successfully replicated CVE‑2026‑0073 on a Samsung Galaxy A22, confirming the vulnerability’s exploitability under the documented pre‑conditions. The project served as an educational exercise in protocol analysis, cryptographic API pitfalls, and the practical art of exploit development. All credit for the original discovery belongs to BARGHEST and the Android security team; this work is merely a reconstruction that validates and learns from their findings.

Acknowledgements

The authors thank BARGHEST for their detailed public analysis of CVE‑2026‑0073 which helped with my analysis.

Disclaimer: No novel vulnerabilities are disclosed in this report. The described exploit relies on a publicly known, patched issue. The author does not distribute exploit code and does not encourage unauthorized access to devices. Author encourages users to update to the latest security patch as per Android "Security patch levels of 2026-05-01 or later address all issues associated with the 2026-05-01 security patch level". https://source.android.com/docs/security/bulletin/2026/2026-05-01

Dynamic Hooking and Overwriting of Native Android Password Validation Using Frida

noreply@blogger.com (iAmTheRealJason) — Sun, 22 Dec 2024 16:00:00 +0000

Dynamic Hooking: Bypassing Android Password Validation and Manipulating UI with Frida

Introduction

In this exploration, we leverage Frida, a powerful dynamic instrumentation toolkit, to manipulate native Android password validation logic and manipulate UI elements programatically. These techniques showcase how we can reveal vulnerabilities and assess applications.

Password Validation Hooking

We begin by dynamically intercepting the password validation function in the native library. The library libnative-lib.so serves as the artifact providing the functionality, and the script attaches to the function Java_com_optiv_ndkcrackme_MainActivity_b, which is responsible for handling password validation:

Java.perform(function () {
    var lib = Module.findExportByName("libnative-lib.so", "Java_com_optiv_ndkcrackme_MainActivity_b");

    if (lib) {
        Interceptor.attach(lib, {
            onEnter: function (args) {
                console.log("Password input: " + Memory.readUtf8String(args[1]));
            },
            onLeave: function (retval) {
                console.log("Original return value: " + retval.toInt32());
                retval.replace(1); // Force valid password
                console.log("Modified return value: " + retval.toInt32());
            }
        });
        console.log("Password bypass hook installed.");
    } else {
        console.log("Target function not found.");
    }
});

Note: The app must be in the foreground to ensure that the native library is loaded into memory and accessible for hooking.

Figure 1: Demonstrating password bypass with Frida

Method Hooking for Password Validation

After enumerating the methods available in MainActivity, we identified b(String) as the method responsible for password validation. Using Frida, we can hook this method and implement custom logic for password verification. This allows us to specify certain passwords that should be accepted or rejected dynamically during runtime.

Implementation

The following script overrides the behavior of b(String) in MainActivity. It accepts the password "correctPassword" and rejects "securePassword123", while defaulting to the original validation logic for other inputs:

Java.perform(function () {
    var MainActivity = Java.use("com.optiv.ndkcrackme.MainActivity");

    MainActivity.b.implementation = function (password) {
        console.log("Password validation called with input: " + password);

        if (password === "correctPassword") {
            console.log("Accepting password: " + password);
            return true; // Accept "correctPassword"
        } else if (password === "securePassword123") {
            console.log("Rejecting password: " + password);
            return false; // Reject "securePassword123"
        }

        // Call original method for other inputs
        var result = this.b(password);
        console.log("Original return value: " + result);
        return result;
    };
});

Running this script produces the following results. We see a specific password is allowed and one is explicitly denied access:

Password validation called with input: securePassword123
Rejecting password: securePassword123
Password validation called with input: correctPassword
Accepting password: correctPassword

This demonstrates how dynamic method hooking can be used to manipulate application behavior, enabling targeted testing and analysis of password validation logic.

Text Replacement Hook

The following section discusses the dynamic text replacement hook implemented using Frida. This script intercepts calls to the setText method of android.widget.TextView, replacing specific text values at runtime. The technique demonstrates how UI manipulation can enhance application testing and highlight potential vulnerabilities.

Implementation

The script attaches to all overloads of the setText method, replacing occurrences of "Password rejected!" with "Access granted!". This ensures a seamless user experience modification, allowing us to bypass textual restrictions dynamically.

Java.perform(function () {
    console.log("Starting text replacer...");

    var TextView = Java.use("android.widget.TextView");

    TextView.setText.overloads.forEach(function (overload) {
        overload.implementation = function (arg1) {
            if (arg1 && arg1.toString) {
                var originalText = arg1.toString();
                console.log("Original Text: " + originalText);

                // Prevent modifying already modified text
                if (!originalText.includes("Access granted")) {
                    var replacedText = originalText.replace("Password rejected!", "Access granted!");
                    console.log("Replaced Text: " + replacedText);

                    // Ensure correct type
                    var javaString = Java.use("java.lang.String").$new(replacedText);
                    return overload.call(this, javaString);
                }
            }
            return overload.call(this, arg1);
        };
    });

    console.log("Text replacer installed.");
});

Execution and Output

Running the script outputs detailed logs of original and replaced text values:

Starting text replacer...
Text replacer installed.
Original Text: Password rejected!
Replaced Text: Access granted!
Original Text: Access granted!
Original Text: Value NOT found.
Replaced Text: Value NOT found.
Original Text: Value stored!
Replaced Text: Value stored!

This demonstrates how text replacement can be applied selectively based on predefined rules, ensuring critical user feedback remains unaltered while bypassing unnecessary restrictions.

Conclusion

Dynamic analysis using Frida provides unparalleled insights into Android application security. These techniques uncover potential vulnerabilities and highlight the importance of secure coding practices in native libraries and sensitive storage operations.

Ethical Disclaimer

These methodologies are intended solely for educational and ethical use. Ensure compliance with all legal regulations and obtain proper authorization before applying these techniques.

Advanced Detection and Mitigation of Rogue Base Stations Using RayHunter & a Rooted 4G Hotspot

noreply@blogger.com (iAmTheRealJason) — Fri, 29 Nov 2024 08:12:00 +0000

Advanced Detection and Mitigation of Rogue Base Stations Using RayHunter & a Rooted 4G Hotspot

////////////////////////////////////////////////////////////////////////////
// As mobile networks become increasingly sophisticated, so do the tools  //
// and techniques used by adversaries to exploit them.                    //
//                                                                        //
// Rogue base stations, also known as IMSI catchers or stingrays,         //
// pose a critical threat to mobile networks. They are capable of         //
// intercepting communications, tracking devices, and even launching      //
// denial-of-service attacks.                                             //
//                                                                        //
// Tools like RayHunter are invaluable for detecting such threats         //
// by analyzing LTE paging messages and other signaling activities.       //
////////////////////////////////////////////////////////////////////////////

Rogue Base Stations: The Threat

A rogue base station masquerades as a legitimate cell tower, tricking nearby devices into connecting to it. Once connected, these devices can be exploited in several ways: ------------------------------------------------------------------------------------- - IMSI Harvesting: Requests devices to reveal their IMSI, compromising user privacy. - Tracking and Surveillance: Tracks devices' movement using temporary identifiers like m-TMSI or identifies repeat users. - Data Interception: Intercepts and manipulates traffic, compromising sensitive communications. -------------------------------------------------------------------------------------

How RayHunter Helps

RayHunter monitors and analyzes LTE traffic, providing visibility into critical signaling activities. It identifies the fingerprints of rogue base stations by detecting patterns such as: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [1] Unusual Paging Patterns: Rogue stations generate atypical paging requests (e.g., frequent/simultaneous paging). [2] Suspicious MMEC and m-TMSI Values: Legitimate base stations frequently randomize these, but rogue stations may fail to. [3] Anomalous Signal Levels: Rogue stations often overpower legitimate towers with stronger signal levels. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MMEC and m-TMSI in Detection

MMEC (Mobility Management Entity Code) - What It Is: Identifies the MME managing a device. Each legitimate network operator has a predictable range of MMEC values. - Rogue Station Red Flag: Detection of MMEC values outside the operator's range may indicate rogue activity. m-TMSI (Temporary Mobile Subscriber Identity) - What It Is: A temporary identifier used to protect IMSI over the air. - Rogue Station Red Flags: * Static or reused m-TMSI values over time (failure to randomize). * m-TMSI values inconsistent with MMEC (illegitimate pairing).

Example from RayHunter

Captured messages from RayHunter flagged anomalies: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [+] MMEC: c3 (195), m-TMSI: c4685385 (3295171461) [+] MMEC: 8c (140), m-TMSI: c2891c10 (3263765520) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Conclusion

Rogue base stations represent a significant threat to user privacy and network security. Tools like RayHunter provide invaluable insights by analyzing LTE paging activity, particularly patterns in MMEC and m-TMSI values. By leveraging these tools, mobile security engineers can detect and deter rogue base stations, ensuring safer mobile environments for users.

Automated Exploitation of a Bluetooth vulnerability that leads to 0-click code execution

noreply@blogger.com (iAmTheRealJason) — Mon, 22 Apr 2024 18:25:00 +0000

This blog post covers an interesting vulnerability that was just discovered earlier this year and an open source free tool that was created to automate testing for this vulnerability in Bluetooth devices.

I will preface this with the warning that this is of course done in my personal testing lab environment with my own devices for learning and demonstration purposes. I am in no way encouraging that these tools, snippets of code or techniques be used maliciously as there can be very serious legal consequences for those that use these hacking tricks nefariously. However, in a personal testing lab environment I think this is great for learning and allows someone to quickly be able to confirm or deny if their personal devices are truly standing up to the Bluetooth CVE of CVE-2023-45866.

CVE-2023-45866 is described as an issue where the "Bluetooth HID Hosts in BlueZ may permit an unauthenticated Peripheral role HID Device to initiate and establish an encrypted connection, and accept HID keyboard reports, potentially permitting injection of HID messages when no user interaction has occurred in the Central role to authorize such access". So in the photo above we see a device that has been sent the commands to open a new incognito browser pointing to my website at thejasongardner.com. This as you can see is done with 0-clicks or user interaction and the device is unfortunately vulnerable to the attack just by being in proximity to the attacking Bluetooth device with Bluetooth enabled.

Variations of this attack can affect Android, Linux, MacOS, iOS and Windows. The BlueDucky tool works because "The Bluetooth stacks in multiple operating systems allow an attacker to pair a virtual Bluetooth keyboard without authentication or user confirmation. The attacker can then inject keystrokes to perform actions as the user, so long as those actions do not require password or bio-metric authentication."

So, basically, if you have paired a Bluetooth device such as a keyboard to your tablet, now an attacker can pretend that they are using that same exact keyboard and type in commands into your device. This is a big problem because there are many situations where you may be exposed to this attack and you would have no way of physically stopping the attack from occurring. The best defense is to make sure your devices are patched to the latest versions of their operating systems and if possible try to only enable Bluetooth when you really need to use it. In the example here a browser is opened without the user doing anything and then the phone's browser seems to have someone typing in the URL and then the device opens my website. My website is just used as an example page but a malicious attacker could direct the device to download malware, a virus or anything else a hacker may want which could lead to the device being compromised after it has left the vicinity of the attacker.

To simplify here the issue is that the pairing can be forced and then keystroke injection is possible where an attacker can emulate a device using HID or the Human Interface Device. As discussed more in detail in this article (What Is a Human Interface Device (HID)? (howtogeek.com))"The biggest advantage of HID is being able to simply connect almost any peripheral to your device and have it start working immediately.". So here this universal usage and simplicity is misused when there are three criterium that were covered in the skysafe repo mentioned above and they are that:

the host is connectable/discoverable
the host supports pairing without authentication via the NoInputNoOutput pairing capability
the attacker can connect to L2CAP ports 17 and 19 on the host

So there is some mitigating criteria to begin with and after the device is patched this attack should result in an error and no unauthenticated pairing or injection should occur. I hope you learned a little more about something interesting and can use this information to be a little safer and more secure with your personal devices.

Sniffing GSM traffic on a private cellphone network

noreply@blogger.com (iAmTheRealJason) — Wed, 31 May 2023 00:09:00 +0000

Legal Disclaimer: GSM Research and Passive Traffic Monitoring

‘The information provided in this blog is for educational and informational purposes only. The author and publisher of this blog are not responsible for any misuse, illegal activities, or damages that may arise from the use of the information provided herein.

The author conducted research using two Samsung phones and a BladeRF with YateBTS to create a small-scale GSM network for the purpose of analyzing and intercepting traffic. It is important to note that intercepting or tampering with wireless communication without proper authorization is illegal in many jurisdictions. The author undertook this research within a controlled and lawful environment, and any techniques or findings described in this blog should not be replicated or applied in unauthorized or illegal activities.

The author strongly advises against engaging in any illegal activities, including but not limited to intercepting or tampering with wireless communications, without the express permission and authorization of the relevant authorities and stakeholders. Unauthorized interception of wireless communications violates privacy laws, regulations, and individual rights. Engaging in such activities may lead to severe legal consequences, including criminal charges and civil liabilities. It is always recommended to consult with legal professionals or authorized experts before conducting any research or experiments in the field of wireless communication.

The author disclaims any liability or responsibility for any damages, losses, or legal implications arising directly or indirectly from the use, misuse, or interpretation of the information provided in this blog.

By reading and using the information in this blog, you agree to the terms of this legal disclaimer and accept the risks associated with unauthorized interception or tampering with wireless communications.’

In this blog post I will be taking a look at cellular traffic and analyzing the GSM packets in Wireshark. However, I will also show how I have created a personal and portable, private cell phone network that I will use for this exercise. I created a portable cell phone network to ensure that I am operating and testing on frequencies that are not interfering or overlapping with any licensed operators in my area. I do not recommend that you attempt to follow along unless you understand how to properly do everything to stay within the bounds of your local laws, rules and regulations. It is illegal to interfere with licensed operators or to sniff the private traffic of individuals. To avoid these issues everything here is done in a private cell phone network I have created for this exercise with my own devices and cellular base station.

The interface for programming the IMSI on the SIM cards was interesting to work with. You also need to specify a KI value as well for authentication . This will come up again when we discuss the Kc value for decoding later on in another post. Here we are going to passively observe gsm network traffic on our own portable cellphone network. The SMS and voice decoding is beyond the scope of this post as for now we will be discussing how to set up a base station, have cellular devices join the private network. Then I will demonstrate how you can have the devices call and text one another on your private cellphone network. Additionally, on another machine I will show how the traffic can be observed and analyzed with a HackRF, grgsm_livemon and Wireshark. I programmed the two SIM cards with 15 digit IMSI numbers to be compatible with the Yate base station.

Here is the interface for writing IMSI and KI values to the custom SIM cards

Writing to a SIM card

Here is what the SIM card reader/writer looks like in action. It's useful for setting up the devices with the YateBTS as I have read that although you can perhaps have your base station freely adopt new subscribers within certain IMSI ranges that at least with the BladeRF there seems to be better performance if the base station is programmed to add specific subscribers with IMSI numbers that are put directly into the backend interface. I did this to get ahead of any connectivity issues and found that the connectivity and service worked quite well and consistently.

Loading the custom SIM cards

So at this point, the devices have been loaded with custom programmed SIM cards. They have the appropriate IMSI values needed for the Yate base station. Next I will show how I setup the base station before we get everything connected. I was able to run the YateBTS of a USB running DragonOS focal that has precompiled versions of the base station software that really helps to get up and running quickly. I flashed a USB with an ISO of the DragonOS focal software. Since it comes pre loaded with all the necessary files compiled and ready to roll thanks to ‘@cemaxecuter’ that helped cut down on setup time tremendously. I will show the GUI interface in a moment. Here is where we start the backend Apache server and load the FPGA files to the BladeRF.

Loading FPGA bitstream to the BladeRF

Since I created custom SIM cards I knew what the IMSI number was that I needed to put for the subscribers I wanted to add to my base station.

Adding subscribers manually with IMSI numbers

After a little bit more configuration in regards to the frequencies being used the BTS will be ready to start. You need to be careful to not transmit at frequencies that can interfere with licensed operators in your area. I chose to create a 2G network on frequencies that definitely are not overlapping with other devices in my area. Additionally also at run time I use an RF enclosure to ensure that my transmissions are not unintentionally affecting anyone else in my area.

There are quite a few steps to get up and running but we have basically everything we need at this point. We created custom SIM cards to put on our devices, we have configured our local base station and loaded the appropriate FPGA bitstream to the BladeRF. Since I want to also see what is going on I will also at this point setup the observing machine with the HackRF. For this purpose I setup another laptop with DragonOS software. I initially scanned the area to see my base station and then since I created the base station I already had the exact transmission frequency that would normally need to be found at this step. Using a tool called grgsm_livemon I am able to monitor a single channel at a time. I additionally started up Wireshark to start monitoring for the GSMTAP packets to be able to later analyze them and learn about the test portable cell phone network I have setup.

Now that the cellular base station is up and running as well and we have another machine observing the traffic and pulling it into Wireshark we are ready to have our devices join the network and see what they're doing in granular detail. Here my network has a generic name of 00101.

Selecting our custom network

Upon joining the network a test message is sent to the device alerting it that it has joined our special network and letting the user know what their new number is on our little private, portable network. For this device below it has now been allocated the phone number of '56789'. If another user needs to contact this user they would text or call '56789' on their device as you would normally dial or text anyone.

Joining the custom network

I decided to do a quick QA test on my network and tested to see if texts and calls were working properly.

Texting devices on the network works

Also calls between devices across the network worked well. This is really cool because you can use cellphones on your own private network as you normally would use a much larger company such as AT&T, T-Mobile or Verizon. And best of all, it's free. The software is completely open source and there are no paid per use limits or any fees whatsoever. Once you are up and running you can use your private cell phone network on a private island or very large ranch to communicate privately with your friends on your own portable cell phone network. I found this to be a really neat project to work on and this is a lot of fun once I got it all setup and working properly. It also helps for security research as I can now investigate things on my own network, with my own devices on my own frequencies so that I am definitely not interfering with any systems, channels or frequencies I am not supposed to be.

Our first call on our private, portable cellphone network

And at this point we can definitely see the traffic flowing on our observation machine. As you can see below gr-gsm livemon is working well and is seeing everything from our base station and what is going on between our devices.

gr-gsm livemon traffic

gr-gsm livemon and Wireshark

Here is a packet from our private network

Here we see the IMSI for one of our test devices

As you can see there is GSM packet with some system information above and below there is one with specific user IMSI information. The first packet shows our 'Unknown' network and a unique location area code that clearly does not really exist anywhere. In the packet below that we have been able to find an IMSI associated with one of our test devices. Additionally, below we see that with a tool called GSMEvil we are even able to intercept SMS messages in addition to being able to observe IMSIs.

Viewing SMS messages on our own network with GSMEvil

I hope you have found this little deep dive into cellular traffic to be interesting and informative. It has been fun to learn how to create a private, portable cellphone network. Also, if you decide to try anything I have discussed above please be mindful of any local rules, laws or regulations. It is best to double check anything you are unsure about before you actually begin any testing, observing, monitoring or transmitting.

What's a Pumpkin Honeypot and why you should probably be using a VPN when you're on free Wi-Fi

noreply@blogger.com (iAmTheRealJason) — Sat, 10 Jul 2021 19:56:00 +0000

So to start off I repurposed the first honeypot I had created a couple of months ago.

This was quite similar to flashing the microSD the first time so I won't go into the details again. You can read more about Kali for Raspberry PI here. This is really cool because once you flash the Kali image onto the SSD with the addition of a battery pack you have now created a portable Kali machine that is ready to take with you on all sorts of adventures. Please remember to only test on things that you have permission to do so. An easy way is to just test against your own devices and I will show a few examples below of some fun things I found going a little deeper into my security research on Wi-Fi. So in the first honeypot I created before I had simple logging capabilities if a rogue device where to connect to my access point. I had at least a mac address and minimal information about the device. So that was interesting but I wanted to go a bit further and see what else you could do. I decided for this next example to not try and reinvent the wheel but rather to see what are some cool tools I could find to help me further understand how this whole Wi-Fi thing works more in depth. There are many tools to explore still but I found this one in particular to be very interesting. It is called WiFiPumpkin3 and you can take a look by grabbing a free copy over on github. They have done away with the graphical user interface which has given way to the command line based version. This makes its use slightly more technical but does allow for more granular control, automation and custom configurations.

And to start off you can name your WiFi any emoji you want which is fun. So now that I connected to the newly created access point nothing really seems off. I went and visited my website at jasongardner.us and started clicking around. Great, we were able to spin up a new wifi access point with the raspberry pi in a minute once wifipumpkin3 was loaded on the Raspberry Pi. However, that's not all that just happened.

So within wifipumpkin3 there is 'sniffkin' which is sniffing the traffic flowing through the honeypot. Here the rogue access point we have created is now allowing devices to connect and browse the web but we are also logging what websites and IP addresses the device is connecting to. That's probably not what you expected when you were just connecting to a free Wi-Fi now is it. Here is another module within wifipumpkin3 that I thought was very interesting. Here this is creating a captive portal so when a device connects to the rogue access point users are greeted with a portal requesting a username and password. You may have seen this on a campus, hotel or even at a Starbucks. The danger here is that this page can be made to look like any login portal anywhere. So when users connect and enter their usernames and passwords then they are not putting those where they think they are.

So here you see that the user has successfully logged into the captive portal on their iPhone. They have unwittingly entered their credentials on a fake login page to use the free Wi-Fi.

As you can see this is just an example and the user 'Admin' with a a password of 'test' is logged in the system. Now the user will connect and not only have the credentials they use to access the local free wifi were logged then any subsequent internet browsing will be logged as well. Well, why am I telling you this? This all seems a bit troubling and makes me think that I shouldn't use free Wi-Fi anymore anywhere. I'm saying that more so that you can be aware of what's out there. I think that by being aware, you can take the proper steps to protect yourself and safeguard your usage of the internet and keep some of your privacy intact from attackers. Sometimes you have to think like an attacker to protect yourself from an attacker. So what can you do? Should you really just leave your phone off the next time you're at the airport or at a hotel? Of course not. Just use a VPN. A VPN will create a tunnel of sorts for your data to travel across the internet safely, securely and privately. All someone would be able to see even if they are sitting right there in the middle of your connection would be scrambled messages and that perhaps you are connecting to a VPN. I decided to investigate this a bit further to see how encrypted or protected my internet usage was with a VPN. Here I am using NordVPN on an iPhone.

You can grab the latest version of Wireshark here. Wireshark allows you to analyze and look at network traffic. Here we are looking at the interface wlan0 which is the Wi-Fi interface where the rogue access point is broadcasting from. By looking at interface wlan0 we are able to see everything going to and from the iPhone and the honeypot. One unexpected thing I found here is that although most of my internet traffic was being routed through the VPN and was therefore encrypted not all app data was going through the VPN tunnel. In fact an observer could see that I'm also listening to music on Spotify. However, at least the important internet traffic like emails and banking are protected which is good. So although the VPN may not work 100% correctly all the time, you are getting an infinitely greater amount of privacy by using the VPN when traveling or visiting new places that you are unfamiliar with where there could be a rogue access point. Again, though to clarify you should not do this against devices you do not own or have the permission to test against. I am showing you this more as a warning of what is out there and why you should be careful when connecting to unknown Wi-Fi and to use a VPN whenever you can.

So is there anything else you can do. Yes, there is one more thing I thought of in this analysis that I don't think it would be complete without and that is - location. Yes, what is the real point of detecting a nefarious device that is connecting if you are then not able to localize yet. Find it? How, it is invisible? Not really. I found another very interesting tool for android phones. This doesn't exist for iOS yet, but I hope that is in the works somewhere. This app is called WiGLE WIFI Wardriving. With this app using the phones GPS and maps we are able to do wireless site surveys that show us precisely where a device is based on an SSID or mac address. This can even help you locate Bluetooth devices. So here I wanted to confirm that my device was indeed correctly connected to the Wi-Fi honeypot and the location is correct and I can confirm I'm connected to the right device. This can also be used to find the device by mac address that was initially logged in our first honeypot. So we have also gone a layer deeper with the wireless site surveys and can now not only identify nefarious devices that have connected but we have a way of finding the location of the devices.

Raspberry Pi WiFi Honeypot 🍯

noreply@blogger.com (iAmTheRealJason) — Thu, 18 Mar 2021 20:29:00 +0000

This was a fun project to work on and build out. I learned a few new interesting tricks along the way. I started with this tutorial from 2013 by Andy Smith. However, a few things have changed with hostapd that I had to figure out through debugging. Also, the configuration of the nginx server as well as dnsmasq were slightly different for me using the new Raspbian Buster for Raspberry Pi 4. This should save you some time if you follow my trick tips later on in the article that I found by searching through various message boards and googling error messages as I did debugging to get this working properly.

I have gone over setting up nginx servers in previous articles so if you need help with getting started these may be helpful.

So first things first. I started with a canakit and assembled the raspberry pi with the appropriate heat sinks and a little fan set to a standard speed. The speed is adjusted by how you install the wiring. If you haven't done this before you can follow the manufacturers documentation to get rolling with that.

Assembling the Raspberry Pi. Hardware assembly is fun if you like puzzles :).

Next I flashed the micro SD card with Raspbian Buster which is the operating system that will be on this tiny computer. I used a little adapter and balenaEtcher on a mac to flash the micro SD card. This is pretty straight forward so I won't go into the details since there are plenty of easy tutorials to do this part.

Success! The card is flashed and we are ready for the next steps.

At this point I went ahead and added a WiFi dongle that can support running as an access point. Additionally for configuring I went ahead and plugged in a keyboard and mouse with a usb hub so now this is looking very cyberpunk but I promise this will be easy and very efficient as we go along further.

Now I did this project over two separate nights so the additional step here is that you will need to briefly connect this to an ethernet cable to grab a few things. Eventually this is not connected to ethernet so we can have a truly sandboxed wifi honeypot that is not connected to the internet and is merely to log attacker activity and attempted access. I plugged in the ethernet cable and grabbed hostapd, nginx, and dnsmasq.

The honeypot at a high level is a simple but quite interesting concept. We will spin up an access point with hostapd that can be joined from a phone or laptop. Here I called the honeypot network 'decepticonNetwork'. Then with a neat little trick dnsmasq will now redirect all requests to our local nginx server which is serving up the little warning page. Getting hostapd up and running is not as easy as it was before but it is more for security that it does not come unmasked out the box so to speak. Through the command line I ran commands to unmask, enable and start and it finally connected properly to both a laptop and a phone.

Now you can configure the nginx server to do anything you want when the device that illicitly connected to our untrusted network tries to access a webpage. I redirected all web requests to my nginx server using dnsmasq. So now after connecting to 'decepticonNetwork' if I type in any url like somerandomurl.com or blaaaaargh.com my nginx warning page gets served up.

Also a fun extra here is that now all users who access the WiFi honeypot are now logged in a dnsmasq.log file for later analysis and review. This was a fun learning experience. Obviously this is just the beginning as you can then get a lot more advanced with your logging and blue team analysis and defense. However, this is a great introductory start to the world of WiFi honeypots and cyber defense.

Hack The Box - Swagshop - CTF writeup

noreply@blogger.com (iAmTheRealJason) — Thu, 03 Dec 2020 20:57:00 +0000

So in preparation for the OSCP and to get better at understanding security vulnerabilities I have been doing what are commonly referred to as capture the flag challenges. Here I will go over a unique vulnerability that allows remote access to a "user.txt" file and a "root.txt" file. The root.txt file can only be acquired remotely if I can gain remote command execution as the root or system user. Since this is a Linux based system I will be trying to escalate my privileges up to root so I can control the system and do the file retrieval.

The biggest and initial step is enumeration. So far I just know there is a box with an IPv4 address of 10.10.10.140. From the name I can assume perhaps that this is a shop of some kind but that is all the initial information given. In essence this CTF is mirroring what you would refer to as black box testing in a security or penetration testing job. Here perhaps a shop owner is concerned about their security and would like to see what if anything bad could happen if an attacker targeted their site so they can know what to patch or fix ASAP. Let's proceed with initial enumeration. I'll start with Nmap.

The initial Nmap scan reveals a common setup. There are two ports open. The service known as ssh or secure shell is open on port 22 which is operating with the tcp or transmission control protocol and is using OpenSSH 7.2p2. This allows an admin to remotely control the machine but without a password I would have to check the version to see if it is a vulnerable or patched version. Next I see that port 80 is open running from an Apache/2.4.18 Ubuntu server.

Well that is rather strange. Our initial scan revealed what appears to be a common web server but we are unable to connect on port 80. Perhaps let me try some DNS rebinding by adding this IPv4 address to my etc/hosts files so my local machine will resolve to the proper address.

It is still not loading. To double check to see if there is data and that it's not an issue from how I am browsing I like to get manual and use the command line. I used a simple cURL request to see the page.

Nice, now we are getting somewhere. This looks more like what I was expecting to be hosted on port 80. There is a webpage and I can see the store is running Magento and we are indeed looking at an e-commerce site.

It was a proxy issue I needed to configure this since in the background I am also using burpsuite to intercept and analyze requests. This just basically means I am routing all the traffic from the site through this tool that allows for more manual analysis and testing.

Sometimes, trial and error is the best teacher. So in fact the site was actually not resolving because I was going to https://10.10.10.140 and not http://10.10.10.140. Since this is for practice the site does not have proper security certificates and therefore when trying to access via https the web browser by default tries to access port 443 which is unavailable. A request in a browser to http goes to port 80 which is open and now here we are at the store.

Now when I go to see the login page I see an interesting behavior in how the server is handling the request. It is common to see a login just served from a web root directory but here I see that there are path parameters in the URL which for a Magento site makes sense since these links are interacting with a database on the backend. So the URL I get sent to when I attempt to login is:

http://10.10.10.140/index.php/customer/account/login/. The index.php before the /customer/account/login is of particular interest. Let's keep that in our notes and move forward.

I now want to see what else is on this server so I will use "gobuster" as follows:

Ok, /app with a 301 is interesting to me so I went and explored that folder. Within it I found /etc/local.xml. This config file has an install date and a key so I'll add that to my notes because keys are usually important if you find them lying around.

Also, the site is using Mage with a copyright date of 2008. Let's check the site to see what version of Magento they are running. Wow, just as I suspected they are running a very old version of Magento. This store is being setup with a 2014 version of Magento. It is always important to use the latest versions of software to have the latest patches against dangerous vulnerabilities. This got me thinking I should perhaps see if I don't have to reinvent the wheel here. Ok, this is good, there appear to be quite a few exploits within Metasploit for Magento. Perhaps what we are looking for already exists which will make this engagement a lot easier than having to code some exploits from scratch. The one that first stands out in the list of potential exploits is the authenticated remote code execution. However we will have to create an admin user to use that one. Upon doing some quick googling I come to find that there is also an exploit that allows me to create an admin user. Perfect. So this will be two steps to get the initial shell. I will have to create an admin account I can use and then run the following exploit with authenticated credentials to have the remote machine connect back to my testing(attacker) box. Here below I am looking at the exploit to create a new admin user. A few points to note are that the default username:password combination will now be forme:forme. In a real penetration test or red team engagement from a public IP you would want to change this to be secure so an attacker from the outside doesn't inadvertently use the backdoor you have just created. Here I am just on a VPN and this is a practice box so this is fine. Also, upon trying to navigate to the /admin/Cms_Wysiwyg/directive/index/ directory I see that this is not allowed.

Well this is rather strange. The directory in the exploit doesn't seem to be accessible in this version of Magento on this particular Apache server. This is going to create a big problem because without that working we won't be able to create the new admin account. But then I remembered something critical.

Do you remember the path parameters from the initial reconnaissance? I tried including index.php before the directory in the url being requested in the exploit and am now granted access to an admin panel. This is great because now that we have a path to access the admin panel we can attempt to run the exploit without it just getting 403 errors from the server.

Ok, so here is a quick overview of the python exploit code I will run against this Magento server. Like I said before you would want to modify the password for security on a real red team engagement. However, here for the purpose of this exercise I am going to just set the target URL and include the path parameter of /index.php.

Now it's time for the rubber to meet the road. Let's see if this exploit works.

Excellent! The exploit worked and the first piece of this puzzle is finally falling into place. Let's test it out. We are now successfully logged in as user "forme". There used to be another exploit that could be run within this panel but it has been patched on this version of Magento. So for now let's log out and return to the authenticated RCE code we had seen above now that we have a way for the program to authenticate with our newly created admin credentials.

Now I will move onto the other python exploit and see what needs to be modified for this particular scenario. Interestingly enough it looks like there is a php function with an argument of 'system' which will allow for the code execution. I configured it with the newly created credentials. And this highlights the importance of reconnaissance in addition to good note taking. I need the exact install date but I have that from the xml file I had found at the beginning in that /app folder. Perfect, this is the missing piece that this exploit needs to work against this particular version of Magento. The exact date and time of install are needed to proceed. Here below you can see how I modified the code:

Well, that is not what was expected. It doesn't run and python is giving some error about no control matching. I see that the module being used in mechanize so I assume there are some issues with the automated requests being sent by this headless browser of sorts.

Unfortunately, that wasn't it. I tried a few variations of the url, included the /index.php and /admin which seems to have solved that problem. Very cool. I don't want to get into all the debugging details but suffice it to say there were a few more variations to get this code running with the newer version of mechanize than when this box was first created. However, moving forward, when I tested with the system command of 'whoami' I see that I am getting remote code execution on this system as 'www-data'. This is good because now I can see if I can establish a foothold with a shell even if it is a low level shell like the one assigned to www-data. For good measure I want to make sure the script is executing on the server correctly so I try to retrieve the /etc/passwd file.

This is great because at this point I am able to do remote code execution on the remote machine. Now to have more control and possibly escalate my privileges I will need an initial shell which is an interactive prompt that allows me to control the machine remotely. I setup a simple netcat listener but had trouble. The issue was that it seems that a firewall was blocking all my attempts except on port 443. There was also something particular with the bash nesting for this to work. However, as you can see in the screenshots below I got the first shell and was able to upgrade it to a proper shell using "python3 -c 'import pty;pty.spawn("/bin/bash")'. Then you pause the session, modify it and return to an interactive prompt that now allows more editing without freezing or hanging.

At this point this solves the first challenge and from here it's a matter of just navigating to the user's desktop. In this case the user is named 'haris' and the 'user.txt' file is on their desktop.

Now from the output above when checking for sudo privileges I see that this user has access to run /usr/bin/vi and appears to have wildcard editing access on /var/www/html/*. I go ahead and open index.php in vi which is a process that I am now running as root. I then, instead of doing :wq! to exit do :!/bin/bash and I am dropped right into the root user's command prompt with full system control and privileges.

From here it is a matter of just navigating to the correct folder to retrieve the 'root.txt' flag. This was a fun box with some tricky little challenges in regards to path parameters in the url, python module debugging and finally an interesting privilege escalation at the end there. I have been learning a lot doing these challenges and I find that there are few things as exciting as getting to be "root".

PHP - Sending e-mail data from a server's localhost

noreply@blogger.com (iAmTheRealJason) — Wed, 10 Jun 2020 00:40:00 +0000

This is a fun example I created from following some tutorials on YouTube. I have built SMTP servers in previous examples, but this can be used to send e-mails from a webpage to a server for contracts or something as simple as a guestbook where an admin would like to have a system send automated e-mails to marketing, sales or management teams.

I used the PHPMailer library found on GitHub for the backend processing. For the front page I just made a simple form where the user can send a resume to a recruiter.

And don't worry this won't just let you put any name in the email text box. The e-mails need to come from a legitimate source such as the secured website where this will be hosted in production. The above was rendered from the code below. Nothing fancy here, just a simple form for submitting attachments.

Success! The form works as intended and I got the test e-mail in my Gmail inbox from my test server.

PHP & jQuery - File/image uploader

noreply@blogger.com (iAmTheRealJason) — Wed, 03 Jun 2020 16:21:00 +0000

For this example I created a page where a user can upload files & images to a web server. The items are stored and reflected so the user can see their multiple uploads. With PHP below I am handling the uploads and if the file already exists the user is notified that they are trying to do a duplicate upload.

And here this is defining the main work being done by this page. This is handling the file type to only allow images with extensions of: .gif, .jpg, .png, .jpeg. The size is also restricted to 500KB.

This is what the page looks like below with a little formatting. The alert below was triggered by trying to upload a file without one of the allowed extensions.

This is now echoing back to the screen the file size restrictions because an excessively large file was being uploaded.

In this block I create the div tags for the "dropZone" above and set the input type to handle the multiple attachments as an array.

And now below you can see what the page looks like after multiple successful image file uploads. The completion stage of the file uploads are shown during the upload. With this a user can upload images to a CRM system for sales, a profile picture for social media or a variety of other systems. The file types and sizes here were customized so this same format can be used to upload any file type of any size.

Using Google reCAPTCHA v2

noreply@blogger.com (iAmTheRealJason) — Mon, 01 Jun 2020 21:54:00 +0000

What is a reCAPTCHA? You have seen them online and perhaps have been wondering how they work. I know I have been seeing these for years but didn't really understand them until I saw the process. In this example I don't go into the creation of the system behind reCAPTCHA's, but rather here I am just showing how to use the Google reCAPTCHA v2. I have seen these used ubiquitously all over the internet and I decided to learn what they are and how I can implement them on my own sites to verify that my site's users are indeed people and not bots.

The PHP is pretty standard. I send the API a user's name, Key, response Key and IP address. Then I get the file contents, decode the JSON and verify a user's authenticity.

PHP CODE:

HTML CODE:

The HTML code for this example is just a simple sample text box form for a user's name, this can be for a username, email or even to verify if a survey is being taken by a human rather than by a bot. The uses for this are endless and that is why you can find these all over the internet.

This next part had me stuck for a moment, I had been referencing some old tutorials and now Google has buttoned down their security for this a bit. To get the correct responses the site needs to be served over HTTPS. I quickly added an SSL cert with Let's Encrypt and now it works properly. Here in this screenshot you can see a simple form box where you can enter your name. Once a user clicks the reCAPTCHA and it verifies that they are not a bot the request is accepted and I am just echoing back the user input. For an application or website I would just pipe the output to whatever database or other page rather than the echo which is done here for illustrative purposes below.

I included this to show the flow of reCAPTCHA although most people have probably seen this as they explore the internet.

Upon successful completion of the above little exercise the system authenticates that a user is authentic or not. Here since the reCAPTCHA was completed successfully and I entered my name as 'J', the system tells me it verified that I'm not a bot and that is has captured my name as 'J'. This system is particularly interesting because its initial purpose was to help digitize illegible books and now it's used to verify users as humans. So not only did I learn some cool PHP tricks while learning how to do this, I also learned a little more about internet history.

PHP - CSRF tokens

noreply@blogger.com (iAmTheRealJason) — Thu, 21 May 2020 15:51:00 +0000

In this example I created a simple CSRF token to validate a user's identity. Obviously the final implementation is going to take more than what I am showing here. But the point here is to understand what CSRF tokens are, how they are created and how they are used.

A CSRF token, is unique to each user and is created in a randomized way. It is then used to identify the subsequent HTTP request and make sure the server is communicating the right data with the correct client. Below in PHP I start a session and then you can see that the session key tied to each user is a bin2hex() function which converts a string of characters to hexadecimal values. So that it remains unpredictable it is then multiplied using the random_bytes function. Random_bytes is a function that cryptographically generates pseudo-random bytes.

The HTML is a simple submit form where a user enters their name and a CSRF token is then created. Within this code you can see that the CSRF token is created using sha256 encryption. Then when the CSRF token matches the name that is submitted the page will reflect "Your name is: (your name you have submitted)".

Here is what the output looks like when the name matches the token.

Here is a view from the Console to see what the page is doing. You can see the long encoded csrf value that is created when I enter my name 'Jason'.

Here since I haven't created somewhere to store values I am going to manually change the values for illustrative purposes. Now I put the value as changedValue0101010101. When I click submit this CSRF token will not match my name and the error message will be displayed.

CSRF tokens are used widely around the internet to ensure safety and are a great mechanism for a server to be able to identify users and to verify identities in HTTP requests.

Mouseflow for understanding customers and visitors

noreply@blogger.com (iAmTheRealJason) — Wed, 20 May 2020 23:17:00 +0000

I found this today and it's quite interesting. With Mouseflow on a web page I am able to see recorded user sessions. This is particularly interesting because you can fully put yourself in the shoes of your visitors and see exactly how they interacted with a web page. It didn't seem to capture my particles.js particles I put on the test page, but it captured everything else. So it's not perfect but it seems to accurately record all the visitor's movements and actions.

This is obviously more useful as you analyze thousands of visitors and then clear patterns can be more visible. So by taking into account what parts of a site people hover a mouse over or what they actually click on it gives a direction for what to focus on based on the site's user base.

The installation was quite simple. I included this little javascript tag:

window._mfq = window._mfq || [];

(function() {

var mf = document.createElement("script");

mf.type = "text/javascript"; mf.defer = true;

mf.src = "//cdn.mouseflow.com/projects/XX.js";

document.getElementsByTagName("head")[0].appendChild(mf);

})();

</script>

I then activated the test page from the Mouseflow owner account and after I visited the page I was able to see my recorded session.

Using Memcached to store and retrieve session data

noreply@blogger.com (iAmTheRealJason) — Tue, 19 May 2020 20:11:00 +0000

I started with creating an Ubuntu VPS. I then installed Memcached from the CLI via SSH from my local machine. I secured the '.conf' file by setting it to listen on localhost and disabling UDP. I then configured SASL support for connecting my PHP scripts to the backend SQL database.

I then added Apache and PHP to the server. Next I created a php info page and put it on the server to view the memcached information. I can see that memcached is installed and is communicating with PHP properly.

Next to get a simple connection working and some data flowing back and forth I created this simple php page with a key. This script opens a new Memcached instance to the localhost and gets the requested key. If no key is found it adds one. On the next refresh then the newly created key which is a string of text is retrieved from Memcached.

Add cPanel & WHM to CentOS VPS (Log Rotation, Configuring BIND nameserver & Backups...)

noreply@blogger.com (iAmTheRealJason) — Wed, 13 May 2020 15:50:00 +0000

For this example I added cPanel & WHM to a CentOS VPS I created. Upon installation of cPanel I did a lot of configurations including setting up the log rotations, a BIND nameserver and backups.

The installation from the command line is simple. The syntax is just a little different than most of the other posts where I use Ubuntu because that's my favorite version of Linux. However, I like to use the most efficient tools when I can and in this case it's CentOS. I have done a fair amount of scripting and automation using CentOS and Vagrant boxes so this was a cinch.

To install the latest version of cPanel from the command line the commands are as follows:

cd /home

wget -N http://httpupdate.cpanel.net/latest

sh latest

/usr/local/cpanel/cpkeyclt

From here the most difficult parts are done and the rest is quite intuitive if you've worked with servers and monitoring systems. I added my email and the nameservers to begin with. As you can see below with cPanel it is more about just knowing how to configure the system and you just select your parameters. For example at the bottom of this screen shot you can even select how you want to receive Apache logs.

Next I was able to configure the Log Rotation. Log rotation is important to not use up all of a system's resources. In this automated process log files are compressed and stored within an archive folder for cPanel.

The cPanel allows for a lot of customization. In a previous blog post I went over how to manually create Cron Jobs: https://jgardnerla.blogspot.com/2020/04/cron-job-daemon-shell-script-to-send.html. However, with cPanel it's very simple to just plug in the days and times you want updates and backups to run. The manual process is good because it allows you to do more customization but this is a good solution if you want simple administration from a GUI.

As simple as cPanel is to use there is a lot it can do. Here I synchronized the server time which is important when serving requests and handling HSTS.

The server is just getting setup but here are the initial server logs. The system is starting up and the daemon's are beginning to listen on their appropriate ports so that they can spring into action when they are needed.

And here is the BIND nameserver starting up successfully.

Now to administer the cPanel I can just return to the secure portal and begin with any customizations or configurations that are required.

Certbot server for SSL certificate (Let's Encrypt) using SHA256withRSA

noreply@blogger.com (iAmTheRealJason) — Mon, 04 May 2020 16:55:00 +0000

This is a really simple way of creating a certbot server for SSL certificates that automatically get renewed using Let's Encrypt. I just added python-certbot-apache from the command line.

Then I edited the /etc/apache2/sites-available/(TheTestDomain).conf file to have the proper server name. I kept the default request scheme and port numbers. Now to renew the certificate all I have to do is run "certbot renew" from the command line and a new certificate will be generated and downloaded to my server.

Now you can see that upon visiting the domain the connection is deemed secure because there is a proper certificate.

Here is more detailed information about the domain and the certificate.

Here is the overview information of the certificate. It is encrypted using SHA256withRSA.

And now I just quickly double checked that certificates can indeed be renewed succesfully.

Disk space utilization monitoring with email alerts - Ubuntu Linux - Apache Server

noreply@blogger.com (iAmTheRealJason) — Mon, 04 May 2020 16:45:00 +0000

This is very simple but very powerful. Within Linux you can create programs that are always executing or running silently in the background. These are called Daemons and they do everything from wake up a computer when a mouse is moved, automatically backup a server or in this case it can monitor a server 24/7 and send alerts when it notices anything suspicious or out of line.

Below I created a simple Daemon that monitors the disk space utilization and it sends emails to an account at tester@slabj.com which is the domain for the test server this is created on.

In essence an infinite loop is created and when a predefined threshold is crossed the server sends an email message to alert the administrator. The rest of the process is identical to what I covered in monitoring memory usage in this way so I won't go over that again but you can look at that article here for more clarity: https://jgardnerla.blogspot.com/2020/04/cron-job-daemon-shell-script-to-send.html.

Create a Samba file share (SMB server) to send and receive files

noreply@blogger.com (iAmTheRealJason) — Mon, 04 May 2020 16:33:00 +0000

Samba works in a similar fashion as FTP but it is more robust and can be used as a file sharing and storage system. First I created a Linux Ubuntu virtual machine and installed Samba from the command line. I created a user named tester and added a password.

I next created a user and a directory to be shared (/home/tester/samba). I configured the etc/samba/smb.conf file as below with the samba path and users. This is also not a read only server so files can be uploaded.

Next I opened a connection locally from my macbook to the server. The server is at the IP of the VPS I created and samba is located at ('/').

Connecting from the mac in this way doesn't require the CLI. From here it is GUI based and is pretty straight forward. I just connect and then I can drag and drop files into my local samba folder which will write the contents to the web folder.

Here is a sample text file I created in Atom on my macbook that I will send to the server.

And here it is on my virtual machine in a text file I opened with nano. Overall SMB creates an easy an efficient way of transferring files from client machines to a main server or vise-a-versa.

User management application using Node.js and Redis

noreply@blogger.com (iAmTheRealJason) — Thu, 30 Apr 2020 20:56:00 +0000

Here I created a user management application using Redis and Node.js. Here we can simply add and search through user detail records.

The application consists of a few components. There is the main app.js file which controls much of the application. And I used express for Node.js with handlebars to add users, create details and search through the users.

In this adduser.handlebars file I create the "POST" method with an action that will send the information below in a post to /user/add which will create the new user in Redis.

Next in the details.handlebars file below I set everything up to handle the display of the records that are retrieved from Redis.

Then I have a searchusers.handlebars file which handles the search functionality.

The main.handlebars file handles the HTML output and is quite similar to any other HTML page with the interesting differentiation of how the body content is handled. The triple curly brackets tell handlebars to display the information from Redis within this container.

And now that I've gone over the files that connect with the main app.js file perhaps it will help clear everything up a bit to focus on how the directives are being initiated. Below I am showing the different constructor variables I setup. This is a Node.js app using express, express-handlebars and I set up a few other parameters that are required.

With everything setup it's simple to create the Redis client from here.

I then set the port and initialize express within the app. I also created some middleware for the body parser, a view engine, setup the MethodOverride function. And then this next part I found interesting because here I am taking the user input from the HTML page and feeding it to Redis in a similar manner as if I as the admin were manually adding users from the command line. Next here is how the search processing is handled. The application sends post request to /user/search and if the object does not exit an error message saying "User does not exist" is returned. In the case that the object exists the instructions below are to render or to show the users the details for a particular obj. In this case I am just searching by user ID's, but this can be run with any of the fields but a user ID is usually the most unique. There may be two John Smiths within the system but there can only be one user001 and one user002.

Next in the "Add User" process I setup the application to create a post request to /user/add with the fields the user is required to enter: id, first_name, last_name, email and phone number. If there is an error it is logged to the console. If everything posts correctly then a new user is created in Redis and the user is redirected to the home page.

Now I can search through the records and add users from this Redis/Node.js application that I can access from the internet.

Cron job - Daemon - Shell script to send email alert to admins when RAM utilization hits critical levels

noreply@blogger.com (iAmTheRealJason) — Tue, 28 Apr 2020 18:12:00 +0000

In this example I am creating a daemon to run a cron job. Cron jobs are scheduled tasks that can be setup to run in an automated fashion on particular, days, weeks or even yearly quarters. And daemons are silent processes that are running in the background constantly in an alert state ready to spring into action.

First, I checked to see how much ram is free on this server at any given time. The server is an Ubuntu LAMP stack on a cloud. In this particular instance 265MB of ram are free.

This command returns the exact value for comparisons and is what I will plug into my program later on:

So now that I know my parameters for where I want my RAM to be running and when I want to be emailed about any alarming spikes in usage. The alerts.sh program I created below sends emails to tester@slabj.com whenever the free ram is less than or equal to 267MB. I set the threshold really low to test my script.

Cool. It's working now and I got an email telling me that the RAM is low. That was expected since I set normal usage as low to check my script.

And here is the email in a little more detail. You can see that I am having "root" email me whenever the RAM free size is "LOW" which is an arbitrary parameter that can be set however I choose.

Here I'm having the script echo back what it is doing to the console. This is for illustrative purposes as daemons are not to be seen nor heard from unless they are taking action.

With the addition of a while loop, this now becomes infinite. The process will start running now and won't stop unless I tell it to.

To make it more clear here I am echoing responses for either state the machine is in.

As you can see, with the Daemon running constantly the alerts are constant. This is not necessarily ideal. I could easily just exclude the echos and have my daemon run all the time without the average user noticing. However, once there are many daemons I don't want them all running in the background eating up memory space or using up CPU power.

Fortunately Linux has a cool tool just for this particular situation. Cron jobs are scheduled tasks that run at assigned dates and times. In this instance I scheduled a Cron job to check the RAM usage every Tuesday at 9:20am. Ideally you'd want to check at different intervals but since I initially created this on Tuesday a little after 9am I decided it would be wise to set the first Cron job to run in the next few minutes to test it out.

And that is it in a nutshell. I now have a program that is automated and chronologically scheduled to run at specific intervals to check system RAM utilization. Additionally, the system sends email alerts to the appropriate individuals if any administration intervention is needed to keep everything running smoothly.

JWT Tokens with Node.js and Express

noreply@blogger.com (iAmTheRealJason) — Tue, 28 Apr 2020 17:18:00 +0000

In this example I show how to create access tokens for an application using Node.js and express. JSON Web Tokens are a standard type of token that is used widely to certify user identity by a server before sending data back to the client machine.

First I sign JWT with a secret token from the client. Then the server verifies the token and reads the information if the token is valid. I also created the ability to have the tokens expire or be refreshed as is needed.

For the initial setup I just needed to make sure Node.js and express were installed and up to date. Then I added a package called nodemon to monitor for any changes and to react accordingly. To handle the authentication in a secure manner I also created a separate server for handling the main request and one that is used purely for authentication.

Additionally, in a rest file I am creating the parameters for the /posts and /login requests. The application type is json hence the name JSON Web Tokens.

The initial test to the server returns a 200 code along with the "accessToken" so I know everything is working up to this point. The access tokens are being generated.

I next modified the code to return a refresh token so that the initial token can be expired and I can give users new tokens to continue to verify user identity but I don't just have one token that can be used over and over. This is for safety too, because it helps me lock the server in essence every time a token expires.

Ok, so now that I have tokens and refresh tokens generating, I need to use those to access data. I now am getting back specific user data based on their token. Here the first post is returned for the username "Jason".

Here below you can see that a token will expire and eventually the server is locked again. Any additional requests will return a "403 Forbidden" error.

This process is actually only part of the equation. JWT tokens are used in tandem for additional security with user passwords. It is in interesting process because it allows granular control of user access to server data in a way which access can be granted, extended or restricted in an accurate and efficient manner.

Gathering and saving eSignatures from an HTML form with Ajax, PHP & jQuery

noreply@blogger.com (iAmTheRealJason) — Wed, 08 Apr 2020 17:35:00 +0000

For this example I show how to create an e-signature form where users can sign a form and then the signature is sent back to the database or server. I used HTML to construct the form and javascript to do AJAX calls with jQuery and the help of PHP. Below is the Javascript code that gets the image from the first location and saves it with the use of another php file called 'save_sign.php'.

Here in 'save_sign.php' I get the image, decode it and save the signature snapshot image as a .png file in a folder I created called doc_signs.

Here I have the output being reflected from the database. Every time a new signature is saved they are put in that document signature folder. So here for showing the concept, I am reflecting the signatures as they get saved right back onto the page. In a production app from here the only thing left to do is to know where the specific project wants to route the signatures. It may suffice to just save the document signatures along with the other customer sign-up or purchasing data.

Setting up and configuring an entire email server in the cloud on Ubuntu(Linux) for a website

noreply@blogger.com (iAmTheRealJason) — Fri, 03 Apr 2020 17:09:00 +0000

So for this example I setup an email server in Ubuntu on a cloud for a testing website I created. The process builds upon previous examples. So for this I started with installing Apache and PHP on the virtual machine to begin the installation and configuration of all the additional components.

First I installed Postfix which serves as the MTA(mail transfer agent). This is the software responsible for delivering and receiving the emails. Then I installed Dovecot as an MDA(mail delivery agent) which then more specifically delivers the emails to/from the mail server. At this point I now have an IMAP/POP3 email server and am going to install SquirrelMail on the email server to have a simple interface to manage emails on my server.

Here I added postfix to the server above and below I am confirming the service status. Everything looks good for the next steps.

Below I now have confirmation that Dovecot is active and running. The email server is up at this point.

I did a code review on SquirrelMail to make sure the configurations are correct for my server. I just had to add a few read/write access modifications to the server for this to work correctly. Also for now since this is a private email service random users can not sign themselves up. I as the admin create users directly on the server as you would normally have for a company's external email login for employees.

I then tested to confirm that I can receive emails from my gmail account and I am also able to send emails to other users with accounts on my server. I created a test account of 'tester' and another of 'squirrelone'. Their respective email addresses are now tester@slabj.com and squirrelone@slabj.com. Here 'squirrelone' has received test messages from 'tester' and myself from my gmail address.

And that's it. I have an Ubuntu cloud based email server correctly setup and configured for a specific domain I created where people or even other servers are now able to send and receive emails.

Testing TCP/UDP baseline functionality with Netcat & Curl through CLI(SSH)

noreply@blogger.com (iAmTheRealJason) — Wed, 01 Apr 2020 17:18:00 +0000

Here I am showing how to setup a simple Netcat listening server to test baseline functionality of TCP/UDP connections. I create a simple document and save it as technical.txt that I will send to my server I am testing.

Here I create the simple document.

On the server for phub.info I setup a Netcat listener at port 8888 that is ready to receive the specific document.

Now from the 'HQ-cloud-green' server I get ready to receive the document with another Netcat server.

To confirm receipt of the file I open it and view the contents from the terminal.

Great so now I can send messages back and forth but I want to test things a little further. I want to know how this connection port and the data being sent through it will be interpreted by browsers. With Netcat I can create a simple HTTP server to serve up content to browsers to see if my server is configured correctly. Here I pulled the data from the URL with cURL and you can see the HTML for the test page I am serving from the Netcat server.

And now when I visit port 8888 at my IP for phub.info (this is just a cloud droplet I spun up and destroyed after this example) I get the following output below and can confirm correct functionality of TCP & UDP.

Using a GPG Keychain to encrypt emails and any text messages

noreply@blogger.com (iAmTheRealJason) — Wed, 01 Apr 2020 16:55:00 +0000

One of the most straightforward methods for integrating PGP keys with e-mails is with Apple e-mail using GPG Keychain. You just put in your e-mail, generate a key and add your e-mail as well as a password.

Now whenever you want to send a message you just tell the program to encrypt with the key of your choosing and you get the results below.

Here is a test message.

I select to use a key I named 'newkey'.

Here is the message above encrypted with the PGP key.

Now with the key configured to my e-mail all I have to do is select and choose to decrypt.