Kapital constante

gonzalo garcia

The topic of DEATH is not one that most people care to talk about, but the truth is that we are all going to die at some point and everything that we did online is going to end up in limbo if we don't make sure that someone we trust is going to be able to gain access to this information. This is going to be extremely important in order to close it down, or have your loved one do whatever you want them to do with your information. There are many things to take into consideration for this kind of situation. If you are like the average modern person, you probably have at least one email account, a couple of social media accounts in places like Facebook and Twitter. Perhaps you also have a website that you run or a blog. These are all very common things that people will usually do at some point and if you have anything that you consider valuable, you should have a way to leave it in the hands of someone you trust when you pass away.

Pass Accounts and Passwords After Death

Maybe you have an online platform that has a lot of content that you find useful and important. Perhaps you have even been able to turn some of that content into monetizable material and you don't want this to end when you pass away. This is more than enough of a reason to make sure that your information can be given to someone when you are no longer around.

There have been many cases when all the information has ended up being impossible to recover when a person has died, at least not without the need for the family members to do all kinds of things in order to prove a person is deceased. So here are some ways, you can passyour online accounts/data after death:

1) Making a Safe 'WILL' (or Locker) containing master password.

Make an inventory of all your online accounts and list them on a piece of paper one by one and give it to your loved one. For eg:– Your primary email address
– Your Facebook ID/email
– The Bank account or Internet banking ID
– etc. To clarify, it will be only a list of the accounts you want your loved one to be able to access after you're dead. Just the list of accounts, nothing else (no passwords).
Set up a brand new e-mail address (Possibly Gmail account). Lets say youraccountsinfo@gmail.com
Now from your usual email account, Send an e-mail to youraccountsinfo@gmail.com, with the following content:– dd349r4yt9dfj
– sd456pu3t9p4
– s2398sds4938523540
– djfsf4p These are, of course, the passwords and account numbers that you want your loved one to have once you're dead.
Tell your loved one that you did these things, and while you're at it, send him/her an e-mail from youraccountsinfo@gmail.com, so he/she will have the address handy in some special folder in his/her inbox.
Put the password for youraccountsinfo@gmail.com in your will or write it down on paper and keep it safe in your bank locker. Don't include the e-mail address as well, just put something like "The password is: loveyourhoney432d".

And its done! Your loved one will only have the password once you're dead, and the info is also secure, since it's split in two places that cannot be easily connected, so if the e-mail address happens to be hacked, the perpetrator won't be able to use it to steal anything that you're going to leave for your loved one.

2) Preparing a Future email (SWITCH) containing login information

This method is very similar to the first one except in this case we will not be using a WILL or Locker. Instead we will be using a Service called "Dead Mans Switch" that creates a switch (Future email) and sends it to your recipients after a particular time interval. Here is how it works.

Create a list of accounts as discussed in the first method and give it to your loved one.
Register on "Dead mans switch" and create a switch containing all the corresponding passwords and enter the recipients email (Your loved one).
Your switch will email you every so often, asking you to show that you are fine by clicking a link. If something happens to you, your switch would then send the email you wrote to the recipient you specified. Sort of an "electronic will", one could say.

3) Using password managers that have emergency access feature

Password managers like LastPass and Dashlane have a feature called as "emergency access". It functions as a dead man's switch. You just have to add your loved one to your password manager, with emergency access rights. he/She does not see any of your information, nor can he/she log into your accounts normally.

But if the worst happens, your loved one can invoke the emergency access option. Next your password manager sends an email to you and starts a timer. If, after a certain amount of time interval, you have not refused the request, then your loved one gets full access to your password manager.

You can always decide what they can potentially gain access to, and you set the time delay.

Why should i bother about passing my digital legacy?

Of all the major online platforms, only Google and Facebook have provisions for Inactiveaccounts (in case of death). Google lets you plan for the inevitable ahead of time. Using the "Inactive Account Manager", you can designate a beneficiary who will inherit access to any or all of your Google accounts after a specified period of inactivity (the default is 3 months).

Facebook on the other hand will either delete your inactive account or turn it into a memorial page when their family can provide any proof of their death, but there is also a large number of platforms that don't have any specific way for people to be able to verify the death of a loved one in order to gain access to the accounts. In either case, you wouldn't want your family to have to suffer through any hassles and complications after you have passed away.

You should also consider the importance of being able to allow your loved ones to collect all the data you left behind. This means photos and experiences that can be used to show other generations the way that you lived and the kind of things you enjoyed doing.

Those memories are now easier to keep and the best photos can be downloaded for the purpose of printing them for photo albums or frames. Allowing them to have the chance to do this in a practical way is going to be a great gesture and securing any profitable information is going to be essential if you want a business or idea to keep moving forward with the help of those you trust.

This is the reason why you need to be able to pass your online account information after death, but no one wants to give access to this kind of information to their loved ones because it's of a private nature and we would feel uneasy knowing that others can access our private conversations or message.

Related word

gonzalo garcia

Why/What Blockchain Exploitation?

In this blog series we will analyze blockchain vulnerabilities and exploit them ourselves in various lab and development environments. If you would like to stay up to date on new posts follow and subscribe to the following:
Twitter: @ficti0n

Youtube: https://www.youtube.com/c/ConsoleCowboys
URL: http://cclabs.io
http://consolecowboys.com

As of late I have been un-naturally obsessed with blockchains and crypto currency. With that obsession comes the normal curiosity of "How do I hack this and steal all the monies?"

However, as usual I could not find any actual walk thorough or solid examples of actually exploiting real code live. Just theory and half way explained examples.

That question with labs is exactly what we are going to cover in this series, starting with the topic title above of Re-Entrancy attacks which allow an attacker to siphon out all of the money held within a smart contract, far beyond that of their own contribution to the contract.

This will be a lab based series and I will show you how to use demo the code within various test environments and local environments in order to perform and re-create each attacks for yourself.

Note: As usual this is live ongoing research and info will be released as it is coded and exploited.

If you are bored of reading already and just want to watch videos for this info or are only here for the demos and labs check out the first set of videos in the series at the link below and skip to the relevant parts for you, otherwise lets get into it:

Background Info:

This is a bit of a harder topic to write about considering most of my audience are hackers not Ethereum developers or blockchain architects. So you may not know what a smart contract is nor how it is situated within the blockchain development model. So I am going to cover a little bit of context to help with understanding. I will cover the bare minimum needed as an attacker.

A Standard Application Model:

In client server we generally have the following:
Front End - what the user sees (HTML Etc)
Server Side - code that handles business logic
Back End - Your database for example MySQL

A Decentralized Application Model:

Now with a Decentralized applications (DAPP) on the blockchain you have similar front end server side technology however

Smart contracts are your access into the blockchain.
Your smart contract is kind of like an API
Essentially DAPPs are Ethereum enabled applications using smart contracts as an API to the blockchain data ledger
DAPPs can be banking applications, wallets, video games etc.

A blockchain is a trust-less peer to peer decentralized database or ledger

The back-end is distributed across thousands of nodes in its entirety on each node. Meaning every single node has a Full "database" of information called a ledger. The second difference is that this ledger is immutable, meaning once data goes in, data cannot be changed. This will come into play later in this discussion about smart contracts.

Consensus:

The blockchain of these decentralized ledgers is synchronized by a consensus mechanism you may be familiar with called "mining" or more accurately, proof of work or optionally Proof of stake.

Proof of stake is simply staking large sums of coins which are at risk of loss if one were to perform a malicious action while helping to perform consensus of data.

Much like proof of stake, proof of work(mining) validates hashing calculations to come to a consensus but instead of loss of coins there is a loss of energy, which costs money, without reward if malicious actions were to take place.

Each block contains transactions from the transaction pool combined with a nonce that meets the difficulty requirements. Once a block is found and accepted it places them on the blockchain in which more then half of the network must reach a consensus on.

The point is that no central authority controls the nodes or can shut them down. Instead there is consensus from all nodes using either proof of work or proof of stake. They are spread across the whole world leaving a single centralized jurisdiction as an impossibility.

Things to Note:

First Note: Immutability

So, the thing to note is that our smart contracts are located on the blockchain
And the blockchain is immutable
This means an Agile development model is not going to work once a contract is deployed.
This means that updates to contracts is next to impossible
All you can really do is create a kill-switch or fail safe functions to disable and execute some actions if something goes wrong before going permanently dormant.
If you don't include a kill switch the contract is open and available and you can't remove it

