Assuming UAC is enabled, does a non-administrator account offer any security improvements? I've been wondering: assuming a modern Windows edition (>= 7), and that UAC is enabled, what benefits are there if I additionally use the system as a standard user? From what I understand, the only difference is that instead of just clicking "yes" on the dialog, I'll have to provide an administrator password, but programs will still be prevented from administrative actions without my consent because of UAC.

The DFIR Blog has a great summary of UAC

In the article, the author recommends the Always Notify approach, especially for administrators and critical servers. Besides social-engineering attacks such as the exploits/windows/local/ask module in the metasploit-framework, there are also tens of UAC bypasses. The author covers the techniques and tools to bypass UAC better than most.

The author does not make mention to, and I do not know of a tool or technique to bypass Always Notify -- however, escalation of privilege -- especially to the SYSTEM account -- may be possible through a privilege-escalation exploit and/or a misconfiguration issue (although any-given privesc exploit must not require administrator privileges, which is not necessarily rare, but a condition that must exist for some exploits to work). Misconfigurations typically include UNC path and/or file/folder/service permission issues. Typically, these privilege escalation techniques require an advanced understanding of the Windows environment that even most NT administrators do not posses, however, again, some are available in the metasploit-framework and other exploitation engines (or bundled with exploit kits) -- thus lowering the barrier to entry to anyone with adversarial intent. Other times, admins or admin tools simply leave password in cleartext (or an easily-reversible format) in files on the operating system, on a sticky note, or other lowered-care OPSEC.

Most end users will revolt against Always Notify, but perhaps not the next-lower setting, the medium-integrity process (which many UAC-bypass techniques work against).

As for local or domain administrator accounts for end user machines, it's very bad practice, as users can simply right click any executable and choose "Run As Administrator" to elevate privileges and destroy the power of UAC (N.B., this can also be done via cmd.exe if a separate admin account password is known by any end user). A lot of malware, especially persistence techniques, rely on administrator access (e.g., for Windows service installation). If UAC must be set to something lower than Always Notify, the best strategy is to also disallow any administrator access (privileged access) and provide additional protections against end-user app installation. My favorite platform for Privileged Identity Management is STEALTHbits and this can be combined with BeyondTrust and other privilege-management solutions.

As an additional protection for non-administrator accounts, the permissions on the user-specific AppData\LocalLow folders also allow malware to activate and persist. Another one to look out for is that some orgs will set the AlwaysInstallElevated registry key to allow non-admins to install applications. However, MSI's elevated privileges can be abused and there is even a metasploit-framework module to do so (i.e., exploits/windows/local/always_install_elevated).

Another distinction to make is for elevation prompts (apps can be written to automatically prompt, but UAC behavior can override/preempt this capability). The book Least Privilege Security for Windows 7, Vista and XP covers this and says:

  Microsoft recommends that in corporate environments, system administrators should configure UAC to automatically deny elevation requests using the User Account Control: Behavior of the elevation prompt for standard users local or Group Policy setting. This ensures that malware can't intercept an elevation prompt and harvest the credentials of an admin account.


Can isolated forms be dangerous for my server security? I'm learning PHP and at the same time I write the examples that I get from the book to .php pages to test them and eventually publish them. My concern is about a bunch of forms that are there to test the codes; these are very basic forms that have no validation code and I would like to know if someone could do bad things into my files/hosting by injecting codes on them. Actually these forms do not point to any important data, they are only there to write on the webpage itself but without saving any information, but I have this concern since I have no knowledge of these web languages.

Your main concern, if you can use these scripts to "write back" to the page, is Cross-Site Scripting (XSS). You should also be aware that just because you don't link to a file, doesn't mean someone won't find it on your site. There are tools (e.g. dirbuster) that can brute-force file and directory names on web servers to find interesting things like admin scripts.

Bottom line: don't put test data on your production server, or, if you absolutely must, at least put the scripts in a directory protected by a password (e.g. htpasswd for Apache).

EDIT: Adnan points out that you want to execute arbitrary PHP code on your server, submitted by users. That's the definition of a horrible security hole. The way that other sites get around it is via heavily sandboxing the PHP installation and blacklisting risky commands, but even then it's not perfect. My suggestion? Don't try to do this if you don't have a lot of experience in PHP, Linux administration, and security.


How to get URL behind REST-style I've asked same question on StackOverflow but topic passed away with no answers except few comments so I'll try to ask the same question here as it's probably more specific to security. The only (possible) duplicate I found is one here and here. Additionally, first question is pointed up to Apache and .htaccess (rewrite rule to hide file extension). The second question is more pointed to doing direct SQL injection to a specific rest-styled website and not gathering URLs behind it.

My question:

Is there any way an attacker may find out what is behind REST-style URLs? For example, SWIM have a user "eg", located in database, which he query from mode.php. After query is done, the page print "eg" on website.

http://example.com/mode.php?user=eg

SWIM CMS use REST-style technique and while user is browsing SWIMs website, user can't see the parameters nor file which is being proceed. An example is shown below.

http://example.com/mode/user/eg

Is there a way an attacker may find out what is hiding behind /mode/user/eg and by that chance try to exploit web-application using either injection or any type of attack. For example, if he founds out that the real URL is as in first example where parameter and it's value are visible, he may try doing SQL injection.

References:
*http://en.wikipedia.org/wiki/Representational_state_transfer
http://en.wikipedia.org/wiki/SQL_injection
SWIM = Someone who isn't me

The use of a REST style URL is unlikely to deter an attacker as it is a relatively well known development pattern these days with a number of popular frameworks using it.

When I'm testing REST based apps (usually pretty easy to spot due to the URL format) I'd always fuzz the URL paths (so, eg, user and mode) in this example as it's expected that they're going to be transformed in someway server-side.

Tools like burp have specific options which can be set on their scanning engines to target REST style apps.

From the BURP Help File

  REST-style URL parameters - The values of all directory and filename tokens within the file path portion of the URL. Testing each of these insertion points can impose a significant overhead and should only be used if you believe the application is using these locations to transmit parameter data.


Should I be concerned if the "FBI" has logged onto my Ubuntu VPS? Yesterday, I was performing a bit of general maintenance on a VPS of mine, using the IPMI console my host provided.

Upon setting up SSH keys again via the IPMI console, I logged in via SSH and was shocked to see this:

Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 2.6.32-042stab116.2 x86_64)
Documentation:  https://help.ubuntu.com/
Last login: Sat Sep 17 04:39:57 2016 from ic.fbi.gov

Immediately, I contacted my hosting company. They said that they didn't know why this might be, and that it's possible the hostname was spoofed.

I did a bit more digging, and resolved ic.fbi.gov to an IP address.

I then ran this on the system:

last -i

This returned my IP address, and then two other IP addresses which were unknown to me. I geoIP'd these two IP addresses. One of them was a VPN and the other was a server from a hosting company in the state of Washington.

Again, the IP that I resolved ic.fbi.gov to was not on the list.

Do you think I should be concerned/worried about the "FBI" obtaining access to my VPS? Or is it just a hacker that spoofed the hostname?

An IP address can be set up in DNS to resolve to any host name, by whoever is in control of that IP address.

For example, if I am in control of the netblock 203.0.113.128/28, then I can set up 203.0.113.130 to reverse-resolve to presidential-desktop.oval-office.whitehouse.gov. I don't need control of whitehouse.gov to do this, though it can help in some situations (particularly, with any software that checks to make sure reverse and forward resolution matches). That wouldn't mean that the president of the United States logged into your VPS.

If someone has access to your system, they can change the resolver configuration which will effectively enable them to resolve any name to any IP address, or any IP address to any name. (If they have that level of access, they can wreak all kinds of other havoc with your system as well.)

Unless and until you verify that the IP address that was used to log in actually is registered to the FBI, don't worry about the host name being one under fbi.gov. That name mapping may very well be faked. Worry instead that there has been a successful login to your account that you cannot explain, from an IP address that you don't recognize.

Chances are that if the FBI wanted the data on your VPS, they would use a somewhat less obvious approach to get it.

You should worry, but not about the fbi.gov hostname.

Go read How do I deal with a compromised server? on Server Fault, and How do you explain the necessity of “nuke it from orbit” to management and users? here on Information Security. Really, do it. Do it now; don't put it off.


Distributing private PKI CA Cert with public SSL CA? Any point? Disclaimer. I'm not even sure if the question is worded correctly in the title. Neither am I sure if I'm asking the right question. If there's literature relevant to this topic, it'd be greatly appreciated.

I'm looking at hashicorp vault to facilitate certificate signing / authentication etc. One thing that bugs me is securing the distribution of the root CA cert and signing.

