Spoofing MMS and Crashing iPhone 4

Around 2013, I exclusively used Google Voice. It seemed silly that telecom companies would only offer phone plans that charged separately for data, voice, and messaging or even just messaging and voice (minutes) when it could all just be sent over data (see previous post about creating a data-only phone plan). The only problem I had with it was that Google Voice didn't support MMS (although I'm happy to say that, as of 2018, they do now).

But could there be a way to force it? I gave it a shot. Overall, it was pretty hacked together, but I was able to receive a photo at my phone, and I could send a photo to a phone from an email client on my phone. This is how it worked: I used an email server (that comes with Linux by default) and wrote a script to route MMS messages across the email account, spoofing the phone number so that responses to the text would be sent back to the phone. After all, an MMS or SMS is basically just an email protocol. Look at the structure of an SMS address:

5558675309@txt.att.net

The first part is your phone number, and the part after the @ is the name of the phone company's SMS server (in this case, AT&T, but you can google the name of yours).

One you know your phone's SMS address, you can use it as part of a call to the email program. In the command line, it's just called mail:

echo "hey girl hey" | mail -v 5551118888@txt.att.net -F 5558675309@txt.att.net -f ConanOBrien

This will send mail to the 111-8888 number, and make it look like it was sent from the 867-5309 number (or "ConanOBrien"). Check the man page for "mail" for more information. Note that if you are testing by using an email address as a target, some email servers (such as an organization using gmail) will blacklist spoofed messages, because that obviously comes off as pretty sketchy. Additionally, don't expect too much privacy if you try to go through a temporary email service, especially one with a public facing inbox like Mailinator. If the user has a way to view the traffic it could show a lot of private details like the host name of your local machine:

Received: from [MY LOCAL DOMAIN] ([MY HOSTNAME] [MY IP])
        by [MAILSPAMMER SITE] with SMTP (Postfix)
        for [INBOX NAME]@mailinator.com;
        Sat, 04 Jan 2014 10:26:39 -0800 (PST)
Received: by [MYCOMPUTER LOCAL DOMAIN] (Postfix, from userid 123)
    id 49C1AEEAAEE; Sat,  4 Jan 2014 13:39:14 -0500 (EST)
To: [MAILSPAMMER SITE]
Subject: subject
Date: Sat,  4 Jan 2014 13:39:14 -0500 (EST)
From: [MYPHONENUMBER]@[PROTOCOL].[CARRIER DOMAIN GATEWAY] ([MYPHONENUMBER]@[PROTOCOL].[CARRIER DOMAIN GATEWAY])
Sender: [MYPHONENUMBER]@[PROTOCOL].[CARRIER DOMAIN GATEWAY]
x-connecting-ip: [MY IP]
x-received-time: 1782851999324
MIME-Version: 1.0

Yikes. Anyway, during this course of this project, I had to attach a photo to an SMS message. One way caused problems for the target (it crashed an iPhone 4):

uuencode little_kitten.JPG little_kitten.JPG | mail -s "Can you see an adorable cat (mms)?" 55511188888@txt.att.net -F "Burninator" -r "5558675309@txt.att.net"

(or possibly MMS.att.net instead of TXT.att.net)

Oops... who knew such an adorable cat picture could crash your phone. It was a text bomb. This sent a lot of bizarre characters to the phone, and I'm honestly not sure if it was because of the amount of data that was being interpreted as text (instead of an image) or if one of those unencoded characters was the cause of the crash (perhaps similar to a problem from last month where a unicode symbol was crashing iPhones).

Remove Required Portion of a Smartphone Data Plan

How to make a contract smartphone remove the required data plan using Faux-Ni-Phone Wireless’s website.
This hack is on a simple form for changing features in your cellular plan. Between the voice plan and data plan, there are so many options… and yet none, since they require you to have a data plan if you have a smart phone. Let’s see if this is enforced solely with client-side logic (hint: yes, it is). I'm going to go through the entire narrative of puzzling out how to do something like this. It's important to understand the thought process of a persistent attacker in order to plan against security issues.

Try #1 : Since one of the plans is selected by default in a group of radio buttons, let’s first find a way to deselect it, so that we simply don’t have to choose one to buy. Let’s try the easiest thing first. The typical selected=”false” on all the input elements didn’t work, so I move on. I’ll try again.

Try #2 : I change the values in the radio button that IS selected to dummy values, but it doesn’t update the total price. Fail. Hm. Apparently, changing the radio button state prompts it to change the total bill sum. Note that I’m not bothering to read the code that would confirm this, you can make some educated guesses based on the UI behavior. I’ll try again.

