-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apache couchdb #267
Apache couchdb #267
Conversation
To Do: 1. Team Testing 2. Finalize secgen customization options from the following: (a) use sample json database -- current version uses sample opensource color dataset (b)create ruby file for more custom database using secgen generators (3) do not create a database but change the port to 0 so it defaults to any available port
To Do: 1. Team Testing 2. Remove Hard coding variables to replace with secgen generators
…preleak TODO: 1. Team Testing 2. Remove Testing Variables
This is working and exploits within user context. Cant work out why i cant seem to change the port on the erlang daemon so for now is always the same port. |
<difficulty>low</difficulty> | ||
|
||
<read_fact>port</read_fact> | ||
<read_fact>known_username</read_fact> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These listed parameters have to match the ones for default inputs below. If you read_fact known_username
, then it should/can also have a default input.
; 'username = password' lines. Don't forget to restart CouchDB after | ||
; changing this. | ||
[admins] | ||
<%= @username %> = <%= @password %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this intended to be a password that's leaked to them on completion? Sounds like it's hashed, so might pose a problem if the thing passed to passwords_to_leak
is not an easily crackable password
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There isn't actually any leak of password or username required for this exploit. I was just very unsure of what purpose these serve in context of the software install, so i left them in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this line required for the exploit to work?
<%= @username %> = <%= @password %>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'm going to merge this, and leave this in, but tweak the metadata.
Continuing on from Sofia's PR. This is now in a working state in SecGen.
The only thing i will need to review is the "port". Seems the exploit runs from a separate requirement software which is hosted on a different port. I will need to look into this further to make it dynamic.
So far exploit runs as user and correctly runs through everything.