Basically Vault has to be secured using SSL. If the internet CA's private key is compromised, there's no point to using Vault (Or any PKI process that relies on internet CA) if the attacker decide to MITM and switch the distributed cert.

I guess the question is:

Is there any point or significant gain in setting up a private PKI that relies on the public PKI for signing/distribution?

The main drawback to issuing your own root certificate is that you will have to install it in each browser and OS in your organization.  Depending on how many computers you're dealing with, and what kinds of computers they are, that could be a lot of work.  (IoT devices may not have a good way to update their trusted root certificates, for example.)  Also, be aware that installing a trusted root certificate in a machine means that machine is exposed during the installation process - a poor certificate distribution process could create a vulnerability for a rogue certificate to be installed.

Depending on your usage model and security policies, you may also have to provide a way for users who bring their own devices (BYOD) to download and install the certificate on their machines.

Another drawback of creating your own is maintenance complexity.  Just whipping up a new cert with openssl is pretty easy, but you have to plan in advance to secure the private key, get it backed up and all copies stored safely offline, etc.  Keeping the copies somewhere safe for 20 years can actually be quite a challenge (would you still have a way to recover an image from a 20-year-old floppy disk today?  In 20 years, will you still have a way to read a 20-year-old CD-ROM?)  You also need to document this fully, so that 20 years from now when this root certificate expires, the next CA admin will know how to spin up a new certificate, secure it, and distribute it.  In 19 years, who is going to notify management that their old root CA is going to expire?

PKI experts are few and far between, so finding one when you need one can be a challenge for a smaller organization.  You may need to bring in an expensive consultant to help get it set up securely.

You'll also want to provide a OCSP server, or at least host a CRL somewhere (although you'll need that anyway).

The advantages of signing with the public cert is that the public cert is already built into all commercial and open source browsers.  The main disadvantage is cost: the commercial CAs are likely to charge you a premium for a certificate with CSA authority.

Another advantage of the public certificate is that your certificates will work outside of your organization.  You won't have to distribute your internal root certificate to your vendors and partners, who won't want to install your cert because they'll have little reason to trust your PKI is safe.  Of course, you can get around this even with a private PKI simply by purchasing a few externally signed certificates for those machines your partners connect to.

All in all, building your own PKI leaves you fully in charge of your destiny, which can be a good thing.  Just make sure you're good enough to be safe, because you're dealing with the security of your entire organization's computing infrastructure for the next 20 years.  Don't design it alone, and make sure you get executive level approval on whatever decision you make.


Can a RootCA be revoked? I have created a New Trusted certification authority which issues certificate to the end entity and the end entity will use this certificate as trusted one for all their PKI operations. Some how the Root CA Key got compromised.

Now my question here is how can I revoke the ROOT CA as its a self -signed ?

Revocation really is cancelling the certificate issuance -- the CA which has signed the certificate announces that it now denies it. A root CA being self-issued, it cannot be revoked. A root CA, by definition, is trusted a priori, not because its certificate was signed by some higher-placed CA in the hierarchy. Thus, there is nobody to emit revocation information that would be authoritative on that CA.

Some extra comments must be made, though:

You do not revoke a CA; you revoke a certificate. Any entity that has a name and owns a key pair, in particular a CA, may own several certificates. Each certificate is an assertion of that key ownership. What you think as a "root CA" may also be an intermediate CA in the following sense: besides its self-issued (traditionally self-signed) certificate, it may also have obtained another certificate that contains its name and its public key, and issued (signed) by another CA. The latter certificate, being issued by a distinct CA, can be revoked. This kind of situation is common in case of "root CA renewal" (a new root CA is created, and "cross-certificates" are issued so that the transition is smooth).
What certificates cannot do, maybe other systems can. For instance, a Web browser may contain a list of a priori trusted root CA (for validation of SSL server certificates); then, any update of the browser executable may add or remove root CA. There is no CRL involved, but it sure looks like a revocation mechanism, especially since modern browsers update themselves automatically. Windows has a similar system with a "disallowed" certificate store that acts like an OS-enforced, super-CRL which can make any certificate untrusted, even root CA certificates explicitly added to the store of trusted roots.

Trying to make a CRL containing the serial number of the compromised root, as was suggested in another answer, will not have the intended effect, for two reasons:

Systems that validate certificates (e.g. SSL clients when trying to verify the server's certificate) download CRL only for certificates where it makes sense, i.e. not for root CA, since they cannot verify the signature on the CRL save relatively to the public-key of the CA higher in the chain, since there is no such CA. You can write what you want in any CRL; if clients don't look at it, it won't get you far.
Even if you could somehow convince a client to download that "suicide CRL", where the root CA kills itself, remember that the private key have been compromised, thus the key thief may produce and sign a counter-CRL that says that everything is fine and nobody is revoked. Since the CRL download cannot be otherwise protected, the attacker can prevent that self-destruction mechanism to happen, even assuming that it would have worked with existing clients (and it does not).


how can you view an HTTP request in transit? In Google Chrome, sometimes you will see the https: protocol in the URL bar with a red strike through it. Clicking on the info button says that not all elements on the page are encrypted, and may be viewed by others while in transit.

My question is: how can one view any/all requests while in transit? I have read a little about HTTP sniffers, but those seem to be inspecting incoming/outgoing requests from your own machine. How can you intercept a request out in the ether, in a particular network?

Packet Sniffers

Packet sniffers allow you to see everything that is travelling on the network. Wireshark is the most popular and free and is easy to download and install.

With a packet sniffer, you can read in plaintext anything that is not encrypted.

These require that you have access to the network where the communication is coming from (either server or host). You cannot read packets on a network that you do not have access to. That is why you have heard that they read what is coming from your own computer.

But, it is possible to gain access to other networks. Wifi (public or hacked private) is a popular and easy means of gaining access to other's network traffic. Some attackers go to great lengths to physically install sniffers in corporate networks so that they can access this type of data.

HTTPS

HTTPS encrypts information between a browser and the server so that sniffers cannot read the actual content of the communication. For a site that has a mix of HTTP and HTTPS content, parts of the communication will be readable, and some will not.

Testing

This is easy to test. Download and install Wireshark and start a capture. Then launch a web browser and navigate to a website that is not HTTPS. Stop the Wireshark capture, then look through the data. You will find the actual text of the website in the capture.

Try again on an HTTPS website (google, for instance) and you will see that you cannot read the text from the website.

Now try the whole process on a mixed website, and you will see what is encrypted and what is not. It is possible that ads and other 3rd party content has not been encrypted, for instance.

Impacts

Packet sniffers are the technical tools, but pre-packaged hacking tools use packet sniffers built into themselves to read this information and format it for malicious uses. Firesheep is the currently famous tool that can hijack someone's connection to Facebook and Twitter.


What risks do I have to consider when encrypting server side as opposed to client-side? I am looking at encrypting user data however performed on the server as opposed as on the client. What risks do I have to consider and if so how do I limit such risks? The reason we are looking at server side encryption is to limit exposure on the client side to trojans, key loggers, etc

EDIT

The data would be sent over SSL and then encrypted on the server. This would limit or alleviate any sniffing.

The term data is also used to describe files, etc

You say you want to use server-side encryption to limit exposure to client-side malware.  That makes no sense.  If there is malware or spyware on the client, then you are hosed either way.  Encrypting on the server doesn't help, since the data still exists in cleartext on the client, and so the client-side malware/spyware can capture the cleartext data.

I think you need to revisit your requirements and your approach.  If you are worried about client-side malware, I can see only two options: (1) ensure that sensitive data never reaches the client in cleartext, or (2) implement defenses to reduce the likelihood of malware on the client side.  Encrypting on the server side doesn't really help.

Sending the data from the client to the server and then encrypting on the server has all the security risks of client-side encryption, plus some additional risks:

If the server is compromised, or if any of the accounts of your employees are compromised, then the attacker gets access to the data.  (Twitter got hosed by the latter.  Many companies have gotten hosed by the former.)
Because you technically have the ability to decrypt the data, it now means you can be subject to subpoenas, warrants, or demands from law enforcement to decrypt the data if they want/need access.  If you are a small operation, this might not be a big deal, but at a big operation, this might start to create some compliance costs for you.
If the attacker can mount a man-in-the-middle attack (e.g., attacking a user who is connecting over open wifi), and if the user clients through SSL cert warnings, then the attacker can gain access to the sensitive data.

One advantage of server-side encryption is that it enables you to do key management on the server side, reducing the burden on users.  For instance, if users lose or forget their keys, you can recover it for them.

Another possible advantage of server-side encryption is that the time window when the data exists on the client side in cleartext might be reduced, which might reduce the exposure to data breaches if, e.g., the client machine is stolen or lost.  However this advantage may be fairly modest in practice, and there may be better solutions to this issue (e.g., full-disk encryption).


Linux password changed. Is this an attack or a hardware glitch? My Linux (Ubuntu 12.04) password suddenly changed last night and I'm not sure if this is an attack or just a hardware/user error. This is on a personal/non-server box. Several strange events led up to it, enumerated below:

While browsing web pages, I can't seem to scroll down. My right hand was on my mouse, left eating food so I'm sure I'm not accidentally pressing any keys. I ran showkey and discovered that every now and then, I'd get spammed by keycode 104 events. 104 seems to be Pg Up.
Then it happened that I can't seem to get my password right when invoking sudo commands. However, I can get sudo to authenticate if I copy-paste my password.
I got suspicious at this point and checked if there are any unwanted log-ins in my box. who command returns as expected (i.e., only me and my open terminals) and sshd is not running nor can I access port 22 (via telnet).
Eventually, I locked my screen and, when I returned, I was prompted for a password and I can't enter it properly anymore.
My machine is dual-boot with Windows 8. I try to log-in to Windows 8 and, when I enter my password, I seem to notice that, when I enter my password (19 chars long, same as Ubuntu's), the cursor suddenly shifts to the first character. So, for instance, if my password is "password", entering it straight out it becomes "dpasswor". This got me a few times until I observed the behavior. It helps that Windows 8 allows you the option to see the password you type. You can still edit it though and log-in to Windows just fine.

This is not the first time that my keyboard glitched like this. Last year, it was the direction buttons that was spamming signals. What particularly bothers me is that I got locked out of my machine and that it seemed to change my password and introduce all that weird behavior.

I left it over night and woke up today to address the issue. Windows is no longer displaying the weird behavior of the last bullet. I have been able to reset my Linux password (to something shorter for the meantime). who and telnet/ssh is same as ever and I no longer seem to observe the unwanted keypress 104 signals. Are there any further steps you advise me to take?

While browsing web pages, I can't seem to scroll down. My right hand
  was on my mouse, left eating food so I'm sure I'm not accidentally
  pressing any keys. I ran showkey and discovered that every now and
  then, I'd get spammed by keycode 104 events. 104 seems to be Pg Up.

  I try to log-in to Windows 8 and, when I enter my password, I seem to
  notice that, when I enter my password (19 chars long, same as
  Ubuntu's), the cursor suddenly shifts to the first character. So, for
  instance, if my password is "password", entering it straight out it
  becomes "dpasswor".

Any more questions? :) There is either food stuck below the PgUp key or it is an electronic problem like a hair-line crack on the motherboard.

How this could affect your password file is mysterious, but maybe it didn't and it jumped around too? More probable the PgUp keystroke got interpreted as part of the password.


Difference between Run and Exploit When using Metasploit for running exploits you have two options:

run
exploit

what is the difference between these two commands?

There is no differences, as exploit is an alias to run:

Auxiliary Commands
==================

    Command       Description
    -------       -----------
    check         Check to see if a target is vulnerable
    exploit       This is an alias for the run command
    pry           Open a Pry session on the current module
    rcheck        Reloads the module and checks if the target is vulnerable
    recheck       This is an alias for the rcheck command
    reload        Reloads the auxiliary module
    rerun         Reloads and launches the auxiliary module
    rexploit      This is an alias for the rerun command
    run           Launches the auxiliary module

... and:

> help exploit
Usage: run [options]

Launches an auxiliary module.
...

like:
    rexploit is an alias for the rerun command.


Can deliberately low-entropy hashes be used to prevent dictionary attacks? Consider a system that receives, but does not store, a piece of sensitive information X from a user. If I wanted to add a way to remember when a user has submitted the same X more than once, what would be the most secure way to do so? X is used for no other purpose; it is not a password.

The obvious but insecure approach would be store all submissions of X and check for duplicates. One way to make this more secure would be to compute a verifier (bcrypt or similar) of submissions. Properly generated, my understanding is that this would defeat precached attacks with rainbow tables.

My concern is with dictionary attacks. If X is relatively guessable, a determined attacker can probably make slow but steady progress against the verifier. One solution to this is to deliberately truncate the verifier to increase the number of possible plaintexts that it matches. Because X is not a password, it should be OK to increase the number of false positives (a duplicate detected when there is none). But on the attacker side, they may find that it's easy to find a matching plaintext, but there are so many of them that it's impossible to tell which one is the original.

In other words, if the verifier entropy is significantly less than the plaintext entropy, the set of all plaintexts that match a given verifier should be much larger than if the entropies were of comparable size. Then it's impossible to tell which plaintext is the original.

Is this a valid approach? Or is it overkill if the verifier is computed using a slow algorithm like bcrypt?

You said that you allow ''X'' to have false-positives. Therefore you can simply strip much entropy and allow false-positives, but attacker would face same problem if he got your database.

But if ''X'' has enough entropy on it's own (128-bit or 256-bit), attacker won't be able to get any more information from hash (for example using SHA-256 or SHA-3), and you wouldn't have false-positives. Hash would exactly only allow this one information - is new information I got same as this one.

If your ''X'' doesn't have enough entropy and/or you accept risk of having false-positives, then you can cut on your hash too (then it becomes how many false-positives you accept to have).

On the other hand when using bcrypt and other PKDF, I find that you will quickly lock yourself out of the information. Assuming information ''a'' was to arrive to you, you had no other choice than to iterate over every bcrypt hash stored and check if it is ''a'', which (as PKDFs are slow) would be inefficient to check.

Also, remember that weak point of system that only passes some confidential information is an active attacker - then he can simply store every ''X'' your service got since it was hacked.


How can Remote Code Execution in Unity infect me? There is a Remote Code Execution Vulnerability in Unity, it sounds like a vulnerability that someone can infect you after they trick you click something, I guess. So assume I hadn't installed the patch, and I worked on a local project (one man project) on my computer (I still used the internet) and I wouldn't install any asset to my project (I just self made the asset), I only connected my work to github, private Repository. Could I get infected?

A tough question to answer. While it's always safer to just update since a patch is available from the vendor + updating shouldn't be too much of a burden since it's just you working on your project. But nevertheless, let me try to lay out the facts.

There's no publicly available exploit - it doesn't look like the researcher or the vendor has provided much information regarding exploiting this vulnerability. All I could find was that there is an input string validation that leads to RCE. Know that the lack of an availabile exploit does reduce chances of exploits being found in the wild.
While I did not find any CVSS on the vendor's website, the NVD CVSS does indicate that this vulnerability can be exploited remotely. If this is true, then I assume that even if you are working alone, but connected to the internet, this vulnerability may be exploitable, hard to tell for sure without knowing the vulnerable component and how it works. That said, NVD CVSS is not 100% trustable in my opinion, but still a point to note when analyzing.
This is a rather old vulnerability and being an RCE, honestly, I'd just recommend patching up. The vendor did promise to release more information about it once they gave their customers time to update but still haven't (the vulnerability received a CVE in 2017). On the plus side, a tweet from the vulnerability finder did mention that they fixed it very quickly (kudos!). Alternatively, they have also released a mitigation tool for those versions that don't have a direct patch. Note - according to the vnedor, the mitigation tool is not a permanent solution and just disables the vulnerable component (check if this component is remotely accessible!).

Again, I'm just stating what's already known. When it comes to patching, other than any heavy effort/downtime, I would not weigh anything against updating (especially for security). If you're working standalone and it's easy to update, I would always advocate patching up :)


Is AES 128 encryption weak for very small payload size? If I have a payload of e.g. 8 bits and I want to encrypt it using AES 128, I will need to add some random padding to make the plaintext 128 bits long. Does this padding affect the security of AES?

Since AES is a block cipher with 128-bit blocks, it can, by definition, process only a 128-bit entry. To turn it into a system that can encrypt and decrypt messages of arbitrary length, then you need to use a mode of operation. Each mode has its own requirements. Most will require an IV which MUST NOT be reused (if you encrypted several messages with the same key, each message needs its own specific IV), and some modes have extra requirements (e.g. in CBC, it is crucial that the IV are selected randomly, uniformly, and in a way that cannot predicted by whoever chooses the data to encrypt).

Some modes also require "padding" in case the input message length is not appropriate in some way. Some modes can process input data of arbitrary length (e.g. CTR), while others need the data to have a length that is a multiple of the block length (e.g. CBC).

Most attack models that warrant encryption may easily be turned into active attack models, in which the attacker not only wants to inspect the data, but he also may modify the data. Thus, whenever you use encryption, you normally need integrity as well. Combining encryption and a MAC is a non-trivial task, so using a mode which combines both features is highly recommended. The most standard mode that combines encryption and MAC safely is, as of early 2016, GCM.

If you do everything correctly, then there is no additional issue with the input data being short. Short data is common in, e.g., SSH connections.

Note, though, that while encryption protects the data contents, it tends to leak the data length. Depending on the kind of data that you are sending, its length might reveal a lot of information to outsiders.

Don't use random padding. Random padding cannot be checked at the decryption side, because it can be anything. Random padding gives extra power to active attackers (in SSL/TLS, see the POODLE attack, which leverages random padding in SSL 3.0). Instead, if padding is necessary, use a deterministic padding that the receiver can check. A mode that does not require padding is preferable, because it is easier to process it correctly on the decrypting side (i.e. without leaking information when an invalid message is sent).

Summary: use GCM.


Are e-mail accounts considered generally insecure to receive sensitive information? Are e-mail boxes generally considered insecure and not good enough to store sensitive information?  Every month several hundred e-mail accounts get hacked.

what is the general view here? Is it not the responsibility of the owner to secure his e-mail box?  Or, is it an expectation for the software solution that uses the e-mail address to communicate sensitive information to provide additional layers of security?

In the internet, most of the cloud services use the reset password mechanisms almost always end up using the e-mail mechanism. How is this considered secure?

Email as a communication medium is generally considered to be insecure; the core protocols were not designed with security in place, and while secure protocols have since been layered on top of it, the nature of email means it has to be designed to "fail open" - everyone expects their email service to be able to send to anyone with a valid email address, so if they don't support TLS then you can't use it. And of course there is the problem of forwarding: once you send me an email with sensitive data in it you have lost control of it. I can forward it or print it out.

Your question mostly comes at it from a slightly different perspective - what about the email mailbox as a secure place to store data. There's not really an answer to that one, as different pieces of email software store the mailbox differently. Most of the modern ones will use decent technology to secure the actual mailbox database. On the other hand, the most popular cloud email services all make their money by reading your email and using the information to sell targeted advertising, which is not good for security.

In general, email accounts get hacked a lot because a) those are one of the best things to attack - "I rob banks because that's where they keep the money" and b) because they are secured with passwords and humans are rubbish at passwords. It's not really that they are inherently insecure.