Try #3: I duplicate one of the input elements and then fill the values and id with dummy data, instead of sku0150033 or whatever it was. Then I select the dummy entry, and the bill is lowered! The data is no longer part of the total! However, when I go to check out, I get a message that ‘346456’ and ‘fasfsdgf’ do not exist in the system. Ok, so what DOES exist on the system? Apparently my keyboard smashing isn’t good enough since they’re doing some server-side validation, go figure. I never would have guessed by the quality of the rest of the site (which is forever breaking when exporting PDFs, or claiming permissions issues on links that disappear and reappear randomly - things like that). So,  as usual, I’ll try again.

Try #4: Anyway, I go back to the form, and restart fresh. I create a dummy input element like I did before, only this time I make my dummy data a little smarter. I assume that it’s checking the format sku + 7 digits, and accepts it directly from the UI (very dangerous: developers, never EVER do this). So, the new smart dummy data will be sku0000000. So I select my newly minted fake data plan, and checkout. The next page has no error! When it tells me to review my order, it doesn’t display anything so I figure something got pretty messed up (Well, really it says: ‘Please review your order and make sure everything looks correct.’ Well, it’s a blank box. Hmm. Yes, I decide that looks about right.) I hit continue. Then, there it is, all the final billing information – and the bill? Impossibly low, since it no longer includes the data plan! I get an email confirmation. Success!
I’m a white hat, I do not actually carry this out. I immediately cancel the order so that the company isn’t financially harmed. I never implement exploits that cause a business to lose money, no matter how outrageous it is that I can’t choose not to purchase and use part of my service. (Besides, it would be more useful to be the only phone with a data plan only and just stick with Google Voice, but ANYWAY, that’s a story for another day…)

So! What did we learn? Client side validation needs to be backed up with server-side validation, and not just for valid formats. The input should have bounds, only filtering the objects the user is allowed to select from.

I hope you enjoyed my new blogging format - I’m going to start listing my thought process instead of just the final result. Thanks for reading!

"Security By Obscurity" means "NO Security"

Today I investigate Spiffy Co. , my nickname for a company that sells licensed, proprietary software. Their intention is to have only registered customers be able to log in to access downloads they've already paid for. Unfortunately, their paywall is very flimsy.
Checking out their robots.txt file, I noticed there was nothing blocking that particular directory (/downloads) from search engine crawlers to see it. So I search "insite [spiffyco.com]" to see what kind of view the public has. Though, it doesn't exactly return what I'm looking for, since it's just manuals in a directory below that directory. So I go to the manuals directory and try to navigate up to see if it will list a directory with downloads and ... nope, no listing. It returns me to the paywall.

At this point, I decide to guess. A pretty intuitive starting place seems to be /downloads/downloads/, since I guess that's what I would do if I were trying to organize the site. Behold, here are the list of .exes. Yep. Just by a guess, and thinking "how would I have done that?". No coding magic here!

Moral of story: Similar to the cheat-on-homework.net post below, you cannot count on directories without links to them to be secure links.

Disclaimer: It is illegal to install and use licensed software that you haven't paid for. Don't try this at home.

Homework-help.net's Customer Identities

No, their real name is not homework-help.net.

It's one of many sites where students can get help with homework. They have a privacy policy. It's quite inaccurate. Improper permissions on their log file has made it easy to find out information about the students using the service.

Anyway, this is part of my investigation into a popular open source logging service. Searching for the log file's name and an IP address from a local university lead me to the log page from a few years ago, so I switched the date in the log title and sure enough it gave me this month's traffic information. The timestamps in the file names are predictable, because it is generated by the service.

The log file contains information like:

 - search terms that lead to the site
- time ranges spent on the site
- IP addresses of visitors, what time the IP address accessed the site
- specific pages accessed
- referrer links
- browser, OS, etc. for each IP
- even window dimension
- etc.

What meta data can be obtained from these things? Not much, considering how often the data is logged. But because the logs were stored in a directory with read access as well (bad admin! NO! BAD!),  there were timestamps on when the files were last modified. Then a script was written to go check up on the file once in a while to see the latest visitor (or at least subset of visitors for a few hours), and then map the timestamps within the file with others. Really, the jackpot only happens when you only get one new visitor in that time frame, so that all successive new data in the diff between the old and current log file can be applied to that one person. For example, even though no timestamps are associated with their web search terms, if there's only one new IP/person, they must have been the one to make the search. I'd like to experiment with this and make sure it's accurate, but the logic seems sound, and it worked for my purposes.

Anyway, this one new customer was interacting with a directory I couldn't navigate to from the log file directory. Of course I am instantly curious, because the directory's named something like /7df83kic. So I browse to that area, which also has public read permissions.

