Hey dear readers it’s been awhile,
tldr; How to avoid apple from yelling out your location to their servers
I personally like to use the Searchlight function of OSX, it provides me a fast way to access my files – but this it also sends my geolocation to apple everytime i do a search. This blogpost will be about how to disable or at least prevent the built-in search function „Searchlight“ from sending your IP-location to the Apple Servers.
But first have a look at what’s being sent:
GET /search?q=asd&latlng=48.082000,8.640000&geosrc=wifi,155.643824&storefront=143443-4,13&locale=de-DE&time_zone=Europe/Berlin&calendar=gregorian&key=montana4289 HTTP/1.1
This request was captured during a Burp session.
What you can see here in the Parameters
- q is the Query you send to the the Apple Servers
- latlng is the Latitude and the Longitude of your current (IP) location
I think it’s needless to say that those information should stay private (at least in my opinion). If you want to keep your searches fancy you can stop reading here, preventing the geolocation will change your search experience but you will gain some privacy back 🙂
So the first way – Old School /etc/hosts
The /etc/hosts is a local text file that tells the system how to resolve an IP-Address to a Domain. The clue here is to point the Apple domain api.smoot.apple.com to the localhost address of your machine (127.0.0.1) this will tell the system to resolve every request to api.smoot.apple.com to the localhost address, thus leading nowhere. To do so:
1. Open a terminal
2. sudo vim /etc/hosts
3. Enter the following 127.0.0.1 line api.smoot.apple.com
4. Clean the DNS cache sudo discoveryutil mdnsflushcache
5. All set 🙂
Second Way – Little Snitch
I don’t want to promote anything here, but the Little Snitch software is worth buying. Little snitch helps you to organize every incoming and outgoing connection, you can simply add a rule for the Spotlight search:
You want to disable the locationd Service that tries to connect to gs-loc.apple.com – forever
you are done 🙂 Privacy saved.
If you enjoy this – give me a feedback as a comment here or drop me an email at patrik.fehrenbach(at)it-securityguard.com if you guys are interested i might do a complete writeup about an OSX hardening.
today i want to share a short story of a bug i found on one of prezi’s subdomains called mailroom.prezi.com.The Webserver at http://mailroom.prezi.com is configured to redirect the Users to the Login Page of Prezi, so far so good, i found out that if you add a Domain lets say http://mailroom.prezi.com/.anydomain.com to the end of the URL it redirects to https://mailroom.prezi.com.anydomain.test,
to validate this one i created a new Subdomain called mailroom.prezi.com.it-securityguard.com, so if an attacker sets up a valid https cloned site of the actual login page a request on http://mailroom.prezi.com/.it-securityguard.com will redirect the user to https://mailroom.prezi.com.it-securityguard.com (the attacker owned domain).
This issue was worth 500$ of cash reward. The Prezi Team as always fixed this issue in less than 24 hours, heads up for this nice and skilled security team.
hope you enjoyed.
I’ve recently set up a honeypot tool called Kippo, Kippo runs a virtual SSH environment and tracks all the SSH bruteforce attemps on our Server. We started the test on third of November and got about 4000 bruteforce attempts on our Server, what is remarkable here is that almost all of the logins came from servers based in china.
Our research showed that almost all the attacking machines run the Windows IIS Webserver, we are currently not sure wether those machines are zombies (hacked machines with the aim to hack other machines) or if those servers are explicitly designed to attack wide ranges. Till today we’ve collected about 2500 distinct Username/Password combinations,
the Top 10 List of combinations is below:
| Username, Password
I collected some charts of the latest attack trends if you want to find out more, have a look at honey.it-securityguard.com
We will keep you up to date with the latest trends of our analysis,
hope you enjoyed!
All the best
during an installation for one of our customers, we had to install a suitable chat plugin for WordPress. There are a lot of them but we decided to choose the first one that comes in the row. Due to the fact that we like security we of course tested the plugins against some well known vulnerabilites, the result was frustrating. Every single plugin of those we’ve tested is vulnerable to stored cross site scripting.
Since we are white hats we’ve reported all of them first to the vendors, only one of them (https://wordpress.org/plugins/wp-live-chat-support/) anserwed us and wanted to have more information, big thumbs up them! for this reason we’ve waited to publish this until they’ve fixed the issue.
1.) WP-Live Chat stored Cross Site Scripting
2.) MyLiveChat stored Cross Site Scripting
3.) Provide Support stored Cross Site Scripting