clarification regarding ip and mac addresses

[keshavsp]

"datos": { "ip_origen":"0.0.0.0:1", "mac_origen":"aa:bb:cc:dd:ee:ff", "mac_destino":"bb:aa:cc:dd:ee:ff", "interfaz": 0, "threads": 100 }, "peticion":[ { "ip_destino":"1.1.1.1:1604", "descripcion": "Citrix ICA protocol", "intentos": 1000,

Is ‘ip_origen’ supposed to be victim’s IP? Also, can you clarify regarding ‘mac_origen’ and ‘mac_destino’ please?

Thanks

Keshav

[daniel0x00]

Dear Keshav,

"ip_origen" supposed to be the IP you want to spoof, that means the IP of third party victim you want to send DRDoS attack. For example, if I want to attack you, that's will be your public IP address.

"mac_origen" it's the MAC address of your adapter (supposed to be the MAC address of the "ip_origen" IP), your could use any fake MAC address like "aa:bb:cc..." but have in mind that if you are running r2dr2 in a virtual machine, your have to specify your real MAC address of the adapter you are using to connect to Internet.

"mac_destino" it's the MAC address of any of "ip_destino" services, you could use any fake address here.

"ip_destino" in "peticion" array are the IP address of the third party services you want to exploit to amplify the attack, like SIP, Citrix ICA, CharGEN, NTP, SNMP, etc.

Have you seen the example video at securitybydefault.com http://www.securitybydefault.com/2014/06/r2dr2-analysis-and-exploitation-of-udp-amplification-vulns.html ? Article it's in English.

IMPORTANT: please have in mind that in order to spoof a public IP address you HAVE to connect directly to Internet, your adapter needs to have a public IP address and your ISP needs to have BCP 38 disabled. Normally ISPs that allow an UDP IP spoofing http://www.hackforums.net/printthread.php?tid=4042055 are in "special" countries that look to another side for this kind of things... You could know if your ISP are blocking you or not using this MIT project http://spoofer.cmand.org/.

Best regards, Daniel.

2014-07-18 21:33 GMT+02:00 keshavsp notifications@github.com:

"datos": { "ip_origen":"0.0.0.0:1", "mac_origen":"aa:bb:cc:dd:ee:ff", "mac_destino":"bb:aa:cc:dd:ee:ff", "interfaz": 0, "threads": 100 }, "peticion":[ { "ip_destino":"1.1.1.1:1604", "descripcion": "Citrix ICA protocol", "intentos": 1000,

Is ‘ip_origen’ supposed to be victim’s IP? Also, can you clarify regarding ‘mac_origen’ and ‘mac_destino’ please?

Thanks

Keshav

— Reply to this email directly or view it on GitHub https://github.com/daniel0x00/r2dr2-udp-drdos-tool/issues/3.

Daniel

[keshavsp]

Thanks for the explanation. Infact, I have everything setup just the way you described. R2DR2 is run in a test environment which consists of vmware esxi instances of attacker, victim and SIP (Asterisk) servers. It just doesn't seem to send any traffic at all. I'm using the 'paquete' from config_example.json. I tried using fake as well as the virtual mac addresses assigned by vmware esxi. yes, I tried watching the video but the command line is not very clear. so I couldn't make use of it..

Regards, Keshav

[daniel0x00]

Please send me your json config file.

Enviado desde mi iPhone

El 22/07/2014, a las 19:22, keshavsp notifications@github.com escribió:

Thanks for the explanation. Infact, I have everything setup just the way you described. R2DR2 is run in a test environment which consists of vmware esxi instances of attacker, victim and SIP (Asterisk) servers. It just doesn't seem to send any traffic at all. I'm using the 'paquete' from config_example.json. I tried using fake as well as the virtual mac addresses assigned by vmware esxi. yes, I tried watching the video but the command line is not very clear. so I couldn't make use of it..

Regards, Keshav

— Reply to this email directly or view it on GitHub.

[keshavsp]

1 { 2 "datos": { 3 "ip_origen":"3.0.21.16:53", 4 "mac_origen":"00:0c:29:ef:a8:7e", 5 "mac_destino":"00:0c:29:84:c4:17", 6 "interfaz": 0, 7 "threads": 100 8 }, 9 "peticion":[ 10 { 11 "ip_destino":"3.0.21.102:5060", 12 "descripcion": "SIP protocol", 13 "intentos": 25, 14 "paquete": [ 15 "4f5054494f4e53207369703a614061205349502f322e300d0a5669613a205349502f322e302f554450203139322e313 6382e312e313a353036303b6272616e63683d310d0a46726f6d3a203c7369703a6140613e3b7461673d310d0a546f3a203c73697 03a6240623e0d0a43616c6c2d49443a2039370d0a435365713a2032204f5054494f4e530d0a0d0a" ] 16 } 17 ] 18 }

Line 3 - victim IP Line 4 - attacker (from where r2dr2.exe is run) Line 5 - mac addr of Asterisk server Line 6 - ‘“interfaz": 0,’ - copied from config_example.json. Not sure what this field does. I tried with a value of ‘2’ which is the interface number of attacker IP (from where r2dr2.exe is run) but it showed an error at the time of loading the file Line 11 - Asterisk server Line 14 - copied from config_example.json

The above json loads successfully but does not send out any traffic.

I have also tried using fake mac addresses (as you mentioned earlier) with the same result.

To make sure my network is properly configured to switch traffic through Asterisk, I have successfully tested voice calls between the attacker and victim using a softphone application (‘PhoneLite’).

Thanks again for looking into this. R2DR2 seems like a pretty neat tool that provides a lot of flexibiity to define data (payload and network info) unlike many other tools that I have seen previously. I guess I just need to know the right json format to make use of it. :)

Keshav

[daniel0x00]

Everything looks great, but tell me something:

1. Are that public IP address or private lan?
2. Interface number it's 0 by default but you can choose another interface on GUI mode and it will override json interface number.
3. Do you know wireshark sniffer? You could install wireshark on attacker and victim computer to see if there is a traffic going out/in. Use "SIP" filter.
4. Have in mind not SIP gateways at all are "vulnerable", I mean, not at all answer to OPTIONS method (that's the reason you have to use wireshark to detect if request is arriving to gateway).

I'm on an airport getting a long way travel, let me arrive to my destiny and I'll send you some public ips vulnerable to SIP options method, so you can try well.

Enviado desde mi iPhone

El 23/07/2014, a las 04:11, keshavsp notifications@github.com escribió:

1 { 2 "datos": { 3 "ip_origen":"3.0.21.16:53", 4 "mac_origen":"00:0c:29:ef:a8:7e", 5 "mac_destino":"00:0c:29:84:c4:17", 6 "interfaz": 0, 7 "threads": 100 8 }, 9 "peticion":[ 10 { 11 "ip_destino":"3.0.21.102:5060", 12 "descripcion": "SIP protocol", 13 "intentos": 25, 14 "paquete": [ 15 "4f5054494f4e53207369703a614061205349502f322e300d0a5669613a205349502f322e302f554450203139322e313 6382e312e313a353036303b6272616e63683d310d0a46726f6d3a203c7369703a6140613e3b7461673d310d0a546f3a203c73697 03a6240623e0d0a43616c6c2d49443a2039370d0a435365713a2032204f5054494f4e530d0a0d0a" ] 16 } 17 ] 18 }

Line 3 - victim IP Line 4 - attacker (from where r2dr2.exe is run) Line 5 - mac addr of Asterisk server Line 6 - ‘“interfaz": 0,’ - copied from config_example.json. Not sure what this field does. I tried with a value of ‘2’ which is the interface number of attacker IP (from where r2dr2.exe is run) but it showed an error at the time of loading the file Line 11 - Asterisk server Line 14 - copied from config_example.json

The above json loads successfully but does not send out any traffic.

I have also tried using fake mac addresses (as you mentioned earlier) with the same result.

To make sure my network is properly configured to switch traffic through Asterisk, I have successfully tested voice calls between the attacker and victim using a softphone application (‘PhoneLite’).

Thanks again for looking into this. R2DR2 seems like a pretty neat tool that provides a lot of flexibiity to define data (payload and network info) unlike many other tools that I have seen previously. I guess I just need to know the right json format to make use of it. :)

Keshav

— Reply to this email directly or view it on GitHub.

[keshavsp]

All are in a lan (none of them are public IPs). I use tcpdump to verify traffic between r2dr2, Asterisk server and the victim. I don't see it appear anywhere. As I mentioned previously, I have verified that traffic goes through the SIP server by running a softphone call between the machine where r2dr2 is installed and the victim (target) machine. If you think my json looks good. then I am not sure where else to look at. I'm pretty sure Asterisk does respond to OPTIONS (I don't see any specific setting to disable it).

Also, can you please elaborate on the OPTIONS field that causes an amplified response from the server? Is it an SDP request within the OPTIONS body that causes an amplified response? If yes, is there a specific SDP request that you can provide that triggers amplified response?

Thanks and Regards,

Keshav