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.
This post outlines a security issue with Discord due to how it handles deletion records and localised caching for media posted in shared channels. The issue Media posted in Discord channels is written to the filesystem of every channel participant, even if that media is deleted from the channel immediately after being posted. It's important to note that this form of caching is a common practice and typically employed to facilitate quicker loading of content. However, the fact that Discord allows for the deletion of channel posts without any clear evidence of the deletion may present a potential vector for attack that I think all Discord users should be mindful of. In an extreme hypothetical scenario, consider if a malicious party was to post indencent images of children or bomb-making plans to a wide-audience Discord channel, then immediately delete the posted images and proceed to file an anonymous report to law enforcement agencies alleging the participants in the channel have copies of that data stored on their filesystems. Whilst some might consider this attack unlikely, the possibility remains, particularly if your threat-model includes state actors with a desire to get their hands on your devices. Finding your Discord cache Open File Explorer and navigate to %AppData%/discord/Cache/Cache_Data Right-click in the window and navigate to Open in Terminal Rename all files in the folder to use the .png extension by running the command:Get-ChildItem -Path "$env:APPDATA/discord/Cache/Cache_Data" -File | ForEach-Object {Rename-Item $_.FullName -NewName "$($_.BaseName).png"} Unfortunately, Discord's lack of configuration options adds to this issue. At the time of this blog post, there are no settings present within the application that allows for cache control. My recommendation is simply to be careful what Discord channels you choose to participate in.Alternatively, you can also opt to employ the use of a Windows Task Scheduler to automatically run a PowerShell script that deletes the folder every 24 hours. Whilst this doesn't solve the problem, it may offer some assurance that cached media won't persist forever. This approach of course also doesn't prevent forensic recovery. Set up a task scheduler to auto-delete your Discord cache Open a notepad file and paste this command into it Remove-Item -Path "$env:APPDATA/discord/Cache/Cache_Data" -Recurse -Force Save the file somewhere you won't lose it, such as to your Documents folder, and rename it to use the .ps1 file extension (such as discord-cache-deletion.ps1). Open the Windows Task Scheduler by searching for Task Scheduler in the start menu. Navigate to Task Scheduler in the start menu. Click on Create Basic Task in the pane on the right side of the window and then add a name and description for the task. Configure the Trigger conditions to run Daily In the Action step, select Start a program In the Program/script field enter powershell.exe and in the Add arguments field, enter the file path -ExecutionPolicy Bypass -File "C:/[YOUR_ACCOUNT_NAME]/Documents/discord-cache-deletion.ps1" Click Finish to save the task.
Over 50 years ago a coin entered circulation. A coin that once belonged to a man named Sean Creamer. Engraved on the faces of this coin are the wordsThis once belonged to Sean Creamer 58 Henry St Limerick — worth £5 to me if returned Today this mystery coin resides with me, after what I suspect has been a very long journey.I'm not sure who Sean Creamer is or what motivated him to inscribe his message, though the words do make me think there's a certain desperation in the creative fight to declare our existence. Much like the reason many of us post online, we're participants of the past speaking our own timeless messages like a familiar chapter in a tattered book — messages that we hope might survive the test of time and someday outlive us. "See me. Remember me. I was here." Perhaps this small relic of the past is intended to function as more than a memento, a keepsake, or a souvenir. Maybe it's an artifact of history that truly belongs to nobody, only temporary caretakers during its journey, and serves to teach an important lesson about value.Maybe a value worth more than we ever realise at the time.
Last week I fell into the abyss of watching random YouTube videos and at one point landed on a video featuring LARQ, the highest valuation company to ever pitch on the popular US television show Shark Tank. The product line they were offering was simple – self-cleaning water bottles that use UV light to purify water. Intrigued to find out if the company had found success since airing and intending to purchase one of their bottles for myself, I registered to their site.Shortly after registering I noticed a security vulnerability, and duly reported this to them that sameday. My report was well received, and as a thank you, they kindly offered to send me any product I wanted for free.Hi Jacob, Our Digital team is very grateful for your time and the issue you have brought to our attention, we would be happy to ship you any LARQ Product of your choice as a thank you! Please be so kind as to confirm which product you would like and your shipping address. Thank you! I opted to select the LARQ Bottle PureVis 740ml (insulated), as I figured this would have been my preferred choice for purchase. Thanks to the LARQ customer experience team for sending me this free gift.
All major UK ISPs seem to stipulate contractual terms which specifically prohibit their customers from employing the use of their home broadband service for security testing activities, regardless of the lawful basis for those activities (such as when penetration testing and bug bounty engagements are authorised). Below are the relevant extracts I pulled from those associated policies. If you're a UK customer of these services and engage in any bug bounty or penetration testing activities, it's likely you've already agreed to comply with these terms, and may therefore be at risk of having your home broadband service suspended for violating them. POLICY EXTRACT Source: Vodafone Acceptable Usage Policy 2. Your use of the Service ... 2.9 You must not use the internet to send information that has forged addresses or are deliberately constructed to adversely affect remote machines or other computer systems. 4. Network security 4.1 You must not take any action that could inhibit or violate the network security of any person or company (including Vodafone) or that could adversely affect their use of the internet. POLICY EXTRACT Source: BT Acceptable Usage Policy Security Violations The BT Network may not be used to violate the security of a network, service or other system. Examples of security include hacking, cracking into, monitoring, or using systems without authorisation; scanning ports; conducting denial of service attacks; distributing viruses or other harmful software; smurf attacks; and unauthorised alteration or destruction of websites or other information. POLICY EXTRACT Source: Virgin Media Acceptable Usage Policy 5. Your responsibilities - Virgin Media’s systems, services and equipment ... 5.2. Specific prohibited acts in relation to Virgin Media’s systems, services and equipment are: ... 5.2.5. attempting to circumvent user authentication or security of any host, network, or account (also known as “cracking” or “hacking”). POLICY EXTRACT Source: Sky Acceptable Usage Policy Do not violate anyone's systems or network security You must not use Sky Broadband, or allow someone else to use Sky Broadband, to violate Sky’s networks’ security or any third party’s system or network security by any method including: ... You must not send, receive, store, distribute, transmit, post, upload or download any materials that are designed to violate Sky Network’s security or any third party’s system or network security. Examples of such prohibited material may include (but are not limited to): ... • tools designed to compromise the security of other sites; These terms make up the components of valid contracts, and as ISPs are in the business of making money, this raises a few questions. Do ISPs actually care what their customers do with their service? How enforcable are the relevant legal obligations in practice? Are ISPs actively monitoring customer traffic for attack characteristics? Do reports of abuse ever result in ISPs terminating services? Such unanswered questions might incentivise security professionals to consider the wider use of commercial VPNs.
For some voluntary work I did, The Royal Mint sent me a limited edition 22 carat gold coin which commemorates the life and legacy of the great mathematician and codebreaker Alan Turing. This included bespoke packaging that contained a small 'Innovation in Science' series booklet detailing Turing's remarkable achievements, and featured one of his most famous quotes: We can see only a short distance ahead, but we can see plenty there that needs to be done ~Alan Turing I would like to express my thanks to The Royal Mint for this thoughtful gift.