Email based password resets are not ideal, but customers find them convenient, and they are cheap at scale, so we're stuck with them.


Is it possible for hackers hack my PC by creating fake AP that my PC probed I heard that hackers can create fake AP that my PC is probing. As soon as my PC found the Fake AP, it will connect automatically. So

To clarify, is it possible for hackers create the Fake AP that my PC is Probing, if they knew the type of security (Wpa/Wep) and the password for the genuine AP (Common; library wifi or Restaurant wifi that i had been using previously).
Is it possible for hackers to break in my PC while using the fake AP.

So basically, it is type of hacking other PC unconnected to any wifi. Is there such a thing?

If they know the SSID and the password then yes they can create a rogue AP that your PC will connect to.  As to the possibility of a "hack", there is a provision in Windows (and a similar feature in other OSes) to designate certain networks as trusted or untrusted.  This causes the local firewall to choose looser or more strict settings, respectively.  It is a good idea to implement this if you are connecting to public WiFi, which will protect your PC from basic intrusions. There is still the chance that a sophisticated attacker can intercept your communication and perform a complex man-in-the-middle, and the only way to guard against that is to use a well configured VPN session any time you are connected to a WiFi access point you don't fully control.


Where to find current information on cipher suite strength? I am hardening the configuration for my /etc/ssh/sshd_config and have a few choices for Ciphers:

aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc,arcfour

Of these, there are some I know not to use, such as arcfour. Beyond that, I often have to search forums and blog posts to find out if a particular cipher suite is still strong. Sometimes this information can be out of date or inaccurate. I have a tough time trusting it.

Is there a reference or website that keeps up to date information on the relative strength of each cipher suite? Ideally, I'd like to know the current situation for both SSH and TLS settings. Also, is there any service that will notify you when the list changes (with the addition of a new cipher suite or the degradation of an old one).

Assuming I'm willing and able to upgrade at any point, I'd like to use the strongest and most secure settings available.

Many countries publish Security standards for cipher suited.
In US, you can rely on pci dss standard, fips 140-2, ANSI, EAL, etc.
In France we have the RGS which indicate the algorithms and key length which can be trusted and how many time we can rely on.
I guess every industrialized country has the same standard.
I personally choose to follow this website: https://syslink.pl/cipherlist/
It gathers best Security practices from many sources.


What are some ways to check for XSS (Cross-Site-Scripting) on a website? I believe I was a recent victim to an XSS script that gathered my cookies; however, I am not for sure certain. I am wondering if there is any way for me to check (I removed all my cookies). Another person I know went to the same website and received a warning, but this person also has a Unified Threat Management system which I do not have. Can an attacker still receive your cookies by inserting a XSS script on a HTTPS based website? How could they receive my credit card cookie details if the website is HTTPS based?

Any advice or answers will help, thanks.

I don't have a specific tool in mind but something that watched network traffic and identified cookies being sent to domains other than the issuer would detect the situation you describe.

As far as the question "Can an attacker still receive your cookies by inserting a XSS script on a HTTPS based website?" the answer is "Yes." There are a number of protections in modern browsers to help prevent this but unfortunately, none of the defaults, CORS being the major one I'm thinking of, prevent data being exfiltrated without at least some developer involvement.

The two major things a site developer should do to prevent cookie exfiltration are:

use the HttpOnly flag when setting a cookie, which instructs the browser to not provide access to the cookie in its JavaScript engine.
escape all input that's displayed back on a page. This prevents the initial insertion of potentially malicious javascript.


What consequences could there be to the continued use of an operating system without updating? As it is well known, the extended support of Windows 7 (Service Pack 1) ends on January 14, 2020. Due to the short time that remains, I raise this question.

What consequences could an outdated operating system without continued updates have?

Taking into account that:

Updated antivirus.
Firewall installed, updated and configured the rules for applications that are allowed to connect to the internet. In addition to this and as additional protection, having the file control of the firewall active (it warns against a change in key registry keys, connection to the network, use of the keyboard, etc).
Standard account for daily use. The administrator account, only to make installations and important modifications in the system.
Updated applications.

Even if I do not have the system updated and having all of this configured, what problems could it bring me?

Even if I do not have the system updated and having all of this configured, what problems could it bring me in the event that one is presented?

Lots of applications use the OS libraries and functions for doing mundane tasks, such as showing videos or pictures, or drawing a UI. A vulnerability in one of those libraries may affect your browser, even though the browser is fully updated.


I gave my cell number to a stranger on the internet. Have I fallen victim to a scam? I was playing an online game and I came in contact with this user. She was listed as from the same country as me (Egypt). So when she asked me for my cell phone number, I gave it to her. I figured it was to add me on WhatsApp so we can chat or something.

However, I instead received an SMS message (titled 'Telegram') with a number, and she asked me to tell her that number. I asked what it's for, she said that she's from Canada (not the country she listed on her avatar) and that she needs that code I received to connect with me, since I'm outside Canada.

At the same time, I received a phone call (no number appeared on my screen) with an automated message. I hung up before hearing that message.

I refused to give this girl the code I received via SMS and parted ways.

My questions:

Was this a scam?
If yes, did I prevent the scam by denying this user the code?
If not, what's at risk? Is my bank account at risk, for instance? (I
only gave the user my cell phone number. No name, no address,
nothing else whatsoever)
If I am at risk, what do I need to do to prevent any theft of my
information, passwords, money, etc.?

Let's go through the process of what actually happened:

Telegram requires a cell phone number to be linked in order to create an account.

To verify that the number exists, they send out a verification code for you to enter in the app while creating the account.

This person obviously didn't want their own cell phone number to be linked to the Telegram account, which is an indication they might use it in malicious ways (terrorism, hacking, …), so:

They tried to set you up to get that code.

So to answer your questions:

Was this a scam?

I'd call it gray zone. But yes, someone did try to scam you for a Telegram verification code.

If yes, did I prevent the scam by denying this user the code?

Yes, you did well, using common sense :-)

If not, what's at risk? Is my bank account at risk, for instance? (I only gave the user my cell phone number. No name, no address, nothing else whatsoever)

That depends, how visible are you on the internet? If you have domain names registered with that number, they can find that. Facebook linked? They can likely find that depending on privacy settings. In brief, if you've linked that number to a lot of accounts, they might find those accounts and the information that's publicly in them.

If I am at risk, what do I need to do to prevent any theft of my information, passwords, money, etc.?

"At risk" is a heavy word in this situation. They just want a Telegram account; I find it likely they just moved on to one of the other 50 people they PMed while talking to you.

