Let me first say that I'm doing nothing illegal. I'm doing this for learning purposes only. Using my own virtual network.
So I am trying to SSH into a server and say I know there is a user called urbasnlug so ssh urbanslug#ipadress but I need the root passoword.
I have a wordlist that contained only strings without alphanumeric strings. How would I use this wordlist to crack a password that has an alphanumeric password which is of mixed cases but the number in the password never goes past 100
Say the wordlist had the strings:
pass
word
How could I use these list to crack a password such as PaSSword99.
Maybe in ways other than with the use of word lists.
If you can't help me at least tell me why you can't.
I can write a C or Python module to do this but I know that there has to be something out there that already exists.
So you have two things to achieve here. The first is generating the set of passwords you wish to try. The second is throwing that list of passwords against your server.
The first problem is a classic use case of John The Ripper, you can have it read in your wordlist, apply some mangling rules (such as appending 0-99 to each word, permuting cases etc), and output a final, complete password list.
The second problem is quite easy to solve once you have the password list. You could just loop over the passwords in bash, but if you're really lazy, Metasploit has an SSH scanner that reads a password list for you.
Of course, breaking this down into two stages means you are storing the huge password list as a file. In general you would be more likely to pipe the output from John The Ripper to your SSH scanner, rather than using an intermediate file.
First off it will be difficult to get the root password if you are only logged in as a normal user. However, there are different ways of getting 'root' which I believe go beyond the scope of this forum.
Nonetheless, I don't get the correlation of where you wordlist comes to play if already know the characters present in the root password;which would mean you have the root password anyway.
Try and use Hashcat to try and retrieve password. You however need a wordlist eg rockyou.txt or any of those available in the OpenWall site (makers of John the Ripper, which is another tool which is only as good as your wordlist.
i think it will be easier (faster?) to get root via a local exploit, read /etc/shadows and crack that password
Related
So as far as I found out it is possible to assign multiple passwords to a LDAP-user. However what I'm trying to figure out is if one could limit one password to a specific application.
As far as I'm concerned this looks like the opposite of what one would like to achieve with using LDAP, however this is my task and I'm trying to go with it.
I explicitly do no want to create seperate users but just two passwords where one logs me into let's say my homepage backend and the other into my email but not the other way around!
Is this doable? I did not find any solutions so far.
I have a number of Java applications which connect to other applications and services via connections secured with SSL. During development, I can specify the keystore/truststore to use and the password by using the JVM args:
-Djavax.net.ssl.trustStore=certificate.jks
-Djavax.net.ssl.trustStorePassword=mypassword
-Djavax.net.ssl.keyStore=certificate.jks
-Djavax.net.ssl.keyStorePassword=mypassword
-Djavax.net.ssl.keyStoreType=jks
This works perfectly. However, there is a requirement when going to production to hide the password, using JVM args means anyone who looks at the process list will be able to see the password in clear text.
Is there a simple way to get around this? I considered importing the certificates into the JRE's lib/security/cacerts file, but my understanding is that this will still require a password. One option would be to store the password, encrypted, in a file and then get the applications to read and decrypt on the fly, but this will involve changing and re-releasing all the applications (there are quite a few of them) so I would rather avoid this if at all possible. Does the javax.net.ssl library have any native built-in support for encrypted passwords (even if it's something as simple as just base64encoding, or anything that makes the passwords not-clear-text)?
Any suggestions much appreciated.
Firstly, you could consider hiding the ps output from other users, see these questions:
I don't want other users see my processes in ps aux. I have root. It's Debian. How to use grsec?
Hide processes from other users based on groups (under Linux)?
How to make a process invisible to other users?
Secondly, importing your certificates (assuming with private keys) into lib/security/cacerts would be pointless: it's the default truststore, but not the default keystore (for which there is no default value).
Thirdly, you can never really "encrypt" the password that's going to be used by your application (in a non-interactive mode). It has to be used, so if it was encrypted, its encryption key would need to be made available in clear at some point. Hence, it's a bit pointless.
Base 64 encoding, as you suggest, is just an encoding. Again, it's quite pointless since anyone can decode it (e.g. based64 -d).
Some tools, like Jetty, can store the password in an obfuscated mode, but that's not much more resistant than base 64 encoding. It's useful if someone is looking over your shoulder, but that's it.
You could adapt your application to read the passwords from a file (in plain text or obfuscated). You would certainly need to make sure this file isn't readable by unauthorised parties.
What really matters is to make sure that the keystore file itself is protected from users who are not meant to read it. Its password is meant to protect the container in cases where it would be readable by others or when you want to protect access in interactive mode. Since you can't really avoid to use the password in clear on a machine in unattended mode, there's little point having a difficult password, rather it's more important to protect the file itself. (It's not clear whether your applications are interactive or not, but I guess few users should be expected to type -Djavax.net.ssl....=... interactively.)
If you can't adapt your code to read from a file, change your keystore and keys passwords to a password you don't mind disclosing like "ABCD", and make sure you protect read access from this keystore file: that's what really matters in the end. Reading the password itself from a secondary file is merely postponing the problem by one step, since the password file and the keystore file are likely to be stored next to one another (and copied together by an unauthorised party).
In my program, I have a simple login prompt so that only certain users may enter a program, as well as make the program function differently depending on the user. What I would like to do is have the information for the user login information (username, password, etc.) securely stored without going through an online database. I know that using a text file to store this information is a very bad idea, and I'm sure there is an easier way to do this than to make an array of this login information internally inside my program. Could you all give me some suggestions of a way to do this?
Hashes are what you need. Paste a hash-making function into your code, MD5 functions are available online for all major platforms. Then store your pairs of hashes in your config file. Devise a clever way to combine a password with your admittance options into another hash so that the file is edit-proof. This way, you can distribute the account configuration and if you don't make a trivial cryptographic mistake, it will work just as you want.
Example of the config file line (hashes truncated to 6 chars for clarity):
1a2b3c print;search;evaluate 4d5e6f
Here, 1a2b3c is obtained as MD5(username.Text+verysecret), the verbs are the account's rights and 4d5e6f is obtained as MD5(line[1]+verysecret+password.Text) where line[1] is the split result of the config line where the verbs are stored and the rest is the user's password.
Note how the password gets automatically salted by the verbs and how the verbs are protected against editing because that would invalidate the password hash. The verysecret constant is something hidden in your executable code that will prevent anybody from computing the hashes and unlocking the program.
Hashing is not an asymmetric cipher or key pair; a motivated attacker can crack your program to bypass protection altogether anyway, so going to further lengths is useless.
If you are cheap to find an asymmetric scheme, but cunning enough, you can change a few initialization constants in that MD5 function. This will make the cracking of your code harder, especially against the making of a counterfeit account file.
EDIT: When authenticating, don't just if(hashfromconfig == computedhash)... Script kiddies know how to hook into the string comparison function. Write if(MD5(hashfromconfig) == MD5(computedhash))... instead... Then the string comparison will work just as before, only it will not see your precious key hash that goes into a wannabe-counterfeit file. Ideally, have several versions of the MD5 function scattered across your code and named differently. Use if(foo(hashfromconfig) == bar(computedhash))... for a nice effect.
"without going through an online database." - do you mean on the client side?
"securely stored" and "client side" are pretty much mutually exclusive terms in this scenario.
There is absolutely no way to securely store data without touching online (server-side) source of some kind. If you are touching server-side source, it might as well be a DB.
Google plus returns ajax requests with )]}' on first line. I heard it is protection against XSS. Are there any examples what and how could anyone do with this without that protection ?
Here's my best guess as to what's happening here.
First off, there are other aspects of the google json format that aren't quite valid json. So, in addition to any protection purposes, they may be using this specific string to signal that the rest of the file is in google-json format and needs to be interpreted accordingly.
Using this convention also means that the data feed wont execute from a call from a script tag, nor by interpreting the javascript directly from an eval(). This ensures front end developers are passing the content through a parser, which will keep any implanted code from executing.
So to answer your question, there are two plausible attacks that this prevents, one cross-site through a script tag, but the more interesting on is within-site. Both attacks assume that:
a bug exists in how user data is escaped and
it is exploited in a way that allows an attacker to inject code into one of the data feeds.
As a simple example, lets say a user figured out how to take a string like example
["example"]
and changed it to "];alert('example');
[""];alert('example');"]
Now if when that data shows up in another user's feed, the attacker can execute arbitrary code in the user's browser. Since it's within site, cookies are being sent to the server and the attacker could automate things like sharing posts or messaging people from the user's account.
In the Google scenario, these attacks won't work for a number of reasons. The first 5 characters will cause a javascript error before the attack code is run. Plus, since developers are forced to parse the code instead of accidentally running it through an eval, this practice will prevent code from being executed anyway.
As others said, it's a protection against Cross Site Script Inclusion (XSSI)
We explained this on Gruyere as:
Third, you should make sure that the script is not executable. The
standard way of doing this is to append some non-executable prefix to
it, like ])}while(1);. A script running in the same domain can
read the contents of the response and strip out the prefix, but
scripts running in other domains can't.
i developed a very simple vb.net application and i need a way for every user to verify that they have paid for it. i would like the simplest method possible. it will be an off-line registration. I am actually looking for a way that I can program this easily myself, and am not interested in third part solutions.
Just ask for the name, and calculate a hash (such as SHA1 or MD5) for that name (maybe lowercase and strip whitespace first), prefixed with some secret text that is hardcoded in your program. If you want different keys for different versions, then also prefix the version number before calculating the hash. That hash will be your registration key (or, if you think it is too long: take the first characters of the hash).
Have the user enter both the name and the registration key, and store those in the program's configuration. Then recalculate the hash in exactly the same way whenever you need to validate it, and compare it to the stored key.
You could store an encrypted string in the user's registry (e.g. his Full name). Decrypt that string at application start to check if the license is valid.
How secure do you want it to be?
If you're looking for rock-solid piracy protection (if it even exists) you'll have to combine it with some sort of online registration/activation system. Or use a 3rd party solution as opted by Mitch Wheat.