
How two dead accounts allowed remote crash of any Instagram Android user - pentestercrab
https://medium.com/bugbountywriteup/how-two-dead-users-allowed-remote-crash-of-any-instagram-android-user-8f20e88b1b59
======
mikeyk
IG co-founder here: users 1 and 2 were our first two attempts at creating
users end to end when getting Instagram v0.1 hooked up to the backend we'd
written. There was a bug so they were left in an incomplete state; post
bugfix, 3 was my co-founder Kevin and 4 is me.

~~~
JorgeGT
Two ghost users, left in an incomplete state by a bug in a previous version of
the codebase... you basically created the Twins from The Matrix!

------
tyingq
_" java.lang.NullPointerException"_

That is probably responsible for more of the lost sleep in my life than any
other single entity.

Various versions of _" out of file descriptors"_ might be a close second.

~~~
tormeh
To be fair, all new serious languages now don't have null pointers.

... but we'll still struggle with java.lang.NullPointerException in 2080.

~~~
davnicwil
A null pointer is just a manifestation of a bug, usually unexpectedly missing
data.

If you can't have nulls, you might have a better chance of spotting the
possibility of that missing data and trying to deal with it, granted, but if
it happens truly unexpectedly the bug is still going to manifest itself
somehow, as an NPE or otherwise.

Following all the way through, let's say there is no exception anywhere and
the missing data gets all the way through to the UI.. well then that's how the
bug manifests.

Is the missing data just not appearing better than a 'oops, something went
wrong' error or similar in response to a 500 caused by an NPE? Depends on the
application and circumstances I guess, but in general probably not. The bug
exists in both cases. You can present it in better and worse ways, but the bug
is that the data is not there and it should be.

The point being, not having NPE doesn't fix any problems, fundamentally. It
just shifts them elsewhere. No language feature saves you from bugs.

~~~
akiselev
_> The point being, not having NPE doesn't fix any problems, fundamentally. It
just shifts them elsewhere. No language feature saves you from bugs._

NPE _is_ the problem. The point of type systems with non-nullable references
is that they force you to handle the null case explicitly using an
Option/Maybe type by throwing a compiler error instead of an exception in
production.

Nobody expects that getting rid of NPEs would get rid of bugs. It would,
however, force one of the most common classes of bugs to be handled when it is
cheapest to do so, rather than when the production system is on fire.

~~~
davnicwil
Respectfully I think you're not addressing the point I'm making, but a
slightly different one.

In the case where a piece of data can be missing, and that's fine, I
completely agree that optional/maybe types are useful to model that explicitly
and unambiguously. They let you and future maintainters know that this is the
case, via the type system, at compile time.

But what I'm talking about here is genuine runtime exceptions (which NPE is in
Java, of course), where the design of the system says that this piece of data
cannot be missing and yet, at runtime, you encounter a case where it is
missing, erroneously, because of some bug somewhere.

Types like optionals won't help you here, because you wouldn't have used them
at design time anyway. The same applies to languages completely without null
references.

All type systems do is formalise expectations about how data is going to look.
If the real data breaks from those expectations because of some bug at
runtime, the type system can't help you.

~~~
RHSeeger
> But what I'm talking about here is genuine runtime exceptions (which NPE is
> in Java, of course), where the design of the system says that this piece of
> data cannot be missing and yet, at runtime, you encounter a case where it is
> missing, erroneously, because of some bug somewhere.

My experience is that this is the less common of the cases in a production
environment (vs dev where one may be experimenting a bit more).

~~~
davnicwil
I agree with you :-)

------
larkeith
Original (non-Medium) post: [https://www.valbrux.it/blog/2019/09/13/how-two-
dead-users-al...](https://www.valbrux.it/blog/2019/09/13/how-two-dead-users-
allowed-remote-crash-of-any-instagram-android-user/)

------
UncleEntity
At my work there were some drivers who cloned the app and were using (a
presumably hacked version of) it on another tablet with the "test user" ID to
make a whole bunch of money, they could see where the trips were going and
would only take the really good ones. Bare minimum we're probably talking at
least an extra $1k/week.

Who knows how long they got away with this before someone noticed "ghost
tablets" logged into the system and locked down the test user account -- which
is also how they got caught because they then had to log in with their actual
ID and _The Powers That Be_ could pinpoint who exactly was doing it.

So, yeah, lock down invalid user account IDs.

~~~
Dylan16807
So any account could do this? It doesn't sound like extra IDs were the real
problem.

And there's something deeply sad about "they prioritized the better jobs, so
we blacklisted them".

------
netdur
More like debugging than security researching? Wonder how much he got!
Congratulations

~~~
donretag
Was about to comment the same thing. Just an average bug, not a security
issue.

~~~
valbrux
I would like to highligth that after the exploitation the instagram
application could not be successfully opened until the affected users were
removed from the group

~~~
tyingq
_" manually removed"_

Which probably means Instagram admin intervention.

------
dillonmckay
Any speculation on what a bounty like this is worth?

~~~
t34543
Depends on their budget. Wild guess but 5-10k seems reasonable.

