I'm about to deploy a small sideproject I've been coding the past 2 weeks and I want to make sure that the site is served over https. Since I'll likely put it on a subdomain to my own company and I don't want to go get another signature from a public authority I thought I would try to roll my own mini-CA chain which I can use for these types of situations.
Continuing with the theme of wifi attacks, tonight I'm looking at the SSLStrip tool.
I'm spending the night learning about the tool ettercap. May as well write down what I learn for future reference.
This is a hack I disclosed around a year ago to the company in question. It involves the company SF, which has a near monopoly on mainstream cinema in Sweden. They have theatres in most Swedish cities.
I'm currently playing around with MMS for a possible hack. So I needed to access more "raw" data in terms of ids etc. If my understanding is correct (currently wip) MMSs' are stored on an external server (like http) and the app fetches it via url.
Anyhow, in the version of android that I'm using (4.4) you can find the messages in an sqlite database under /data/data/com.android.providers.telephony/databases/mmssms.db. Note that you need root to access it. So to access it from your e.g. computer:
- plug in usb and enable developer mode. Allow for ADB-access.
- adb start-server to start the adb server for communicating with your android. Then adb root to run it in root mode. Finally adb shell to get a shell.
- Now in the shell you can run sqlite3 /data/data/com.android.providers.telephony/databases/mmssms.db and you have access to your stored messages.
sqlite> .tables addr pdu threads android_metadata pending_msgs words attachments rate words_content canonical_addresses raw words_segdir drm sms words_segments part sr_pending
I didn't find much information on the database schema, but it doesn't seem too hard to figure out. The table "sms" seems to contain the basic text messages. MMS seem to be stored in "pdu" and "part".
I figured I'd write down as I fix a basic sandboxing for my web users on my VPS. In my haste to set up the domains earlier I missed that they could pull down the entire filesystem. Oops :). Here's a small how-to enable sandbox (chroot) in OpenSSH.
Add the following lines to /etc/ssh/sshd_config. It will match any user in the sftpusers group for the sandboxing.
Match Group sftpusers ChrootDirectory /home/%u ForceCommand internal-sftp AllowTcpForwarding no X11Forwarding no
Create and set home directory for said user. I moved my sites to their own /home/ directory.
This should now sandbox the user to it's own home directory.
More detailed info and the guide I followed found here: https://wiki.archlinux.org/index.php/SFTP_chroot
About a year ago I found a few vulnerabilities on the one.com website. For those of you that don't know, one.com is a fairly big and cheap hosting provider in Scandinavia. I reported the issues, but some have not been fixed yet. Since it's been so long and one.com went silent in our communication, I've decided to disclose the following vulnerabilities.
They're old and mostly don't work any longer, but they might be interesting still.
A few months ago I bought a fitbit, which is a wristband tracking device. It mainly tracks your steps in a not-so-accurate manner and presents it to you in a nice GUI as both a website and app. It also has some other functions like tracking your sleep and a silent alarm function which vibrates the wristband at a set time. Also you get to compete against your friends. Fun times, though the two other people I know who bought fitbits and got me into buying one too both quit within the first month.
Naturally I felt a need to check the security of the website.
About a year and a half ago I started running. Not sure what drove me to it, but I guess some motivation behind it was as a way to get in better shape/health. I bought myself a cheap pair of running shoes and clothes and started out on a short run.