mirror of
https://github.com/nmap/nmap.git
synced 2025-12-16 04:39:03 +00:00
Reformat ordered lists in NSEdoc
This commit is contained in:
@@ -14,12 +14,13 @@ any Domino ID Files attached to the Person document. Passwords are presented
|
||||
in a form suitable for running in John the Ripper.
|
||||
|
||||
The passwords may be stored in two forms (http://comments.gmane.org/gmane.comp.security.openwall.john.user/785):
|
||||
|
||||
1. Saltless (legacy support?)
|
||||
Example: 355E98E7C7B59BD810ED845AD0FD2FC4
|
||||
John's format name: lotus5
|
||||
Example: 355E98E7C7B59BD810ED845AD0FD2FC4
|
||||
John's format name: lotus5
|
||||
2. Salted (also known as "More Secure Internet Password")
|
||||
Example: (GKjXibCW2Ml6juyQHUoP)
|
||||
John's format name: dominosec
|
||||
Example: (GKjXibCW2Ml6juyQHUoP)
|
||||
John's format name: dominosec
|
||||
|
||||
It appears as if form based authentication is enabled, basic authentication
|
||||
still works. Therefore the script should work in both scenarios. Valid
|
||||
|
||||
@@ -368,34 +368,29 @@ spend some time talking about how it works.
|
||||
Running a script happens in several stages:
|
||||
|
||||
1. An open fileshare is found that we can write to. Finding an open
|
||||
fileshare basically consists of enumerating all shares and seeing which
|
||||
one(s) we have access to.
|
||||
|
||||
fileshare basically consists of enumerating all shares and seeing which
|
||||
one(s) we have access to.
|
||||
2. A "service wrapper", and all of the uploadable/extra files, are uploaded.
|
||||
Before they're uploaded, the name of each file is obfuscated. The
|
||||
obfuscation completely renames the file, is unique for each source system,
|
||||
and doesn't change between multiple runs. This obfuscation has the benefit
|
||||
of preventing filenames from overlapping if multiple people are running this
|
||||
against the same computer, and also makes it more difficult to determine
|
||||
their purposes. The reason for keeping them consistent for every run is to
|
||||
make cleanup possible: a random filename, if the script somehow fails, will
|
||||
be left on the system.
|
||||
|
||||
Before they're uploaded, the name of each file is obfuscated. The
|
||||
obfuscation completely renames the file, is unique for each source system,
|
||||
and doesn't change between multiple runs. This obfuscation has the benefit
|
||||
of preventing filenames from overlapping if multiple people are running this
|
||||
against the same computer, and also makes it more difficult to determine
|
||||
their purposes. The reason for keeping them consistent for every run is to
|
||||
make cleanup possible: a random filename, if the script somehow fails, will
|
||||
be left on the system.
|
||||
3. A new service is created and started. The new service has a random name
|
||||
for the same reason the files do, and points at the 'service wrapper'
|
||||
program that was uploaded.
|
||||
|
||||
for the same reason the files do, and points at the 'service wrapper'
|
||||
program that was uploaded.
|
||||
4. The service runs the processes. One by one, the processes are run and
|
||||
their output is captured. The output is obfuscated using a simple (and
|
||||
highly insecure) xor algorithm, which is designed to prevent casual sniffing
|
||||
(but won't deter intelligent attackers). This data is put into a temporary
|
||||
output file. When all the programs have finished, the file is renamed to the
|
||||
final output file
|
||||
|
||||
their output is captured. The output is obfuscated using a simple (and
|
||||
highly insecure) xor algorithm, which is designed to prevent casual sniffing
|
||||
(but won't deter intelligent attackers). This data is put into a temporary
|
||||
output file. When all the programs have finished, the file is renamed to the
|
||||
final output file
|
||||
5. The output file is downloaded, and the cleanup is performced. The file
|
||||
being renamed triggers the final stage of the program, where the data is
|
||||
downloaded and all relevant files are deleted.
|
||||
|
||||
being renamed triggers the final stage of the program, where the data is
|
||||
downloaded and all relevant files are deleted.
|
||||
6. Output file, now decrypted, is formatted and displayed to the user.
|
||||
|
||||
And that's how it works!
|
||||
|
||||
Reference in New Issue
Block a user