I am starting to test proof of concept exploits in my VM. I came across this Microsoft animated cursor vuln - MS07-017.
I saw the process in exploit-db. The compilation is ok:-
Win32/VC++ : cl -o HOD-ms05002-ani-expl HOD-ms05002-ani-expl.c
Win32/cygwin: gcc -o HOD-ms05002-ani-expl HOD-ms05002-ani-expl.c
Linux : gcc -o HOD-ms05002-ani-expl HOD-ms05002-ani-expl.c
But the next step is not understood:
C:\>HOD-ms05002-ani-expl.exe poc 7777
I see the same "poc(may be proof of concept)" in the command for linux too
$ HOD-ms05002-ani-expl poc 7777 192.168.0.30
What is the meaning of the above two commands?
I exploited the vulnerability in my XP virtual machine from Kali- metasploit and that was by XP visiting the URIPATH. But the above method is out of my grip.
Thanks
kriss332
Got the answer, I wasnt looking at the code part. poc was just an argument passed to program.
Related
I'm having trouble setting up DB2 on macOS via Docker on my M1-Max MacBook Pro (32 GB RAM). I already had a look at this question, which might be related, however there is not a lot of information and I cannot exactly say, if it is about the exact same thing.
I set up following docker-compose.yml:
version: '3.8'
services:
db2:
image: ibmcom/db2
platform: linux/amd64
container_name: db2-test
privileged: true
environment:
LICENSE: "accept"
DB2INSTANCE: "db2dude"
DB2INST1_PASSWORD: "db2pw"
DBNAME: "RC1DBA"
BLU: "false"
ENABLE_ORACLE_COMPATIBILITY: "false"
UPDATEVAIL: "NO"
TO_CREATE_SAMPLEDB: "false"
REPODB: "false"
IS_OSXFS: "true"
PERSISTENT_HOME: "true"
HADR_ENABLED: "false"
ETCD_ENDPOINT: ""
ETCD_USERNAME: ""
ETCD_PASSWORD: ""
volumes:
- ~/workspace/docker/db2-error/db2/database:/database
- ~/workspace/docker/db2-error/db2/db2_data:/db2_data
ports:
- 50000:50000
on my Intel-MacBook, this spins up without any issue, on my M1-MacBook however I see after Task #4 finished, I see following portion inside of the STDOUT:
DBI1446I The db2icrt command is running.
DBI1070I Program db2icrt completed successfully.
(*) Fixing /etc/services file for DB2 ...
/bin/bash: db2stop: command not found
From what I could figure out, the presence of (*) Fixing /etc/services file for DB2 ... already seems to be wrong (since it does not appear in my intel log and does not sound like everything's fine) and the /bin/bash: db2stop: command not found appears due to line 81 of /var/db2_setup/include/db2_common_functions, which states su - ${DB2INSTANCE?} -c 'db2stop force'.
As far as I understand, su - should run with the path of the target user. In every single .profile or .bashrc in the home directory, the ~/sqllib/db2profile is being sourced (via . /database/config/db2dude/sqllib/db2profile).
However, when as root inside of the container (docker exec -it db2-test bash), calling su - db2dude -c 'echo $PATH', it prints /usr/local/bin:/bin:/usr/bin. Therefore, the PATH obviously is not as expected.
Maybe someone can figure out, what's happening at this point. I also tried running Docker with "new Virtualization framework", which did not change anything. I assume, Dockers compatibility magic might not be perfect, however I'm looking forward to find some kind of workaround, maybe by building an image upon ibmcom/db2.
I highly appreciate your time and advice. Thanks a lot in advance.
As stated in #mshabou's answer, there is no support yet. One way you can still make it work is by prepending your Docker command with DOCKER_DEFAULT_PLATFORM=linux/amd64 or executing export DOCKER_DEFAULT_PLATFORM=linux/amd64 in your shell before starting the container.
Alternatively, you can also use colima. Install colima as described on their GitHub page and then start it in emulated mode like colima start --arch x86_64. Now you will be able to use your ibmcom/db2 image the way you're used to (albeit with decreased performance).
db2 is not supported on ARM architecture, only theses Architectures are supported: amd64, ppc64le, s390x
https://hub.docker.com/r/ibmcom/db2
Using pvymomi, I can determine the OS. How does one determine the OS version?
#!/usr/bin/python3
import sys
import atexit
from pyVmomi import vim
from pyVim.connect import SmartConnectNoSSL, Disconnect
si = SmartConnectNoSSL(host = 'xxx', user = 'xxx', pwd = 'xxx', port = 443)
atexit.register(Disconnect, si)
content = si.RetrieveContent()
vm = si.content.searchIndex.FindByIp(None, sys.argv[1], True)
print(vm.summary.config.guestFullName)
print(vm.summary.config.guestId)
The above code produces the following:
$ ./example.py 10.120.73.45
CentOS 7 (64-bit)
centos7_64Guest
I can see the VM is running CentOS 7, but is it 7.6 or 7.9? I'm not seeing what property or even what data object gives that information.
After doing some research into this question, I have found that the vSphere Web Services API, which the Python package pyvmomi uses does not have an easy way to collect the exact version operating system version with a basic API call.
If you look at the vSphere Web Services API information for
guestFamily, which is in GuestInfo you will not see any API call for precise versioning information.
Additionally, to obtain the exact operating system version information for CentOS you would normally have to query the kernel, which contains this information.
You can obtain the version of CentOS using this command:
cat /etc/centos-release
# output
CentOS Linux release 7.9.2009 (Core)
You can query this information GuestProgramSpec
Here is some pseudocode for doing this.
ps = vim.vm.guest.ProcessManager.ProgramSpec(programPath="/usr/bin/cat", arguments=" /etc/centos-release > /tmp/os_version_info.txt")
res = pm.StartProgramInGuest(vm, creds, ps)
You can also obtain this information using the uname tool, which is commonly used to obtain information about the processor architecture, which as the system hostname and the version of the kernel running on the system.
Here is the command - uname -s -r
-s, (--kernel-name) - Prints the kernel name
-r, (--kernel-release) - Prints the kernel release.
Here is a website that provides some information on mapping the kernel releases information to a specific operating system. Here is another website. Using the latter website I can see that kernel-3.10.0-1160.el7.x86_64 maps to CentOS 7.9.2009 for x86_64.
Here is some pseudocode for doing this.
ps = vim.vm.guest.ProcessManager.ProgramSpec(programPath="/usr/bin/uname", arguments=" -s -r > /tmp/os_kernel_info.txt")
res = pm.StartProgramInGuest(vm, creds, ps)
Based on my research getting this information back to the console is more complex. Here is a Stack Overflow question in how to do this.
UPDATE
I discovered this sample pyvmomi script, which can execute a command and retrieve the content back to the console.
Execute program in a virtual machine
I've been at it for days but could not solve my problem.
I am running:
mpiexec -hostfile ~/machines -nolocal -pernode mkdir -p $dstpath where $dstpath points to current directory and "machines" is a file containing:
node01
node02
node03
node04
This is the error output:
Failed to parse XML input with the minimalistic parser. If it was not
generated by hwloc, try enabling full XML support with libxml2.
[node01:06177] [[6421,0],0] ORTE_ERROR_LOG: Error in file base/plm_base_launch_support.c at line 891
--------------------------------------------------------------------------
ORTE was unable to reliably start one or more daemons.
This usually is caused by:
* not finding the required libraries and/or binaries on
one or more nodes. Please check your PATH and LD_LIBRARY_PATH
settings, or configure OMPI with --enable-orterun-prefix-by-default
* lack of authority to execute on one or more specified nodes.
Please verify your allocation and authorities.
* the inability to write startup files into /tmp (--tmpdir/orte_tmpdir_base).
Please check with your sys admin to determine the correct location to use.
* compilation of the orted with dynamic libraries when static are required
(e.g., on Cray). Please check your configure cmd line and consider using
one of the contrib/platform definitions for your system type.
* an inability to create a connection back to mpirun due to a
lack of common network interfaces and/or no route found between
them. Please check network connectivity (including firewalls
and network routing requirements).
--------------------------------------------------------------------------
[node01:06177] 1 more process has sent help message help-errmgr-base.txt / failed-daemon-launch
[node01:06177] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
Failed to parse XML input with the minimalistic parser. If it was not
generated by hwloc, try enabling full XML support with libxml2.
[node01:06181] [[6417,0],0] ORTE_ERROR_LOG: Error in file base/plm_base_launch_support.c at line 891
I have 4 machines, node01 to node04. In order to log into these 4 nodes, I have to first log in to node00. I am trying to run some distributed graph functions. The graph software is installed in node01 and is supposed to be synchronised to the other nodes using mpiexec.
What I've done:
Made sure all passwordless login are setup, every machine can ssh to any other machine with no issues.
Have a hostfile in the home directory.
echo $PATH gives /home/myhome/bin:/home/myhome/.local/bin:/usr/include/openmpi:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
echo $LD_LIBRARY_PATH gives
/usr/lib/openmpi/lib
This has previously worked before, but it just suddenly started giving these errors. I got my administrator to install fresh machines but it still gave such errors. I've tried doing it one node at a time but it gave the same errors. I'm not entirely familiar with command line at all so please give me some suggestions. I've tried reinstalling OpenMPI from source and from sudo apt-get install openmpi-bin. I'm on Ubuntu 16.04 LTS.
You should focus on fixing:
Failed to parse XML input with the minimalistic parser. If it was not
generated by hwloc, try enabling full XML support with libxml2.
[node01:06177] [[6421,0],0] ORTE_ERROR_LOG: Error in file base/plm_base_launch_support.c at line 891
I installed the Freeswitch on Ubuntu Image in the Docker, referring to the documentation mentioned here.
When I did the following:
Start FreeSWITCH
First Time
cd /usr/local/freeswitch/bin
./freeswitch
I got to the following screen on my command prompt.
And as the last line says, [WARNING] switch_console.c:1053 We've become an orphan, no more console for us., something is wrong here I believe.
As per the documentation, I was expecting the prompt, like freeswitch#domain> .
Does anyone know what could be the problem? Upon researching this error I landed at the source file many times at different places, for example, one mentioned here
I had the same problem.
If we look in the source code of Freeswitch, we see
if (getppid() == 1) {
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_WARNING, "We've become an orphan, no more console for us.\n");
break;
}
We see that we had pid == 1, this mean that parent process for freeswitch is init process but we launched it in bash
docker run -it freeswitch_container bash
Problem described here
To solve this you just need to run another bash in running bash, so it will have pid != 1.
I have multithreaded application, it is working fine at my development server (HP-UX). When it is deployed to client server it gives the following error:
. Process 16448. Starting (CONT) Thread: 0 /usr/lib/pa20_64/dld.sl:
Unsatisfied code ymbol 'pthread_create' in load module 'bin/CCQO'.
Killed
I fond that libpthread.1 at customer server does not have pthread_create method with nm command. This from client server:
/usr/lib/pa20_64 > nm -g libpthread.1 | grep 'pthread_cre'
[475] | 4611686018427436512| 1116|FUNC |GLOB |0|.text|__pthread_create_system
But when I run the same command on my development server I get following output:
[733] | 4611686018427467256| 2160|FUNC |GLOB |0| .text|__pthread_create_generic
[712] | 4611686018427467192| 64|FUNC |GLOB |0| .text|__pthread_create_system
[625] | 4611686018427467112| 64|FUNC |WEAK |0| .text|pthread_create
I tried to copy libraries from my server to client server but it does not work.
Please me know how can I now the version of threading library at my machine and at client machine ?
How can I update client machine with updated library ?
Can copying my libraries to other server, solve the issue ? If yes, then what are steps.
I fond that libpthread.1 at customer server does not have pthread_create method with nm command.
Your customer's libpthread.1 is corrupt. Perhaps the customer ran strip, or molested it in some other way.
Can copying my libraries to other server, solve the issue ?
This can render the machine un-bootable, and you should almost certainly not do that.
The right solution is for the customer's sysadmin to restore system libraries from his HP-UX media.