I have a Security Checklist for AWS which you can apply to any Cloud Computing service, it was too painful for me to find the original so I was lazy and linked it from my LinkedIn:
Maybe you are running an old version of Postgres? Exploit DB might have some means for me to find a way in: exploit-db.com/
Are you using dependabot?
Are you using that searches for CVEs? eg. Synk
Have you tried sniffing for credentials that may be in the git history?
Are you enforcing MFA? Are you enforcing signing of git commits?
Do you have tests for all your endpoints? If not that that is a good place to look to abuse access to records I should not have access to
Are you hosted on AWS? If not I bet lots of you're resources have public-facing addresses, Are you using Sidekiq? That means you're using Redis, maybe Redis is public-facing and you have not kept it up to date and I can gain access via an exploit.
I would run Metasploit against your servers
A bit busy at the moment but a very fun thing to investigate
I don't think a tutorial will be valuable. it's just a Linux distro with pentesting tools. The best way is to start with a general security book like hacking exposed to understand the main process and go from there to experiment with the various tools. (They are a little complex but that's just the Unix philosophy)
Agreed. There are kali-specific tutors out there, but the distro is more about the endless toolkit.
There are - separately - a trillion tutors on the tools, where they coincidentally use Kali. Those are the better start.
Pentest has soooo many angles, the tooling and concepts are the jump-off point, not the distro.
I think that's what intrigues me so much. My career is builder/creator. I make a thing that does a thing, and that's fun. ... ... ...but I'm not geared for "include an ampersand and this specific text is your ajax call, or create you avatar in this specific way if the server is running on this specific version of blank, then do this and this and this, and now you have admin privileges"
Young me had no idea how important it was to hide the powered-by response header.
CSS hacks blow me away! Just a little tiny bit of user control, and a bad actor can slip-in a background-image that points to a remote gif that triggers a script-kiddie rig that does who-knows-what 🤯
I think that every hack out of there is the subversion of normal input. You're not creating a new entity, you just inserting something not expected which can trigger an abnormal response from an existing one.
I'm also a creator and the only things that were ever interesting for me in pen testing were reverse engineering and programming rootkits. Both because you have to set yourself to learning mode. It's like exploring those portions of the map where it's marked "Here be dragons".
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
It's funny how much things have changed with respect to AWS and "default public" settings: more things default-closed, plus, when you explicitly open things up, you get colored warning-labels in the web consoles (and that's without leveraging any of the advanced threat-detection and auto-remediation tools available in mos of the commercial regions).
Helpful that GitHub and GitLab both now do basic checks for credential-y looking things.
As to enforcing MFA ...if you're allowing interactive logins to your production hosts/instances, at all (let alone from random systems around the Internet), you're probably doing other stuff really wrong, too. Which is a good 50,000' nugget of information to gather as you move your audit-tasks from the outside inwards.
It's hard in practice to get engineering teams to stop fiddling with servers directly.
It should be logical that instances should be hands-off, and tasks should be automated through Run Commands or something such as Anisble. It really comes down to stubbornness.
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Yeah... One of my main customer's internal groups was flogging their favored CM system, recently. Touting, "but you can extend management from legacy systems to the newer, cloud-hosted (and it's cross-cloud!) systems" (while being able to compose a global dashboard would be a good justification, that group's never really been into hiring the kinds of people you need to have around to get worthwhile reports authored/updated). Ironically, the person that was flogging it was also joking, earlier, about "you could also use it to manage containers, but that would be horribad." All I could think was, "why do I need lifecycle-CM for my cloud-VMs: when it comes time to patch (etc.), we just nuke and re-deploy …and that's for the systems that we don't have running as part of auto-scaling groups (with scheduled scaling-actions configured for frequent replacement)".
It's not just Operations types that are hard to break of habits, the Security teams might be worse. A couple years ago, they insisted they needed interactive-shell access to run their tools. So, we arrange for that to be doable ...and then they got pissy that system-ids were constantly changing and their databases were filling up with systems that no longer existed. Note, this was the same team that insisted that our containers had to be "whole OS" types of containers, since their scanning tools didn't know how to work with minimized containers in a way that allowed them to check off all the same boxes they were used to checking off with "whole OS" VMs and legacy servers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have a Security Checklist for AWS which you can apply to any Cloud Computing service, it was too painful for me to find the original so I was lazy and linked it from my LinkedIn:
linkedin.com/posts/andrew-wc-brown...
Rails has very sane defaults, Rails Security outline gives you a good idea where to look:
guides.rubyonrails.org/security.html
OWASP top ten is a useful resource:
owasp.org/index.php/Category:OWASP...
A fun way of thing of ways to compromise an app/system is looking at Kali Linux full list of tools for inspiration.
tools.kali.org/tools-listing
Maybe you are running an old version of Postgres? Exploit DB might have some means for me to find a way in:
exploit-db.com/
A bit busy at the moment but a very fun thing to investigate
I have Kali in a vm and a bootable usb both - but I know very little about how to ACTUALLY use it. 🤷♀️
But... Infosec isn't really my main thing
I've never honestly found any good tutorials on it. There is one company which has Certifications for Kali Linux but it is at absurd prices eg. 1K
I don't think a tutorial will be valuable. it's just a Linux distro with pentesting tools. The best way is to start with a general security book like hacking exposed to understand the main process and go from there to experiment with the various tools. (They are a little complex but that's just the Unix philosophy)
Agreed. There are kali-specific tutors out there, but the distro is more about the endless toolkit.
There are - separately - a trillion tutors on the tools, where they coincidentally use Kali. Those are the better start.
Pentest has soooo many angles, the tooling and concepts are the jump-off point, not the distro.
I think that's what intrigues me so much. My career is builder/creator. I make a thing that does a thing, and that's fun. ... ... ...but I'm not geared for "include an ampersand and this specific text is your ajax call, or create you avatar in this specific way if the server is running on this specific version of blank, then do this and this and this, and now you have admin privileges"
Young me had no idea how important it was to hide the powered-by response header.
CSS hacks blow me away! Just a little tiny bit of user control, and a bad actor can slip-in a background-image that points to a remote gif that triggers a script-kiddie rig that does who-knows-what 🤯
I think that every hack out of there is the subversion of normal input. You're not creating a new entity, you just inserting something not expected which can trigger an abnormal response from an existing one.
I'm also a creator and the only things that were ever interesting for me in pen testing were reverse engineering and programming rootkits. Both because you have to set yourself to learning mode. It's like exploring those portions of the map where it's marked "Here be dragons".
Heh...
It's funny how much things have changed with respect to AWS and "default public" settings: more things default-closed, plus, when you explicitly open things up, you get colored warning-labels in the web consoles (and that's without leveraging any of the advanced threat-detection and auto-remediation tools available in mos of the commercial regions).
Helpful that GitHub and GitLab both now do basic checks for credential-y looking things.
As to enforcing MFA ...if you're allowing interactive logins to your production hosts/instances, at all (let alone from random systems around the Internet), you're probably doing other stuff really wrong, too. Which is a good 50,000' nugget of information to gather as you move your audit-tasks from the outside inwards.
It's hard in practice to get engineering teams to stop fiddling with servers directly.
It should be logical that instances should be hands-off, and tasks should be automated through Run Commands or something such as Anisble. It really comes down to stubbornness.
Humans are such a pain
Yeah... One of my main customer's internal groups was flogging their favored CM system, recently. Touting, "but you can extend management from legacy systems to the newer, cloud-hosted (and it's cross-cloud!) systems" (while being able to compose a global dashboard would be a good justification, that group's never really been into hiring the kinds of people you need to have around to get worthwhile reports authored/updated). Ironically, the person that was flogging it was also joking, earlier, about "you could also use it to manage containers, but that would be horribad." All I could think was, "why do I need lifecycle-CM for my cloud-VMs: when it comes time to patch (etc.), we just nuke and re-deploy …and that's for the systems that we don't have running as part of auto-scaling groups (with scheduled scaling-actions configured for frequent replacement)".
It's not just Operations types that are hard to break of habits, the Security teams might be worse. A couple years ago, they insisted they needed interactive-shell access to run their tools. So, we arrange for that to be doable ...and then they got pissy that system-ids were constantly changing and their databases were filling up with systems that no longer existed. Note, this was the same team that insisted that our containers had to be "whole OS" types of containers, since their scanning tools didn't know how to work with minimized containers in a way that allowed them to check off all the same boxes they were used to checking off with "whole OS" VMs and legacy servers.