Second Note: Code Is Open Source

Smart Contracts are generally open source
Which means people like ourselves are manually bug hunting smart contracts and running static analysis tools against smart contract code looking for bugs.

When issues are found the only course of action is:

Kill the current contract which stays on the blockchain
Then deploy a whole new version.
If there is no killSwitch the contract will be available forever.

Now I know what you're thinking, these things are ripe for exploitation.

And you would be correct based on the 3rd note

Third Note: Security in the development process is lacking

Many contracts and projects do not even think about and SDLC.
They rarely add penetration testing and vulnerability testing in the development stages if at all
At best there is a bug bounty before the release of their main-nets
Which usually get hacked to hell and delayed because of it.
Things are getting better but they are still behind the curve, as the technology is new and blockchain mostly developers and marketers. Not hackers or security testers.

Forth Note: Potential Data Exposure via Future Broken Crypto

If sensitive data is placed on the blockchain it is there forever
Which means that if a cryptographic algorithm is broken anything which is encrypted with that algorithm is now accessible
We all know that algorithms are eventually broken!
So its always advisable to keep sensitive data hashed for integrity on the blockchain but not actually stored on the blockchain directly

Exploitation of Re-Entrancy Vulnerabilities:

With a bit of the background out of the way let's get into the first attack in this series.

Re-Entrancy attacks allow an attacker to create a re-cursive loop within a contract by having the contract call the target function rather than a single request from a user. Instead the request comes from the attackers contract which does not let the target contracts execution complete until the tasks intended by the attacker are complete. Usually this task will be draining the money out of the contract until all of the money for every user is in the attackers account.

Example Scenario:

Let's say that you are using a bank and you have deposited 100 dollars into your bank account. Now when you withdraw your money from your bank account the bank account first sends you 100 dollars before updating your account balance.

Well what if when you received your 100 dollars, it was sent to malicious code that called the withdraw function again not letting the initial target deduct your balance ?

With this scenario you could then request 100 dollars, then request 100 again and you now have 200 dollars sent to you from the bank. But 50% of that money is not yours. It's from the whole collection of money that the bank is tasked to maintain for its accounts.

Ok that's pretty cool, but what if that was in a re-cursive loop that did not BREAK until all accounts at the bank were empty?

That is Re-Entrancy in a nutshell. So let's look at some code.

Example Target Code:

function withdraw(uint withdrawAmount) public returns (uint) {

1. require(withdrawAmount <= balances[msg.sender]);

2. require(msg.sender.call.value(withdrawAmount)());

3. balances[msg.sender] -= withdrawAmount;

4. return balances[msg.sender];

}

Line 1: Checks that you are only withdrawing the amount you have in your account or sends back an error.

Line 2: Sends your requested amount to the address the requested that withdrawal.

Line 3: Deducts the amount you withdrew from your account from your total balance.

Line 4. Simply returns your current balance.

Ok this all seems logical.. however the issue is in Line 2 - Line 3. The balance is being sent back to you before the balance is deducted. So if you were to call this from a piece of code which just accepts anything which is sent to it, but then re-calls the withdraw function you have a problem as it never gets to Line 3 which deducts the balance from your total. This means that Line 1 will always have enough money to keep withdrawing.

Let's take a look at how we would do that:

Example Attacking Code:

function attack() public payable {

1. bankAddress.withdraw(amount);

}

