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.

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.

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

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.