- Hacked Gadgets: A resource for DIY project documentation as well as general gadget and technology news.
- Exploit DB: An archive of exploits and vulnerable software by Offensive Security. The site collects exploits from submissions and mailing lists and concentrates them in a single database.
- Packet Storm: Information Security Services, News, Files, Tools, Exploits, Advisories and Whitepapers.
- KitPloit: Leading source of Security Tools, Hacking Tools, CyberSecurity and Network Security.
- The Hacker News: The Hacker News — most trusted and widely-acknowledged online cyber security news magazine with in-depth technical coverage for cybersecurity.
- Phrack Magazine: Digital hacking magazine.
- HackRead: HackRead is a News Platform that centers on InfoSec, Cyber Crime, Privacy, Surveillance, and Hacking News with full-scale reviews on Social Media Platforms.
- Hakin9: E-magazine offering in-depth looks at both attack and defense techniques and concentrates on difficult technical issues.
- Metasploit: Find security issues, verify vulnerability mitigations & manage security assessments with Metasploit. Get the worlds best penetration testing software now.
Tuesday, June 30, 2020
Top 9 Hacking Websites 2018
Thursday, June 11, 2020
Hacking Facebook By Using PHP Script | Social Engineering Attack | LAN And WAN (Same Or Different Networks)
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)Related posts
Cracking Windows 8/8.1 Passwords With Mimikatz
You Might have read my previous posts about how to remove windows passwords using chntpw and might be thinking why am I writing another tutorial to do the same thing! Well today we are not going to remove the windows user password rather we are going to be more stealth in that we are not going to remove it rather we are going to know what is the users password and access his/her account with his/her own password. Sounds nice...
Requirements:
- A live bootable linux OS (I'm using Kali Linux)(Download Kali Linux)
- Mimikatz (Download | Blog)
- Physical Access to victim's machine
- A Working Brain in that Big Head (Download Here)
Steps:
1. First of all download mimikatz and put it in a pendrive.2. Boat the victim's PC with your live bootable Pendrive (Kali Linux on pendrive in my case). And open a terminal window
3. Mount the Volume/Drive on which windows 8/8.1 is installed by typing these commands
in the terminal window:
mkdir /media/win
ntfs-3g /dev/sda1 /media/win
[NOTE] ntfs-3g is used to mount an NTFS drive in Read/Write mode otherwise you might not be able to write on the drive. Also /dev/sda1 is the name of the drive on which Windows OS is installed, to list your drives you can use lsblk -l or fdisk -l. The third flag is the location where the drive will be mounted.
4. Now navigate to the System32 folder using the following command
cd /media/win/Windows/System32
5. After navigating to the System32 rename the sethc.exe file to sethc.exe.bak by typing the following command:
mv sethc.exe sethc.exe.bak
sethc.exe is a windows program which runs automatically after shift-key is pressed more than 5 times continuously.
6. Now copy the cmd.exe program to sethc.exe replacing the original sethc.exe program using this command:
cp cmd.exe sethc.exe
[Note] We made a backup of sethc.exe program so that we can restore the original sethc.exe functionality
7. With this, we are done with the hard part of the hack now lets reboot the system and boot our Victim's Windows 8/8.1 OS.
8. After reaching the Windows Login Screen plugin the usb device with mimikatz on it and hit shift-key continuously five or more times. It will bring up a command prompt like this
9. Now navigate to your usb drive in my case its drive G:
10. Now navigate to the proper version of mimikatz binary folder (Win32 for32bit windows and x64 for 64 bit windows)
11. Run mimikatz and type the following commands one after the other in sequence:
privilege::debug
token::elevate
vault::list
the first command enables debug mode
the second one elevates the privilages
the last one lists the passwords which include picture password and pin (if set by the user)
That's it you got the password and everything else needed to log into the system. No more breaking and mess making its simple its easy and best of all its not Noisy lol...
Hope you enjoyed the tutorial have fun :)
Related articles
The RastaLabs Experience
Introduction
It was 20 November, and I was just starting to wonder what I would do during the next month. I had already left my previous job, and the new one would only start in January. Playing with PS4 all month might sound fun for some people, but I knew I would get bored quickly.
Even though I have some limited red teaming experience, I always felt that I wanted to explore the excitement of getting Domain Admin – again. I got my first DA in ˜2010 using pass-the-hash, but that was a loooong time ago, and things change quickly.
While reading the backlogs of one of the many Slack rooms, I noticed that certain chat rooms were praising RastaLabs. Looking at the lab description, I felt "this is it, this is exactly what I need." How hard could it be, I have a whole month ahead of me, surely I will finish it before Christmas. Boy, was I wrong.
The one-time fee of starting the lab is 90 GBP which includes the first month, then every additional month costs 20 GBP. I felt like I was stealing money from Rastamouse and Hackthebox... How can it be so cheap? Sometimes cheap indicates low quality, but not in this case.
My experience
Regarding my previous experience, I already took OSCP, OSCE, SLAE (Securitytube Linux Assembly Expert), and PSP (Powershell for Pentesters), all of which helped me a lot during the lab. I also had some limited red teaming experience. I had more-than-average experience with AV evasion, and I already had experience with the new post-exploit frameworks like Covenant and Powershell Empire. As for writing exploits, I knew how a buffer overflow or a format string attack worked, but I lacked practice in bypassing ASLR and NX. I basically had zero experience with Mimikatz on Windows 10. I used Mimikatz back in 2012, but probably not since. I also had a lot of knowledge on how to do X and Y, on useful tools and hot techniques, but I lacked recent experience with them. Finally, I am usually the last when it comes to speed in hacking, but I have always balanced my lack of speed with perseverance.
RastaLabs starts in 3,2,1 ...
So I paid the initial entry fee, got the VPN connection pack, connected to the lab, and got my first flag after ... 4 days. And there were 17 of them in total. This was the first time I started to worry. I did everything to keep myself on the wrong track, stupid things like assuming incorrect lab network addresses, scanning too few machines, finding the incorrect breadcrumbs via OSINT, trying to exploit a patched web service (as most OSCPers would do), etc. I was also continually struggling with the tools I was using, as I never knew whether they were buggy, or I was misusing them, or this is just not the way to get the flag. I am sure someone with luck and experience could have done this stage in 2-3 hours, but hey, I was there to gain experience.
During the lab, whenever I got stuck with the same problem for more than 30-40 hours and my frustration was running high, I pinged Rastamouse on the official RastaLabs support channel on https://mm.netsecfocus.com/. I usually approached him like "Hi, I tried X, Y, and Z but no luck", then he replied "yeah, try Y harder". This kind of information was usually all I needed, and 2-3 hours later I was back on track again. His help was always enough, but never too much to spoil the fun. The availability and professionalism of Rastamouse was 10/10. Huge multi-billion dollar companies fail to provide good enough support, this one guy here was always there to help. Amazing. I highly recommend joining the Mattermost channel – it will help you a lot to see that you are not the only one stuck with problems. But please do not DM him or the channel if you have not already tried harder.
What's really lovely in the lab is that you can expect real-world scenarios with "RastaLabs employees" working on their computer, reading emails, browsing the web, etc. I believe it is not a spoiler here that at some point in time you have to deliver malware that evades the MS Defender AV on the machine. Yes, there is a real working Defender on the machines, and although it is a bit out of date, it might catch your default payload very quickly. As I previously mentioned, luckily I had recent experience with AV evasion, so this part was not new to me. I highly recommend setting up your own Win10 with the latest Defender updates and testing your payload on it first. If it works there, it will work in the lab. This part can be especially frustrating, because the only feedback you get from the lab is that nothing is happening, and there is no way to debug it. Test your solution locally first.
Powershell Empire turned out to be an excellent solution for me, the only functionality it lacked was Port Forwarding. But you can drop other tools to do this job efficiently.
A little help: even if you manage to deliver your payload and you have a working C&C, it does not mean your task with AV evasion is over. It is highly probable that Defender will block your post-exploit codes. To bypass this, read all the blog posts from Rastamouse about AMSI bypass. This is important.
Lateral movement
When you finally get your first shell back ...
A whole new world starts. From now on, you will spend significant time on password cracking, lateral movement, persistence, and figuring out how Windows AD works.
In the past, I played a lot of CTF, and from time to time I got the feeling "yeah, even though this challenge was fun, it was not realistic". This never happened during RastaLabs. All the challenges and solutions were 100% realistic, and as the "Ars poetica" of RastaLabs states:
...which is sooooo true. None of the tasks involve any exploit of any CVE. You need a different mindset for this lab. You need to think about misconfigurations, crackable passwords, privilege abuse, and similar issues. But I believe this lab is still harder to own than 90% of the organizations out there. The only help is that there are no blue-teamers killing our shells.
About the architecture of the lab: When connecting to the lab with VPN, you basically found yourself in a network you might label as "Internet", with your target network being behind a firewall, just as a proper corporate network should be.
There are a bunch of workstations – Win10 only, and some servers like fileserver, exchange, DC, SQL server, etc. The majority of servers are Windows Server 2016, and there is one Linux server. The two sites are adequately separated and firewalled.
As time passed, I was getting more and more flags, and I started to feel the power. Then the rollercoaster experience started. I was useless, I knew nothing. Getting the flag, I was god. One hour later, I was useless.
For example, I spent a significant amount of time trying to get GUI access to the workstations. In the end, I managed to get that, just to find out I did not achieve anything with it. For unknown reasons, none of the frameworks I tried had a working VNC, so I set up my own, and it was pain.
On December 18, I finally got Domain Admin privileges. So my estimation to "finish the lab" in one month was not that far off. Except that I was far from finishing it, as I still had to find five other flags I was missing. You might ask "you already have DA, how hard could it be to find the remaining five?". Spoiler alert, it was hard. Or to be more precise, not hard, just challenging, and time-consuming. This was also a time when connections on Mattermost RastaLabs channel helped me a lot. Hints like "flag X is on machine Y" helped me keep motivated, yet it did not spoil the fun. Without hints like this, I would not have written this post but would have been stuck with multiple flags.
About exploitation
And there was the infamous challenge, "ROP the night away." This was totally different from the other 16. I believe this image explains it all:
If you are not friends with GDB, well, you will have a hard time. If you don't have lots of hands-on experience with NX bypass - a.k.a ROP - like me, you will have a hard time with this challenge. The binary exploit challenges during OSCP and OSCE exams are nowhere near as complex as this one. If you have OSEE, you will be fine. For this challenge, I used GDB-Peda and Python pwntools – check them out in case you are not familiar with them. For me, solving this challenge took about 40 hours. Experienced CTF people could probably solve it in 4 hours or less.
Conclusion
I would not recommend taking this lab for total beginners *. I also do not recommend doing the lab if you only have limited time per day, which is especially true if you are working on your home computer. I probably would have saved hours or even days if I had set up a dedicated server in the cloud for this lab. The issue was that the lab workstations were rebooted every day, which meant that I always lost my shells. "Persistence FTW", you might say, but if your C&C is down when the workstation reboots, you are screwed. "Scheduled tasks FTW", you might say, but unless you have a strict schedule on when you start your computer, you will end up with a bunch of scheduled tasks just to get back the shell whenever you start your computer. Day after day I spent the first hour getting back to where I had been the day before. And I just figured out at the end of the lab why some of my scheduled tasks were not working ...
I would be really interested to see how much time I spent connected to the lab. Probably it was around 200–250 hours in total, which I believe is more than I spent on OSCP and OSCE combined. But it was totally worth it. I really feel the power now that I learned so many useful things.
But if you consider that the price of the one-month lab is 20 GBP, it is still a very cheap option to practice your skills.
* It is totally OK to do the lab in 6 months, in case you start as a beginner. That is still just 190 GBP for the months of lab access, and you will gain a lot of experience during this time. You will probably have a hard time reaching the point when you have a working shell, but it is OK. You can find every information on Google, you just need time, patience and willingness to get there.
Anyway, it is still an option not to aim to "get all the flags". Even just by getting the first two flags, you will gain significant experience in "getting a foothold". But for me, not getting all the flags was never an option.
If you are still unconvinced, check these other blog posts:
Or see what others wrote about RastaLabs.
Footnote
In case you start the lab, please, pretty please, follow the rules, and do not spoil the fun for others. Do not leave your tools around, do not keep shared drives open, do not leave FLAGs around. Leave the machine as it was. If you have to upload a file, put it in a folder others won't easily find. This is a necessary mindset when it comes to real-world red teaming. Don't forget to drop a party parrot into the chat whenever you or someone else gets a new flag. And don't forget:
OSCP has no power here. Cry harder!
I will probably keep my subscription to the lab and try new things, new post-exploit frameworks. I would like to thank @_rastamouse for this great experience, @superkojiman for the ROP challenge. Hackthebox for hosting the lab with excellent uptime.
As for @gentilkiwi and @harmj0y, these two guys probably advanced red-teaming more than everyone else combined together. pwntools from @gallopsled was also really helpful. And I will be forever grateful to Bradley from finance for his continuous support whenever I lost my shells.
Wednesday, June 10, 2020
ANNOUNCEMENT: Submitters Of Papers And Training For Global AppSec DC 2019 (Formerly AppSec USA)
Read more
How To Start | How To Become An Ethical Hacker
Are you tired of reading endless news stories about ethical hacking and not really knowing what that means? Let's change that!
This Post is for the people that:
- Have No Experience With Cybersecurity (Ethical Hacking)
- Have Limited Experience.
- Those That Just Can't Get A Break
OK, let's dive into the post and suggest some ways that you can get ahead in Cybersecurity.
I receive many messages on how to become a hacker. "I'm a beginner in hacking, how should I start?" or "I want to be able to hack my friend's Facebook account" are some of the more frequent queries. Hacking is a skill. And you must remember that if you want to learn hacking solely for the fun of hacking into your friend's Facebook account or email, things will not work out for you. You should decide to learn hacking because of your fascination for technology and your desire to be an expert in computer systems. Its time to change the color of your hat 😀
I've had my good share of Hats. Black, white or sometimes a blackish shade of grey. The darker it gets, the more fun you have.
If you have no experience don't worry. We ALL had to start somewhere, and we ALL needed help to get where we are today. No one is an island and no one is born with all the necessary skills. Period.OK, so you have zero experience and limited skills…my advice in this instance is that you teach yourself some absolute fundamentals.
Let's get this party started.
- What is hacking?
Hacking is identifying weakness and vulnerabilities of some system and gaining access with it.
Hacker gets unauthorized access by targeting system while ethical hacker have an official permission in a lawful and legitimate manner to assess the security posture of a target system(s)There's some types of hackers, a bit of "terminology".
White hat — ethical hacker.
Black hat — classical hacker, get unauthorized access.
Grey hat — person who gets unauthorized access but reveals the weaknesses to the company.
Script kiddie — person with no technical skills just used pre-made tools.
Hacktivist — person who hacks for some idea and leaves some messages. For example strike against copyright.
- Skills required to become ethical hacker.
- Curosity anf exploration
- Operating System
- Fundamentals of Networking
HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL
HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL
When it comes to email providers, there's no competitor to Google's awesome features. It is efficient which connects seamlessly with the rest of your Google products such as YouTube, Drive, has a major application called Gmail Inbox, and is overall an extremely powerful email service. However, to use it with a custom domain, you need to purchase Google Apps for either $5 or $10/month, which for casual users is a bit unnecessary. On top of that, you don't even get all of the features a personal account gets, e.g. Inbox. So, here's a free way to use your Gmail account with a custom domain. I am just going to show you hacking Gmail for free custom domain email.
SO, HOW HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL
PASSWORD: EHT
STEPS:
- First, register with Mailgun using your Gmail address. Use your Gmail only. Once you have clicked the confirm link, log in to the Mailgun website. Now you're in the dashboard, move on the right under "Custom Domains", click "Add Domain".
- Follow the setup instructions and set DNS records with whoever manages your DNS. Once you've done this, click on the "Routes" link on the top to set up email forwarding.
- Now move to the Route tab and click on Create New Route.
- As you click the button, you will see a page like below. Just enter the information as entered in the following screenshot.
- Just replace the quoted email with your desired email in the above-given screenshot.
- Next, we'll setup SMTP configuration so we would be able to send emails from an actual server. Go to "Domains" tab, click on your domain name.
- On this page, click "Manage your SMTP credentials" then "New SMTP Credential" on the next page.
- Type in the desired SMTP credentials. And, go to Gmail settings and click "Add another email address you own". Once you open, enter the email address you wish to send from.
- In the next step, set the SMTP settings as follows.
- After clicking "Add Account" button, now you're done.
- The final step, make sure to set it to default email in the Gmail settings > Accounts.
That's all. Now you got free Gmail custom domain with 10,000 emails per month. Hope it will work for you. If you find any issue, just comment below.
Note: Use Virtual Machine and scan on VirusTotal before downloading any program on Host Machine for your privacy.
More info
Collection Of Pcap Files From Malware Analysis
Update: Feb 19. 2015
We have been adding pcaps to the collection so remember to check out the folder ( Pcap collection) for the recent pcaps.
I had a project to test some malicious and exploit pcaps and collected a lot of them (almost 1000) from various public sources. You can see them in the PUBLIC folder. The credits go to the authors of the pcaps listed in the name of each file. Please visit their blogs and sites to see more information about the pcaps, see their recent posts, and send them thanks. The public pcaps have no passwords on them.
Update:Dec 13. 2014
Despite rare updates of this post, we have been adding pcaps to the collection so remember to check out the folder ( Pcap collection (New link)) for the recent pcaps!
Update:Dec 31. 2013 - added new pcaps
I did some spring cleaning yesterday and came up with these malware and exploit pcaps. Such pcaps are very useful for IDS and signature testing and development, general education, and malware identification. While there are some online public sandboxes offering pcaps for download like Cuckoo or Anubis but looking for them is a tedious task and you cannot be totally sure the pcap is for the malware family supposedly analysed - in other words, if the sandbox says it is Zeus does not necessarily mean that it is.
I found some good pcap repositories here (http://www.netresec.com/?page=PcapFiles) but there are very few pcaps from malware.
These are from identified and verified (to the best of my knowledge and belief - email me if you find errors) malware samples.
All of them show the first stage with the initial callback and most have the DNS requests as well. A few pcaps show extended malware runs (e.g. purplehaze pcap is over 500mb).
Most pcaps are mine, a few are from online sandboxes, and one is borrowed from malware.dontneedcoffee.com. That said, I can probably find the corresponding samples for all that have MD5 listed if you really need them. Search contagio, some are posted with the samples.
Each file has the following naming convention:
BIN [RTF, PDF] - the filetype of the dropper used, malware family name, MD5, and year+month of the malware analysis.
I will be adding more pcaps in the future. Please donate your pcaps from identified samples, I am sure many of you have.
Thank you
Download
Download all together or separately.
All pcaps archives have the same password (same scheme), email me if you need it. I tried posting it without any passwords and pass infected but they get flagged as malware. Modern AV rips though zips and zips with the pass 'infected' with ease.
APT PCAPS
- 2012-12-31 BIN_Xinmic_8761F29AF1AE2D6FACD0AE5F487484A5-pcap
- 2013-09-08 BIN_TrojanPage_86893886C7CBC7310F7675F4EFDE0A29-pcap
- 2013-09-08 BIN_Darkcomet_DC98ABBA995771480AECF4769A88756E-pcap
- 2013-09-02 8202_tbd_ 6D2C12085F0018DAEB9C1A53E53FD4D1-pcap
- 2013-09-02 BIN_8202_6d2c12085f0018daeb9c1a53e53fd4d1-pcap
- 2013-09-02 BIN_Vidgrab_6fd868e68037040c94215566852230ab-pcap
- 2013-09-02 BIN_PlugX_2ff2d518313475a612f095dd863c8aea-pcap
- 2013-09-02 BIN_Taidoor_46ef9b0f1419e26f2f37d9d3495c499f-pcap
- 2013-09-02 BIN_Vidgrab_660709324acb88ef11f71782af28a1f0-pcap
- 2013-09-02 BIN_Gh0st-gif_f4d4076dff760eb92e4ae559c2dc4525-pcap.zip
- 2013-07-15 BIN_Taleret.E_5328cfcb46ef18ecf7ba0d21a7adc02c.pcap
- 2013-05-14 BIN_Mediana_0AE47E3261EA0A2DBCE471B28DFFE007_2012-10.pcap
- 2013-05-14 BIN_Hupigon_8F90057AB244BD8B612CD09F566EAC0C
- 2013-05-14 BIN_LetsGo_yahoosb_b21ba443726385c11802a8ad731771c0_2011-07-19
- 2013-05-13 BIN_IXESHE_0F88D9B0D237B5FCDC0F985A548254F2-2013-05-pcap
- 2013-05-06 BIN_DNSWatch_protux_4F8A44EF66384CCFAB737C8D7ADB4BB8_2012-11-pcap
- 2013-05-06 BIN_9002_D4ED654BCDA42576FDDFE03361608CAA_2013-01-30-pcap
- 2013-05-06 BIN_BIN_RssFeeder_68EE5FDA371E4AC48DAD7FCB2C94BAC7-2012-06-pcap (not a common name, see the traffic ssheet http://bit.ly/maltraffic )
- 2013-04-30 BIN_MSWab_Yayih_FD1BE09E499E8E380424B3835FC973A8_us-pcap
- 2013-04-29 BIN_LURK_AF4E8D4BE4481D0420CCF1C00792F484_20120-10-pcap
- 2013-04-29 BIN_XTremeRAT_DAEBFDED736903D234214ED4821EAF99_2013-04-13-pcap
- BIN_Enfal_Lurid_0fb1b0833f723682346041d72ed112f9_2013-01.pcap
- BIN_Gh0st_variant-v2010_B1D09374006E20FA795B2E70BF566C6D_2012-08.pcap
- BIN_Likseput_E019E37F19040059AB5662563F06B609_2012-10.pcap
- BIN_Nettravler_1f26e5f9b44c28b37b6cd13283838366.pcap
- BIN_Nettravler_DA5832657877514306EDD211DEF61AFE_2012-10.pcap
- BIN_Sanny-Daws_338D0B855421867732E05399A2D56670_2012-10.pcap
- BIN_Sofacy_a2a188cbf74c1be52681f998f8e9b6b5_2012-10.pcap
- BIN_Taidoor_40D79D1120638688AC7D9497CC819462_2012-10.pcap
- BIN_TrojanCookies_840BD11343D140916F45223BA05ABACB_2012_01.pcap
- PDF_CVE-2011-2462_Pdf_2011-12.pcap
- RTF_Mongall_Dropper_Cve-2012-0158_C6F01A6AD70DA7A554D48BDBF7C7E065_2013-01.pcap
- OSX_DocksterTrojan.pcap
CRIMEWARE PCAPS
- 2013-11-12_BIN_ChePro_2A5E5D3C536DA346849750A4B8C8613A-1.pcap
- 2013-10-15_BIN_cryptolocker_9CBB128E8211A7CD00729C159815CB1C.pcap
- 2013-09-20_BIN_Lader-dlGameoverZeus_12cfe1caa12991102d79a366d3aa79e9.pcap
- 2013-09-08 BIN_Tijcont_845B0945D5FE0E0AAA16234DC21484E0-pcap
- 2013-09-08 BIN_Kelihos_C94DC5C9BB7B99658C275B7337C64B33-pcap.zip
- 2013-08-19 BIN_Nitedrem_508af8c499102ad2ebc1a83fdbcefecb-pcap
- 2013-08-17 BIN_sality_CEAF4D9E1F408299144E75D7F29C1810-pcap
- 2013-08-15 BIN_torpigminiloader-pcap.zip
- 2013-13-08 EK_popads_109.236.80.170_2013-08-13.pcap
- 2013-11-08 BIN_Alinav5.3_4C754150639AA3A86CA4D6B6342820BE.pcap
- 2013-08-08 BIN_BitcoinMiner_F865C199024105A2FFDF5FA98F391D74-pcap
- 2013-08-07 BIN_ZeroAccess_Sirefef_C2A9CCC8C6A6DF1CA1725F955F991940_2013-08-pcap
- 2013-07-05 BIN_Kuluoz-Asprox_9F842AD20C50AD1AAB41F20B321BF84B
- 2013-05-31 Wordpress-Mutopy_Symmi_20A6EBF61243B760DD65F897236B6AD3-2pcap.pcap
- 2013-05-15 BIN_Zeus_b1551c676a54e9127cd0e7ea283b92cc-2012-04.pcap
- 2013-05-15 BIN_Gypthoy_3EE49121300384FF3C82EB9A1F06F288-2013-05.pcap
- 2013-05-12 BIN_PassAlert_B4A1368515C6C39ACEF63A4BC368EDB2-2013-05-13
- 2013-05-12 BIN_HorstProxy_EFE5529D697174914938F4ABF115F762-2013-05-13-pcap
- 2013-05-12 BIN_Bitcoinminer_12E717293715939C5196E604591A97DF-2013-05-12-pcap
- 2013-05-07 BIN_ZeroAccess_Sirefef_29A35124ABEAD63CD8DB2BBB469CBC7A_2013-05-pcapc
- 2013-05-05 BIN_PowerLoader_4497A231DA9BD0EEA327DDEC4B31DA12_2013-05-pcap
- 2013-05-05 BIN_GameThief_ECBA0FEB36F9EF975EE96D1694C8164C_2013-03-pcap
- 2013-05-05 BIN_PowerLoader_4497A231DA9BD0EEA327DDEC4B31DA12_2013-05-pcap
- 2013-04-27 EK_BIN_Blackhole_leadingto_Medfos_0512E73000BCCCE5AFD2E9329972208A_2013-04-pcap
- 2013-04-26 -- BIN_Citadel_3D6046E1218FB525805E5D8FDC605361-2013-04-samp
- BIN_CitadelPacked_2012-05.pcap
- BIN_CitadelUnpacked_2012-05.pcap
- BIN_Cutwail_284Fb18Fab33C93Bc69Ce392D08Fd250_2012-10.pcap
- BIN_Darkmegi_2012-04.pcap
- BIN_DarknessDDoS_v8g_F03Bc8Dcc090607F38Ffb3A36Ccacf48_2011-01.pcap-
- BIN_dirtjumper_2011-10.pcap
- BIN_DNSChanger_2011-12.pcap
- BIN_Drowor_worm_0f015bb8e2f93fd7076f8d178df2450d_2013-04.pcap
- BIN_Googledocs_macadocs_2012-12.pcap
- BIN_Imaut_823e9bab188ad8cb30c14adc7e67066d.pcap
- BIN_IRCbot_c6716a417f82ccedf0f860b735ac0187_2013-04.pcap
- BIN_Kelihos_aka_Nap_0feaaa4adc31728e54b006ab9a7e6afa.pcap
- BIN_LoadMoney_MailRu_dl_4e801b46068b31b82dac65885a58ed9e_2013-04 .pcap
- BIN_purplehaze-2012-01.pcap
- BIN_ponyloader_470a6f47de43eff307a02f53db134289.pcap
- BIN_Ramnitpcap_2012-01.pcap
- BIN_Reedum_0ca4f93a848cf01348336a8c6ff22daf_2013-03.pcap
- BIN_SpyEye_2010-02.pcap
- BIN_Stabuniq_F31B797831B36A4877AA0FD173A7A4A2_2012-12.pcap
- BIN_Tbot_23AAB9C1C462F3FDFDDD98181E963230_2012-12.pcap
- BIN_Tbot_2E1814CCCF0C3BB2CC32E0A0671C0891_2012-12.pcap
- BIN_Tbot_5375FB5E867680FFB8E72D29DB9ABBD5_2012-12.pcap
- BIN_Tbot_A0552D1BC1A4897141CFA56F75C04857_2012-12.pcap
- BIN_Tbot_FC7C3E087789824F34A9309DA2388CE5_2012-12.pcap
- BIN_Tinba_2012-06.pcap
- BIN_Vobfus_634AA845F5B0B519B6D8A8670B994906_2012-12.pcap
- BIN_Xpaj_2012-05.pcap
- BIN_ZeroAccess_3169969E91F5FE5446909BBAB6E14D5D_2012-10.pcap
- BIN_ZeusGameover_2012-02.pcap
- BIN_Zeus_2010-12.pcap
- EK_Blackholev1_2012-03.pcap
- EK_Blackholev1_2012-08.pcap
- EK_Blackholev2_2012-09.pcap
- EK_Blackhole_Java_CVE-2012-4681_2012-08.pcap
- EK_Phoenix_2012-04.pcap
- EK_Smokekt150(Malwaredontneedcoffee)_2012-09.pcap - credit malware.dontneedcoffee.com
Read more
Practical Bleichenbacher Attacks On IPsec IKE
We found out that reusing a key pair across different versions and modes of IPsec IKE can lead to cross-protocol authentication bypasses, enabling the impersonation of a victim host or network by attackers. These vulnerabilities existed in implementations by Cisco, Huawei, and others.
This week at the USENIX Security conference, I will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE written by Martin Grothe, Jörg Schwenk, and me from Ruhr University Bochum as well as Adam Czubak and Marcin Szymanek from the University of Opole [alternative link to the paper]. This blog post is intended for people who like to get a comprehensive summary of our findings rather than to read a long research paper.
In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.
We show that the strength of these oracles is sufficient to break all handshake variants in IKEv1 and IKEv2 (except those based on PSKs) when given access to powerful network equipment. We furthermore demonstrate that key reuse across protocols as implemented in certain network equipment carries high security risks.
We additionally show that both PSK based modes can be broken with an offline dictionary attack if the PSK has low entropy. Such an attack was previously only documented for one of those modes (edit: see this comment). We thus show attacks against all authentication modes in both IKEv1 and IKEv2 under reasonable assumptions.
Bleichenbacher attacks are adaptive chosen ciphertext attacks against RSA-PKCS #1 v1.5. Though the attack has been known for two decades, it is a common pitfall for developers. The mandatory use of PKCS #1 v1.5 in the PKE authentication methods raised suspicion of whether implementations resist Bleichenbacher attacks.
PKE authentication is available and fully functional in Cisco's IOS operating system. In Clavister's cOS and ZyXEL's ZyWALL USG devices, PKE is not officially available. There is no documentation and no configuration option for it and it is therefore not fully functional. Nevertheless, these implementations processed messages using PKE authentication in our tests.
Huawei implements a revised mode of the PKE mode mentioned in the RFC that saves one private key operation per peer (we call it RPKE mode). It is available in certain Huawei devices including the Secospace USG2000 series.
We were able to confirm the existence of Bleichenbacher oracles in all these implementations. Here are the CVE entries and security advisories by the vendors (I will add links once they are available):
To phrase it differently: In TLS-RSA, a Bleichenbacher oracle allows to perform an ex post attack to break the confidentiality of the TLS session later on, whereas in IKEv1 a Bleichenbacher oracle only can be used to perform an online attack to impersonate one of the two parties in real time.
The figure above depicts a direct attack on IKEv1 PKE:
I promised that this blogpost will only give a comprehensive summary, therefore I am skipping all the details about IKEv2 here. It is enough to know that the structure of IKEv2 is fundamentally different from IKEv1.
If you're familiar with IT-security, then you will believe me that if digital signatures are used for authentication, it is not particularly good if an attacker can get a signature over attacker chosen data. We managed to develop an attack that exploits an IKEv1 Bleichenbacher oracle at some peer A to get a signature that can be used to break the IKEv2 authentication at another peer B. This requires that peer A reuses its key pair for IKEv2 also for IKEv1. For the details, please read our paper [alternative link to the paper].
For the decryption attack on Cisco's IKEv1 responder, we need to finish the Bleichenbacher attack in 60 seconds. If the public key of our ASR 1001-X router is 1024 bits long, we measured an average of 850 responses to Bleichenbacher requests per second. Therefore, an attack must succeed with at most 51,000 Bleichenbacher requests.
But another limit is the management of Security Associations (SAs). There is a global limit of 900 Phase 1 SAs under negotiation per Cisco device in the default configuration. If this number is exceeded, one is blocked. Thus, one cannot start individual handshakes for each Bleichenbacher request to issue. Instead, SAs have to be reused as long as their error counter allows. Furthermore, establishing SAs with Cisco IOS is really slow. During the attack, the negotiations in the first two messages of IKEv1 require more time than the actual Bleichenbacher attack.
We managed to perform a successful decryption attack against our ASR 1001-X router with approximately 19,000 Bleichenbacher requests. However, due to the necessary SA negotiations, the attack took 13 minutes.
For the statistics and for the attack evaluation of digital signature forgery, we used a simulator with an oracle that behaves exactly as the ones by Cisco, Clavister, and ZyXEL. We found that about 26% of attacks against IKEv1 could be successful based on the cryptographic performance of our Cisco device. For digital signature forgery, about 22% of attacks could be successful under the same assumptions.
Note that (without a patched IOS), only non-cryptographic performance issues prevented a succesful attack on our Cisco device. There might be faster devices that do not suffer from this. Also note that a too slow Bleichenbacher attack does not permanently lock out attackers. If a timeout occurs, they can just start over with a new attack using fresh values hoping to require fewer requests. If the victim has deployed multiple responders sharing one key pair (e. g. for load balancing), this could also be leveraged to speed up an attack.
Huawei published firmware version V300R001C10SPH702 for the Secospace USG2000 series that removes the Bleichenbacher oracle and the crash bugs we identified. Customers who use other affected Huawei devices will be contacted directly by their support team as part of a need-to-know strategy.
Clavister removed the vulnerable authentication method with cOS version 12.00.09. ZyXEL responded that our ZyWALL USG 100 test device is from a legacy model series that is end-of-support. Therefore, these devices will not receive a fix. For the successor models, the patched firmware version ZLD 4.32 (Release Notes) is available.
This week at the USENIX Security conference, I will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE written by Martin Grothe, Jörg Schwenk, and me from Ruhr University Bochum as well as Adam Czubak and Marcin Szymanek from the University of Opole [alternative link to the paper]. This blog post is intended for people who like to get a comprehensive summary of our findings rather than to read a long research paper.
IPsec and Internet Key Exchange (IKE)
IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and configuration options. Therefore, IKE is one of the most complex cryptographic protocols in use.In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.
Attacks on IKE implementations
With our attacks we can impersonate an IKE device: If the attack is successful, we share a set of (falsely) authenticated symmetric keys with the victim device, and can successfully complete the handshake – this holds for both IKEv1 and IKEv2. The attacks are based on Bleichenbacher oracles in the IKEv1 implementations of four large network equipment manufacturers: Cisco, Huawei, Clavister, and ZyXEL. These Bleichenbacher oracles can also be used to forge digital signatures, which breaks the signature based IKEv1 and IKEv2 variants. Those who are unfamiliar with Bleichenbacher attacks may read this post by our colleague Juraj Somorovsky for an explanation.The affected hardware test devices by Huawei, Cisco, and ZyXEL in our network lab. |
We show that the strength of these oracles is sufficient to break all handshake variants in IKEv1 and IKEv2 (except those based on PSKs) when given access to powerful network equipment. We furthermore demonstrate that key reuse across protocols as implemented in certain network equipment carries high security risks.
We additionally show that both PSK based modes can be broken with an offline dictionary attack if the PSK has low entropy. Such an attack was previously only documented for one of those modes (edit: see this comment). We thus show attacks against all authentication modes in both IKEv1 and IKEv2 under reasonable assumptions.
Where's the bug?
The public key encryption (PKE) based authentication mode of IKE requires that both parties exchanged their public keys securely beforehand (e. g. with certificates during an earlier handshake with signature based authentication). RFC 2409 advertises this mode of authentication with a plausibly deniable exchange to raise the privacy level. In this mode, messages three and four of the handshake exchange encrypted nonces and identities. They are encrypted using the public key of the respective other party. The encoding format for the ciphertexts is PKCS #1 v1.5.Bleichenbacher attacks are adaptive chosen ciphertext attacks against RSA-PKCS #1 v1.5. Though the attack has been known for two decades, it is a common pitfall for developers. The mandatory use of PKCS #1 v1.5 in the PKE authentication methods raised suspicion of whether implementations resist Bleichenbacher attacks.
PKE authentication is available and fully functional in Cisco's IOS operating system. In Clavister's cOS and ZyXEL's ZyWALL USG devices, PKE is not officially available. There is no documentation and no configuration option for it and it is therefore not fully functional. Nevertheless, these implementations processed messages using PKE authentication in our tests.
Huawei implements a revised mode of the PKE mode mentioned in the RFC that saves one private key operation per peer (we call it RPKE mode). It is available in certain Huawei devices including the Secospace USG2000 series.
We were able to confirm the existence of Bleichenbacher oracles in all these implementations. Here are the CVE entries and security advisories by the vendors (I will add links once they are available):
- Cisco: CVE-2018-0131, Security Advisory
- Huawei: CVE-2017-17305, Security Advisory
- Clavister: CVE-2018-8753, Security Advisory
- Zyxel: CVE-2018-9129, Security Advisory
A Bleichenbacher Attack Against PKE
If a Bleichenbacher oracle is discovered in a TLS implementation, then TLS-RSA is broken since one can compute the Premaster Secret and the TLS session keys without any time limit on the usage of the oracle. For IKEv1, the situation is more difficult: Even if there is a strong Bleichenbacher oracle in PKE and RPKE mode, our attack must succeed within the lifetime of the IKEv1 Phase 1 session, since a Diffie-Hellman key exchange during the handshake provides an additional layer of security that is not present in TLS-RSA. For example, for Cisco this time limit is currently fixed to 60 seconds for IKEv1 and 240 seconds for IKEv2.To phrase it differently: In TLS-RSA, a Bleichenbacher oracle allows to perform an ex post attack to break the confidentiality of the TLS session later on, whereas in IKEv1 a Bleichenbacher oracle only can be used to perform an online attack to impersonate one of the two parties in real time.
Bleichenbacher attack against IKEv1 PKE based authentication. |
The figure above depicts a direct attack on IKEv1 PKE:
- The attackers initiate an IKEv1 PKE based key exchange with Responder A and adhere to the protocol until receiving the fourth message. They extract the encrypted nonce from this message, and record the other public values of the handshake.
- The attackers keep the IKE handshake with Responder A alive as long as the responder allows. For Cisco and ZyXEL we know that handshakes are cancelled after 60 seconds, Clavister and Huawei do so after 30 seconds.
- The attackers initiate several parallel PKE based key exchanges to Responder B.
- In each of these exchanges, they send and receive the first two messages according to the protocol specifications.
- In the third message, they include a modified version of the encrypted nonce according to the the Bleichenbacher attack methodology.
- They wait until they receive an answer or they can reliably determine that this message will not be sent (timeout or reception of a repeated second handshake message).
- After receiving enough answers from Responder B, the attackers can compute the plaintext of the nonce.
- The attackers now have all the information to complete the key derivation and the handshake. They thus can impersonate Responder B to Responder A.
Key Reuse
Maintaining individual keys and key pairs for each protocol version, mode, and authentication method of IKE is difficult to achieve in practice. It is oftentimes simply not supported by implementations. This is the case with the implementations by Clavister and ZyXEL, for example. Thus, it is common practice to have only one RSA key pair for the whole IKE protocol family. The actual security of the protocol family in this case crucially depends on its cross-ciphersuite and cross-version security. In fact, our Huawei test device reuses its RSA key pair even for SSH host identification, which further exposes this key pair.A Cross-Protocol Version Attack with Digital Signature Based Authentication
Signature Forgery Using Bleichenbacher's Attack
It is well known that in the case of RSA, performing a decryption and creating a signature is mathematically the same operation. Bleichenbacher's original paper already mentioned that the attack could also be used to forge signatures over attacker-chosen data. In two papers that my colleagues at our chair have published, this has been exploited for attacks on XML-based Web Services, TLS 1.3, and Google's QUIC protocol. The ROBOT paper used this attack to forge a signature from Facebook's web servers as proof of exploitability.IKEv2 With Digital Signatures
Digital signature based authentication is supported by both IKEv1 and IKEv2. We focus here on IKEv2 because on Cisco routers, an IKEv2 handshake may take up to four minutes. This more relaxed timer compared to IKEv1 makes it an interesting attack target.I promised that this blogpost will only give a comprehensive summary, therefore I am skipping all the details about IKEv2 here. It is enough to know that the structure of IKEv2 is fundamentally different from IKEv1.
If you're familiar with IT-security, then you will believe me that if digital signatures are used for authentication, it is not particularly good if an attacker can get a signature over attacker chosen data. We managed to develop an attack that exploits an IKEv1 Bleichenbacher oracle at some peer A to get a signature that can be used to break the IKEv2 authentication at another peer B. This requires that peer A reuses its key pair for IKEv2 also for IKEv1. For the details, please read our paper [alternative link to the paper].
Evaluation and Results
For testing the attack, we used a Cisco ASR 1001-X router running IOS XE in version 03.16.02.S with IOS version 15.5(3)S2. Unfortunately, Cisco's implementation is not optimized for throughput. From our observations we assume that all cryptographic calculations for IKE are done by the device's CPU despite it having a hardware accelerator for cryptography. One can easily overload the device's CPU for several seconds with a standard PC bursting handshake messages, even with the default limit for concurrent handshakes. And even if the CPU load is kept below 100 %, we nevertheless observed packet loss.For the decryption attack on Cisco's IKEv1 responder, we need to finish the Bleichenbacher attack in 60 seconds. If the public key of our ASR 1001-X router is 1024 bits long, we measured an average of 850 responses to Bleichenbacher requests per second. Therefore, an attack must succeed with at most 51,000 Bleichenbacher requests.
But another limit is the management of Security Associations (SAs). There is a global limit of 900 Phase 1 SAs under negotiation per Cisco device in the default configuration. If this number is exceeded, one is blocked. Thus, one cannot start individual handshakes for each Bleichenbacher request to issue. Instead, SAs have to be reused as long as their error counter allows. Furthermore, establishing SAs with Cisco IOS is really slow. During the attack, the negotiations in the first two messages of IKEv1 require more time than the actual Bleichenbacher attack.
We managed to perform a successful decryption attack against our ASR 1001-X router with approximately 19,000 Bleichenbacher requests. However, due to the necessary SA negotiations, the attack took 13 minutes.
For the statistics and for the attack evaluation of digital signature forgery, we used a simulator with an oracle that behaves exactly as the ones by Cisco, Clavister, and ZyXEL. We found that about 26% of attacks against IKEv1 could be successful based on the cryptographic performance of our Cisco device. For digital signature forgery, about 22% of attacks could be successful under the same assumptions.
Note that (without a patched IOS), only non-cryptographic performance issues prevented a succesful attack on our Cisco device. There might be faster devices that do not suffer from this. Also note that a too slow Bleichenbacher attack does not permanently lock out attackers. If a timeout occurs, they can just start over with a new attack using fresh values hoping to require fewer requests. If the victim has deployed multiple responders sharing one key pair (e. g. for load balancing), this could also be leveraged to speed up an attack.
Responsible Disclosure
We reported our findings to Cisco, Huawei, Clavister, and ZyXEL. Cisco published fixes with IOS XE versions 16.3.6, 16.6.3, and 16.7.1. They further informed us that the PKE mode will be removed with the next major release.Huawei published firmware version V300R001C10SPH702 for the Secospace USG2000 series that removes the Bleichenbacher oracle and the crash bugs we identified. Customers who use other affected Huawei devices will be contacted directly by their support team as part of a need-to-know strategy.
Clavister removed the vulnerable authentication method with cOS version 12.00.09. ZyXEL responded that our ZyWALL USG 100 test device is from a legacy model series that is end-of-support. Therefore, these devices will not receive a fix. For the successor models, the patched firmware version ZLD 4.32 (Release Notes) is available.
FAQs
- Why don't you have a cool name for this attack?
The attack itself already has a name, it's Bleichenbacher's attack. We just show how Bleichenbacher attacks can be applied to IKE and how they can break the protocol's security. So, if you like, call it IPsec-Bleichenbacher or IKE-Bleichenbacher. - Do you have a logo for the attack?
No. - My machine was running a vulnerable firmware. Have I been attacked?
We have no indication that the attack was ever used in the wild. However, if you are still concerned, check your logs. The attack is not silent. If your machine was used for a Bleichenbacher attack, there should be many log entries about decryption errors. If your machine was the one that got tricked (Responder A in our figures), then you could probably find log entries about unfinished handshake attempts. - Where can I learn more?
First of all, you can read the paper [alternative link to the paper]. Second, you can watch the presentation, either live at the conference or later on this page. - What else does the paper contain?
The paper contains a lot more details than this blogpost. It explains all authentication methods including IKEv2 and it gives message flow diagrams of the protocols. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2. Furthermore, we describe the quirks of Huawei's implementation including crash bugs that could allow for Denial-of-Service attacks. Last but not least, it describes a dictionary attack against the PSK mode of authentication that is covered in a separate blogpost.
Media Coverage, Blogs, and more
English
German
Related word
Subscribe to:
Posts (Atom)