tkp

About a month ago, I arrived back to work after vacation with the understanding I was getting a promotion. Turns out it was the opposite and being included in a reduction in force was the card I was dealt.

Nearly 4 years of hacking away at some of the largest web and mobile applications in the world ended on a whim. Many vulnerabilities discovered, new methodologies designed, and a lot of time staring at network traffic.

Instead of immediately searching for a job, I've been writing lots of code and building a search tool from scratch. Setting up and hardening servers, getting PHP + Python + Javascript + HTML + CSS to play nice together, going through the beta testing phase, and just remembering to take time away from the computer has been a journey.

Anyways, life is a rollercoaster. I hope to have this search tool complete and publicly accessible soon. It's not a security tool, but just something I made because I wanted to learn more about the backend instead of just attacking it.

https://pentester.land/writeups/ just got updated. their last update was in october, so there are a lot of new write ups to dig into.

Kinda depressing to see this bug only get a $1337 payout: https://bugs.xdavidhu.me/google/2021/01/18/the-embedded-youtube-player-told-me-what-you-were-watching-and-more/

Seems like privacy related leaks should be worth more, especially considering the hundreds of millions of dollars of GDPR fines being levied against companies for leaking private user data.

I've been experimenting with the iOS Lockdown mode on iOS 16.2.

Some interesting observations are the Web Audio API being disabled in mobile web browsers (Firefox, Chrome, Safari, Brave, and DuckDuckGo).

Additionally, the "autocomplete="one-time-code" is disabled in mobile browsers and mobile apps. No quick access to SMS based One Time Passcodes (OTP).

I made a browser extension that allows you to search an Instagram account's posts by text (caption, tags, locations).

https://addons.mozilla.org/en-US/firefox/addon/insta-search/

Otherwise on Instagram you've got to manually scroll through all of an account's posts and click on every single thumbnail to figure out if the post contains the text you are looking for.

I shared this on LinkedIn because supposedly when you're unemployed, that's where you're supposed to "get noticed". Then I realized, infosec.exchange may also appreciate it.

Saw a post about a potential Punycode attack on a popular MacOS package manager using Google ads. ( https://github.com/Homebrew/install/issues/866 ). Not sure how the attackers are pulling that one off. The 2nd image in this post shows that Google search is outputting punycode properly (at least for the character I used).

While taking a look at the ad buying process I decided to see if I could recreate all of the reports I've seen for years about spoofing urls in ads. Turns out the trust of the business name is the issue. Since it's election season, why not use Whitehouse.gov as an example?

Google search displays the final destination link in the results, which makes the url of that ad more clear, the others, not so much.

I should note I didn't complete the buying process by paying for the ads, so I can't fully confirm these ads getting pushed into the wild and seen by others. These are just previews of the how the ads are supposed to look according to Google.

Starting going through the Cybersecurity and Infrastructure Security Agency's (CISA) Industrial Control System (ICS) trainings at https://ics-training.inl.gov .

So far they have been really good high-level overviews of ICS, which has been a nice break for someone like me who typically spends all their time deep in the weeds of technical research.

I orginally put this on LinkedIn , but realized I should probably contribute to Infosec Exchange.

If you've ever wondered what rate limiting from the back end looks like, here's an example.

The purple box is a command run on my local machine which sends 10 requests very quickly to an external server's web application.

The green box is the web server's Redis instance logging each "request".

First, the instance checks if the request IP address EXISTS. If not, it is SET as a key with a value of 1 and an expiration of X seconds, X being predetermined. Each request from that IP address will increment (INCR) the value by 1 if the key has not expired.

This instance data is used in a PHP script for each search to check if a key exists and if so, is its value greater than the limit defined in the script. If the limit has been exceeded, the script will not perform the search.

The blue box is a visual proof that the server has stopped returning the full request data due to the IP being rate limited.

If you look closely at the green box, you will notice there are multiple INCR. This is because the IP address is saved for an extended limit check.

There are issues with just limiting based off IP, but I'll address those further down the line. Things could be tricky since the web application does not require user registration.

I built this limiter from a variety of public documentation and hope to release it as an open source project at some point. Some of the documentation was vulnerable to simple bypasses, so there's likely a lot of by buggy limiters out there.

I'd prefer to not rate limit users, but with limited server resources, it seems like a wise move.

launched a search tool today at https://shoplurker.com

it was built from scratch using php, sql, html, css, javascript, python and bash

having fun with https://github.com/ECTO-1A/AppleJuice before it gets patched.

mobile device on left is iphone 13 pro running ios 16.6. mobile device on right is iphone 10 running ios 16.2

hello friends. i'm still hacking away at a variety of web and mobile apps for work, while also finding free time to develop things.

my most development project is https://roads.today, which creates time lapses from publicly available traffic camera photos.

there are some upcoming snow storms and they are always fun to watch pass through the sierra nevada mountain range.

The Folsom, California reservoir capacity went from 34% on December 29, 2022 to 63% on January 1, 2023.

Source: http://cdec.water.ca.gov/resapp/Rescond

If my math is correct, that 29% increase converts to over 92 billion liquid US gallons (92,323,363,830) or 349 billion litres (349,481,948,380) of water added to the reservoir in 3 days.