AsiaCel
shalom goyim
★★★★★
- Joined
- Nov 24, 2017
- Posts
- 30,181
- Online time
- 21h 49m
As a developer, you know what are vulnerable and what aren't, and my company is hilariously vulnerable.
We are a very small team.
For OPSEC reasons, the details are replaced with fictional but similar details to the real details.
1. We use a universal superadmin account across all apps.
The account is used across all apps, and the password is hilariously easy, too.
The superadmin account is called Company2. It's password is Company2-123.
2. Company rebranding = password rebranding
One of the epic fails. When the company rebranded from company1 to company2, we rebranded the account, which is not an big issue in itself, but we also rebranded the password from Company1-123 to Company2-123. I think the boss really hates the old name.
3. There are two sets of admin passwords
Company2-123 and Company2-456+
Not joking. One is for database, and another one is for account.
4. The configs are exposed on the git
On almost every project you find on the Git, you can check the app settings.json, and you can see all sorts of API keys, IPs, and even the database connection string. Unsurprisingly, most of the apps have the same database password: Company2-123.
Not only that, but also AWS and other service details too.
5. The APIs are barely secured
If you check the APIs, most of the APIs, even the ones that literally send you the user list (full name, email, phone numbers, user certificates, but not passwords), are not secured. As long as you are a user, you have a session, you can call the API with no permission restrictions.
Literally all you have to do is to press F12, Ctrl+R, and guess the endpoint name, like company2.com/getallusers.
6. Everyone in the office knows the passwords
Everyone from support staff to developers knows the passwords.
7. Developers rely on shared emails
Developers rely on a network of shared emails, like [email protected], making it impossible to see who did what.
8. There are no backups
There are no database backups for the servers. If the servers died or got hacked, the best data they have are going to be years ago backups. The only 'backup' they do is logging and git version control.
9. The admin panel
Interestingly, they were interested in a universal admin app, which I made; the app is secure, but nothing can stop people with a password from getting in. The system is so good that it's actually easy to wreck havoc on a large scale, in multiple apps, but that's not my fault.
10. The iPads have the same passwords
The iPads offered for internal development use have the same passwords and similar usernames. Can you imagine if the management gave guests an ipad to play with?
We are a very small team.
For OPSEC reasons, the details are replaced with fictional but similar details to the real details.
1. We use a universal superadmin account across all apps.
The account is used across all apps, and the password is hilariously easy, too.
The superadmin account is called Company2. It's password is Company2-123.
2. Company rebranding = password rebranding
One of the epic fails. When the company rebranded from company1 to company2, we rebranded the account, which is not an big issue in itself, but we also rebranded the password from Company1-123 to Company2-123. I think the boss really hates the old name.
3. There are two sets of admin passwords
Company2-123 and Company2-456+
Not joking. One is for database, and another one is for account.
4. The configs are exposed on the git
On almost every project you find on the Git, you can check the app settings.json, and you can see all sorts of API keys, IPs, and even the database connection string. Unsurprisingly, most of the apps have the same database password: Company2-123.
Not only that, but also AWS and other service details too.
5. The APIs are barely secured
If you check the APIs, most of the APIs, even the ones that literally send you the user list (full name, email, phone numbers, user certificates, but not passwords), are not secured. As long as you are a user, you have a session, you can call the API with no permission restrictions.
Literally all you have to do is to press F12, Ctrl+R, and guess the endpoint name, like company2.com/getallusers.
6. Everyone in the office knows the passwords
Everyone from support staff to developers knows the passwords.
7. Developers rely on shared emails
Developers rely on a network of shared emails, like [email protected], making it impossible to see who did what.
8. There are no backups
There are no database backups for the servers. If the servers died or got hacked, the best data they have are going to be years ago backups. The only 'backup' they do is logging and git version control.
9. The admin panel
Interestingly, they were interested in a universal admin app, which I made; the app is secure, but nothing can stop people with a password from getting in. The system is so good that it's actually easy to wreck havoc on a large scale, in multiple apps, but that's not my fault.
10. The iPads have the same passwords
The iPads offered for internal development use have the same passwords and similar usernames. Can you imagine if the management gave guests an ipad to play with?
Last edited:





