NSE: failed to initialize the script engine: - lua

I'm new to VAPT and I'm using GUI for windows, this is what I got when I used this script from nmap online guide [nmap -p 80 --script http-default-accounts.routers xx.xx.xx.xx]. I borrowed the script from here : https://nmap.org/nsedoc/scripts/http-default-accounts.html
[nmap -p 80 --script http-default-accounts.routers xx.xx.xx.xx]
Nmap output begins below this line:
NSE: failed to initialize the script engine:
C:\Program Files (x86)\Nmap/nse_main.lua:823: 'http-default-accounts.category' did not match a category, filename, or directory
stack traceback:
[C]: in function 'error'
C:\Program Files (x86)\Nmap/nse_main.lua:823: in local 'get_chosen_scripts'
C:\Program Files (x86)\Nmap/nse_main.lua:1315: in main chunk
[C]: in ?
QUITTING!

Nmap uses the --script option to introduce a boolean expression of script names and categories to run. To provide arguments to these scripts, you use the --script-args option. So what you wanted to run was: nmap --script http-default-accounts --script-args http-default-accounts.category=routers
In most cases, you can leave the script name off of the script argument name, as long as you realize that another script may also be looking for an argument called category. For example: nmap --script http-default-accounts --script-args category=routers

If you are using this command:
nmap --script vulscan.nmap-vulners -sV {target}
Then use the following command instead.
nmap -sV --script vulners {target}
For me, it worked.

As for Nmap 7.90 [2020-10-03] changelog, dealing with directories has changed:
[GH#2051]Restrict Nmap's search path for scripts and data files. NMAPDATADIR, defined on Unix and Linux as ${prefix}/share/nmap, will not be searched on Windows, where it was previously defined as C:\Nmap . Additionally, the --script option will not interpret names as directory names unless they are followed by a '/'. [Daniel Miller]
So basically if we said you are using kali and this is your old command:
nmap --script vulscan -sV ###.###.###.###
It should become like:
nmap --script vulscan/ -sV ###.###.###.###
adding a / after directory name.

Related

xonsh "which" equivalent - how to test if a (subprocess mode) command is available?

I would like to test (from xonsh) if a command is available or not. If I try this from the xonsh command prompt:
which bash
Then it works:
user#server ~ $ which bash
/usr/bin/bash
But it does not work from xonsh script:
#!/usr/bin/env xonsh
$RAISE_SUBPROC_ERROR = True
try:
which bash
print("bash is available")
except:
print("bash is not available")
Because it results in this error:
NameError: name 'which' is not defined
I understand that which is a shell builtin. E.g. it is not an executable file. But it is available at the xnosh command prompt. Then why it is not available inside an xonsh script? The ultimate question is this: how can I test (from an xonsh script) if a (subprocess mode) command is available or not?
import shutil
print(shutil.which('bash'))
While nagylzs' answer led me to the right solution, I found it inadequate.
shutil.which defaults to os.environ['PATH']. On my machine, the default os.environ['PATH'] doesn't contain the active PATH recognized by xonsh.
~ $ os.environ['PATH']
'/usr/bin:/bin:/usr/sbin:/sbin'
I found I needed to pass $PATH to reliably resolve 'which' in the xonsh environment.
~ $ $PATH[:2]
['/opt/google-cloud-sdk/bin', '/Users/jaraco/.local/bin']
~ $ import shutil
~ $ shutil.which('brew', path=os.pathsep.join($PATH))
'/opt/homebrew/bin/brew'
The latest version of xonsh includes a built-in which command. Unfortunately, the version included will emit an error on stdout if the target isn't found, a behavior that is not great for non-interactive use.
As mentioned in another answer, which exists in the current version of xonsh (0.13.4 as of 15/12/2022) so your script would work. However, it outputs its own error message so it's necessary to redirect stderr to get rid of it.
Also, unless you redirect its stdout as well (using all>), it migh be a good idea to capture its output so the final version would look like this:
#!/usr/bin/env xonsh
$RAISE_SUBPROC_ERROR = True
try:
bash = $(which bash err> /dev/null)
print(f"bash is available: {bash}")
except:
print("bash is not available")

How to debug Oracle 11g packages/procedures in docker with SQL Developer?

I'm running an Oracle 11g image (https://hub.docker.com/r/oracleinanutshell/oracle-xe-11g) on a docker container.
I'm creating the container with the debug option as explained:
docker run --name oracle-xe-11g -idt -p 1521:1521 -p 49161:8080 -e ORACLE_ALLOW_REMOTE=true oracleinanutshell/oracle-xe-11g /bin/bash
After that I logged in the container as sudo, configured the listener.ora with the correct hostname, everything following this guide (it's in pt-Br, but the commands are easy to understand)
http://loredata.com.br/2017/08/31/rodando-o-oracle-no-docker/
I can connect with SQL Developer and with my main application running in a Wildfly server, but for support purposes I need to debug some package and stored procedures.
I compiled all my packages and procedures to allow debugging, gave the debug permissions to the user, but when I try to debug a procedure in a package using the SQL Developer default debug options I get the following error:
Conectando ao banco de dados SFW_DOCKER.
Executando PL/SQL: ALTER SESSION SET PLSQL_DEBUG=TRUE
Executando PL/SQL: CALL DBMS_DEBUG_JDWP.CONNECT_TCP( '127.0.0.1', '20587' )
ORA-30683: falha ao estabelecer conexão com o depurador
ORA-12541: TNS:não há listener
ORA-06512: em "SYS.DBMS_DEBUG_JDWP", line 68
ORA-06512: em line 1
Processo encerrado.
Desconectando do banco de dados SFW_DOCKER.
It says there's no listener, but I'm sure everything is running fine.
I also tried to run in ports 4000-4999 exposing them in the create container command and forcing SQL Developer to use them, but I get the same error.
Anyone can help me with this question?
To solve try:
Use IPv4 from your local machine
Set 'Debugging Port Range' from 4000 to 4000
Check the option 'Prompt for Debugger Host for Database Debugging'
SQL Developer -> Tools -> Preferences -> Debugger
Debugger configuration
I solved it by setting DatabaseDebuggerDisableJDWP=true in ide.properties. On linux this can be done with this:
find ~/.sqldeveloper/ -name ide.properties -type f -exec sh -c "echo 'DatabaseDebuggerDisableJDWP=true' >> {}" \;

Monitor a service running on a port other than 80 in Nagios

How do we monitor a remote service running on a machine using Nagios.
I have created a cfg file as follows:
define command {
command_name check_http
command_line /usr/lib64/nagios/plugins/check_http -H $HOSTADDRESS$ -p 8082
}
Now when I reload the configuration file, it throws following error:
Warning: Duplicate definition found for command 'check_http' (config file '/etc/nagios/servers/cfbase-prod.cfg', starting on line 19)
Error: Could not add object property in file '/etc/nagios/servers/cfbase-prod.cfg' on line 20.
Error processing object config files!
I am not able to figure out what is the problem.
Please help!
The basic problem is that the command_name value conflicts with the original/standard check_http command. You have (at least) a couple choices:
Set a unique command_name, e.g. check_http_8082.
Define a command to check http on an arbitrary port that gets passed as an argument. E.g.
define command{
command_name check_http_port
command_line /usr/lib64/nagios/plugins/check_http -H $HOSTADDRESS$ -p $ARG1$
}

yaws failed to start yet erlang works very well

I downloaded and installed win32 yaws-1.98 installer for my win7 and tried to start it from windows command prompt with: yaws -i. the result I got is just as right below. where I have placed # was a simicolon.
Failed to create the process entirely.
Tried to invoke: erl.exe -pa "C:/Program Files/Yaws-1.98/ebin" -conf "C:\Program Files\Yaws-1.98\yaws.conf" -run yaws -yaws id default #
Make sure you have erl in your environment PATH
after some research, I placed the following paths in the O.S environment variables list separated by semicolon, first under the name ERL_LIBS and then PATH all with no change :
C:\Program Files\erl5.10.3\erts-5.10.3\bin
C:\Program Files\erl5.10.3\bin
what could I be missing
...s.b help.

Windows Server 2003 call to secedit within a batch script generates "C:\Program" on system reboot

In executing
secedit /configure /db %~1\tomcat.sdb" /cfg %~1\2003.inf" /log %~1\dtomcat.log" /quiet
where
%~1 == C:\Program Files\myDirectory\mySubDirectory\mySuperSubDirectory
a file titled "C:\Program" is generated and within the file is the output for calling
secedit /?
I am curious as to why this is occuring because it makes it quite difficult to start certain services after an installation of a new product, for instance a PostGres windows service.
You appear to be missing quotes in a couple of places:
secedit /configure /db "%~1\tomcat.sdb" /cfg "%~1\2003.inf" /log "%~1\dtomcat.log" /quiet
^ ^ ^
You need to enclose the pathname in quotes:
"C:\Program Files\myDirectory\mySubDirectory\mySuperSubDirectory"
The space in "Program Files" is treated as a delimiter.

Resources