Just keep an eye open for "strange things" (like hacking attempts to other accounts etc.), research yourself with that phone number and see if what you can find needs changing.


Enforcing software expiration on virtual machines It is possible for virtual machine guests to bypass the software expiration timers for paid software. This example shows one way to do this on VMWare. A simpler method is for the user to "revert to snapshot".

How can a software publisher still protect their content and enforce the expiration of the software installed on virtual machines? What can be done to maintain the state of elapsed time in spite of attempts by the user to modify the system time?

DRM is a notoriously difficult problem to solve. One should always assume that whatever code is in the hands of an uncontrolled client can never be fully protected.

One solution to the simple "rollback snapshot" bypass will be to have the client "dial home" to a server once in a while. Another good method can be to tie the license key to a user account and have the user authenticate whenever he wants to use the software.

However, this can still be bypassed by reverse engineering the binary and removing the portion of code that dials home. This is an unavoidable problem unless you want to host the bulk of the application on your servers and simply let the client be a "dumb client" that displays whatever the server tells it to. If this is acceptable to you, you might want to looking into providing a SaaS business model.


How to limit web API microservice communication to specific list of machines? I have an PHP API that I want to be consumed only by one static website.

However the HTTP is not secure as from what I suspect any header can be spoofed (IP - I may be wrong here, domain name, and so on), so what are my options to ensure that API request came from exactly that website?

The stack is Docker, Nginx, and PHP.
Both API and website have Let's Encrypt SSL certificate.

IP Spoofing, successful three way handshake (which used by TCP protocol) is not at everyone's fingertips. Yes TCP have security issues and also there is spoofing techniques but I believe your level of interest does not require that much attention. HTTP works over TCP.

Would you want to have one of the following solution.

If you are using a cloud provider, use their "security group" configuration for restricting access of website. Use outgoing ip address of that website. If this website is service provider, they will provide outgoing ip address.
If this application stored at a hosting firm, you don't have much choise, migrate this app to cloud or search for "php firewall"
If you have your dedicated server (virtual or not) and does not have firewall, you can check services like CloudFlare, Sucuri etc.
If you are looking for enterprise grade integration between them, deploy a tunnel for that communication (both parties need to install / configure)


Windows: Who is this randomname person that authored *my* LibreOffice document? A friend of mine for which I manage the computer has presented me a problem.
How is it possible that Windows shows a random name in field "Authors" for a given document ?

Here is a bit of context:

The computer is not shared with anyone.
The name of the Windows session is obviously not "JPDenis". We know no one bearing this name. The Window session as a password that is not the strongest but not the weakest either.
This file was not edited (or stored) on another computer.
This computer was mainly used inside his home, with a wifi network that as a good key, behind the internet provider's box.
I personally installed a fresh Windows 10 with a genuine ISO about 10 month ago. There is no antivirus on the computer, apart from "Windows Defender" (or something like that). No craky software is installed on the computer. Windows is up to date. I am quite sure I installed LibreOffice from a file downloaded at the official website. The browser is Firefox with almost no addons.
My friend is not a tech savy and installed very little software on the computer and none that I think could be harmful. He knows that suspiciously looking emails should not be opened.

My friend is quite upset about this strange thing. I will eventually Linux his computer but we would like to understand what could have happened.

Someone downloaded a word document and they might have used it as a template for their report. The author you are seeing would then be first author of the word document.


Can a laptop be monitored when booted from external drive? If a laptop is monitored (say from employer) and I boot it from an external USB hard drive or a LIVE-CD/USB-Stick, can it then still be monitored somehow?

While it is technically possible to do so, it would require modifying the device firmware to spy on the running operating system. The chances that your employer would do this are astronomically low.

It is feasible that some laptop manufacturer could design (or has already designed) firmware with a feature to log information about each booted machine, in which case you would need to disable that feature. I suggest you check your BIOS/UEFI to make sure you see nothing like that.


How secure is choosing one out of N generated passwords? I'm looking to generate some new passwords for myself that are easy to remember, but hard to crack. By choosing a generation algorithm and generating one random password with it, I can be relatively confident of how hard to crack my password is. (I can calculate its entropy.)

If, instead, I keep generating passwords until I see one I like, the security of my password is (significantly?) less. Worse, because I can't analyze my own mind like I could analyze an algorithm, I don't even know how insecure my password might be. It should be better (in terms of security) to control myself and say, before the password is generated, "whatever password is generated is the one I will use". But it might not be as easy a password to remember as "correct horse battery staple". It's hard to predict what will be easy/hard to memorize, and it can vary a lot from person to person.

What about a happy medium, where I decide that I will generate exactly N (for example, 10) random passwords, and choose one of them? Would this be any worse than "1/N times" secure?

one I like

That is the bane of precise entropy calculations: human psychology. It is hard to quantify precisely how much the attacker can model your aesthetic choice. There are two extremes:

The attacker may totally fail to guess what kind of password you like or don't like. In that case, your selection cannot be exploited by the attacker, and the entropy computation for the password generator is unchanged.
The attacker may have an accurate model of your brain, and precisely know what is a "likable" and an "unlikable". In that case, the attacker will try the most likable passwords first. In that case, the entropy, from the attacker's point of view, will be divided by at most N (if you express entropy as "bits", as is customary, then you will lose log N bits).

The reality will be somewhere between these two extremes. The cautious stance is to assume the worst. Thus, if you generate N = 16 passwords and allow the user the select one, then consider that you just lost 4 bits of entropy (because 16 = 24); in the "correct horse" method with four words from a list of 2048 words, hence 44 bits of entropy, you drop to 40 bits -- which is weaker but still quite decent, as passwords go.

At least it can be mathematically demonstrated that allowing a choice among N random passwords cannot reduce the entropy by more than a factor of N (i.e. you cannot lose more than log N bits that way).


glibc getaddrinfo (CVE-2015-7547) vulnerability: should I update glibc if I do not configure DNS? Recently Googly discover glibc getaddrinfo (CVE-2015-7547) vulnerability:
https://googleonlinesecurity.blogspot.co.il/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

We run our application on CentOS 6.
I found here the following:
https://rhn.redhat.com/errata/RHSA-2016-0225.html

Note: this issue is only exposed when libresolv is called from the
nss_dns NSS service module. (CVE-2015-7547)

Should I update glibc if I do not configure DNS?
I have the following in /etc/resolv.conf

nameserver 127.0.0.1

Should I update glibc if I disable DNS service?

  Should I update glibc if I enable DNS service?

The DNS service is about running your own DNS server. This bug is unrelated to this but is instead related to the DNS lookups done by the applications, i.e. your browser looking up the IP address of a site based on the hostname in the URL.
Thus yes, you need to update.

  Should I update glibc if I do not configure DNS? I have the following in /etc/resolv.conf

Unless the name server at 127.0.0.1 is a server which protects you this kind of attacks then you should update. Note that according to redhat the usual dnsmasq etc will probably not fully protect you:

  Can a trusted DNS resolver protect against this issue?
  A trusted resolver, in a default, protocol-compliant configuration, cannot mitigate this issue because potential exploits could involve syntactically well-formed DNS responses.


keys.openpgp.org keyserver fails to send confirmation mail to an Outlook-address I uploaded my master key's public part to the keys.openpgp.org-keyserver. It has 4 UIDs set up (4 different e-mail addresses) and each of them are correct and valid e-mail addresses.
The keyserver sent a confirmation mail to all of the e-mail addresses specified in my UIDs, but I did not receive a confirmation link on my outlook.de address. Of course, I checked junk folders etc., but there is simply nothing.
Since all other e-mail addresses could be successfully reached and thus verificated, I am now left with a certificate missing one entry - and this missing entry will likely lead to the removal of the certificate after 14 days.
Why did this happen? Is it because I altered my primary UID? Alphabetically sorted, the outlook.de-address would be the first one, but I manually overwrote this via gpg command line before submitting the  public cert to the keyserver.

From my experience it is not unusual for Microsoft Mail services (Hotmail, Outlook) to accept mails but then silently drop these if they look suspicious without any information to the sender or recipient. I don't think there is much you can do, except using a different mail provider.


What is the vulnerability in my PHP code? A website of mine was recently hacked. Although the actual website remain unchanged, they were somehow able to use the domain to create a link that re-directed to an ebay phishing scam.

I've taken the website down, for obvious reasons, so I can't link to the code. I'm wondering how I can go about finding out what vulnerability they used so that I can avoid this problem in the future. The page used PHP, and also some javascript (for form validation).

Is there a free service that will scan my code for vulnerabilities? What are my other options?

If anyone's willing to take the time to look it over, I will gladly .zip up the code and host it somewhere...

Thanks, Jeff

Free doesn't go far, but you can try running the following yourself:

