This post is about PKCE [RFC7636], a protection mechanism for OAuth and OpenIDConnect designed for public clients to detect the authorization code interception attack.
At the beginning of our research, we wrongly believed that PKCE protects mobile and native apps from the so called „App Impersonation" attacks. Considering our ideas and after a short discussion with the authors of the PKCE specification, we found out that PKCE does not address this issue.
In other words, the protection of PKCE can be bypassed on public clients (mobile and native apps) by using a maliciously acting app.
OAuth Code Flow
In Figure 1, we briefly introduce how the OAuth flow works on mobile apps and show show the reason why we do need PKCE. In our example the user has two apps installed on the mobile phone: an Honest App and an Evil App. We assume that the Evil App is able to register the same handler as the Honest App and thus intercept messages sent to the Honest App. If you are more interested in this issue, you can find more information here [1].
Figure 1: An example of the "authorization code interception" attack on mobile devices.
Step 1: A user starts the Honest App and initiates the authentication via OpenID Connect or the authorization via OAuth. Consequentially, the Honest App generates an Auth Request containing the OpenID Connect/OAuth parameters: client_id, state, redirect_uri, scope, authorization_grant, nonce, ….
Step 2: The Browser is called and the Auth Request is sent to the Authorization Server (usually Facebook, Google, …).
The Honest App could use a Web View browser. However, the current specification clearly advice to use the operating system's default browser and avoid the usage of Web Views [2]. In addition, Google does not allow the usage of Web View browser since August 2016 [3].
Step 3: We asume that the user is authenticated and he authorizes the access to the requested resources. As a result, the Auth Response containing the code is sent back to the browser.
Step 4: Now, the browser calls the Honest App registered handler. However, the Evil App is registered on this handler too and receives the code.
Step 5: The Evil App sends the stolen code to the Authorization Server and receives the corresponding access_token in step 6. Now, the Evil App can access the authorized ressources.
Optionally, in step 5 the App can authenticate on the Authorization Server via client_id, client_secret. Since, Apps are public clients they do not have any protection mechanisms regarding the storage of this information. Thus, an attacker can easy get this information and add it to the Evil App.
Proof Key for Code Exchange - PKCE (RFC 7636)
Now, let's see how PKCE does prevent the attack. The basic idea of PKCE is to bind the Auth Request in Step 1 to the code redemption in Step 5. In other words, only the app generated the Auth Request is able to redeem the generated code.
Figure 2: PKCE - RFC 7636
Step 1: The Auth Request is generated as previosly described. Additionally, two parameters are added:
The Honest App generates a random string called code_verifier
The Honest App computes the code_challenge=SHA-256(code_verifier)
The Honest App specifies the challenge_method=SHA256
Step 2: The Authorization Server receives the Auth Request and binds the code to the received code_challenge and challenge_method.
Later in Step 5, the Authorzation Server expects to receive the code_verifier. By comparing the SHA-256(code_verifier) value with the recieved code_challenge, the Authorization Server verifies that the sender of the Auth Request ist the same as the sender of the code.
Step 3-4: The code leaks again to the Evil App.
Step 5: Now, Evil App must send the code_verifier together with the code. Unfortunatelly, the App does not have it and is not able to compute it. Thus, it cannot redeem the code.
PKCE Bypass via App Impersonation
Again, PKCE binds the Auth Request to the coderedemption.
The question rises, if an Evil App can build its own Auth Request with its own code_verifier, code_challenge and challenge_method.The short answer is – yes, it can.
Figure 3: Bypassing PKCE via the App Impersonation attack
Step 1: The Evil App generates an Auth Request. The Auth Request contains the client_id and redirect_uri of the Honest App. Thus, the User and the Authorization Server cannot recognize that the Evil App initiates this request.
Step 2-4: These steps do not deviate from the previous description in Figure 2.
Step 5: In Step 5 the Evil App sends the code_verifier used for the computation of the code_challenge. Thus, the stolen code can be successfully redeemed and the Evil App receives the access_token and id_token.
OAuth 2.0 for Native Apps
The attack cannot be prevented by PKCE. However, the IETF working group is currently working on a Draft describing recommendations for using OAuth 2.0 for native apps.
YardStick One Unleashed, Automating RF Attacks In Python - An RFCat Primer
I decided to dive into our current device a bit more before moving on to a new device, and really ramp up the skillsets with RFCat and the Yardstick.So for this blog you will need our previous Target and a Yardstick One. We will be hacking everyting using only the Yardstick and Python.
So last time we scanned for signals with GQRX and a Software Defined Radio device. We took the demodulated wave forms in Audacity and discerned what the binary representation of our wave forms were by decoding them manually. We then transferred those into a hex format that our yardstick understood.However there is a way to do everything with our Yardstick. It will require a bit more understanding of the RFCat library, and a bit of python.
This blog will be your RFCAT primer and coding tutorial, but don't be scared with the word "Programming" I will be using simple code, nothing complicated.So if your a programmer, tune out any coding explanation and understand RFCat, if your not a coder, then use this as a jumping point to start making some quick python scripts for hacking.
Video Series PlayList Associated with this blog:
The first thing we did in our last blog after looking up the frequency was to open up GQRX and check if we can see our devices signals. As it turns out you can actually do this in python with RFCat. Which is really convenient if you left your Software Defined Radio dongle at home but happen to have access to a Yardstick.
RFCat as a Spectrum Analyzer:
In order to use RFCat as a spectrum analyzer we need to make sure we have RFcat installed and a few prerequisites such as python and PySide modules.I actually did this inside of an Ubuntu VMware because Pyside was giving me issues on OSX and I didn't feel like trying to fix it. So If you spin up an ubuntu vm you can do the following to get things up and running..
Install Spectrum Analyzer PreReqs:
sudo pip install PySide
sudo apt-get install ipython
Plug in your adapter and type in the following:
rfcat -r
d.specan(315000000)
You will then see the below output of RFCat Specan running in the 315 MHz range.
Click our doorbell, or trip the motion sensor and you will see a frequency spike as shown in the second picture.
This is similar to what you saw in GQRX but all with your Yardstick and the Python RFCat library.
So everything seems to be working and we can see our devices transmitting on the 315MHz frequency.Unfortunately we have no record button on Spescan. This leaves us to dive a little deeper into RFCat. We will see what RFCat can do for us in the recording and sniffing capacity.
Sniffing RF Data With The YardStick and Python:
In RFCat there is a simple listening command in our interactive session which will give us an idea of what is being transmitted and in what type of data format we are recieving. When using GQRX we received a WAV file, but what does RFCat give us?One thing I have realized over the years is programming is all about dealing with data in various formats and figuring out how to parse and use it in various implementations. So the first thing we have to figure out is what kind of data we are dealing with.
Lets hop back into RFCat and set a few parameters so the yardstick knows to listen on 315MHz and to use ASK modulation.The settings below should all be familiar from our last blog with an exception of "lowball" which configures the radio to use the lowest level of filtering. We basically want to see everything but may experience some noise by not filtering it out.. For example before you hit your doorbell button you may see random FF FF FF FF data outputted to the screen.
Below is the cmdline input needed and some example output. After all of our settings are in place we can use RF.listen() to start listening for everything in the 315000000 frequency range and have it output to the screen.
After you set it up, you can press the button on your doorbell and you will receive the following output. We have lots of zeros and what might be some hex output.
Destroy ficti0n$rfcat -r
>>> d.setFreq(315000000)
>>> d.setMdmModulation(MOD_ASK_OOK)
>>> d.setMdmDRate(4800)
>>> d.setMaxPower()
>>> d.lowball()
>>> d.RFlisten()
Entering RFlisten mode...packets arriving will be displayed on the screen
If you hit "ENTER" in your terminal you will stop receiving packets and drop back into a python interactive terminal. If we take a look at the repeating pattern in the above output, it looks like some random patterns and then a repeating pattern of, 84e708421084e738.If we convert that to binary we can compare with what we decoded WAV from our previous blog.
Since we are already in a python terminal you can type the following to see the binary representation:
Lets break that up into 8 bit bytes and compare it to our previous blogs binary, hmm its lot different then what we originally decoded the signal to be:
If we take the above capture data and format it correctly for RFcat with the replay code from the last blog. When we send it over, it does indeed ring the doorbell, thats interesting. A completely different value in both hex and in binary and still we get a doorbell to ring. So the variance we talked about last time extends a bit more. Below is the code with the new hex from the capture data:
I will also take a minute to note something before we continue. I had a little trouble at first when using a telescopic antenna in RFcat and the YardStick.So I will list those issues below as notes for you to play with if you run into random looking captures when pressing your doorbell button.
When using a telescopic antenna closed I had almost repeating output with some random bits flipped
When extending the antenna it went crazy output with random noise
I then used a small rubber ducky antenna and got the repeating output shown above.
What we have done so far:
So above, we managed to figure out the following all in RFCat
Verify the frequency with RFCat
How can I listen for it and capture a transmission with RFCat
How can I send this transmission with RFCat
We have basically eliminated the immediate need for the graphical tools that we were using in the last blog. Not to say that they are not useful. They absolutely are, and we should use them often and know how to work with all kinds of formats and understand everything.. However, if we are living in a reality that all we have is a Yardstick and no other tools. We are not helpless and we can still kick some serious RF butt.
Now we are going to take this a bit further so we can learn some more about RFCat, Python and mistakesI made when trying to automate this stuff. I found some interesting quirks I had to work through and I would like to save others some time who are also in the learning process as I am.
Using RFrecv() for Listening:
Ok first thing I learned is that RFListen() is not all that useful when it comes to automating this stuff. I tried to set its output to a variable but that did not seem to work.. So instead we will be working with another feature that lets us listen and that is RFrecv().If we fire up our RFCat in the terminal again we can give that a try:
Destroy:~ ficti0n$ rfcat -r
>>> d.setFreq(315000000)
>>> d.setMdmModulation(MOD_ASK_OOK)
>>> d.setMdmDRate(4800)
>>> d.setMaxPower()
>>> d.lowball()
>>> d.RFrecv()
Traceback (most recent call last):
File "", line 1, in
File "/Library/Python/2.7/site-packages/rflib/chipcon_nic.py", line 1376, in RFrecv
data = self.recv(APP_NIC, NIC_RECV, timeout)
File "/Library/Python/2.7/site-packages/rflib/chipcon_usb.py", line 664, in recv
raise(ChipconUsbTimeoutException())
ChipconUsbTimeoutException: Timeout waiting for USB response.
OK thats not cool we are getting a weird error if we don't get a signal right away regarding ChipconUsbTimeoutException.
No problem since we are in a python terminal we can just capture this exception and pass it, then continue with sniffing.This is done with a Try/Except block.
try:
... d.RFrecv()
... except ChipconUsbTimeoutException:
... pass
...
That looks a little better, I am no longer receiving errors, but lets put this in a loop so we are continuously listening with RFrecv() and press our doorbell so we can capture our doorbell signal.Below is the output of a random signal that came in followed by our doorbell.. but its all kinds of crazy looking and a bit hard to read:
try:
... d.RFrecv()
... except ChipconUsbTimeoutException:
... pass
...
while True:
... try:
... d.RFrecv()
... except ChipconUsbTimeoutException:
... pass
Lets try to fix the output a little and make it more readable by encoding it before we view it. Open up your text editor and use the following code.What we are doing here is simply setting up our listener as we did before and then setting it to a variable we can use.
Line 12: Setting our RFrecv() output to the variable y and z. The y variable is the output that we want
Line 13: We will wrap the y variable with an encode function to encode it with a HEX encoding.
Line 14: After that we just print it out.
When we run this script from the command line we will get a much nicer output shown below, much like we did with the RFlisten function above. The big difference being that our data is now set to the variable "capture"on line 13 and we can do what we want with that data. For example we can directly replay that data rather then manually performing the actions.
Parsing and replaying data:
This actually took me a bit of time to figure out, so we need to do a few things to get this to work:
We need to parse out the data from the surrounding 0s
We need to convert it to a format we can send (tricker then it sounds)
We need to add padding and send that data over (We know how to do this already)
Parsing Data:
So with this I first tried all kinds of regular expressions, but for some reason the inverse of more then 3 zeros in a row does not seem to work. I am no regex master but that seemed like it should be working. I then tried a few creative solutions reducing repeating zeros down to pairs that I could split on with string functions. This actually worked well but then my buddy showed me this which was more efficient:
re.split ('0000*', capture)
All this is doing is using the regex library to parse on a set of 4 or more zerosand return whats left in a list of useable hex data for sending.So lets add that into our code and give it a try to see what we get back. I made the following code changes:
Line 2: Import the Regex library
Line 11: We defined the capture variable so we can access it outside of the Try Block and the loop
Line 21: We created a payloads variable and created a list from the capture file of non 0000 blocks
Line 22: We print out our list of useable payloads which can been seen in the below output
Data Format Woes:
So we have data in a list we can pull from, thats awesome but I ran into a few issues. I first tried to parse this data into the \x format we normally used when sending our attack payloads manually, but that actually does not work. Reason being that if I use a code snippet like the following to convert this data into the right format everything looks ok and something like this \x84\xe7\x08\x42\x10\x84\xe7.But it won't actually work when I send it with RFCat. For some reason when you paste in your own hex its in a different format then if you programmatically create hex like below. You don't really need to understand the code below, just know it takes our payload and creates the hex in a visual format to what we used in the last blog:
DON'T USE THIS.. IT WONT WORK!!!
for payload in payloads:
formatted = ""
if (len(payload) > 6) and (len(payload) % 2 == 0):
print "Currently being formatted: " + payload
iterator = iter(payload)
for i in iterator:
formatted += ('\\x'+i + next(iterator))
else:
continue
Formatted Hex Vs Manually Pasted Hex
So lets compare the outputs of our manually created Hex String versus what we get when we format with the above code
Below is the output of the following:
Your encoded capture
Your parsed payloads in a nice list
Your payload being processed into hex.
But this is where things go wrong, you then have :
Your nicely formatted Hex created by your code above (Yay for us)
Then you have your manually pasted in hex from your original attack payloads as unprintable characters(What?)
You can clearly see there is a major difference between when we manually paste in our hex like we did in the last blog and when we create it from our capture file.This led to another sleepless night of researching whats going on. I did a bunch of troubleshooting until I found some code on the RFcat site and saw it using the BitString library and something called BitArray.The examples for this library were using binary data instead of hex and then converting it.
BitString BitArray Formating FTW:
If you remember above we created binary input with some python, so lets use that code in our current program template and then feed it into byteArray and see what happens. We can install bitstring with the following:
Install Bitstring:
sudo pip install bitstring
Our New code using BitString:
Line 2: I imported bitstring
Line 25: I added a for loop to go through our payload list one by one
Line 27: I convert our current payload to binary
Line 28: I take that binary and I feed it into bitstring to fix the formatting issues
Lines 29-30:Print out our binary and our new data that match our manually pasted data format, shown below
With these conversions the data above looks like its correct to attack our target devices. I know this seems like a lot of steps, but honestly this is only 50 lines of code in all to automate our replay attacks in a simple way.It is also very easy if you know what your doing and don't spend all of your time figuring it out like I did. You just need to understand how to work with the types of data each component understands.
With this latest code update we are ready to send our code with a simple modification to our RFxmit line from the last blog. We will now change RXxmit to take our formatted variable and then append our padding:
Below is our full code to automate this attack, with a few changeups, but not many.. Really all I did was add some conditional statements to limit our data to longer payloads that are divisible by 2 since our hex takes 2 string characters for example \x41 is the string character 4 and 1.I originally did this for the iterator code which required the proper amount of characters but decided to leave it since it makes sense anyway.I also set it so that if there is a capture it breaks out of the loop. This way we are not continuously attacking every transmission we see. Instead for our testing we can hit our doorbell, replay all the values before our script finishes and exits.
Note: I sent similar code to a friend and had him run it against a black box real world target. He had permission to attack this target via the owner of a facility and it worked flawlessly. So although a doorbell is a trivial target. This same research applies to garages, gates, and any other signal not using protection mechanism such as rolling code, multiple frequencies at once etc.
Also note that when you run this, almost all of the payloads in your list will ring the doorbell which is why I put a timing variable before the sending command. This way your doorbell isn't overburdened. I already broke a few of these devices during testing LOL.
I have since modified this code to be more effective, and have additional features and more niceties, I will release that code when its ready.. For now enjoy the below code and hit me up with any questions or comments.
I hope this blog is helpful in demystifying RFCat in order to successfully perform/automate attacks with only Python and your Yardstick One. This is essentially a few nights of my research posted here for everyone to learn from. Because it was a pain to find useful information, and I would like to save other people a lot of sleepless nights. I am by no means the master of RF or RFCat, there is tons more to learn. Up next I will get back on track with a real world attack against a device and creating our own keyfobs to replay our attacks in the future.
I realized the other day I posted Part 2 of this series to my youtube awhile ago but not blogger so this one will be quick and mostly via video walkthrough. I often post random followup videos which may never arrive on this blog. So if you're waiting on something specific I mentioned or the next part to a series its always a good idea to subscribe to the YouTube. This is almost always true if there is video associated with the post.
In the last blog we went over using virtual CAN devices to interact with a virtual car simulators of a CAN network This was awesome because it allowed us to learn how to interact with he underlying CAN network without fear of hacking around on an expensive automobile. But now it's time to put on your big boy pants and create a real CAN interface with hardware and plug your hardware device into your ODB2 port.
The video I created below will show you where to plug your device in, how to configure it and how to take the information you learned while hacking around on the virtual car from part1 and apply it directly to a real car.
Video Walk Through Using Hardware on a Real Car
As a reference here are the two device options I used in the video and the needed cable:
Hardware Used:
Get OBD2 Cable: https://amzn.to/2QSmtyL
Get CANtact: https://amzn.to/2xCqhMt
Get USB2CAN: https://shop.8devices.com/usb2can
Creating Network Interfaces:
As a reference here are the commands from the video for creating a CAN network interface:
USB2Can Setup:
The following command will bring up your can interface and you should see the device light color change:
sudo ip link set can0 up type can bitrate 125000
Contact Setup:
Set your jumpers on 3,5 and 7 as seen in the picture in the video
Sudo slcand -o -s6 /dev/ttyACM can0 <— whatever device you see in your DMESG output
Ifconfig can0 up
Summary:
That should get you started connecting to physical cars and hacking around. I was also doing a bit of python coding over these interfaces to perform actions and sniff traffic. I might post that if anyone is interested. Mostly I have been hacking around on blockchain stuff and creating full course content recently so keep a look out for that in the future.
Whenever security professionals recommend the 5 most important IT security practices to average users, one of the items is usually something like: "Avoid using open Wifi" or "Always use VPN while using open WiFi" or "Avoid sensitive websites (e.g. online banking) while using open WiFI", etc.
What I think about this? It is bullshit. But let's not jump to the conclusions. Let's analyze all risks and factors here.
During the following analysis, I made two assumptions. The first one is that we are comparing public WiFi hotspots with no encryption at all (referred to as Open), and we compare this to public WiFi hotspots with WPA2-PSK (and just hope WEP died years before). The other assumption is there are people who are security-aware, and those who just don't care. They just want to browse the web, access Facebook, write e-mails, etc.
The risks
Let's discuss the different threats people face using public hotspots, compared to home/work internet usage:
1.Where the website session data is not protected with SSL/TLS (and the cookie is not protected with secure flag), attackers on the same hotspot can obtain the session data and use it in session/login credentials stealing. Typical protocols affected:
HTTP sites
HTTPS sites but unsecured cookie
FTP without encryption
IMAP/SMTP/POP3 without SSL/TLS or STARTTLS
2.Attackers can inject extra data into the HTTP traffic, which can be used for exploits, or social engineer attacks (e.g. update Flash player with our malware) – see the Dark Hotel campaign
3.Attackers can use tools like SSLStrip to keep the user's traffic on clear text HTTP and steal password/session data/personal information
4.Attackers can monitor and track user activity
5.Attackers can directly attack the user's machine (e.g. SMB service)
WPA2-PSK security
So, why is a public WPA2-PSK WiFi safer than an open WiFi? Spoiler alert: it is not!
In a generic public WPA2-PSK scenario, all users share the same password. And guess what, the whole traffic can be decrypted with the following information: SSID + shared password + information from the 4-way handshake. https://wiki.wireshark.org/HowToDecrypt802.11
If you want to see it in action, here is a nice tutorial for you
Any user having access to the same WPA2-PSK network knows this information. So they can instantly decrypt your traffic. Or the attackers can just set up an access point with the same SSID, same password, and stronger signal. And now, the attacker can instantly launch active man-in-the-middle attacks. It is a common belief (even among ITSEC experts) that WPA2-PSK is not vulnerable to this attack. I am not sure why this vulnerability was left in the protocol, if you have the answer, let me know. Edit (2015-08-03): I think the key message here is that without server authentication (e.g. via PKI), it is not possible to solve this.
Let me link here one of my previous posts here with a great skiddie tool:
Decrypt all HTTP/FTP/IMAP/SMTP/POP3 passwords or other sensitive information
Can launch active attacks like SSLStrip, or modify HTTP traffic to include exploit/social engineer attacks
Can monitor/track user activity
The only difference between open and WPA2-PSK networks is that an open network can be hacked with an attacker of the skill level of 1 from 10, while the WPA2-PSK network needs and an attacker with a skill level of 1.5. That is the difference.
The real solutions
1.Website owners, service providers should deploy proper (trusted) SSL/TLS infrastructure, protect session cookies, etc. Whenever a user (or security professional) notices a problem with the quality of the service (e.g. missing SSL/TLS), the service provider has to be notified. If no change is made, it is recommended to drop the service provider and choose a more secure one. Users have to use HTTPS Everywhere plugin.
2.Protect the device against exploits by patching the software on it, use a secure browser (Chrome, IE11 + enhanced protection), disable unnecessary plugins (Java, Flash, Silverlight), or at least use it via click-to-play. Also, the use of exploit mitigations tools (EMET, HitmanPro Alert, Malwarebytes AntiExploit) and a good internet security suite is a good idea.
3.Website owners have to deploy HSTS, and optionally include their site in an HSTS preload list
4.Don't click blindly on fake downloads (like fake Flash Player updates)
5.The benefits of a VPN is usually overestimated. A VPN provider is just another provider, like the hotspot provider, or the ISP. They can do the same malicious stuff (traffic injecting, traffic monitoring, user tracking). Especially when people use free VPNs. And "Average Joe" will choose a free VPN. Also, VPN connections tend to be disconnected, and almost none of the VPN providers provide fail secure VPNs. Also, for the price of a good VPN service you can buy a good data plan and use 4G/3G instead of low-quality public hotspots. But besides this, on mobile OSes (Android, iOS, etc.) I strongly recommend the use of VPN, because it is not practically feasible to know for users which app is using SSL/TLS and which is not.
6.Use a location-aware firewall, and whenever the network is not trusted, set it to a Public.
7.In a small-business/home environment, buy a WiFi router with guest WiFi access possibility, where the different passwords can be set to guest networks than used for the other.
Asking the question "Are you using open WiFi?", or "Do you do online banking on open WiFi?" are the wrong questions. The good questions are:
Do you trust the operator(s) of the network you are using?
Are the clients separated?
If clients are not separated, is it possible that there are people with malicious intent on the network?
Are you security-aware, and are you following the rules previously mentioned? If you do follow these rules, those will protect you on whatever network you are.
And call me an idiot, but I do online banking, e-shopping, and all the other sensitive stuff while I'm using open WiFi. And whenever I order pizza from an HTTP website, attackers can learn my address. Which is already in the phone book, on Facebook, and in every photo metadata I took with my smartphone about my cat and uploaded to the Internet (http://iknowwhereyourcatlives.com/).
Most articles and research publications are full of FUD about what people can learn from others. Maybe they are just outdated, maybe they are not. But it is totally safe to use Gmail on an open WiFi, no one will be able to read my e-mails.
PS: I know "Average Joe" won't find my blog post, won't start to read it, won't understand half I wrote. But even if they do, they won't patch their browser plugins, pay for a VPN, or check the session cookie. So they are doomed to fail. That's life. Deal with it.
This Video is absolutely for Educational Purposes only, please don't do any illegal activity. If you do then I'm not responsible for your illegal activity. The purpose of this video is to show you How hackers can hack your social media by using their own local servers.
Basically these type of attacks known as Social Engineering attacks or Phishing. Attacker just send the duplicate vulnerable HTML page to the victim, when victim enters any type of information to that vulnerable page it'll automatically received by the attacker.
Phishing is a form of fraud in which an attacker masquerades as a reputable entity or person in email or other communication channels. The attacker uses phishing emails to distribute malicious links or attachments that can perform a variety of functions, including the extraction of login credentials or account information from victims.
How phishing works
Phishing attacks typically rely on social networking techniques applied to email or other electronic communication methods, including direct messages sent over social networks, SMS text messages and other instant messaging modes.
Phishers may use social engineering and other public sources of information, including social networks like LinkedIn, Facebook and Twitter, to gather background information about the victim's personal and work history, his interests, and his activities.
Hacking by PHP
As PHP is server side scripting language so first of all you have need to install a local server (WAMP, XAMPP or LAMPP) over your system. Because if there is no any server running on your system then you can't even run your PHP script. So if you wanna do a programming with PHP this is the first step to download and install a server from the Internet. You can easily download and install servers by watching my videos. Just visit my YouTube channel and watch there.
Hacking Facebook By Using PHP Script | Social Engineering Attack | You can perform this attack over LAN and WAN (Same or Different Networks)
The name sounds exciting but really does it jam WiFi networks? Yes, it is able to do the thing which it's name suggests. So today I'm going to show you how to annoy your friend by cutting him/her short of the WiFi service.
Requirements:
A computer/laptop with WiFi capable of monitoring (monitor mode).
And the most obvious thing wifijammer (If you're having BlackArch then you already have it).
How does it work? You maybe thinking!, it's quite simple it sends the deauth packets from the client to the AP (Access Point) after spoofing its (client's) mac-address which makes AP think that it's the connected client who wants to disconnect and Voila!
Well to jam all WiFi networks in your range its quite easy just type:
sudo wifijammer
but wait a minute this may not be a good idea. You may jam all the networks around you, is it really what you want to do? I don't think so and I guess it's illegal.
We just want to play a prank on our friend isn't it? So we want to attack just his/her AP. To do that just type:
sudo wifijammer -a <<AP-MAC-ADDRESS>>
here -a flag specifies that we want to jam a particular AP and after it we must provide the MAC-ADDRESS of that particular AP that we want to jam.
Now how in the world am I going to know what is the MAC-ADDRESS of my friend's AP without disturbing the other people around me?
It's easy just use the Hackers all time favorite tool airodump-ng. Type in the following commands:
sudo airmon-ng
sudo airodump-ng
airmon-ng will put your device in monitor mode and airodump-ng will list all the wifi networks around you with their BSSID, MAC-ADDRESS, and CHANNELS. Now look for your friend's BSSID and grab his/her MAC-ADDRESS and plug that in the above mentioned command. Wooohooo! now you are jamming just your friend's wifi network.
Maybe that's not what you want, maybe you want to jam all the people on a particular channel well wifijammer can help you even with that just type:
sudo wifijammer -c <<CHANNEL-NUMBER>>
with -c we specify to wifijammer that we only want to deauth clients on a specified channel. Again you can see with airodump-ng who is on which channel.
wifijammer has got many other flags you can check out all flags using this command that you always knew:
Most of the web applications I see are kinda binary when it comes to CSRF protection; either they have one implemented using CSRF tokens (and more-or-less covering the different functions of the web application) or there is no protection at all. Usually, it is the latter case. However, from time to time I see application checking the Referer HTTP header.
A couple months ago I had to deal with an application that was checking the Referer as a CSRF prevention mechanism, but when this header was stripped from the request, the CSRF PoC worked. BTW it is common practice to accept empty Referer, mainly to avoid breaking functionality.
The OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet tells us that this defense approach is a baaad omen, but finding a universal and simple solution on the Internetz to strip the Referer header took somewhat more time than I expected, so I decided that the stuff that I found might be useful for others too.
Solutions for Referer header strip
Most of the techniques I have found were way too complicated for my taste. For example, when I start reading a blog post from Egor Homakov to find a solution to a problem, I know that I am going to:
learn something very cool;
have a serious headache from all the new info at the end.
This blog post from him is a bit lighter and covers some useful theoretical background, so make sure you read that first before you continue reading this post. He shows a few nice tricks to strip the Referer, but I was wondering; maybe there is an easier way?
Rich Lundeen (aka WebstersProdigy) made an excellent blog post on stripping the Referer header (again, make sure you read that one first before you continue). The HTTPS to HTTP trick is probably the most well-known one, general and easy enough, but it quickly fails the moment you have an application that only runs over HTTPS (this was my case).
The data method is not browser independent but the about:blank trick works well for some simple requests. Unfortunately, in my case the request I had to attack with CSRF was too complex and I wanted to use XMLHttpRequest. He mentions that in theory, there is anonymous flag for CORS, but he could not get it work. I also tried it, but... it did not work for me either.
Krzysztof Kotowicz also wrote a blog post on Referer strip, coming to similar conclusions as Rich Lundeen, mostly using the data method.
Finally, I bumped into Johannes Ullrich's ISC diary on Referer header and that led to me W3C's Referrer Policy. So just to make a dumb little PoC and show that relying on Referer is a not a good idea, you can simply use the "referrer" meta tag (yes, that is two "r"-s there).
As you can see, there is quite a lot of ways to strip the Referer HTTP header from the request, so it really should not be considered a good defense against CSRF. My preferred way to make is PoC is with the meta tag, but hey, if you got any better solution for this, use the comment field down there and let me know! :)
