Wireless Pentesting with Qubes

[endeavour]

Hello Everyone,
I need help regarding wireless pentesting.
Installed Os= Parrot OS as standalone HVM.
Chaining= sys-usb (provides network) < sys-firewall < Parrot OS
I have also tried directly using sys-usb upto no avail.

Any help would be much appreciated.

[51lieal]

Not a right place to asking for pentest,
but if you want learn how networking works in qubes, there’s a good doc Networking | Qubes OS and Firewall | Qubes OS

[endeavour]

Thanks, will go through those asap.

[unman]

You don’t say how many WiFi devices you have, or what you are trying to
do.
If you only have one device, then some techniques will work, some wont,
If you intend to pentest low level features of WiFi itself, then get a
dedicated device, which you attach to the Parrot qube.
If you want to pentest over WiFi that will work with your set-up.

[endeavour]

I am trying to do some moniter mode stuff using aircrack-ng.
While internal wifi works using PCI passthrough I need usb adapter to work.
I tried assigning usb controller to parrot qube but got the following error while boot:
Start failed: internal error: “Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or bus reset available, see /var/log/libvirt/libxl/libxl-driver.log for details”.

Meanwhile here is what I got from logs:

1. libxl: libxl_pci.c:1489:libxl__device_pci_reset: The kernel doesn’t support reset from sysfs for PCI device 0000:00:14.0

2. libxl: libxl_domain.c:853:pvcontrol_cb: guest didn’t acknowledge control request: -9

3. libxl: libxl_device.c:1146:device_backend_callback: Domain 37:unable to remove device with path /local/domain/33/backend/vif/37/0

4. libxl: libxl_domain.c:1529:devices_destroy_cb: Domain 37:libxl__devices_destroy failed

5. libxl: libxl_device.c:1146:device_backend_callback: Domain 48:unable to remove device with path /local/domain/38/backend/vif/48/0

6. libxl: libxl_domain.c:1529:devices_destroy_cb: Domain 48:libxl__devices_destroy failed

I will appreciate if you can guide me properly in this regard.

[51lieal]

Good doc about pci too, you can find how to fix there.

PCI troubleshooting

[endeavour]

I was trying to apply usb controller to main parrot vm not usb-qube.

In my case there are three sys-usb vms namely sys-usb, sys-usb-clone, parrot-usb.
So my question is if I apply “qvm-pci attach --option no-strict-reset=true parrot-usb dom0:00_14.0” to parrot-usb will it affect other also?
If Yes, how to reset this option?

On another note is there any way to attach usb adapter to parrot os itself without any middleman i.e, sys-usb (parrot-usb in this case)?

[enmus]

Try to set PV mode for the correspondent sys-usb qube, then attach it to parrot via qvm-usb attach --persistent..…

[deeplow]

See this:

@deeplow

Network Recon Qube

A way to probe a network with physical interfaces rather than virtual ones.

Pretty much like the default sys-net but with network analysis tooling like nmap and wireshark.

Use inter-qube communication to move recon data into Analysis Qube

The Qubes team always cautions users to always move data from more trusted VMs into less trusted VMs.

So, if in doubt that your Analysis Qube is more trusted than your Recon Qube, just copy and paste the dumps through the clipboard - since in the end it’s all just text files.

Another more trustworthy way is to take screenshots (which are taken from dom0) and then send them over to the Analysis Qube.

This qube is not connected to sys-firewall

The qube is not connected to any firewall proxy (like sys-firewall ), so there is a bit more elevated risk - but this is the only actual way to probe the network while using Qubes.

Plug in in a network peripheral

This qube gets attached a USB WiFi network peripheral (you don’t want to mess anything up with your sys-net )

[endeavour]

Here are my takeaways from this post, correct me if I am wrong:

1. Clone sys-net and install pentest tools on it.

2. Allow it to access usb adapter using pci passthrough and capture data.

3. Allow it to transmit data backchannel safely.

4. Perform inspection on data in pentest qube.

I will be researching more and report back my findings for future users.

At last I have unorthodox question regarding virtualization inside one of my sanboxed windows hvm. I am trying to run vmware inside of it to perform some analysis. Encountered error as follows:

This host does not support Intel VT-x.
This host does not support “Intel EPT” hardware assisted MMU virtualization.
VMware Workstation does not support the user level monitor on this host.
Module ‘MonitorMode’ power on failed.
Failed to start the virtual machine

Is that possible? If Yes, do point me in right direction.

[unman]

You can, but need not, use a cloned sys-net for pentesting.
Depending on the tools you want to use you can run them from a connected
qube.

If you want to keep normal and pentesting activities separate then
using a separate sys-net with separate attached NICs is a good thing™

I gather data in “pentest qube” and analyse it in a separate qube,
sometimes disposable, either offline or part of a virtual net.

On your bonus question, it is possible to run VMware in nested VMs.
Whether you can do this will depend on what hardware you have, what
guests you want to run, what version of VMware you have, and so on.
I’m fairly certain that Workstation wont work under Xen, but you could
prove me wrong.