2. function () public payable {

3. if (address(bankAddress).balance >= amount) {

4. bankAddress.withdraw(amount);

}

Line 1: This function is calling the banks withdraw function with an amount less than the total in your account

Line 2: This second function is something called a fallback function. This function is used to accept payments that come into the contract when no function is specified. You will notice this function does not have a name but is set to payable.

Line 3: This line is checking that the target accounts balance is greater than the amount being withdrawn.

Line 4: Then again calling the withdraw function to continue the loop which will in turn be sent back to the fallback function and repeat lines over and over until the target contracts balance is less than the amount being requested.

Review the diagram above which shows the code paths between the target and attacking code. During this whole process the first code example from the withdraw function is only ever getting to lines 1-2 until the bank is drained of money. It never actually deducts your requested amount until the end when the full contract balance is lower then your withdraw amount. At this point it's too late and there is no money left in the contract.

Setting up a Lab Environment and coding your Attack:

Hopefully that all made sense. If you watch the videos associated with this blog you will see it all in action. We will now analyze code of a simple smart contract banking application. We will interface with this contract via our own smart contract we code manually and turn into an exploit to take advantage of the vulnerability.

Download the target code from the following link:

https://github.com/cclabsInc/BlockChainExploitation

Then lets open up an online ethereum development platform at the following link where we will begin analyzing and exploiting smart contracts in real time in the video below:

https://remix.ethereum.org

Coding your Exploit and Interfacing with a Contract Programmatically:

The rest of this blog will continue in the video below where we will manually code an interface to a full smart contract and write an exploit to take advantage of a Re-Entrency Vulnerability:

Conclusion:

In this smart contract exploit writing intro we showed a vulnerability that allowed for re entry to a contract in a recursive loop. We then manually created an exploit to take advantage of the vulnerability. This is just the beginning, as this series progresses you will see other types of vulnerabilities and have the ability to code and exploit them yourself. On this journey through the decentralized world you will learn how to code and craft exploits in solidity using various development environments and test nets.

More information

gonzalo garcia

Gotanda is OSINT(Open Source Intelligence) Web Extension for Firefox/Chrome.

This Web Extension could search OSINT information from some IOC in web page.(IP,Domain,URL,SNS...etc)

This Repository partly the studying and JavaScript practice.

Download link below.

Usage

Right click highlighted IOC strings, It will show contextmenus.(Or right clicking any link. )

When You want to search using some engine, You choose one of list.

Search Engine List

Name	URL	Category
Domain Tools	https://whois.domaintools.com/	whois Lookup
Security Trails	https://securitytrails.com/	whois lookup
whoisds	https://whoisds.com/	whois lookup
ThreatCrowd	https://www.threatcrowd.org/	Domain, IPv4
AbuseIPDB	https://www.abuseipdb.com/	IPv4
HackerTarget	https://hackertarget.com/	IPv4
Censys	https://censys.io/	IP, Domain
Shodan	https://shodan.io/	IP, Domain
FOFA	https://fofa.so/	IP, Domain
VirusTotal	https://virustotal.com/	IP, Domain, URL,Hash
GreyNoise	https://viz.greynoise.io/	IPv4
IPAlyzer	https://ipalyzer.com/	IPv4
Tor Relay Search	https://metrics.torproject.org/	IP,Domain
Domain Watch	https://domainwat.ch/	Domain, Email,whois lookup
crt.sh	https://crt.sh/	SSL-certificate
SecurityHeaders	https://securityheaders.com/	URL, Domain
DNSlytics	https://dnslytics.com/	IPv4,IPv6,ASN
URLscan	https://urlscan.io/	URL
Ultratools	https://www.ultratools.com/	IPv6
Wayback Machine	https://web.archive.org	URL
aguse	https://www.aguse.jp/	URL
check-host	https://check-host.net/	URL
CIRCL	https://cve.circl.lu/	CVE
FortiGuard	https://fortiguard.com/	CVE
Sploitus	https://sploitus.com/	CVE
Vulmon	https://vulmon.com/	CVE
CXSecurity	https://cxsecurity.com/	CVE
Vulncode-DB	https://www.vulncode-db.com/	CVE
Malshare	https://malshare.com/	MD5 Hash
ThreatCrowd	https://www.threatcrowd.org/	IP,Domain
Hybrid Analysis	https://www.hybrid-analysis.com/	hash
Twitter	https://twitter.com/	SNS, w/TimeLine
Qiita	https://qiita.com	SNS
GitHub	https://github.com	SNS
Facebook	https://www.facebook.com/	SNS, w/TimeLine
Instagram	https://www.instagram.com/	SNS
LinkedIn	https://linkedin.com/	SNS
Pinterest	https://www.pinterest.jp	SNS
reddit	https://www.reddit.com/	SNS

About Twitter and FaceBook could search timeline with any words.

Misc

This extension is optimized for the Japanese environment.

Download Gotanda

Kapital constante

sábado, 3 de junio de 2023

How To Pass Your Online Accounts After Death – 3 Methods