Whoa, buckets of uploaded user files! I check around on the site, and the only time you can upload an assignment is when you sign up for the service. What's more, these are the original documents, meaning all meta data is included, whether it be a .PDF, .doc, .docx etc. So in addition to the teacher's email, class name, university name, etc., there are, for example, the author names on the Microsoft Word licenses when you check out the properties. Or a username. (Random example from the interwebs on the left.)

The site's remediation plan was to change the name of the directory, but it would be much better to correct the file permissions (since the traffic log is still public and shows the new file upload location...)

Moral of Story: There are reasons Facebook caches photos that you upload, and that cached version is what gets displayed. All those little hidden bits of meta data (like facial-detection tags in Picasa and the names you've added) in that photo disappear when the picture is saved in a different format, compressed, what have you. Or, another interesting example is code hidden in pictures, but that's another story. In essence, don't use original upload data,  and sanitize everything from form data to uploads.

UPDATE as of August 5 2018: there are a lot of other sites with this same vulnerability, where this particular logging library sets its log files to public by default. I recently came across another situation where the logs revealed someone unsuccessfully trying to use this appserv vulnerability (discussed here), by setting the URL parameter to appserv_root as malicioussite.com/attack.gif, a gif which presumably has some PHP in it that would be executed during the PHP include. Most of this was only visible in the 404 part of the log because the attacker was attempting the attack a few times with various typos.

Cilent Controlled Subscriber Content

Site, for this post I shall dub you fun-trails-for-hiking.com. Here is another case where paid subscriber content can be reached with some JavaScript tweaking. These happen often.

Here's the idea - they say you must be a premium subscriber to see a larger area of the map. Instead you change

<div id="trailBox" class="topoSml">

to

<div id="trailBox" class="topoLrg">  or <div id="trailBox" class="topoMed">

When coding on a team, it's really helpful to use descriptive variable names (wasn't it the author of "Clean Code" that said if your variable names work you don't need any comments explaining code?). No where else on the page are the words "topoLrg" or "topoMed", but because the site looks well put together and professional, it's reasonable to infer that the map sizes other than "small" or named similarly.

"Prominent Political TV Host" Poll Center

I'm surprised this trick still works, I bothered them with it like a year ago, and it works as of a few days ago. In fairness, the site has a disclaimer that says "These polls are not scientific. Only one count is counted per visitor".  This turns out not to be the case. Anyway, in my usual style, it's simple JavaScript edits with a few goals in mind for the poll center of this site:

To Do:

1. Sway the results of closed archived polls
2. Make the poll results add up to less than 100%
3. View the results of a poll before it is aired on the show

You can see this as a product of poor data sensitization. Messing with FireBug Firefox extension causes permanent data changes on the server that no one seems to notice or care about. So if you're a developer, may this be a lesson you never have to learn in production - sanitize input on client side and server side.

1. Change archived poll results

Simply change loadArchivePoll to loadPoll. That's it.

<div class="Pollwrap">
              <div style="padding: 5px; cursor:pointer; border-bottom: 1px solid #cccccc;" class="pollArchiveItemOff" id="pollArchiveItem0_0" onmouseover="" onmouseout="changeBackgroundClassArchivePoll('0','0', 'Off');" onclick="loadArchivePoll('0','9337','0');"><span style="display:block;">Make a prediction - will Attorney General Eric Holder resign?<br>May 30, 2013</span></div>
</div>

 

2. Polls that add up to less than 100% 

This effect can be easy triggered. If the radio button's value  attribute is edited to something not in the given values in the multiple choice survey, it won't be counted.

<input type="radio" value="Fake value." name="surveyAnswer">

3. View the results first

Okay, I'm leaving this one as an exercise for you! Trust me, it's as trivial as the other two hacks. Hint: take a poll legitimately, and figure out where the form takes you to view the results.

Client Side (Instead of the Dark Side)

It's astonishing how much power there is in simply looking/editing web page source! Possibly anything more seems to get you on the news, so you can stay on the bright side: the client side. Granted, it depends on the contest or website, I guess, but every once in a while you get a gem like this:

answersTxt[3] = "<div id=\"answer-input-3\" class=\"answer-result \"><span></span></div>"; 

answersImg[4] = "<div id=\"answer-final-4\" class=\"contest-answer result hasImage\"><img src=\"/sites/files/bottle.jpg\" alt=\"Picture4\" /></div>"; 

Yes, there's an array called answersTxt[] and answersImg[].

This was a matching game where pictures were matched to text. The administrators have remediated this... they have started hashing the names of the pictures to avoid future shenanigans.