Blog

  •

    Create an AD sign-in honeytoken with Teams alerting

    5.00 of 38 votes

    This post aims to provide some insight into a new approach at tackling a particular type of phishing, and guidance on how to self-host your own honeytoken to help defend against it. Click here to skip to the self-host honeytoken generator AitM (Adversary in the Middle) attacks targeting companies is nothing new. Attackers will typically recon to identify a company Azure Entra ID login page, such as the one we're commonly familiar with at https://login.microsoftonline.com, and then clone or proxy this page including all the cosmetic assets responsible for custom branding. After cloning or proxying the page, attackers will attempt to serve this in phishing campaigns against unsuspecting employees. These cloned/proxied pages are tailored to harvest employee AD credentials and MFA tokens by means of interception, which can then be used to compromise company accounts. A solution? What if you could receive an immediate alert before any phishing could start? An alert that tells you the domain and IP the cloned page is hosted on? This would enable you to block access to that domain/IP before any phishing campaigns could even begin. I recently came across an interesting blog post by Thinkst, a trusted and reputable deception technology supplier that specialises in detection engineering. They provide a number of free canarytokens, which includes the new release of an Azure Entra ID token, aimed at producing high quality alerts to help with this exact problem. I got straight into testing this myself. In summary, the way it works is you add a piece of code to your Azure Entra ID sign-in page, then when an attacker clones and hosts that page on their own server your code detects this and sends you an alert. For anyone interested in a simple deployment, Thinkst certainly have the best offering, and I'm a strong supporter of pretty much their whole product line. That being said, I did notice a few ways to improve the efficacy of this particular concept through a self-hosted solution. Below were my observations. Thinkst Azure Entra ID Canarytoken Pros Super simple to deploy Reputable supplier Free Token can be easily managed Cons Token pattern is consistent which may be easier for an adversary to identify than a self-hosted asset Common privacy extensions strip the token out Customer remains reliant on Thinkst to maintain hosting responsibility My Self-Host Token Pros A bit harder for an adversary to detect No detection from privacy tools (from my testing anyway) Always free Easier to hook directly into sending automated MS Teams alerts Cons A few more steps to deploy No ability to easily manage the token Requires a web server running PHP If you're interested in self-hosting your own token, I have created a form below which will automatically create the necessary files for you to self-host. All you need to do is: Input your company name. This is used to make the token characteristics a little more convincing. Input the directory path of where you want to host your static asset on your company website. I recommend creating a custom folder just for this purpose. Input a Microsoft Teams webhook URL, which you can create by following the Create Incoming Webhooks guide. Once you submit the form, the necessary files will be created in your browser, and can then be hosted as per the guidance provided once you submit the form. Please note: The form below executes client-side only. Files are dynamically generated by your browser using the values you submit in the form, and your browser then makes those files available for download. No submitted values, secrets, or files are sent to nor stored by my server at any time. When you close this page, any files you created but did not download while it was open will be lost. Company Name: Web Host Path: Webhook: Submit   Step 1   Download the above 3 files, and host them at your specified URL path here: Step 2   Download the above CSS file. Navigate to your Azure Entra ID login customisation page. Choose Layout, scroll down to Custom CSS, click Browse and choose the downloaded file. Here is a summarised breakdown of the files created, which you are welcome to review yourself: The PNG image This is a small transparent image, which my code generates using randomised size dimensions. The reason the image uses randomised dimensions is to evade privacy focused browser extensions, which commonly flag 1px images as tracking pixels and strip them out to prevent them being served to the browser. The filename also incorporates the specified company name in a dynamic format to make it look more natural to an adversary should they clone your Azure Entra ID login page. The PHP file This contains the core code responsible for detection and alerting. First it ensures the image is served without delay, then it executes a number of functions responsible for checking the HTTP referer. If the referer domain is anything other than the host upon which the .php file resides or the two official domains expected from Microsoft for legitimate AD login, it will proceed to fire an alert to the MS Teams webhook you specified in the form. This alert will contain the unexpected refer domain and the IP address of that domain. The .htaccess file This contains a forced redirect to the PHP file for any browsers which attempt to render the PNG image. The PHP file is responsible for serving the image, and then executing the remainder of its code. The CSS file This contains a CSS 'background' call to fetch the PNG image from your specified web host directory path. Once this is uploaded to your Azure Entra ID login page as custom CSS, it will execute every time the page is loaded in a browser. An example MS Teams alert when the honeytoken triggers can be seen below:

  • A DNS obfuscation technique proof of concept

    • General
    • by Jacob Riggs
    • 21-01-2024
    4.87 of 75 votes

    For my Deadswitch project, I've always been conscious of threat model and wanted to ensure the architecture employed a layered approach. One consideration was DNS tracking mitigations, and what I could do to help make efforts to identify customers more expensive to an adversary.One of the ways Deadswitch works is each customer is issued a uniquely generated subdomain that they can access in order to trigger/terminate their individual switch. These subdomains point to automatically spun up 'user instances', which host a lightweight web app portal that the customer can authenticate into in order to trigger/terminate their switch.One of the threats to user instances hosted on unique subdomains are sophisticated adversaries (such as APTs) that may occupy and monitor network level traffic. This means that when a Deadswitch customer visits their issued subdomain to access the trigger/terminate form, that HTTP traffic will be easy for the ISP to identify in their traffic logs. If the ISP is cooperating with a state actor, then the ISP could share knowledge of the subdomain which could enable the user instance to be identified and attacked (such as DoS).On this page I have created a JavaScript-driven PoC which aims to help obfuscate the destination subdomain from ISP identification. In practice, when a customer creates their own switch, the following will occur: A unique link will be sent to their email inbox along with a 6 digit code (for example 133337). The link will direct them to a Deadswitch web page. On that web page will be a form field (like the form field below). To access your user instance, please enter the code we emailed to you here:   SUBMIT   When the correct 6 digit code is entered (for example 133337), the customer will be presented with a button on the page. When clicked, the button will execute JavaScript which cycles the customer's browser through 9 uniquely generated Deadswitch subdomains randomly in the background. These 9 subdomains point to honeypot user instances, and help to obfuscate the 1 subdomain that hosts the real user instance, which is then presented to the customer in a new browser window. Since the ISP traffic logs will show 10 GET requests to randomly generated Deadswitch subdomains, the ISP will not know which 1 of these 10 is legitimate (if any). The idea of this is to help obfuscate customer's access to their user instance when not already employing the use of a VPN. As can be seen from the video above, the client browser automatically makes all GET requests to honeypots silently in the background. This is further supported by the Wireshark packet capture video below, where all requests at network level share no unique characteristics that might enable an adversary to identify the legitimate switch subdomain. To further support the above experiements, here is a diff covering the packet capture of the request to the honeypot (left) against legitimate switch subdomain (right): https://www.diffchecker.com/rYxzcrG9 And here is the control test diff covering the packet capture of the request to the honeypot (left) to another honeypot (right): https://www.diffchecker.com/yGeoRuRH This PoC example is made using JavaScript for demonstration purposes, but in practice the authentication would take place server-side (using PHP). In such circumstances, if the 6 digit code supplied was valid, then the server would dynamically generate the JavaScript responsible for the honeypot URLs and serve this back to the client in the response. All flows and code execution would be silent, seemless, and occur in the background so not to impact the user experience.In my view the costs to deploy this approach are minimal, as the network overhead is small and honeypots represent lightweight single-page applications. Furthermore, employing the use of a wildcard SSL certificate on the *.deadswitch.com parent domain means that certificate transparency logs will not expose the existence of individual subdomains. If anyone is interested in leveraging this approach in their own projects, I've added a PHP example implementation here.

  • Write-up of a reMarkable security vulnerability

    5.00 of 100 votes

    This is a write-up on an integer overflow vulnerability that enabled me to zero balance any order at reMarkable. I was looking to buy a reMarkable tablet as a gift to my boss (for putting up with me) and noticed they had a VDP. Unfortunately, they don’t offer bug bounty rewards, but curious about their ecommerce setup, I figured I’d take a look at the application checkout logic to see how it works.The first step was to create a new order: Observing the raw HTTP traffic I could see that adding this to cart naturally creates a PUT request to the https://api.store.remarkable.com/v2/carts/77b5a997-500d-4ea6-9f53-2958a9c99cb2/items endpoint (where 77b5a997-500d-4ea6-9f53-2958a9c99cb2 represents a uniquely generated 128-bit value UUID for the cart): In the request body we can see the sku value represents the item code and the quantity value for the selected item is represented as an integer.We can tell this is an integer by the fact it’s not encased in quotation marks. Nothing unusual about this, it’s just important to note the difference between an integer and a string, as depending on how the backend handles these values there might be differences in how the application behaves.Where the quantity value is a string: Where the quantity value is an integer: When the natural request is processed by the server, we observe a 200 response where we can see the arithmetic operations performed on the quantity are consistent with what we expect. They’re clearly being stored in the database as an integer. Now let’s try modifying the request integer value to 999999999999999 (15 digits): We observe another 200 response: And here is the bottom part of the same response: And if we refresh the checkout page in the browser, we can see the quantity has been updated. The backend has processed the given quantity integer value with the expected arithmetic operations, which calculates the total value amount by simply multiplying the price of an item by its represented quantity. Why is this interesting? Well firstly, it’s possible that adding this many items to a unique cart ID could temporarily affect stock analytics. For example, if there are only 1,000 units of a particular item in stock, an attacker adding an amount beyond this to their basket may render an “out-of-stock” error for other legitimate customers attempting to make purchases, but this really depends on how the application is configured to handle stock control.The more interesting element is the fact that there doesn’t appear to be any server-side input validation limiting the quantity integer in requests to a maximum value.Remember we submitted 15 digits before? What response might we get if we submit 16 digits? And if we now refresh the checkout page in the browser? So to recap: 999999999999999 (15 digits) produces a total of £33,597,677,788,712,864 9999999999999999 (16 digits) produces a total of £0 To understand why this happened, it’s important to understand how integer values are stored by a database. Integer values are stored in databases using a specific data type that determines the range of values the integer can hold. The storage size and range depends on the database system and the specific integer type chosen. In this example, the backend is likely using a 64-bit signed integer to store the quantity values. When the quantity value is increased to 16 digits, it exceeds the maximum value that can be stored in a 64-bit integer, resulting in an integer overflow. This vulnerability exists because the server is attempting to store 16 digits inside an integer variable value which is higher than the maximum value the variable can hold. When an arithmetic operation results in a value that exceeds the maximum value the integer type can store, the value wraps around to the minimum value and continues counting up from there. Similar to how a seven-digit odometer within a car works to display the mileage - it can only store seven-digits, so if the counter hits 9999999 miles then the next integer up will roll it back to 0. To mitigate this vulnerability, the application should ideally perform input validation checks to ensure that submitted quantities are within acceptable ranges and use appropriate data types for database objects that can handle the range of values the application expects to process.This was reported in-gratis and in good faith to reMarkable within 48 hours of discovery, in accordance with their VDP. My report was well received and they have since provided recognition by linking to my blog from their website at the bottom of the Vulnerability Disclosure Policy page.I have since purchased my boss a Type Folio bundle (which was wrapped spectacularly I might add). He takes a lot of notes in the course of his work, so expect it will serve him well, and perhaps persuade him to read more of my write-ups!

  • Write-up of a simple Activision security vulnerability

    5.00 of 65 votes

    This will be a short write-up as this one took no more than two minutes to identify from start to finish, and I actually found it laying in bed half asleep on my phone. Be warned, it's so simple it's underwhelming. The vulnerability is not device specific so this write-up will use desktop device screenshots for ease of reference.My friend forwarded me an InfoSec related job advert for Activision via LinkedIn on the weekend. I took a quick look as I’m a long-standing Activision customer, but the role wasn’t a fit for me. However, reading through the job description I noticed the benefits at the bottom of the page and was curious what entitlements Activision employees enjoy. I took note of what appeared to be a custom employee benefits portal. As bug hunters know all too well, 'custom' often = vulnerabilities. I could see employees enjoyed a 30% discount from a number of stores when registering with their employee email address.I quickly registered to see what the standard account creation and email activation process looked like... I proceeded to input my personal email address and following registration form submission, I immediately received an automatic account activation email. My account was automatically activated? No double-opt in? Interesting! You can probably guess what I tried next... Success! I managed to register and auto-activate registration for what the application might recognise as an employee account. Now to see if the 30% discount applies when adding items to cart. Seems promising. Now to see if I can reach the checkout page without any validation requirements. Success! From here the payment process gets handed over to the Shopify API for completion. I of course made sure to not proceed further and began writing up my findings for responsible disclosure. In determining the potential scope of impact I was able to see that the following stores were affected by this vulnerability: https://gear.blizzard.com https://shop.callofduty.com https://shop.callofdutyleague.com https://shop.overwatchleague.com My report was provided sameday, in-gratis, and in good faith. Given the size of Activision's customer base, the low complexity required to exploit this particular vulnerability, and the financial impact it could have, it's of course possible I wasn't the first to find this. For this reason I also encouraged Activision to consider investigating if any abuse may have ocurred prior to my report. Repeat efforts were made over the span of 109 days to serve Activision notice of this vulnerability and encourage remediation prior to public disclosure. At the time of this write-up publication no official response had been received.

  •

    How to carry out mobile app risk assessments

    5.00 of 91 votes

    If you work for a large organisation, the chances are that a requirement may occasionally surface for a new mobile app to be deployed on company-issued mobile devices for staff usage. This post is to help guide security analysts and engineers on how they can use MobSF to carry out basic internal security reviews of any mobile applications that their respective organisation may intend to deploy for their end users. Please note that this blog post is high-level, intended for moderately technical audiences, and is limited in scope to only static analysis of Android apps. I may cover more involved assessment methodologies via dynamic analysis in a future post. Requirements A Linux OS (in this guide I'll be using Kali) Some basic CLI experience A dedicated Android device which is rooted (optional)   Installing and deploying MobSF To get started we can leverage the open-source Mobile Security Framework, more commonly known as MobSF, to automate static analysis and generate a report. Install MobSF using: git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.gitcd Mobile-Security-Framework-MobSF./setup.sh Update MobSF using: git pull origin master. venv/bin/activatepip install --no-cache-dir --use-deprecated=legacy-resolver -r requirements.txtpython manage.py makemigrationspython manage.py makemigrations StaticAnalyzerpython manage.py migratedeactivate Deploy MobSF using: ./run.sh 127.0.0.1:8000 Obtain an APK file for analysis: To interrogate the compiled binaries and functionality for analysis, MobSF requires the raw APK file of the desired app. APK files can be obtained a number of ways, and the process can differ between free and paid-for apps. I plan to create a separate blog post in the future which helps guide through the process I've standardised for myself involving a rooted Android device. For now I might recommend trying third-party services such as APK Pure. Upload an APK file for analysis: From here you can upload any .apk binary for static analysis. Note, any uploaded file should be a raw .apk and not the compressed .zip container or .xapk package in which the .apk files usually reside.If an .xapk package is sourced, you can extract the raw .apk files from this by renaming the filename to a .zip extension. For example, if the filename is com.riggsmobileapp.xapk, rename this to com.riggsmobileapp.zip, open the .zip, then pull out the .apk file(s) you wish to analyse and submit them into MobSF for analysis. Third-party app providers also reserve the ability to supply these files and may do so upon request. Review the generated report: Once static analysis is complete, MobSF will produce a report detailing its findings. These can be interactively navigated using the categories listed within the left sidebar, or exported into a PDF file using the PDF Report button. What should your assessment of the MobSF report aim to cover? This will largely depend on the mobile app and on your organisational risk appetite for introducing new mobile apps into their environment. Below I will expand on some key areas I think are worth reviewing, but please note that these should not be considered exhaustive. Application permissions The functionality and access of an app are determined by its permissions. These permissions vary, spanning from the ability to retrieve data stored on the mobile device, such as contacts and media files, to operating certain hardware components like the device's camera or microphone.This information can be found in the following location of the report: Permissions The Permissions tab provides detailed information about permissions extracted from the AndroidManifest.xml file. This file in an Android application is responsible for declaring the permissions the app needs, along with many other settings. Within this tab you should see a list of permissions the app has requested and brief descriptions of what those permissions allow the app to do. You should pay particular attention to any permissions which do not align with the app's described purpose and that can potentially compromise user privacy or the device security. Network traffic In static analysis, it's useful to assess specific destinations, or servers, to which an app dispatches data and the sources from where it extracts data. This means it's useful to consider the server's credibility, the integrity of the connections (whether they're all secured or only a fraction of them), and the nature of information returning via these links (for example, whether malware or phishing attacks are originating from a previously considered safe URL).This information can be found in the following locations of the report: Reconnaissance > Hardcoded Secrets Check for any URLs which might be hardcoded as destination servers. Assess if any shown are unexpected (in the context of the application purpose) and consider manual review of their IP reputation and conduct reverse-lookups to identify any anomolies. Malware Analysis > Domain Malware Check Check for any URL domains within the report which indicate a suspicious status. This may indicate that the app communicates with a server domain that is known to have been associated with malicious activities in the past. While the report can offer some information about the usage of secure data transfer protocols, it may not provide a complete picture. The application could make decisions at runtime about which protocols to use, or it could use different protocols in different circumstances. For a more thorough analysis, you might need to intercept and inspect the application's network traffic using a tool like Burp Suite. Secure data transmission Android platforms by default employ TLS to protect all data transmitted to or from an Android device. However, developers have the discretion to modify their app's network security settings to permit unencrypted connections. For this reason it's useful to validate that any network configurations observed are optimised to leverage secure protocols.This information can be found in the following locations of the report: Scan Options > View AndroidManifext.xml The report will provide a detailed analysis of the AndroidManifest.xml file, which could include usage of insecure protocols, if they are declared. Security Analysis > Code Analysis Here, you can find the analysis of the .java or .kt files. Look for usage of HTTP/HTTPS calls in this section. It might show insecure HTTP calls (http://) if the application is using them, which would indicate that it is not using secure SSL/TLS protocols for those calls. Application components It's useful to inspect the fundamental components of the application, including the programming language, techniques, libraries, frameworks etc, to ensure that the application employs safe elements devoid of known vulnerabilities.This information can be found in the following locations of the report: Components > Services This displays a list of all the services used by the Android application. A service is an application component that can perform long-running operations in the background, and it does not provide a user interface. It can continue running even if the application's main process is not active, or the application is in the background. These services can be important from a security perspective because they can perform actions without direct user interaction. For example, a service could be used to periodically sync data with a server, or to run some computation in the background. Components > Libraries This section offers a detailed view of the native libraries that the app includes, which can be helpful in the security analysis of the application, as by knowing which third-party libraries are used, you can check if these libraries have known vulnerabilities. If the version of the library used by the application is known to have security vulnerabilities, then the application might be vulnerable as well. App store records It may be useful to conduct a thorough analysis of the data available on the app store. This includes information like the identity of the developer, the number of app installations, the frequency of updates, the presence of a process for reporting bugs, and any negative or fraudulent app reviews. Additionally, it's worth examining the developer's credibility for indications of fraudulent activities. Warning signs may include nonfunctional 'contact us' links, irrelevant information on FAQ pages, or a collection of unrelated or suspicious apps within their portfolio. Third-party intelligence It can also be useful to consider looking for assessments or reports shared by other researchers to gain additional insight. For example, you could try submitting search queries to Google such as "[INSERT APP NAME HERE] vulnerability" or "[INSERT DEVELOPER NAME HERE] data breach" to identify if any evidence exists within the public domain to suggest that your organisation's adoption of the app could introduce risk. My risk report template Below I have included a copy of a Microsoft Word document template I drafted to help with documenting the appropriate risk report findings. My recommendation is to consider using a document like this to evidence your analysis and archive it, along with the full MobSF output, within your organisation's filesystem for auditable reference. This should help the business understand any associated point-in-time risk a particular mobile app may carry, and can be relied upon as evidence when required to demonstrate that you have exercised a reasonable degree of due diligence. Mobile App Risk Report Template (.DOCM) Mobile App Risk Report Template (.PDF)   Please note that the Microsoft Word .docm file made available above includes a small VBA macro script I added which basically allows for the risk level ratings to be easily selected from within an interactive drop-down menu in the document. The script then auto-populates the corresponding cell with an appropriate background colour. This was added purely for convenience. If you have any concerns, you can still use the file as a template without permitting the macro functionality, which in most cases should be blocked by default anyway. The key is to present your report findings in a clear, concise manner, offering a complete picture of the potential risks, while also giving actionable recommendations for mitigating these risks. Remember to adjust and customise the template as necessary to best suit the requirements of your organisation and the specific nature of the app that you're assessing.

  •

    I got a cat

    5.00 of 88 votes

    Please welcome my new feline companion, Mr Slevin. Slevin is a domestic semi-long hair tabby, born 3rd June 2021 alongside his brother and sister. He was always a bit slower than his siblings. Prone to bumping into things, falling over, and spectacularly failed escape attempts. I adopted Slevin at age 1, after he had seemingly grown enough to produce an abundance of fur that somehow sticks to all upholstery. It took him a while to adjust to the new environment, but I think he’s settled in well, and I’ve fortunately got the assistance of my Roomba to help keep his fluffy deposits under control.Just like most cats, he’s rather nocturnal, and prefers the cover of darkness to explore in all his feline curiosity. This works well for my insomnia, as I’m often awake in the early hours of the morning, incidentally curious about hacking all the things. It’s comforting to share his company. Whilst my exposure to cats has been somewhat limited, I’ve always enjoyed their company. Just like hackers, they seem to exhibit natural information seeking behaviours, a daring curiosity of their environment, and share an innate desire to understand and test boundaries. I have no doubt we'll enjoy each other's company for many years to come.