The community edition of netsparker:  http://www.mavitunasecurity.com/communityedition/
skipfish:  http://code.google.com/p/skipfish/
And if you want to dig deeper & you're willing to spend a little time learning how to wield it, you can download and fire up Burp:  http://www.portswigger.net/burp/

The black box scanners listed above would likely catch the more obvious vulnerabilities (especially if you manually "crawl" your app to ensure the scanners test everything - each tool supports manual crawls, for example, https://netsparker.zendesk.com/entries/351851-manual-crawl-proxy-mode)

Also, you need to do validation on the client AND server:

  OWASP:  "Performing validation in client side code, generally JavaScript, provides no protection for server-side code. An attacker can simply disable JavaScript, use telnet, or use a security testing proxy such as WebScarab to bypass the client side validation."


When installing a new software repository, is it required to check the repository key fingerprint? I'm recording a video about installing some software from a vendor repository. At some point, I download the GPG key for the remote repository and check manually its fingerprint before adding key and the new repository to the list of trusted repositories for the current host:

REPO="https://download.docker.com/linux/debian"
# Download and check GPG key
# Expected fingerprint:
# 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88
curl -fsSL "${REPO}/gpg" > docker.debian.gpg
gpg --no-option \
    --with-fingerprint --keyid-format LONG \
    docker.debian.gpg

And only if the fingerprint matches, I continue the process:

# Add Docker repository
apt-key add docker.debian.gpg
add-apt-repository \
   "deb [arch=amd64] ${REPO} \
   $(lsb_release -cs) \
   stable"

(the code above is for Debian, but I follow the same pattern for CentOS/RedHat)

I feel like checking the key fingerprint is an important step to ensure we will not install a software from a subverted repository. But I'm not quite sure of myself: some other tutorials I saw seem to actually assume the repository key will be automagically checked at a later time.

So, in such case, what extra layer of security does that add to check the key fingerprint? What would be the risks of not doing that?

[I'm not an expert on apt or yum/dnf, so this is just an opinion.]

  some other tutorials I saw seem to actually assume the repository key will be automagically checked at a later time.

Checked against what? Against the same repository that gave it to you in the first place? If this happens to be a malicious repo, of course it's going to continue to tell you it's the real thing. There's no magic list somewhere of which keys are authentic for which repos. Well, actually there is, the list that ships with apt, but you're explicitly telling apt to modify that list.

My understanding of add-apt-repository is that once you add it, this becomes an anchor of trust against which to check all future signatures from this source. If it is malicious, then once you insert it into your trusted keys list you are open to receiving malicious / spoofed software from that developer.

Establishing trust

The real question is: where are you getting this from?

# Expected fingerprint
# 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88

If you got it from the same source that will be serving you the packages, or from a non-encrypted HTTP page, or from some sketchy blog, then that's not doing you much good.

Ideally you want to be getting the fingerprint "out of band", ie from a different source that you already have real-world trust in.


How does the Shellshock patch actually prevent the problem? I can't understand something about Shellshock bug - if these environmental functions (which declaration begins with "()" ) are executed on the shell start, how does the patch prevent the problem?

We can still set some function through HTTP headers, and the next time when on the server someone opens Terminal for example (when bash loads), the body of the function will be executed, even when the parser doesn't run arbitrary commands after the function body (like in unpatched version, where we invoke bash with 'bash -c :' and get the RCE immediately).

The name of the variable that holds the function shouldn't matter.

what is the difference if it will be 'x' or 'HTTP_COOKIE'?
Can someone explain me?

Bash has a feature whereby it interprets some environment variables as function definitions. For example, with the environment variable HTTP_COOKIE set to () { echo hello; }, bash parses the value of the variable as a function definition, as if the script had started with HTTP_COOKIE () { echo hello; }. The body of the function is not executed, unless the script calls HTTP_COOKIE as a command: it's the function definition that's executed.

The Shellshock vulnerability is due to interpreting the variables as more than function definitions. For example, if HTTP_COOKIE is set to () { echo hello; }; echo pwned, then bash parses and executes the function definition when it starts up, and happily goes on to execute the rest of the content of the variable, so it executes the instruction echo pwned.

With the Shellshock patch, only well-formed function definitions are accepted. A value like () { echo hello; }; echo pwned is rejected because it contains trailing code after the function definition.

The script must be written carefully and not use HTTP_COOKIE (or whatever variables have content that may be chosen by an adversary) as a command name. Only variable names that are used as command names by the script can lead to code injection: variable names that are used as variables or not used in the script are not a problem.

An environment variable defined in a CGI script has no influence whatsoever on a shell started in a terminal. Environment variables affect processes and are inherited by subprocesses, they don't somehow magically jump to other processes that happen to run the same application.


Service Account Best Practices I am getting a presentation together for a topic I am not SUPER knowledgeable in.

I am an admin within a nameless system, and of the opinion that a service account should be created for each individual integration(rather than sharing an integration account across multiple integration points).

Let's say, for example, certain data is getting updated by an integration account. I would be able to tell exactly which integration is causing the unintended update.

Am I correct in having the unique service account per integration stance? In my mind, this boils down to PAM, and properly managing privileged accounts.

There is some reference in NIST 800-53 AC-2 Account Management, I was just hoping someone could provide some real world practice.

Am I correct in having the unique service account per integration stance?

This is something I always recommend doing because you can set permissions per account. The least privilege principle should always be applied.

As you mentioned yourself, it is easier to perform audits when having separated accounts.

Additionally, service account should not be able to be used in order to login to a system and either get a shell or remote desktop connection (depending on the environment).


I received an encrypted email attachment as a reply to a previous conversation, months later As in the title - I received an email reply to a months old thread containing a password protected zip file. I had previously asked them for a particular CAD file, but this was months ago and we had resolved the issue without me ever needing the file.

My internal alarms are going off. The thing is, it was sent as a reply to the conversation that we previously had. The original sender is a legitimate business that I am comfortable dealing with, and I have no other reason for suspicion. However, the message was accompanied with no other explanation, just a message telling me the password was 1234567.

Is it possible his email account is compromised and being used to send malware? Is there a safe way to inspect this file?

You are correct to be suspicious. This fits a pattern of recent phishing styles and indicates that the account was compromised.

The easiest course of action is to call/text/IM the sender to confirm (just not email).


Is it possible to "steal" someone else's ransomware bitcoin payment? I'm not too sure if this belongs on security.SE, so feel free to close or migrate to a different SE.

It seems that many ransomwares use Bitcoin as currency (for good reason), and tell you to send X BTC to address A. In order to verify that you have made a payment, I believe they will ask for your transaction ID.

However, as far as I know, all transaction IDs are publicly available. Thus, is it possible that I could just stay on blockchain.info and look at payments to address A, wait until a new one pops up, and immediately type that into my own instance of the ransomware? The malware should not have any way of linking who owns what wallet, so is it possible that someone else might make a payment and I enter the transaction ID first, effectively "stealing" their transaction, using it to pay for my own infection?

I could be completely wrong about this, I don't know much about bitcoin. I also understand that ransomware writers would not be bothered by this, since either way, they're receiving the money.

EDIT: I thought of a way ransomware writers might use to get around this: make a separate bitcoin address for each victim. However, this seems like extra work on the ransomware writer's side, so I'm not sure if many ransomwares do this.

Yeah, you're right that in this type of setup it's possible for one ransomware victim to claim that someone else's transaction to the ransomware address was their own transaction, because all transactions including the transaction id and destination address are public.

The proper way for the ransomware operator to handle things would be for them to generate a new address for every victim. Just like how every Bitcoin exchange generates unique deposit addresses for every user, every Bitcoin payment processor generates a unique deposit address for each transaction, etc. The ransomware operator's use-case isn't truly different from those use-cases. The ransomware operators who use the "tell us your transaction id" solution picked their solution either out of laziness or lack of knowledge.


Why use PBKDF2 over multiple iterations of a another cryptographic hash function? People often recommend PBKDF2 over using hash functions directly, but typically they compare PBKDF2 to a single unsalted hash. What advatages are there to using PBKDF2 over multiple iterations of a cryptographic function with the password and salt appended to the previous hash at each iteration?

Pseudo-code:

password="mypass0rd";
salt=random();
hash = password;
for (int i=0;i<1000;i++){
    hash = sha512(hash+password+salt);
}

Don't roll your own crypto. Generally, if you are directly calling (as opposed to specifying the name of) some crypto primitive (SHA-512, AES, etc), then you are violating this rule. If you think crypto implementation bugs are not hard to avoid, I suggest you give Matasano's crypto challenges a try.
Fewer lines of your code. This means fewer chances of you messing something up. It also means cleaner, more maintainable code.
Configurable iteration counts. Sure you could change the iteration variable in your code, but what about all the hashes you already have lying around? A library implementing PBKDF2 will have a built-in way to store and retrieve the iteration count for each hash.
Avoid RNG bugs. Your code makes a call to random(), but most languages' built-in PRNGs are not crypto-safe. Get a library that does salt generation for you, and you avoid the extra hassle and possible bugs.
Portability. Need to upgrade or change your backend? You can probably just copy (database export/import) your users' records and old hashes into the new framework. Otherwise you have to rewrite your custom hashing algorithm for the new framework, running into implementation differences:

Is the output of sha512 raw bytes or hex?
What character encoding did you use for passwords?
Is salt a string or a number, and how does it get converted into bytes for the input to sha512?


How to turn off need for bitlocker to go on Windows 7 I am the system administrator of my local computer (Windows 7) and I am unable to write to an external hard drive if it is not encrypted using Bitlocker to go. The local computer is not encrypted and I have searched for a way to turn off the need for encryption, but have been unsuccessful in finding an answer. Any help would be appreciated.

Thanks

Not sure if this is still an open issue, but there are some registry settings that you can set to zero to turn off the read only access to external drives as enforced by BitLocker to go.

The settings can be found in the registry as follows.

HKLM\System\CurrentControlSet\Policies\Microsoft\FVE\RDVDenyWriteAccess
HKLM\Software\Policies\Microsoft\FVE\RDVDenyCrossOrg

I validated that modifying this setting works in the latest release of Windows 10.


How do AV scanners in VirusTotal check if a file is malicious or not and how trustworthy is its report? So i have seen many times that people provide the virus total report for a file to prove its not a virus

but i just checked and when i submit a file its not even uploading it (i checked my bandwidth), its just computing its hash somehow without uploading it, I'm pretty sure I'm not uploading the file because a 10mB executable file takes half a second to "load" in their website and check even tho my upload speed is 30KB/s! (tried renaming the file too but still only took half a second)

so i have three questions:

when i submit a file, how does it upload it so fast? is my file even getting uploaded? if not, then how does it compute the hash?
does it only send the hash of the file to AV scanners? if so, doesn't this mean i can easily bypass it by changing   the PE/ELF file a bit?
is there any better alternative that actually performs some static or even dynamic analysis on the file to check if its malicious or not?

ad 1: It does upload your file, but only if the hash is not known. As the very first thing, a piece of Javascript will calculate a cryptographic hash (SHA-256 if I recall correctly, but might be wrong) and sends that. The engine then, rather than scanning, looks up the hash in a already-did-it database. Only if not present, or if you insist, it will upload the actual file.
How secure is this? Pretty much 100%, or as close as you can get to it. The odds that your file has the same hash as an already scanned file but isn't the same file are diminuitive. Not quite zero, admittedly, but as good as.

ad 2: It doesn't make much of a statement at all by itself other than "no problems were found" if there were zero hits reported. What it does is, it runsaround 60-70 different scanners, some of which are well-known, and some I've never heard of, and displays their output. Which, sometimes, contains false positives, and which may very well contain false negatives. The actual usefulness of virus scanners is being disputed, but alas it's as good as you can get. At least, virus scanners detect well-known threats relatively well.
Plus, there's the community thingie where users can give ratings, but it all comes down to trusting some unknown guy on the internet, so... bleh.

ad 3: Hardly. The best alternative is to never execute programs of unknown or even dubious origin. Anything else is reading tea leaves. Sure, some read the tea leaves better than others, but they are still only reading tea leaves. Dynamic analysis exists, pretty much every desktop AV software has that nowadays (running most system calls through a proxy lib), but whether it actually does something useful other than burn massive CPU is questionable. Virus Total may be somewhat better insofar as it runs a massive amount of scanners. Whether that actually increases security is uncertain. If you think about it: Assuming the scanners that are run are actually worth their salt, then a single one of them should do. On the other hand, if they're not worth their salt, what value is added by running more of them? Quoting an old wisdom: If you add nothing to nothing, the sum remains rather small. Or, as stated in Fidelio: "Nothing, if you add to nothing air".

If you got a file from a presumably trustworthy site, and you have zero hits on VT, then it's probably, usually, rather safe. If you keep the file around for two weeks and re-scan it again two weeks later, even better (assuming a new threat may become known in the mean time). That's what I'm doing, and I've done that years before VirusTotal even existed -- so far it works very well (or, it seems to work, I might have malware that I don't know about). In the end, you never know for sure.

About dynamic analysis
That's not happening. You can deduce what kind of analysis VirusTotal is doing from its display. It is almost certainly not just a forwarding of hashes to some other service (as suggested in a comment) because of the time it takes to scan, and because definition files are not always in sync (indeed most of the time they're not) with the manufacturers' tools. You can also unpack and re-pack a ZIP file (which almost certainly results in a non-identical file), and it will be scanned just fine. How would that work if only hashes are being handed around? It wouldn't... but it does. That, and the fact that sometimes one or another scanner fails to open an archive, indicates that actual scanning happens.
You can deduce that they do static signature matching and heuristic scanning because signature matching is what every AV does and has been doing for 30+ years by default, and heuristic analysis is what most (if not all) scanners do by default for at least 20 years, too.

On the other hand side, you can be pretty sure that no dynamic analysis is done because that is forbidding and impractical for a web service. In order to do dynamic analysis, you must run the binary in a secured environment (emulator, virtual machine or similar) which provides a complete operating system for the binary to run, and which is able to accomodate the memory and CPU requirements of a haphazard amount of a-priori unknown programs. That's hardly realistic. Plus, there is a very non-neglegible risk in running unknown software which could do basically everything including running malware services inside the VM, or breaking out of the VM. You know, for example a web browser or a mail client needs internet access to function properly. How do you provide that without also granting any malware that you run internet access? Google (the owner of VirusTotal) very certainly wouldn't like being accused of running malware services.
Lastly, you must have 100% coverage to be sure (else, the analysis is pretty pointless, malware does not necessarily do its work upon program launch), so you need either a human or the most advanced fuzzing robot in the world to provide adequate input to the program so it takes all possible paths. Do that for a web service which maybe ten million or so people use every day, and nobody likes to wait longer than a minute or two for the results, good luck.


How come keys can stay secure through factorization of primes Sooo I under n=pq where p and q are both large primes so it making factorizing them inefficient to the point of impossible but there must a a list of prime sets (heard people call them trap doors I think?) That are well know? Like if p and q are both know pairs wouldn't you be able look at n and go well I know this already so I don't need to even work it out I already can tell you it's pq. Or are there an infinite number of primes available and Is it only limited by the how large the key is? Isn't there a finite ammount of primes available in 2048 bits that it wouldn't be that hard? Clearly it's time consuming enough that it hasn't been cracked but I don't get why not since you know how many primes there are and also what they all are.

There are around 10^305 eligible primes for 2048 bit key (1024-bit long primes, as given by the prime counting function approximation), so the total combination count(p*q) is around 10^610. Each key is 2048 bits long, so the whole key space is 10^613 bits. Or 10^562 petabytes of data. This is an impossibly large number of keys, number of atoms in the universe is 10^80.

So no, enumerating this keyspace is out of the question. RSA is weak to quantum implementation of Shor’s algorithm, but we haven’t built a quantum computer big enough for cracking even 10-bit RSA keys.


Definition of Idle Timeout Should I run the session idle timeout timer

From the start of the first request to the start of the next request, or
From the end of the first request to the start of the next request?

A bit of context - I have a 10 minute idle timeout on a Web API application. Some of the requests take a long time (say around 8 minutes). If I do 1., users effectively lose 8 minutes of their idle quota on these requests. If I do 2., it does not sit well with the definition of idle - the user has been (forced to be) idle since initiating the first request.

I'm inclined to 2. because of UX but definition concerns aside, is there any way 2. could be misused?

I believe the idle timeout is in place for most of the reasons as in https://security.stackexchange.com/a/54668/164690 and am ok for any answers to focus on these requirements (unfortunately, I can't find any formal requirements supporting my belief - the current system is based on a very old system, whose requirements are unfortunately lost in the annals of time. For the same reason, I'm not sure why 10 minutes and not 9 or 11). That said, I am curious as to whether there are any sort of security loopholes that can utilize 2. and not 1.

Note - I also have an absolute timeout running from the start of the session

This depends on what should be achieved with the timeout. You might timeout a session if the user did not interact with the site for some time. Or you might timeout the session if the user has not visited the site for some time, but don't timeout if the site is still open inside the browser. The first way is more secure but the second is more comfortable for the user (longer timeouts are more comfortable too). How to weight security vs. usability depends on your specific use case.

If the session timeout should be triggered based on actual user activity then it should be reset only if such activity is found, i.e. at the start of a HTTP request which was caused by activity of the user.

If the session timeout should instead be based on browser activity (i.e is the web site is still open in the browser) then it can be reset whenever data is successfully exchanged with the browser. Such successful exchange means that the web site is still open inside the browser and the the browser has network connection but it does not mean that the user is actually doing something with the site (i.e. might be away from keyboard).


Does Visa Checkout have preventive measures against spoofing? A few online merchants are offering special deals for using Visa Checkout, a payment service similar to PayPal, so I've been trying to learn something about it before signing up. When you are on a shopping site and click the Visa Checkout icon, it pops up a window to enter your Visa Checkout username and password:

Is this scheme secure? I don't see anything that lets me verify that this popup is valid and protects my information. It seems that a rogue site could easily fake the popup and harvest the login credentials.

With PayPal, I am directed to the PayPal site to sign in, which lets my browser show me the PayPal host and TLS authentication:

If I check those items on the URL bar, I feel reasonably confident that I am delivering my credentials only to PayPal.

Is the PayPal scheme more secure than Visa Checkout? Or is there some way I'm missing to protect against spoofing?

The problem you mention is a real one.

This scheme was a subject of criticism and led to a newer implementation ("3D Secure by ...", the old one unfortunately also sometimes uses this name) which is two-factor (you usually get an SMS with a code you must input on the merchant's page). You are also warned of the upcoming operation ("you will now be transferred to 3D secure..."). The scheme you mention failed to pass the European Central Bank requirements.

The requirements for e-commerce payments were strengthened with the PCI-DSS SAQ A-EP, specifically designed for modern e-commerce payments (where you are not redirected to a bank or processor's page to fulfill your payment)).

The redirection to PayPal in your example is a good compromise - you get into a better-known page which, as you mention, you can analyse and check against common-sense security (specifically to whom the cert was delivered to).


Is it okay to log a user into multiple accounts when the email and password are the same? We have a single web platform, where users can log in to different workspaces.
Each workspace has its own list of users with email and password credentials and various permissions for each of those users. Email and password pairs can be duplicated across the workspaces. The passwords are hashed and stored in a database alongside the user data.

There'll only be a single login page, and we'll log the user into the workspace that has matching credentials.

However, if there are multiple workspaces that have a matching email and password – we want to log them into all of those matching workspaces.

Does this pose a security issue?

Follow-up question:
Would it be best to share the password hashes across workspaces? (this would add some complexity to the app)
Or can it be done without sharing the hashes? – and simply checking the password across all workspaces for that email (where there might be different salts, but the underlying password would be the same)

A typical solution for this problem would be delegating the authentication to an external single sign-on (SSO) service instead of comparing the passwords against many different databases. Here, the different workspaces would work as service providers (SP) and the login page as an identity provider (IdP). Only the IdP needs to be aware of the password hashes, and the SPs trusts this identity, giving access based on the matching username (or email).

Despite this might add some complexity at first, it's much easier both for the users and for the management in the long run. You don't have to reinvent the wheel as there are many SSO services both open source and proprietary. Some of them are based on the Security Assertion Markup Language (SAML), some works with the Kerberos authentication etc. It's probably possible to find a solution that is at least close to your current authentication scheme. You could start by looking at the List of single sign-on implementations.


Is there more to consider than just keyspace when determining a password's strength? Please consider the following passwords:
CO/l37)[Ou
It contains characters taken from a pool that contains [a-zA-Z0-9] and 32 'special' characters. That makes 94 characters in total.

And this one:
XFnSzoN3Ype
This one contains characters taken from a pool of [a-zA-Z0-9], so just 62 characters.

Note that the second password is one character longer than the first.

If you look only at the number of possible passwords that you can construct using the given pools and lengths, you will find that both are about equally strong.
1) 94^10 = 5.4 * 10^19
2) 62^11 = 5.2 * 10^19

Disregarding this slight difference for a moment, would there still be a case to make for preferring the first password over the second? Is there more to consider than just keyspace when determining the strength of a password?

Determining whether a particular password is "strong" is an imprecise exercise.  A slightly better question is whether it's strong against a particular type of attack.  This provides a framework from which you can start to evaluate how many guesses or how much time is consumed trying to match guesses to your particular password.  But this also forces you to make some assumptions about what attacks and approaches will be tried, and these might not match up with what would happen in the real world.

So, looking at your two presumably randomly generated passwords we can say that the obvious attack is to try all possible random combinations with their respective character pools.  We know if we try all combinations we will find a match at some point during that search.  We could also evaluate how exactly the guessing software iterates through the random strings and estimate where within the overall brute force process those passwords are likely to be cracked.

Just to make up numbers, let's say your first password would be matched 4% of the way through a brute force of its respective keyspace, and the second password would be matched 39% of the way through its respective keyspace.  You could take those results and accurately say that the second password is stronger against this specific type of brute force attack.

But this couldn't tell you that either pool of characters was better or worse at producing secure passwords.  It is limited to comparing those two specific passwords.  On average both pools would produce random passwords of approximately the same strength since they have a similar keyspace.

We could also look at the computational feasibility of an attacker exhausting all possibilities in a brute force of either keyspace and say that today it isn't likely.  At one trillion password guesses per second it would take over 600 days to exhaustively search either keyspace.  If neither is likely to be cracked then you could argue they are equally strong, or at least both strong enough, from a practical standpoint.

Another attack might be guessing dictionary words.  It's seems safe to say that neither of these passwords should appear in a dictionary.  In this case they're also equally strong, since neither have a chance of being guessed.

However, if we step back to evaluate the likelihood of their respective keyspaces matching dictionary words we might see a different result.  Your first password's keyspace is made up of around 0.27% strings that are all lowercase, all uppercase, or a mixture of alphabetic cases.  In comparison, your second password's keyspace is around 14.45% of those same strings that could be dictionary words.

Now that certainly doesn't mean all these alphabetic strings are words (or combinations of words).  A very, very small percent of those strings would match any given word list.  But you could make the argument that a higher possibility of a randomly generated password from the second pool containing only letters means that this pool has a higher chance of generating passwords that match words.  I'd urge you to actually measure this effect with word lists before proclaiming this to be true, but some people might see this and say that the first pool generates stronger passwords.

So my conclusion would be that there are different ways of measuring the strength of these passwords (and I only discussed a few).  Depending on which approach or approaches you took you might get different results.


SSL VPN Detection and possible to block Is it possible to determine the difference between a VPN on port 443 compared to standard SSL traffic?

In order to access SSL websites you need port 443 open but if you setup a VPN Service on port 443 you can dial out of the firewall.

Yes. Even if you run a VPN on port 443, HTTPS (which uses port 443) and VPNs have enough differences within the protocols that can be distinguished from the outside that a firewall or device that does deep packet inspection would be able to immediately classify both.

If your firewall does not block a VPN connection on port 443, it is likely that the firewall is only doing port filtering, or does not have protocol signatures for VPN connections yet.


Using OpenSSL as a library versus calling output from standalone command in a program being written In another question about how to use OpenSSL programmatically  a community member was writing, one suggestion was to use the system() command whereas another was to include the C headers and work with the library using functions directly. Also, if using system() is there a security benefit to using popen() or another function instead?

What would be the security implications of running OpenSSL as a library versus calling a compiled executable from the system? I imagine there might be issues about integrity and authenticity relying upon openssl installed on a system in some cases, but its also possible an application might use an outdated library. Are there certain considerations for this scenario, or can this be answered more generally (If so, please feel free to edit the question).

As a rough summary, OpenSSL has been designed as a library and was meant to be used as such. The command-line utility was, initially, a tool for testing and for manual tasks. Potential issues with invoking the command-line utility from a C application, with system() or popen(), include the following:

The tool expects its inputs as files, which must be produced and managed. Some of them are sensitive, e.g. files which contain private keys; you need to exercise great care when copying them.
The tool produces its outputs as files or text on its standard output; the text is meant for human consumption, not for automatic parsing. A number of corner cases can be troublesome (e.g. if you use openssl as a way to analyse the contents of X.509 certificates, what does happen if a string within the certificate contains a newline character ?). The format of text output might vary with details of the system configuration (e.g. system-wide language or encoding).
Error reporting will be hard. With the C API, you can know exactly which step failed and why; with the command-line tool, you will get, at best, a synthetic error status ("something failed") and a text message.
system() and its brother popen() are a definite no-go in setuid applications (that's the king of "get root shell" holes of the 1980s).

To sum up, calling openssl (the command-line utility) from C code is cumbersome, inefficient, and complex. Complexity alone almost mechanically implies security issues.