try to "hack" my login.

capasha · 2016-07-25 17:13:28

So I have been coded a bit. And added a login to my site. I have not added much security in it.
It's using PHP and MySQL. If anyone want to try to bypass or succeeds to login, post it here.

My site: http://trustno1.info/eeditor/index.php

220 gems code to Everybody Edits. To the one that can exploit my login, or find any security issues.

Zumza · 2016-07-25 18:15:32

I limit me to make it say "cant fetch data" should I continue further?

drunkbnu · 2016-07-25 18:16:15

Use SQL injection

capasha · 2016-07-25 19:08:27

Zumza wrote:

I limit me to make it say "cant fetch data" should I continue further?

I saw that the MySQL PHP version was newer, and didn't support to disable special characters.
But I guess that is fixed now. Try again and continue.

capasha · 2016-07-25 21:55:35

Btw. I have updated the login site now. It would be gold if you people found a way to exploit it.

MartenM · 2016-07-25 22:18:30

I tried...

Username: admin
Password: password

I failed, but atleast I tried.

hummerz5 · 2016-07-26 03:42:58

Can we assume you've nixed the SQL injection?

capasha · 2016-07-26 12:18:18

I know some people doesn't do this for fun. So I pay the one with EE gem code with 220 gems, that find exploits or bad security.

hummerz5

skullz17 · 2016-07-26 14:18:48

I would do it for fun if I knew anything about security. But I don't, and others are probably the same.

realmaster42 · 2016-07-26 14:39:45

Ayy you use a refferer
are you trying to get money from this?
btw
Trying

It didn't work did it? :-(

drunkbnu · 2016-07-26 14:50:41

Resource Limit Is Reached

The website is temporarily unable to service your request as it exceeded resource limit. Please try again later.

daemon · 2016-07-26 15:39:35

Asset: Login Authentication and authorization.
Threat: Any method to impersonate an existing user (the usual bruteforcing- and dictionary attack, infamous SQLi) or circumvent authentication.
Attack vector: HTTP interaction obviously.
Vulnerability:
Some conditionals of what may happen and how to better avoid it;
+ Server-side sanitization.
- If sanitization fails, SQL code can be injected.
= Use of prepared statements (PDO) is recommended.

- If PHP code becomes transparent (access to .git folder, Apache down-time), so will the MySQL account credentials.
- If the MySQl account credentials are transparent, then at best only via localhost can be connected to the database and no harm is inflicted,
worse the MySQL database is compromised and at worst, the MySQL password is re-used for FTP/SSH.
= Store account credentials outside of the Apache webroot directory (Preferably in an XML file inside /etc/ with only sufficient file permissions).

Some serious (exploitable) issues you are facing;
- Cookies are client-side and should not be used for authentication nor authorization.
- Passwords are not encrypted (preferably with a salt to prevent cracking by rainbow tables) and go insecurely over the wire.

Exploit:
- Use any addon to create a new cookie called 'LoginCookie', which is checked for during authentication and authorization.
Proof of concept: imgur.com/6KhNu3M
- Put NIC in promisc. mode to capture network packets and subsequently account credentials in POST superglobal variable (Wireshark).

Proposed fix:
- Just do not use cookies (and any other client-side mechanism) for authentication and authorization.
- SSL layer (HTTPS) and cert from CA to not leak passwords over the network.
- Use password_hash()/1 and password_verify()/2 PHP functions to not leak passwords when the database is hacked.

Pingohits, kubapolish, Anch

capasha · 2016-07-26 17:47:07

daemon wrote:

Asset: Login Authentication and authorization.
Threat: Any method to impersonate an existing user (the usual bruteforcing- and dictionary attack, infamous SQLi) or circumvent authentication.
Attack vector: HTTP interaction obviously.
Vulnerability:
Some conditionals of what may happen and how to better avoid it;
+ Server-side sanitization.
- If sanitization fails, SQL code can be injected.
= Use of prepared statements (PDO) is recommended.
- If PHP code becomes transparent (access to .git folder, Apache down-time), so will the MySQL account credentials.
- If the MySQl account credentials are transparent, then at best only via localhost can be connected to the database and no harm is inflicted,
worse the MySQL database is compromised and at worst, the MySQL password is re-used for FTP/SSH.
= Store account credentials outside of the Apache webroot directory (Preferably in an XML file inside /etc/ with only sufficient file permissions).
Some serious (exploitable) issues you are facing;
- Cookies are client-side and should not be used for authentication nor authorization.
- Passwords are not encrypted (preferably with a salt to prevent cracking by rainbow tables) and go insecurely over the wire.
Exploit:
- Use any addon to create a new cookie called 'LoginCookie', which is checked for during authentication and authorization.
Proof of concept: imgur.com/6KhNu3M
- Put NIC in promisc. mode to capture network packets and subsequently account credentials in POST superglobal variable (Wireshark).
Proposed fix:
- Just do not use cookies (and any other client-side mechanism) for authentication and authorization.
- SSL layer (HTTPS) and cert from CA to not leak passwords over the network.
- Use password_hash()/1 and password_verify()/2 PHP functions to not leak passwords when the database is hacked.

I know that the site doesn't have SSL. But if I had money I would buy it.
One thing is, how did you know that my site set "loginCookie"? I have tried everything that I know. And I can't get it.
I know, cookies isn't that good to use. But I'm still trying to learn more about MySQL and PHP.

HG wrote:

Resource Limit Is Reached
The website is temporarily unable to service your request as it exceeded resource limit. Please try again later.

I guess you tried to connect too many times at too short time.

AlphaJon · 2016-07-26 22:26:39

You can use sessions instead of cookies to be able to manage data on the server side while still using cookies.
It gives a PHP-generated session ID which is kept by the client in a cookie, but if the client ID changes through cookie manipulation, data can't be accessed by the client anymore because it is linked server-side.
To add a safety layer, you could bind the session ID to one IP address, in case those session IDs somehow get leaked.
I'm not the most trustworthy source here, but you can look at it and decide by yourself if sessions are worth using for you.

daemon

daemon · 2016-07-26 23:33:29

First of all, to secretly send account credentials between client and server, it is necessary to enforce the use of HTTPS in the URL (simply redirect traffic from HTTP to HTTPS).
HTTP traffic will then be encapsulated inside an SSL layer.
For this SSL connection, a handshake is required in which keys are exchanged for asymmetric encryption (to avoid the key distribution problem).
You simpy need to get a private key as well as a certificate signed by a trusted CA with your public key.
https://letsencrypt.org/ offers all these requirements for free (be cautious when selecting a trusted CA, especially when you trust no1).

Secondly, how I discovered the name of the cookie is irrelevant (I purposely keep you in the dark about it); It is a good practice to assume that client- and server-side code is transparent to anyone.
For the sake of an answer; I could have bruteforced the name, creating and testing plausible cookie names until by trial and error I stumbled upon 'LoginCookie'.

Finally, PHP sessions are popular for login systems but as AlphaJon mentioned, they are just cookies, and just like cookies can be hijacked, now suddenly the session can be hijacked too.
Note that counteracting session hijacking by binding each session to an IP only works on network scale; hosts within a network can still hijack eachothers sessions, but I guess that's a job for the network administrator.

Good luck, don't hesitate to ask more.

capasha · 2016-07-27 00:10:10

I sent my code to a guy. So I guess you are that guy, if you can't tell me how you could retrieve the cookie.
Send me a pm, if you don't want to write it here.

daemon · 2016-07-27 19:30:05

I would like to emphasize

For the sake of an answer; I could have bruteforced the name, creating and testing plausible cookie names until by trial and error I stumbled upon 'LoginCookie'.

and the fact that 'LoginCookie' is a plausible name.
Therefore a dictionary attack (creating legio of cookie names, including 'LoginCookie') will work and - when narrowed down - yield the cookie name.
Do not bother about it anymore.

hummerz5 · 2016-07-27 21:33:35

well cap you're not letting me see the wonderful page anymore

but iirc there's an addon to show cookies for FF, plus just right click, show cookies for this site. but you probz know that.

Kira · 2016-07-27 22:00:17

Stop invading off topic coding nerds

AlphaJon · 2016-07-28 00:28:54

Kira wrote:

Stop invading off topic coding nerds

If we could put non-EE related stuff in bots and programming, we woulddiff halp pls, do sumting

hummerz5 · 2016-07-28 00:31:46

AlphaJon wrote:

Kira wrote:
Stop invading off topic coding nerds
If we could put non-EE related stuff in bots and programming, we would

At the same time, I want to make ten legitimate discussions about coding to invade this off topic exhaustively.

Actually yeah, just a "programming" forum with EE related stuff in there would be pretty swell. But then do you leave the subforum in "Game Discussion" or send it off to offtopic?

AlphaJon

daemon · 2016-08-01 18:10:30

Just a reminder for Capasha that I qualify for

220 gems code to Everybody Edits. To the one that can exploit my login, or find any security issues.

Although I have been waiting eagerly (Do not mistake me for a moneygrubber though), I have not yet received 220 gems (PM me for my ingame name).
Cheers.

hummerz5 · 2016-08-01 18:32:31

Wait was the login cookie something like userID or username in plaintext? If so, I get it. But if he had a random string, hashed in the DB, isn't that the way to do remember me systems?

capasha · 2016-08-01 19:48:06

daemon wrote:

Just a reminder for Capasha that I qualify for
220 gems code to Everybody Edits. To the one that can exploit my login, or find any security issues.
Although I have been waiting eagerly (Do not mistake me for a moneygrubber though), I have not yet received 220 gems (PM me for my ingame name).
Cheers.

1) I can't get a gem code
2) I still need to know how you got that cookie. Because bruteforcing or dictionary attack my page wont work.
If you can't tell how you found it. I can't give you anything. I'm sorry for that.

hummerz5 wrote:

Wait was the login cookie something like userID or username in plaintext? If so, I get it. But if he had a random string, hashed in the DB, isn't that the way to do remember me systems?

It was a cookie with a name, if anyone set a value to it they would be able to login. I'm sorry that I'm bad at MySQL and PHP.

hummerz5 · 2016-08-01 19:52:05

Can someone explain to me how finding cookies is actually difficult?

It seems to presumptuous of me to assume you guys don't know about how easy it is to find cookies.

Are you sure they're "Cookies" and not something else? I can't see the webpage to show how easy or difficult it would be to find the ecookie, soooo

Official Everybody Edits Forums

#1 2016-07-25 17:13:28, last edited by capasha (2016-07-26 12:16:08)

try to "hack" my login.

#2 2016-07-25 18:15:32

Re: try to "hack" my login.

#3 2016-07-25 18:16:15, last edited by drunkbnu (2016-07-25 18:16:26)

Re: try to "hack" my login.

#4 2016-07-25 19:08:27, last edited by capasha (2016-07-25 19:34:31)

Re: try to "hack" my login.

#5 2016-07-25 21:55:35

Re: try to "hack" my login.

#6 2016-07-25 22:18:30

Re: try to "hack" my login.

#7 2016-07-26 03:42:58

Re: try to "hack" my login.

#8 2016-07-26 12:18:18

Re: try to "hack" my login.

#9 2016-07-26 14:18:48

Re: try to "hack" my login.

#10 2016-07-26 14:39:45

Re: try to "hack" my login.

#11 2016-07-26 14:50:41

Re: try to "hack" my login.

#12 2016-07-26 15:39:35, last edited by daemon (2016-07-26 18:30:31)

Re: try to "hack" my login.

#13 2016-07-26 17:47:07, last edited by capasha (2016-07-26 20:18:39)

Re: try to "hack" my login.

#14 2016-07-26 22:26:39

Re: try to "hack" my login.

#15 2016-07-26 23:33:29

Re: try to "hack" my login.

#16 2016-07-27 00:10:10

Re: try to "hack" my login.

#17 2016-07-27 19:30:05

Re: try to "hack" my login.

#18 2016-07-27 21:33:35

Re: try to "hack" my login.

#19 2016-07-27 22:00:17

Re: try to "hack" my login.

#20 2016-07-28 00:28:54, last edited by AlphaJon (2016-07-28 01:00:52)

Re: try to "hack" my login.

#21 2016-07-28 00:31:46

Re: try to "hack" my login.

#22 2016-08-01 18:10:30

Re: try to "hack" my login.

#23 2016-08-01 18:32:31

Re: try to "hack" my login.

#24 2016-08-01 19:48:06, last edited by capasha (2016-08-01 19:50:45)

Re: try to "hack" my login.

#25 2016-08-01 19:52:05

Re: try to "hack" my login.

Board footer