Es el estado de nosotros como seres humanos de completar bien el bienestar fisico, mental y social de la salud; y tener en cuenta no solo de la ausencia de enfermedad.
o_O, he repasado caracter a caracter y son visualmente iguales, si mirais en un editor hexa vereis que realmente no lo son, lógicamente no se trata de un expedienteX.
La cuestion es que según la fuente que tengais, debajo de la comilla o debajo del ] hay un punto microscópico :)
Esto es como cuando me emparanoie de que gmail cuando llevas un rato escribiendo un email y se hace auto-save, aparece una especie de acento raro en la pantalla :)
En estos casos, la metodología tipica de copypastear un trozo de la primera sentencia con el resto de la segunda sentencia, te lleva a los 2 caracteres que varían, pero no aprecias (segun la fuente que tengas) la diferéncia.
Son dígitos unicode, sabe Dios de que pais, y sabe Dios también como los escribí con mi teclado, se me ocurren bromas de código fuente que se pueden hacer con esto :D, pero vamos, si tenemos metodología de reaccién ante expedientesX, sobretodo aquello de divide y vencerás dicotómico, en pocos minutos se resuelven este tipo de problemas.More information
Airbash is a POSIX-compliant, fully automated WPA PSK handshake capture script aimed at penetration testing. It is compatible with Bash and Android Shell (tested on Kali Linux and Cyanogenmod 10.2) and uses aircrack-ng to scan for clients that are currently connected to access points (AP). Those clients are then deauthenticated in order to capture the handshake when attempting to reconnect to the AP. Verification of a captured handshake is done using aircrack-ng. If one or more handshakes are captured, they are entered into an SQLite3 database, along with the time of capture and current GPS data (if properly configured).
After capture, the database can be tested for vulnerable router models using crackdefault.sh. It will search for entries that match the implemented modules, which currently include algorithms to compute default keys for Speedport 500-700 series, Thomson/SpeedTouch and UPC 7 digits (UPC1234567) routers.
Requirements WiFi interface in monitor mode aircrack-ng SQLite3 openssl for compilation of modules (optional) wlanhc2hcx from hcxtools In order to log GPS coordinates of handshakes, configure your coordinate logging software to log to .loc/*.txt (the filename can be chosen as desired). Airbash will always use the output of cat "$path$loc"*.txt 2>/dev/null | awk 'NR==0; END{print}', which equals to reading all .txt files in .loc/ and picking the second line. The reason for this way of implementation is the functionality of GPSLogger, which was used on the development device. Calculating default keys After capturing a new handshake, the database can be queried for vulnerable router models. If a module applies, the default keys for this router series are calculated and used as input for aircrack-ng to try and recover the passphrase. Compiling Modules The modules for calculating Thomson/SpeedTouch and UPC1234567 (7 random digits) default keys are included in src/ Credits for the code go to the authors Kevin Devine and [peter@haxx.in].
If on Android, you may need to copy the binaries to /system/xbin/ or to another directory where binary execution is allowed. Usage Running install.sh will create the database, prepare the folder structure and create shortlinks to both scripts which can be moved to a directory that is on $PATH to allow execution from any location. After installation, you may need to manually adjust INTERFACE on line 46 in airba.sh. This will later be determined automatically, but for now the default is set to wlan0, to allow out of the box compatibility with bcmon on Android. ./airba.sh starts the script, automatically scanning and attacking targets that are not found in the database. ./crackdefault.sh attempts to break known default key algorithms. To view the database contents, run sqlite3 .db.sqlite3 "SELECT * FROM hs" in the main directory. Update (Linux only ... for now): Airbash can be updated by executing update.sh. This will clone the master branch into /tmp/ and overwrite the local files. Output _n: number of access points found __c/m: represents client number and maximum number of clients found, respectively -: access point is blacklisted x: access point already in database ?: access point out of range (not visible to airodump anymore) The Database The database contains a table called hs with seven columns. id: incrementing counter of table entries lat and lon: GPS coordinates of the handshake (if available) bssid: MAC address of the access point essid: Name identifier psk: WPA Passphrase, if known prcsd: Flag that gets set by crackdefault.sh to prevent duplicate calculation of default keys if a custom passphrase was used. Currently, the SQLite3 database is not password-protected.
7 Types of hacker 1-Script Kiddies-They are just download overused software & watch youtube video on how to use it. Script kiddies don't care about hacking. 2-White Hat-They are the good guys of the hacker world. They also known as Ethical Hacker. 3-Black Hat-They finds bank or other companies with weak security and steal money or credit card information. They also known as cracker. They are dangerous because they are illegal to gain unauthorized access. 4-Gray Hat-They don't steal money or information sometimes they deface a website or they don't help people for good. 5-Green Hat-These are the hacker "noobz" but unlike Script Kiddies.They care about Hacking and strive to become full-blown hacker. 6-Red Hat-These are the vigilantes of the hacker world. They are like White Hats in that they halt Black Hats but these folks are downright SCARY to those who have ever tried so much as penetrest. 7-Blue Hat-If a Script Kiddy took revenge he/she might become a Blue Hat.Most Blue Hats are noobz.They have no desire to learn.
In part 1 and 2 we covered re-entrancy and authorization attack scenarios within the Ethereum smart contract environment. In this blog we will cover integer attacks against blockchain decentralized applications (DAPs) coded in Solidity.
Integer Attack Explanation:
An integer overflow and underflow happens when a check on a value is used with an unsigned integer, which either adds or subtracts beyond the limits the variable can hold. If you remember back to your computer science class each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers.
If you go outside of the constraints of the number type you are using it may handle things in different ways such as an error condition or perhaps cutting the number off at the maximum or minimum value.
In the Solidity language for Ethereum when we reach values past what our variable can hold it in turn wraps back around to a number it understands. So for example if we have a variable that can only hold a 2 digit number when we hit 99 and go past it, we will end up with 00. Inversely if we had 00 and we subtracted 1 we would end up with 99.
Normally in your math class the following would be true:
99 + 1 = 100 00 - 1 = -1
In solidity with unsigned numbers the following is true: 99 + 1 = 00 00 - 1 = 99
So the issue lies with the assumption that a number will fail or provide a correct value in mathematical calculations when indeed it does not. So comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that does not check for safe values.
That comparison may very well be comparing the output of an over/under flowed value and be completely meaningless. The Require statement may return true, but not based on the actual intended mathematical value. This in turn will lead to an action performed which is beneficial to the attacker for example checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Lets go through a few examples.
Simple Example:
Lets say we have the following Require check as an example: require(balance - withdraw_amount > 0) ;
Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously they don't have the money for this transaction correct?
This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above where we can hold 2 digits with an unsigned integer?
Let's do some math. 5 - 6 = 99
Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.
Because the following math returns true: require(99 > 0)
Withdraw Function Vulnerable to an UnderFlow:
The below example snippet of code illustrates a withdraw function with an underflow vulnerability:
In this example the require line checks that the balance is greater then 0 after subtracting the _amount but if the _amount is greater than the balance it will underflow to a value above 0 even though it should fail with a negative number as its true value.
require(balances[msg.sender] - _amount > 0);
It will then send the value of the _amount variable to the recipient without any further checks:
msg.sender.transfer(_amount);
Followed by possibly increasing the value of the senders account with an underflow condition even though it should have been reduced:
balances[msg.sender] -= _amount;
Depending how the Require check and transfer functions are coded the attacker may not lose any funds at all but be able to transfer out large sums of money to other accounts under his control simply by underflowing the require statements which checks the account balance before transferring funds each time.
Transfer Function Vulnerable to a Batch Overflow:
Overflow conditions often happen in situations where you are sending a batched amount of values to recipients. If you are doing an airdrop and have 200 users who are each receiving a large sum of tokens but you check the total sum of all users tokens against the total funds it may trigger an overflow. The logic would compare a smaller value to the total tokens and think you have enough to cover the transaction for example if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?
You have 10,000 tokens in your account You are sending 200 users 499 tokens each Your total sent is 200*499 or 99,800
The above scenario would fail as it should since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Lets do some more math and see how that changes the outcome.
You have 10,000 tokens in your account You are sending 200 users 500 tokens each Your total sent is 200*500 or 100,000 New total is actually 0
This new scenario produces a total that is actually 0 even though each users amount is 500 tokens which may cause issues if a require statement is not handled with safe functions which stop an overflow of a require statement.
Lets take our new numbers and plug them into the below code and see what happens:
1: The total variable is 100,000 which becomes 0 due to the 5 digit limit overflow when a 6th digit is hit at 99,999 + 1 = 0. So total now becomes 0.
2: This line checks if the users balance is high enough to cover the total value to be sent which in this case is 0 so 10,000 is more then enough to cover a 0 total and this check passes due to the overflow.
3: This line deducts the total from the senders balance which does nothing since the total of 10,000 - 0 is 10,000. The sender has lost no funds.
4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 as this does not trigger an overflow condition. Thus sending out 100,000 tokens without reducing the senders balance or triggering an error due to lack of funds. Essentially creating tokens out of thin air.
In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.
Lab Follow Along Time:
We went through what might have been an overwhelming amount of concepts in this chapter regarding over/underflow scenarios now lets do an example lab in the video below to illustrate this point and get a little hands on experience reviewing, writing and exploiting smart contracts. Also note in the blockchain youtube playlist we cover the same concepts from above if you need to hear them rather then read them.
For this lab we will use the Remix browser environment with the current solidity version as of this writing 0.5.12. You can easily adjust the compiler version on Remix to this version as versions update and change frequently. https://remix.ethereum.org/
Below is a video going through coding your own vulnerable smart contract, the video following that goes through exploiting the code you create and the videos prior to that cover the concepts we covered above:
This next video walks through exploiting the code above, preferably hand coded by you into the remix environment. As the best way to learn is to code it yourself and understand each piece:
Conclusion:
We covered a lot of information at this point and the video series playlist associated with this blog series has additional information and walk throughs. Also other videos as always will be added to this playlist including fixing integer overflows in the code and attacking an actual live Decentralized Blockchain Application. So check out those videos as they are dropped and the current ones, sit back and watch and re-enforce the concepts you learned in this blog and in the previous lab. This is an example from a full set of labs as part of a more comprehensive exploitation course we have been working on.
It's a 32bits elf binary of some version of vsftpd, where it have been added a backdoor, they don't specify is an authentication backdoor, a special command or other stuff.
I started looking for something weird on the authentication routines, but I didn't found anything significant in a brief period of time, so I decided to do a bindiff, that was the key for locating the backdoor quickly. I do a quick diff of the strings with the command "strings bin | sort -u" and "vimdiff" and noticed that the backdoored binary has the symbol "execl" which is weird because is a call for executing elfs, don't needed for a ftp service, and weird that the compiled binary doesn't has that symbol.
Looking the xrefs of "execl" on IDA I found that code that is a clear backdoor, it create a socket, bind a port and duplicate the stdin, stdout and stderr to the socket and use the execl:
There are one xrefs to this function, the function that decides when trigger that is that kind of systems equations decision:
The backdoor was not on the authentication, it was a special command to trigger the backdoor, which is obfuscated on that systems equation, it was no needed to use a z3 equation solver because is a simple one and I did it by hand.
The equation:
cmd[0] = 69
cmd[1] = 78
cmd[1] + cmd[2] = 154
cmd[2] + cmd[3] = 202
cmd[3] + cmd[4] = 241
cmd[4] + cmd[5] = 233
cmd[5] + cmd[6] = 217
cmd[6] + cmd[7] = 218
cmd[7] + cmd[8] = 228
cmd[8] + cmd[9] = 212
cmd[9] + cmd[10] = 195
cmd[10] + cmd[11] = 195
cmd[11] + cmd[12] = 201
cmd[12] + cmd[13] = 207
cmd[13] + cmd[14] = 203
cmd[14] + cmd[15] = 215
cmd[15] + cmd[16] = 235
cmd[16] + cmd[17] = 242
The solution:
cmd[0] = 69
cmd[1] = 75
cmd[2] = 79
cmd[3] = 123
cmd[4] = 118
cmd[5] = 115
cmd[6] = 102
cmd[7] = 116
cmd[8] = 112
cmd[9] = 100
cmd[10] = 95
cmd[11] = 100
cmd[12] = 101
cmd[13] = 106
cmd[14] = 97
cmd[15] = 118
cmd[16] = 117
cmd[17] = 125
The flag:
EKO{vsftpd_dejavu}
The binary: https://ctf.ekoparty.org/static/pre-ekoparty/backdoor
SQLi hunter is a tool to scan for an SQLi Injection vulnerability in a website on auto-pilot. It automates the search of SQLi vulnerable links from Google using different dorks. SQLi hunter can also find admin panel page of any website by using some predefined admin page lists. Download SQLi hunter v1.2.
FEATURES
– Supports 500 results – Url List can be Imported / Exported – The setting for connection timeout – Proxy Settings
If you're not totally satisfied with this tool, you can try other sql injection tools like havij , sqli dumper and sqlmap. These tools are incredibly super flexible with their advanced injection features.
In this post we will show why Gridcoin is insecure and probably will never achieve better security. Therefore, we are going to explain two critical implementation vulnerabilities and our experience with the core developer in the process of the responsible disclosure.
In our last blog post we described the Gridcoin architecture and the design vulnerability we found and fixed (the good). Now we come to the process of responsibly disclosing our findings and try to fix the two implementation vulnerabilities (the bad).
Update (15.08.2017): After the talk at WOOT'17 serveral other developers of Gridcoin quickly reached out to us and told us that there was a change in responsibility internally in the Gridcoin-Dev team. Thus, we are going to wait for their response and then change this blog post accordingly. So stay tuned :) Update (16.08.2017): We are currently in touch with the whole dev team of Gridcoin and it seems that they are going to fix the vulnerabilities with the next release. TL;DR The whole Gridcoin currency is seriously insecure against attacks and should not be trusted anymore; unless some developers are in place, which have a profound background in protocol and application security.
What is Gridcoin?
Gridcoin is an altcoin, which is in active development since 2013. It claims to provide a high sustainability, as it has very low energy requirements in comparison to Bitcoin. It rewards users for contributing computation power to scientific projects, published on the BOINC project platform. Although Gridcoin is not as widespread as Bitcoin, its draft is very appealing as it attempts to eliminate Bitcoin's core problems. It possesses a market capitalization of $13,530,738 as of August the 4th 2017 and its users contributed approximately 5% of the total scientific BOINC work done before October 2016.
A detailed description of the Gridcoin architecture and technical terms used in this blog post are explained in our last blog post.
The Issues
Currently there are 2 implementation vulnerabilities in the source code, and we can mount the following attacks against Gridcoin:
We can steal the block creation reward from many Gridcoin minters
We can efficiently prevent many Gridcoin minters from claiming their block creation reward (DoS attack)
So why do we not just open up an issue online explaining the problems?
Because we already fixed a critical design issue in Gridcoin last year and tried to help them to fix the new issues. Unfortunately, they do not seem to have an interest in securing Gridcoin and thus leave us no other choice than fully disclosing the findings.
In order to explain the vulnerabilities we will take a look at the current Gridcoin source code (version 3.5.9.8).
WARNING: Due to the high number of source code lines in the source files, it can take a while until your browser shows the right line.
Stealing the BOINC block reward
The developer implemented our countermeasures in order to prevent our attack from the last blog post. Unfortunately, they did not look at their implementation from an attacker's perspective. Otherwise, they would have found out that they conduct not check, if the signature over the last block hash really is done over the last block hash. But we come to that in a minute. First lets take a look at the code flow:
In the figure the called-by-graph can be seen for the function VerifyCPIDSignature.
Then we call a function to verify the CPID used in the block. Due to the massive changes over the last years, there are 3 possible verify functions. We are interested in the last one (VerifyCPIDSignature), for the reason that it is the current verification function.
In the last function the real signature verification is conducted [Source]. When we closely take a look at the function parameter, we see the message (std::string sMsg) and the signature (std::string sSig) variables, which are checked. But where does this values come from?
If we go backwards in the function call graph we see that in VerifyCPIDSignature the sMsg is the string sConcatMessage, which is a concatenation of the sCPID and the sBlockHash. We are interested where the sBlockHash value comes from, due to the fact that this one is the only changing value in the signature generation. When we go backwards, we see that the value originate from the deserialization of the BOINC structure (MiningCPID& mc) and is the variable mc.lastblockhash [Source, Source]. But wait a second, is this value ever checked whether it contains the real last block hash?
No, it is not....
So they just look if the stored values there end up in a valid signature.
Thus, we just need to wait for one valid block from a researcher and copy the signature, the last block hash value, the CPID and adjust every other dynamic value, like the RAC. Consequently, we are able to claim the reward of other BOINC users. This simple bug allows us again to steal the reward of every Gridcoin researcher, like there was never a countermeasure. Lock out Gridcoin researcher The following vulnerability allows an attacker under specific circumstances to register a key pair for a CPID, even if the CPID was previously tied to another key pair. Thus, the attacker locks out a legit researcher and prevent him from claiming BOINC reward in his minted blocks.
Reminder: A beacon is valid for 5 months, afterwards a new beacon must be sent with the same public key and CPID.
Therefore, we need to take a look at the functions, which process the beacon information. Every time there is a block, which contains beacon information, it is processed the following way (click image for higher resolution):
In the figure the called-by-graph can be seen for the function GetBeaconPublicKey.
In the last function GetBeaconPublicKey there are different paths to process a beacon depending on the public key, the CPID, and the time since both were associated to each other. For the following explanation we assume that we have an existing association (bound) between a CPID A and a public key pubK_A for 4 months.
The case, if a different public key pubK_B for the CPID A was sent via beacon.
The existing public key for the CPID is expired
After 5 months a refresh for the association between A and pubK_A is required.
When an incoming beacon is processed, a look up is made, if there already exists a public key for the CPID used in the beacon. If yes, it is compared to the public key used in the beacon (case 2 and 3). If no public key exists (case 1) the new public key is bound to the CPID.
If a public key exists, but it was not refreshed directly 12.960.000 seconds (5 months [Source]) after the last beacon advertisement of the public key and CPID, it is handled as no public key would exist [Source].
Thus, case 1 and 4 are treated identical, if the public key is expired, allowing an attacker to register his public key for an arbitrary CPID with expired public key. In practice this allows an attacker to lock out a Gridcoin user from the minting process of new blocks and further allows the attacker to claim reward for BOINC work he never did.
There is a countermeasure, which allows a user to delete his last beacon (identified by the CPID) . Therefore, the user sends 1 GRC to a special address (SAuJGrxn724SVmpYNxb8gsi3tDgnFhTES9) from an GRC address associated to this CPID [Source]. We did not look into this mechanism in more detail, because it only can be used to remove our attack beacon, but does not prevent the attack.
The responsible disclosure process
As part of our work as researchers we all have had the pleasure to responsible disclose the findings to developer or companies.
For the reasons that we wanted to give the developer some time to fix the design vulnerabilities, described in the last blog post, we did not issue a ticket at the Gridcoin Github project. Instead we contacted the developer at September the 14th 2016 via email and got a response one day later (2016/09/15). They proposed a variation of our countermeasure and dropped the signature in the advertising beacon, which would result in further security issues. We sent another email (2016/09/15) explained to them, why it is not wise to change our countermeasures and drop the signature in the advertising beacon. Unfortunately, we did not receive a response. We tried it again on October the 31th 2016. They again did not respond, but we saw in the source code that they made some promising changes. Due to some other projects we did not look into the code until May 2017. At this point we found the two implementation vulnerabilities. We contacted the developer twice via email (5th and 16th of May 2017) again, but never received a response. Thus, we decided to wait for the WOOT notification to pass by and then fully disclose the findings. We thus have no other choice then to say that:
The whole Gridcoin cryptocurrency is seriously insecure against attacks and should not be trusted anymore; unless some developers are in place, which have a profound background in protocol and application security.
Further Reading
A more detailed description of the Gridcoin architecture, the old design issue and the fix will be presented at WOOT'17. Some days after the conference the paper will be available online.
bWAPP, or a buggy web application, is a free and open source deliberately insecure web application. It helps security enthusiasts, developers and students to discover and to prevent web vulnerabilities. bWAPP prepares one to conduct successful penetration testing and ethical hacking projects.
What makes bWAPP so unique? Well, it has over 100 web vulnerabilities! It covers all major known web bugs, including all risks from the OWASP Top 10 project. bWAPP is for web application security-testing and educational purposes only.
Have fun with this free and open source project! bWAPP is a PHP application that uses a MySQL database. It can be hosted on Linux/Windows with Apache/IIS and MySQL. It can also be installed with WAMP or XAMPP. Another possibility is to download the bee-box, a custom Linux VM pre-installed with bWAPP.
First of all you have need to install a local server over system that may be XAMPP, WAMP or LAMP. These servers are totally free of cost you can freely download from the internet. Mostly XAMPP is used because it has more functionalities than others on the other hand WAMP is also a simple platform for PHP while, LAMP is used over the Linux distributions. After downloading any one of them you have need to install that first after that you'll be able to configure bWAPP over your system.
Why we use the software application for configuring this bWAPP? As we know PHP is a server side language and there must be a server to read the PHP script. Without using any server we can't do programming with PHP. If you have a little piece of code of PHP you must install a server in your system for running that PHP script.
Ethical Hackers Platform: How to Install a bWAPP In Windows 2018. Free source for exploring things related to an Ethical Hacking.
Interators are usually implemented using signed integers like the typical "for (int i=0; ..." and in fact is the type used indexing "cstr[i]", most of methods use the signed int, int by default is signed. Nevertheless, the "std::string::operator[]" index is size_t which is unsigned, and so does size(), and same happens with vectors. Besides the operator[] lack of negative index control, I will explain this later.
Do the compilers doesn't warn about this?
If his code got a large input it would index a negative numer, let see g++ and clang++ warnings:
No warnings so many bugs out there...
In order to reproduce the crash we can load a big string or vector from file, for example:
I've implemented a loading function, getting the file size with tellg() and malloc to allocate the buffer, then in this case used as a string. Let see how the compiler write asm code based on this c++ code.
So the string constructor, getting size and adding -2 is clear. Then come the operator<< to concat the strings. Then we see the operator[] when it will crash with the negative index. In assembly is more clear, it will call operator[] to get the value, and there will hapen the magic dereference happens. The operator[] will end up returning an invalid address that will crash at [RAX]
In gdb the operator[] is a allq 0x555555555180 <_znst7__cxx1112basic_stringicst11char_traitsicesaiceeixem plt="">
(gdb) i r rsi rsi 0xfffffffffffefffe -65538
The implmementation of operator ins in those functions below:
(gdb) bt #0 0x00007ffff7feebf3 in strcmp () from /lib64/ld-linux-x86-64.so.2 #1 0x00007ffff7fdc9a5 in check_match () from /lib64/ld-linux-x86-64.so.2 #2 0x00007ffff7fdce7b in do_lookup_x () from /lib64/ld-linux-x86-64.so.2 #3 0x00007ffff7fdd739 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2 #4 0x00007ffff7fe1eb7 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2 #5 0x00007ffff7fe88ee in _dl_runtime_resolve_xsavec () from /lib64/ld-linux-x86-64.so.2 #6 0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29
Then crashes on the MOVZX EAX, byte ptr [RAX]
Program received signal SIGSEGV, Segmentation fault.
0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29 29 cout << "penultimate byte is " << hex << s[i] << endl; (gdb)
What about negative indexing in std::string::operator[] ? It's exploitable!
In a C char array is known that having control of the index, we can address memory. Let's see what happens with C++ strings:
The operator[] function call returns the address of string plus 10, and yes, we can do abitrary writes.
Note that gdb displays by default with at&t asm format wich the operands are in oposite order:
And having a string that is in the stack, controlling the index we can perform a write on the stack.
To make sure we are writing outside the string, I'm gonna do 3 writes:
See below the command "i r rax" to view the address where the write will be performed.
The beginning of the std::string object is 0x7fffffffde50. Write -10 writes before the string 0x7fffffffde46. And write -100 segfaults because is writting in non paged address.
So, C++ std::string probably is not vulnerable to buffer overflow based in concatenation, but the std::string::operator[] lack of negative indexing control and this could create vulnerable and exploitable situations, some times caused by a signed used of the unsigned std::string.size()
Welcome back to the Linux Command Line Hackery series, this is Part-V of the series. Today we are going to learn how to monitor and control processes on our Linux box, so wrap your sleeves up and let's get started. Command: ps Syntax: ps [options] Description: ps displays information about the currently running processes. Some of the common flags of ps are described briefly below Flags: -Aor -e -> select all processes -a -> select all processes except both session leaders and processes not associated with a terminal. T -> select all processes associated with current terminal -u<username or id> -> select all processes of a given user or userlist Open up a terminal and type ps: ps what you'll see is a list of processes currently running in your terminal. One important thing to notice in the output is what's called as PID which stands for process ID. It is the number that uniquely identifies a process. Just keep that PID concept in mind we'll use it soon. OK I know that's not really what you want to see rather you want to see all the processes that are currently running on your box. Don't worry we have flags to rescue, in order to see all the processes you can use the -e flag like this: ps -e Boom! you get a long list of processes currently running on your machine (don't stare at me like that, you asked and I gave you that). If you want to see processes of a particular user you can type the following command in your terminal: ps -u bob here "bob" is a username. This command will list all processes of the user with effective user name of bob. You can do a full-format listing of the processes using the -f flag like this: ps -fubob But the output of the ps command is a snapshot not really a live preview of what is going on in your box. I know your next question is going to be something like this, Isn't there a command in Linux that gives me a live updating information of the processes? Yes, there is a command called top that we'll learn about next. Command: top Syntax: top [options] Description: top gives a dynamic real-time view of a running system. That is, it gives the up-to-date information about all the processes running on your Linux box (sounds fun!). Besides giving information about current processes and threads top also provides a brief system summary. To start top just type this command: top and you'll get a nice and cute looking ugly display :). Well what the heck is going on here you might ask, right? What you get is information about what is going on with your computer. To see what more can you do with top just type <h> within the program window and you'll be given list of options that you can play with. OK looking at what processes are going on in your box is cool but what if you want to terminate (or close) a process, is there a command line utility for that? Yes, there is and that's what we are going to look at next. Command: kill Syntax: kill [options] <pid> [...] Description: kill is used to send a signal to process which by default is a TERM signal meaning kill by default sends a signal of termination to process (Cruel guy). To list the available signals we can use the -l or -L flag of the kill command. To simply terminate a process we provide kill command a PID (process ID) and it will send the TERM signal to the process. So to kill a process first we'll list the running processes and then we'll keep the PID of the process in mind that we want to terminate. After that we'll issue the kill command with the PID that we just found. ps -ax kill 1153 the above command will send a TERM signal to the process whose PID is 1153, as simple as that. We can also use our already learned skills to refine the output of ps command. Say we have a xterm terminal running on our box and we want to terminate it. By using ps command all alone we'll get a long listing of all processes running on our box. But we can limit the output of ps command to just those processes that we're interested in by piping ps command with the grep command like this: ps -ax| grep xterm wow! that's amazing, we're able to pull out only those results from the ps command that contained xterm in them. Isn't that a cool trick? But what is that vertical bar ( | ) doing in the middle, you may be thinking, right? Remember we learned about the input and output re-directors previously, the vertical bar (pipe in geeky terms) is another re-director whose task is to redirect the output of one command as input to another command. Here the pipe redirects the output of ps -ax command as input to grep command and of-course from the previous article you know that grep is used to search for a PATTERN in the given input. That means the above command searches for the xterm word in the output of ps -ax command and then displays just those lines of ps -ax command which contain xterm. Now get that PID and kill that process. That's it for today, try these commands up on your own box and remember practice is gonna make you master the Linux command line. :)
Related articles
