Convert raw memory dump into a format recognized by volatility I dumped the RAM of a Windows 7 pc using LiveKd which basicly worked. The memory was dumped but then the convert of the binary dump into "summary format" failed. When I then tried to read the file using volatility it tells me there is no suitable address space mapping which is logical. Is there a way to convert the raw memory dump into a format that is recognized by volatility?

By default, LiveKD acquires a kernel memory dump that appears as a crash dump file, not a complete raw dump of the contents of RAM. Volatility requires a complete memory dump. I recommend any of these tools for Windows memory imaging. The goal of LiveKD is for debugging, not forensic analysis (KD = kernel debugging). It's an alternative to having to use WinDbg and KD via a serial connection to debug the kernel 'live' (and the system doesn't have to be booted in debug mode). LiveKD fools the debuggers into thinking that they are looking at a crash dump file by implementing a file system filter driver that presents a 'virtual' crash dump file that debuggers can open.

With that said, the dump from LiveKD technically may contain a complete dump of RAM if the correct options were given to it but with a header preceding it so that debuggers recognize the file format as a crash dump file. A crash dump file is simply a file header followed by the contents of physical memory, so that the driver can satisfy reads of the virtual dump file with the contents of physical memory, which the driver can easily read from the \Device\Physical Memory section object the memory manager creates.

In the book The Art of Memory Forensics written by the creators of Volatility, they discuss the structure of Windows crash dumps on pp. 96-98, explaining that "the Windows crash dump file format was designed for debugging purposes" and that they begin with either a _DMP_HEADER or _DMP_HEADER64 structure (p. 96). The authors clarify that only complete memory dumps are compatible with Volatility, not kernel memory dumps nor small dumps (here is a MS TechNet blog entry that explains the difference).

I personally use the 010 Hex Editor for many forensic parsing tasks involving binary data, and it has a pre-made template for parsing 32-bit crash dumps. See the Volatility documentation for further information about the crash dump header formats.


Alternative to client certificate authentication with HTTP/2 We are currently busy improving an Android application with connects to an Azure App Service API using client certificates and bearer token for authentication over TLS 1.2.

We are investigating moving to HTTP/2 for bandwidth & performance requirements.
HTTP/2 standard has no implementation for client certificate authentication.

https://www.ietf.org/mail-archive/web/httpbisa/current/msg25262.html
https://tools.ietf.org/id/draft-ietf-httpbis-http2-secondary-certs-01.html

We still want an extra layer next to the bearer token authentication. What are valid and secure options to explore to harden our API?

Adding a nonce is a possible solution to block malicious requests, but we would like to limit public access to our API.

We solved this by using Azure App Service IP restrictions.
This was only possible because we control all the clients.


xss payload "-confirm``-" I found -confirm``- this payload on xsstrike while scanning one of my websites. I want to know more about it.

It's a payload for a sink inside a JavaScript string context. It might eg exploit the following vulnerable code:

<script>var x = "[user input]";// process x</script>

The payload uses confirm because some applications filter alert; using `` removes the need for ( and ) in the payload, and the biggest advantage is that subtraction (-) is used to add new statements (in place of eg ;).

An alternative payload exploiting the same issue would eg be ";alert(1);x=". But "-confirm``-" has the advantage that it leaves the rest of the code completely intact. It can eg be used in contexts such as this, where other generic payloads may fail:

<script>
x("[user input]");
function x(y) {
    alert(y);
}
</script>

If you weren't using subtraction in your payload, you would need to "fix" the code before and after your injection  (eg ");alert(1);//. But that payload isn't generic anymore (it wouldn't work for the first example).


Are there any real life scenarios where usage of the Gutmann method is appropriate? Peter Gutmann himself wrote the following:

  If you're using a drive which uses encoding technology X, you only
  need to perform the passes specific to X, and you never need to
  perform all 35 passes. For any modern PRML/EPRML drive, a few passes
  of random scrubbing is the best you can do. As the paper says, "A good
  scrubbing with random data will do about as well as can be expected".
  This was true in 1996, and is still true now.

Source

It seems like the method of data reconstruction described in the paper is more of an academic problem than something that is done in real life.

Nonetheless many data erasure tools are implementing the Gutmann method. (For example DBAN, Recuva, shred, TrueCrypt)
Is there any real life scenario where the Gutmann method is actually needed? Or do they just provide it as a feel-good feature for paranoid users?

Assuming an adversary is able to get data off the raw chips, over-provisioning on solid state drives could leave data behind after a single wipe. In this scenario multiple passes would help remove data on the extra storage. Depending on what kind of data and adversaries you have 10+ passes could be justified, though why you wouldn't just destroy the drive and chips at that point is beyond me.


Impossible removing JS:Downloader-FHB trj im having big issues removing "JS:Downloader-FHB trj" on my computer, i already tried all software available, and after detecting and removing than the software says that is clean, but is not in reality, i used everything including the adwclear from bleepingcomputer.

The strange thing is that the malware shows when i login the backoffice of my online store (magento), the avast alert shows, and everything on my website cant me touch used because the scripts from the website is not being loaded, is very strange, im quite new at this things of malware., and im sure that is realted with my computer and not the hosting because is only firing on my pc.

Can someone tell me if there is a solution.

Try clearing your magento caches. I had the same malware warning from Avast - after clearing my Magento caches, it went away - I suspect it was false positive of sorts.


How does tunneling actually work? I recently saw a question in which someone implied that tunneling could foil MITM even if it were implemented while an MITM was taking place. My understanding of tunneling is that it is only capable of stopping MITM if it connects to the actual network before the attack is attempted, otherwise the VPN would be set up between the target and the hacker. Is this correct, or am I somehow confusing this? As a side question, could anyone tell me if an Evil Twin attack can be successfully implemented against a VPN? Thanks.

Evil twin is an attack against wireless networks, it has nothing to do with VPNs. It may be that you are asking whether an attacker could successfully masquerade as a VPN destination in order to trick the source in to thinking it is valid. The answer to this would be a qualified no. Evil twin attacks work because wireless networks generally provide no way for a connecting host to verify the authenticity of the broadcasting station, in the case of VPNs like IPSEC both sides use a shared secret or key pairs to verify each other's authenticity.

An attacker might be able to spoof an IP address and trick one side into connecting, but without the shared secret or correct key pair a VPN would never be allowed to form.


Mobile hotspot security I travel a lot. When I am away from home, I connect to the internet using a mobile hotspot provided by a major ISP in the US. I am the only one who uses this computer and this hotspot, both of which I own.

Assuming my ISP has not been compromised how hard would it be for an unsavory person be able to intercept or view my internet traffic? Are there any ways to make the system more secure?

Part of your answer depends on how your ISP allows you to connect to the Internet.

First consider the security of the device itself.

From the ISP side facing the Internet: If your hotspot is given a public IP address either permanently or temporarily it would be susceptible to attacks from the Internet, and while on-line it would likely get indexed in major vulnerability scanning projects like shodan.io or scans.io at some point (Note: you may be able to find similar devices like yours on sites like shodan.io). Likewise during these times your hotspot was on-line it could potentially be susceptible to attack, especially if no one is regularly going through efforts to secure it.

A quick way to check your security would be to determine your own IP when using the hotspot then perform remote testing against the IP in use and check to see if there are any signs that you can connect to it directly (insert long conversation here). Please note depending on where you live it may not be legal to test this either.

From the wireless side: This will vary a bit more based on the protocols both in use at the time and also the protocol supported by the device over all. You may access it using a more modern cipher in a secure fashion but the device itself may support many weak protocols which may enable an attacker to perform brute force attacks to access it. More importantly a LOT of these devices support web servers on their internal wireless network which could easily be attacked. Finally since the devices TCP/IP kernel is essentially accepting wireless connections from anyone around you it could also be attacked directly (this is far more difficult to do but it is a distinct possibility).

Second, consider how you are using it. What protocols does the device use to connect to the ISP ? are these secure ? does it fall back to insecure protocols when it can't connect to it's primary connection ? Does the device support roaming ? Similarly what protocols do you normally use to connect to it, could your connection be downgraded by an attacker, what's the weakest protocol supported, and do the weaknesses in the worst case scenario allow for an attacker to be able to sniff your traffic ? Do you trust the firmware of the device ? The software ? Where it calls home to ? All the protocols it uses ? Does your ISP track and monitor your connections and things like DNS requests ?

Third, how do you verify you are actually connecting to your device first ? Is it possible that someone nearby with a wi-fi pineapple could be intercepting your traffic then forwarding it on ? Do you verify that you are connecting to the correct device each time ? Do you have any type of certificate authentication in place ?

Basically, the security of these devices are not ideal especially if they don't receive regular security updates from the ISP (rare at best). That said they may not be much worse than any other random wi-fi connection you use anywhere else. If you have serious security concerns you should assume the worst and simply think of it as part of the untrusted Internet and leverage things like VPN's to minimize the risk where possible.

There are many other components about a secure connection that I am not including here (long conversation) but this will help you assess the risk areas and some of the attack surface for such a device.


Is accepting old passwords a bad policy? This question is inspired by an experience I had today with online banking, as follows.
One year ago I opened an online deposit account. (Without naming the bank, I will say the company is currently a constituent of the Dow -- in other words, not a fly-by-night institution.) Earlier this month, they launched a redesigned web interface, and today was the first time I accessed my account since the redesign. I accidentally used the same password I used when I originally created the account. However, I had previously changed my password. The old password should not have worked, but it did!

Subsequently it became apparent they had associated my account with old information: They asked to send an activation code to a phone number I have long since abandoned, but which I used when opening the account. After opening the account, I had replaced the old phone number with a new one in addition to changing the password. So it would appear the bank reverted to my outdated personal information (ie, password and phone number).

People sometimes change their password because they believe their old password may have been compromised. But this countermeasure is ineffective if the institution will still accept an old password.

Is there any reason to believe a reputable bank would intentionally accept an old password?

Well, I can't comment on this story of your bank, but the answer to your overall question is that it's very stupid to accept old passwords, because then users have no way to secure their account if their password is ever compromised.


Access control for embedded device We develop a protocol for computer remote control of a certain kind of toy. It's basically a sensor and actor network that is usually connected to the user PC via serial port or USB. Now some users wish to connect via Ethernet, and we want to design some kind of gateway in an embedded device.

It is expected to be used only in home LANs (e.g. from mobile devices through a WiFi router), but those shouldn't be considered secure and there's always a chance of being exposed to the internet. The risks involved are manifold:

those toys are expensive and could be destroyed through abuse
the environment might be harmed by messing with the actor power supplies
the devices are capable of (unsecured) firmware updates and could be taken over or bricked
generic disturbance of service operation
eavesdropping on private data

The embedded gateway device would expose some kind of server that accepts connections - which need to be limited to authorised ones. How to do this?

After the initial idea of wrapping our serial protocol in UDP packets (for low latency and low overhead), we considered TCP to avoid dealing with packet loss in wireless networks. TLS is the next logical step, which provides encryption1. But how to do the authentication and authorisation?

Is TLS applicable at all, when used in a non-web context? We don't necessarily have host names, or even internet access, and I don't know how to validate the certificates. We cannot use a CA, so our PKI would look different and I don't know what security holes are introduced by manually managing certificates. It's probably already enough of an issue to get each server - each device - its own randomly generated certificate. (I also found these two questions dealing with similar issues)

Would some kind of pairing process (similar to Bluetooth or WPS) solve the issue with unvalidated certificates? The embedded device would be equipped with one simple push-button to accept a client2, and the client would remember ("pin"?) the server certificate. This first connection would be susceptible to a MITM-attack, but subsequent connections would not. Does that sound viable and secure? I'm doubtful about home-brewed schemes.

An alternative to the pairing I considered would be a password authorisation scheme, where the client sends a password to the server to gain access.3 However, users tend to choose weak passwords, and also I have no idea how (i.e. which protocol to use) to send the password over the unsecured connection - still not having validated any certificates -, avoiding MITM or replay attacks.

Please help me find a good solution - either by answering the above questions or by suggesting a completely different approach that I missed entirely. Our main objectives/restrictions are:

good usability even for non-technical users - without any administrative maintenance
simple implementation with widely available libraries for many programming languages
high level of security (if necessary ignoring setup phase where it might be impossible)

1: As long as used with the right settings, I gathered.
2: I guess we must not forget a way to remove clients
3: With the initial password randomly assigned to each device and printed on the bottom

This is a rather broad question, so I cannot give more that hints. First at its lowest level, the SSL/TLS library (OpenSSL) only require that both parts involved in a communication have private and public keys and that each knows the public key of the other one. That is the way it is used for example in OpenSSH. The PKI infrastructures and CA and only a way to validate public keys for entities that do not know each other.

In your use case, you could use a (private) Certificate Authority to validate certificates for the devices and eventually certificates for the client PCs. But in case a key was compromised, the renewal of a certificate would be hard while it does not add much security to a mere public key exchange the way OpenSSH do.

So my advice would be:

find/build an acceptable way to generate random key pairs on the devices and client software. The good point with it is that is the device is sold, the new owner can install a brand new key on it.
imagine and develop a way to exchange public keys between a device and a PC. Something like broadcasting them in a time window followed by an agreement protocol if one and only one key has been received. After that point, the peer key should be pinned on each part

From now on, the device should just reject any connection request that cannot prove the knowledge of its peer key. That allows you to:

rely on the high quality OpenSSL (or probably LibreSSL) library.
allow the owner to change the keys on his device at will if it can suspect his PC or device could have been compromised, or if for any reason the device or the PC hast lost its previous key (for example is the device memory had to be replaced, or if the PC disk crashed)
require no more that 2 buttons (generate a new key and start an association) on the device or even one single button if a new association can consistently use a new key

Alternatively, you could setup a special mode (activated by a button on device) in which any certificate will be accepted during a time window and that certificate will be pinned for further exchanges provided one and only one was received. In that mode only the connection should be possible and no command would be processed. This variant avoids to setup a key exchange protocol and simply rely on the ability of SSL to pass certificates. So you end on both side with:

generation of a new self signed certificate
on special mode allowing the pinning of a peer certificate
all other exchanges rely on the certificate send being the same as the pinned certificate

I know that this is far from a definitive answer, but it could allow to ask more precise questions here or on StackOverflow...


What is this strange GET request (GET /A0A32579-2767) DoSed my apache? I have apache behind nginx on my webserver.
Today my apache stops answering to requests. Investigations shows this situation:

Number of apache processes grows more that 500 but MaxChildren=256 in config (I have mpm_itk, also tried mod_prefork).

server-status shows that 256 of processes were busy and near all of them served request like GET /A0A32579-2767-F346-A463-9EC16718D7E7/9FDAE968-8090-9C4F-8122-DCBEA5A9A8EC/from.
First part before "/" was always same and second differs.

According apache logs it answers 404 to such requests.

After blocking such request on nginx everything goes normal. But I'm interested what was it?

I have
Ubuntu 12.04.5
apache-2.2.22-1ubuntu1.7
php-5.3.10-1ubuntu3.1

From my experience, it looks like you were DoSed with a SlowLoris attack. It would appear that the attacker tried to retrieve a random non-existent page and then used SlowLoris which caused the DoS effect.

Essentially the attacker generated two 16-byte GUID's/UUID's, appended them together with /, and then loaded the index file of /GUID_1/GUID_2. When the server began to reply, the attacker's application then read back the bytes very slowly and thus caused the connection to stay open. Meanwhile, several other threads likely opened other concurrent connections and performed the same process. Thus each of the attacker's threads occupied 1 connection on the server and the server could not reply to any other connections because it was still attempting to serve the attacker's connections with the 404 error.

Because this is considered a layer 7 attack ("Application Layer"; see the image below), a smart attacker could use proxies to prevent tracking and IP blocking.

The best mitigation would be both blocking the attacker's IP Address(es) (or the IP Address(es) of the proxies the attacker used) and installing some server mods which can detect and prevent these attacks. In this article, I read that installing libapache2-mod-qos to the server will prevent SlowLoris on susceptible Apache machines.

It is worth noting that Microsoft's ISS servers are not vulnerable to a SlowLoris incomplete HTTP GET Attack; however, the ISS servers are vulnerable to "R-U-DEAD-YET" incomplete HTTP POST Attacks.


Folders with .js files that I didnt create are in my pictures directory windows 10, virus? About a month ago, two folders appeared in my /pictures directory named:

Ready To Glare  (@ReadytoglareYT) _ Twitter_files and Lawrence's stream mom _ funhaus_files .
Inside the folders are .js.download files, html files, .jpg files, and .png files, _api files(whatever that means), etc.

I didnt create them and never witnessed this type of behavior before. I tried a virus scan with Comodo Antivirus, Kasperski antivirus, and malwarebytes. They didnt find anything.

I cant find anything that would explain this on Google.

Anyone have any idea how this could have happened?

These are files for saved webpages. I can almost completely guarantee that you've accidentally hit Ctrl+S in your browser and saved a page to your Pictures directory.

If you go up one folder, you'll almost certainly find a pair of HTML files that correspond to the folder names. The _files directories are where the resources (images, scripts, etc.) are saved for those saved HTML pages.


What can I do to get rid of spam emails that come from different, randomized email addresses? Here's an example of the address they're coming from:

I'm familiar with filtering settings, but how can I filter something that's different each time?

The apparent "FROM" is readily faked. Look at the full email headers for several of the spams, odds are good there is a common identifier buried inside that you can use as a filter, it may even be as simple as the originating IP.
Don't forget that your filter need not be an EQUAL match. You may find that a substring match using CONTAINS will work best.


Do VPNs provide sufficient protection over public wireless networks? I know that VPNs are the standard way to secure communication between a remote user and their primary network, but I've never felt entirely comfortable relying on them when using an open wireless network, like at a coffee shop or airport. Even though I know the connection is encrypted, the fact that it can easily be sniffed makes me too nervous to connect to any important systems.

Is that fear unfounded, or is it a good idea to avoid transmitting sensitive information over the air, even when it's encrypted?

I guess the bottom line is, would you feel comfortable logging into your bank's website from a coffee shop, as long as it was tunneled through a VPN? (For the sake of simplicity, assume that the VPN is properly configured, physical security isn't an issue, etc... the scope of this question is just the VPN's role).

With due considerations to the recent developments in terms of PPTP based VPN connections that lead to compromise of data, usage of Wifi under a VPN is still highly secure for a number of reasons.

Firstly, if you're a casual user who's performing Internet Banking, the practical overhead of performing the exploit procedure and then the decryption of the captured data is quite significant. No local coffee shop hacker would do it, and professionals wouldn't be interested in spending his time on you.

If security is absolutely critical to your transactions then, there are a number of simple additions:

Ensure that the VPN connection is at least an AES-256 with certificate authentication. Do the usual checks to ensure that the certificate is not compromised to a MiTM attack. Eg OpenVPN
Keep the sessions inside your VPN connection them self encrypted. ie. Don't use HTTP, use certified HTTPS, replace FTP by SFTP, etc.
VPNs are over-rated as per me. A good SSH tunnel configured properly works as a lower cost and light weight, easy to deploy solution for encryption. Plus you channel it through your rented server and if you have the need and resources you could for example, setup any custom modifications of the encryption procedure. I'm not encouraging obscurity, just saying you don't have to limit yourself to the current textbook compliance procedures and thus use infamous but more secure encryption techniques.

My point being, for banking, the chances of an attacker being able to break through a VPN encryption, then say a SSH tunnel and then finally your HTTPS web page traffic is extremely improbable, even for highly confidential EOW data.

And even then, banking sessions generally last for a few minutes at max. Apart from certain broken information, there would be no way in any practical banking system with even basic security to use that in order to steal money from you or hack you.


Intermediate certificate not allowed to issue certificates? I'm making a certificate chain:

  ..|root
  .....|intermediate
  ........|server

When my certificates are installed, the intermediate certificate has an error:

  This certification authority is not allowed to issue certificates or cannot be used as an end-entity certificate.

As a result, my server certificate is invalid.

My code:

#Root CA
OpenSSL> genrsa -out root.key 4096
OpenSSL> req -new -x509 -days 1826 -key root.key -out root.crt

#Intermidiate CA
OpenSSL> genrsa -out intermediate.key 4096
OpenSSL> req -new -key intermediate.key -out intermediate.csr

#Root signs Intermidiate
OpenSSL> x509 -req -days 1826 -in intermediate.csr -CA root.crt -CAkey root.key -CAcreateserial -out intermediate.crt

#Server CA
OpenSSL> genrsa -out server.key 4096
OpenSSL> req -new -key server.key -out server.csr

#Intermediate signs Server
OpenSSL> x509 -req -days 1826 -in server.csr -CA intermediate.crt -CAkey intermediate.key -CAcreateserial -out server.crt

My config file:

dir                     = .

[ ca ]
default_ca              = CA_default

[ CA_default ]
serial                  = $dir/serial
database                = $dir/certindex.txt
new_certs_dir           = $dir/certs
certificate             = $dir/cacert.pem
private_key             = $dir/private/cakey.pem
default_days            = 365
default_md              = md5
preserve                = no
email_in_dn             = no
nameopt                 = default_ca
certopt                 = default_ca
policy                  = policy_match
x509_extensions         = v3_ca

[ policy_match ]
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
default_bits            = 1024              # Size of keys
default_keyfile         = key.pem           # name of generated keys
default_md              = md5               # message digest algorithm
string_mask             = nombstr           # permitted characters
distinguished_name      = req_distinguished_name
req_extensions          = v3_req
keyUsage                = digitalSignature, nonRepudiation
extendedKeyUsage        = serverAuth,clientAuth,emailProtection,codeSigning

[ req_distinguished_name ]
# Variable name                Prompt string
#-------------------------    ----------------------------------
commonName                     = Common Name (hostname, IP, or your name)
commonName_max                 = 64
0.organizationName             = Organization Name (company)
organizationalUnitName         = Organizational Unit Name (department, division)
emailAddress                   = Email Address
emailAddress_max               = 40
localityName                   = Locality Name (city, district)
stateOrProvinceName            = State or Province Name (full name)
countryName                    = Country Name (2 letter code)
countryName_min                = 2
countryName_max                = 2

# Default values for the above, for consistency and less typing.
# Variable name                Value
#------------------------     ------------------------------
0.organizationName_default     = My Company
localityName_default           = My Town
stateOrProvinceName_default    = State or Providence
countryName_default            = US

[ v3_ca ]
basicConstraints            = CA:TRUE
subjectKeyIdentifier        = hash
authorityKeyIdentifier      = keyid:always,issuer:always

[ v3_req ]
basicConstraints            = CA:TRUE
subjectKeyIdentifier        = hash

[ usr_cert ]
basicConstraints            = CA:TRUE

Honestly, I'm a beginner when it comes to making certificates. My configuration file was copied from the internet. I need some help.
What am I doing wrong? How do I get rid of the error?

I think your problem is that your intermediate CA is actually just a 'regular' cert, with the following extensions:

keyUsage                = digitalSignature, nonRepudiation
extendedKeyUsage        = serverAuth,clientAuth,emailProtection,codeSigning

Although you did set

[ v3_req ]
basicConstraints            = CA:TRUE

(which is not something you really should be doing), you need something else.

Per man x509:

  A CA certificate must have the keyCertSign bit set if the keyUsage extension is present.

I realise you are probably trying to do the 'right thing' here by having an intermediate doing the day-to-day issuance, you might consider making things a little simpler for yourself while you research openSSL and using it to generate PKIs (aka: read at least https://www.feistyduck.com/books/openssl-cookbook/). Also check the 'Certificate Extensions' section in https://www.openssl.org/docs/manmaster/man1/x509.html.

I would suggest you look at cfssl to help you get the cert you need right now, if you don't have the leisure to research things thoroughly at the moment. You might also want to take a look at Hashicorp's Vault.


Reaction to spam from acquaintance It often happens that I receive an email like this:

  From: acquaintance@herbal-viagra.com

  To: me@domain.com

  Hi, me@domain.com --

  Check this out: http://herbal-viagra.com

  -- acquaintance@yahoo.com

This looks like my acquaintance has gotten his computer infected with malware that has harvested his email contacts.

Often this happens with people I'm only slightly acquainted with, and for whom I have no means of contact other than email. Is it reasonable to respond to this by emailing acquaintance@yahoo.com with a copy of the message, saying: Hey, I think your computer got infected with malware that has harvested your email contacts? Or should I:

not respond at all
blacklist email from herbal-viagra.com in my spam filter

The likely scenario is that the sender's account got compromised, not necessarily their computer. Accounts are easier to hack because attackers just need to guess a password.

Responding has a high chance of alerting the sender, so it is worth a shot. Sometimes an attacker has active control of the account and will try to delete incoming emails, but I haven't seen that often. Even if that is the case, it is still worth a shot.

Blocking the domain of the link in your spam blocker will not be effective. The email comes from a completely different domain than the link destination. On the other hand, if you want to block that domain in your DNS or web filtering software, that might help a little, but those domains tend to exist for short periods of time.


Why is WPA3 using 192-bit encryption? Why is WPA3 going to be using 192-bit encryption and not 256-bit in the security suite?

The articles I'm reading echo J Modi's point. For instance:

  WPA3 also contains a 192-bit security suite, aligned with the Commercial
  National Security Algorithm (CNSA) Suite from the Committee on National Security Systems, to help protect government and other secured networks, the Wi-Fi Alliance said.

Computer scientist Mathy Vanhoef thinks the

  feature [that] will strengthen user privacy in open networks through individualized data encryption [may refer to] Opportunistic Wireless Encryption: encryption without authentication. See https://tools.ietf.org/html/rfc8110


wordpress server certificate does not match url When visiting a WordPress blog using HTTPS Chrome gives me a warning that the domain on the certificate (*.wordpress.com) does not match the URL (someguysblog.com).

This seems to be a known issue. So is there any way to whitelist this URL in chrome? And should/could I just whitelist all urls with this type of wordpress domain certificate?

(In case it is important, the certificate is signed by Go Daddy G2, which appears in my list of trusted root authorities in chrome settings.)

Do not do this!

Installing this certificate dramatically reduces the security of SSL for all sites (eg: your bank), not just the Wordpress sites.

If an attacker can redirect your request from a site you intend to access over SSL to any site hosted on Wordpress, your browser will not issue a warning once you have installed the certificate as described. Attacks such as DNS poisoning and MiTM are examples of attacks that would allow this redirection to occur.

Instead of trusting the certificate, you can manually approve the certificate on each access.


brute force ssh account with key-pair authentication? Recently one of my servers has been hacked and it seems they got SSH access (logs are removed, ransom readme files created etc..). The account has a ssh certificate authentication (incl. passphrase for the private key) and I wonder if:

there's any real chance for an attacker to brute force certificate based accounts via ssh?
or the greater chance is, that they even got a trojan on my local computer and got the key file incl. the passphrase?

Brute forcing the certificate is very unlikely. More likely are:

Virus/trojan extracting the certificate from one of your systems
Vulnerability in SSH server (advanced attacker and/or outdated software)
Another entry point besides SSH. Check open ports with nmap


$_GET injection through the URL? I am building a website, and I was wondering what would happen if I left my $_GET command unsanitized in some simple case like this:

<?php
if (isset($_GET['example'])) {
    $object_name = $_GET['example'];
}else{
    header( 'Location: ./index.php');
    exit();
}
echo $object_name;
?>

Where I am taking some input for the url www.example.com/file.php?example=30 Is there anything I could replace 30 with that would give me access to write code directly onto the website's backend, or other bad things?

Also, if I didn't have print there but instead passed that variable to something more complicated, is there any risk to leaving it unsanitized? What is the best sanitation method? Would htmlentities() stop everything?

What your example basically does is echoing back whatever you give it. That means that an attacker could craft a link with some content in the URL, and whoever clicks the link will be served the content the attacker chose.

So how can that be used, other than to mildly embarass you? That depends on the content type. Since nothing else is specified I asume that it is text/html. If an attacker can serve HTML, she can also serve scripts that will be run in the browser as if they were from your origin. This in turn means that the script could e.g. steal authentications cookies, keylog passwords or perform actions on behalf of the victim. What you have here is a prime example of reflected XSS, and that is very, very bad.

But could the attacker run code on the backend, i.e. the server? No, not directly. The response is sent to the client, after all. But this could be used as a spring board for privelige escalation that could easily lead to remove code execution if there is some kind of weakness in whatever webapp you are using that e.g. lets administrators modify PHP code.

So how do you sanitize? That is a question to broad to answer in full here, but let me at least say this: htmlentities() will protect you in some cases but not all. To understand when it is useful and why, read its documentaiton and the OWASP XSS prevention cheat sheet.

As pointed out in Tom's answer, doing other stuff with the unsanitized data will lead to other problems, e.g. SQL injection if you use it in SQL queries.


Relaxed access to tcpdump I'm looking to do some packet sniffing on a computer that I do not have privileged access on. I am considering asking the admins to allow users in a specific group access to tcpdump. Specifically, I am thinking about asking them to change the group owner of /usr/sbin/tcpdump to the specific group. https://askubuntu.com/questions/530920/tcpdump-permissions-problem

If access to tcpdump were relaxed, what kinds of impacts to the security of the system would I have to consider?

Thanks.

Mainly that the data in the unencrypted traffic could be read by that user and that knowledge of the networking setup (i.e. what IP of the file server is) and any login credentials that might be hard-coded into any of the applications and sent unencrypted. If you are able to switch users and someone else were to log in then their network data would be at risk too.


Penetration Testing List I have been to various documents such as OSSTMM, NIST 800-115, PCI DSS pentesting document. But is there any place where I can find out baseline list for internal network penetration testing? For example, a list which has a common application list which I should be checking for penetration testing in Windows, Linux, Network devices etc.

Its in general up to the pentester, the context, and your abilities...you can check those links for hints:

Network Penetration Testing Checklist
Web Application Penetration Testing Checklist
Pentest methodology


Standard to represent digital signature on paper Users are making a deal using the website. Website generated PDF file (something like contract or report). Users perform digital signing of this file (analogous to hand-written signature on paper contract). They use government-issued RSA certificates.

Currently this works as follows:

I'm generating PDF file once. Then I calculate SHA-512 checksum of that file. I send this checksum to users, they perform digital signing of this checksum and sending me their certificate and their signature.

When I generate PDF, I incorporate QR-code with URL: https://server.com/deal/123/report. User can print PDF, scan this QR-code, navigate this URL, enter his login details and download PDF using that URL. There's nothing to prove that anyone signed that PDF (though I have signatures in database and can prove if necessary).

Is there some standard for those things? Like digital signature, printing it on paper, verifying with some standard software, etc.

I'm thinking now of the following approach:

Start is the same as now, but when users signing first PDF, second PDF generates with their signature incorporated as QR-code. First PDF is not removed, of course, so user can download first PDF and using information from QR-codes of second pdf user can check that signatures are indeed correct. But, of course, he needs special software to check that.

Your question is a good one. The basic issue is that a digital signature is associated with digital data. And (equally importantly), access to the original digital data is required in order to verify the signature or signatures.

Therefore, the transmission medium needs to be digital.

Three answers:

The paper copy is a pointer to the real (digital) original

In this scenario, the paper print out contains a QR code to the real original, which is stored on a server. There is no need to worry about proving the validity of the paper print out since it is merely a pointer to the real original, which is stored on your server.

The recipient (the relying party) would always need to look up the server copy to see what it contains and to verify its standard digital signature.

You would want to put a minimum of information on the paper printout since you do not want a recipient to think that they can rely on the contents of the paper printout--they can't and shouldn't rely on it, it is not reliable.

The paper copy would simply say "The agreement was digitally signed on date by signer. Download the original and verify its signatures by using the QR code."

I would suggest that you not require any user names or passwords in addition to what is contained in the QR code itself.

The paper copy's data can be verified

In this case, you want the recipient to be able to verify the paper copy's data without needing an online version of the data. Unfortunately, regular print on paper is not digital (OCR is not 100% accurate or repeatable.)

So I would re-cast your question to be "How can I reliably transmit digital data using paper?"

There are answers for that these days including 3d bar codes and special OCR fonts. Depending on how much content there is, you would include the original text as a digitally signed pdf file in the QR code. You could include a copy of the original text on the page.

You would have the same problem as above--if the document's text is readable on the page, then verification that it is the exact same as the text that was signed is very difficult or impractical. On the other hand, disputes are infrequent. The printed version could be verified when necessary.

The paper copy is a representation of the signed data

These types of documents are accepted by relying parties all the time (they're called faxes). There is plenty of case law about the legal validity of a faxed document. The laws differ by state and country, so consult a local lawyer.

If a facsimile of the original document is acceptable and legal, then you can simply print out a representation of the digitally signed document. Hopefully a graphic signature was supplied by the digital signer. If not, you can create one using the signer's common name from their certificate and a script font. The important issue would be to include a reference number to enable the original, digitally signed document to be retrieved if needed by a challenge. DocuSign and other vendors do this. Note the reference number for the online version.


Can data be restored from a hard drive after using magnets to wipe the data? Can a 512GB SATA hard disk be successfully restored after using magnets to wipe off it's data?

From the movie: "The Core", https://youtu.be/g3KPSyNxnL8, rat using magnets to wipe his drive and puts his CDs in the microwave.

The only accepted way to erase data from a hard drive using magnetism is through a process called degaussing, which involves using an extremely powerful electromagnet which alternates its polarity thousands of times a second. It is the changing magnetic field which erases data, not the presence of magnetism itself. A human being cannot rotate a magnet fast enough to effectively degauss a hard drive. Most likely, if you put a strong magnet to a hard drive, you will just damage the delicate head inside it, but not irrecoverably destroy all the contents of the drive.

So yes, data most likely can be recovered from a hard drive that was exposed to a magnet held to it by a human.


Can an SSL client send CLIENT HELLO with version 3.2 and NOT negotiate 3.1 Can an SSL client send CLIENT HELLO with version 3.2 and NOT negotiate 3.1.
For sslv2 and 3, one could do that by sending ssl23 CLIENT HELLO or SSL3. Please provide input on how one can support 3.2 but NOT 3.1 or if it is even possible.

There is a theoretical way which is explained in appendix E of RFC 5246; but its implementation is not necessarily easy.

In the ClientHello message, the client sends a "protocol version" which is the highest that the client supports (and is willing to use). This includes the implicit message "but I may support some older versions as well". The server then chooses the version which will be used, and states it in its ServerHello message. For instance, the client may have sent "up to TLS 1.1" (encoded as 0x0302) and the server could respond "we'll do TLS 1.0" (encoded as 0x0301).

There is no way for the client to proactively announce exclusions (as in: "I support TLS 1.1 but I don't want to do TLS 1.0"). However, if the server tries to use a protocol version that the client does not want to support, then the client always has the possibility to close the connection. Appendix E says that:

  If the version chosen by the server is not supported by the client
     (or not acceptable), the client MUST send a "protocol_version" alert
     message and close the connection.

In all generality, if the client wishes to support only a non-contiguous set of protocol versions, then he can enforce that by dint of using several connection attempts. For instance, suppose that, for some reason, the client wants to do TLS 1.1 or SSL 3.0, but not TLS 1.0. In that case, the client may first send a ClientHello specifying TLS 1.1 as highest supported version, and, if the server tries to use TLS 1.0, the client may close the connection (preferably with the "protocol_version" alert message), and then connect again, this time sending a ClientHello specifying SSL 3.0 as highest supported version.

This works only if the usage context is such that the client can attempt several connections (e.g. we are talking about HTTPS, with TCP connections that the client can open at will).

In practice, a server or a client usually supports a contiguous range of protocol versions (e.g. supports TLS 1.1 and 1.2, but not 1.0 or SSL 3.0). In that case, a single handshake attempt is sufficient: either the server will choose at the first try a protocol version which will be acceptable to the client, or there is no version which is acceptable to both client and server and it will never work.

Whether a given implementation of a SSL client offers an API to disable support of an old protocol version, is another question, of course.


If you could have only one book on web security, what would it be? If you could have only one book on web security, what would it be?

Many people do recommend this one book: The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws, which I also find very useful. But you should not rely upon only on one book. This book was released back in 2007 year, now there have appeared many new technologies. So, besides books you should follow standards, RFC's and other documents. I know other really good and fresh book. I have only hard copy in German, not aware if it is available in English - Sichere Webanwendugen.


Do you detect/react to DNS tunnelling? I've just seen a talk about tunnelling TCP/IP over DNS requests, because port 53 UDP is usually open and unfiltered. What techniques exist to detect and block such tunnels, and have you ever seen that tunnelling on a real network?

The technique uses base32-encoded requests for TXT records which result in base64-encoded responses in the answer. Banning TXT records outright seems a bit harsh, so perhaps anomalous traffic needs to be searched for. I don't know of any tool that specifically handles this case.

The most systematic answer is to implement split horizon DNS in your infrastructure, such that only internal addresses resolve; clients then must use a proxy server to connect out to the internet, and the proxy server resolves external DNS for them. This is particularly effective if your core network doesn't have a default route, so that packets destined outside your network are dropped.

The downside, obviously, is that retrofitting those controls into a running environment is likely to be an expensive and complex proposition...


Is it possible to export user account certificates remotely with NTLM hash authentication? The EFS encryption uses user certificate, generated with his username and password, to encrypt the files so that only that user can access it. My question is this:

Can you export user certificates remotely(using PowerShell) authenticating with NTLM hash of that user?

If so, does that user have to be logged on?

It is a domain environment, and said user would be a standard domain user.

The cert's private keys are protection by DPAPI which uses the user's password as part of the KDF.  That means that NTLM will not work, as the actual password never ends up on the remote host.
https://msdn.microsoft.com/en-us/library/ms995355.aspx?f=255&MSPPError=-2147217396

You can export the certificate, but not the private key.


How does DOCTYPE selection affect security of my AJAX app? I'm considering using modern techniques to protect my Javascript code and am studying how the DOCTYPE element selection may impact that.  Specifically, the linked question used IFrames which are not permitted in certain selections of DOCTYPE.

In taking a broader view of this question, not specifically linked to the IFrame protection, are there any other considerations to take into account when choosing a DOCTYPE for my site?

Document types (or DOCTYPE) is a declarative and semantical element which is part of the W3C specification regarding markup languages documents (such as XHTML).

Their presence (or non-presence) within a markup document does not influence a whatever security aspect when they are being rendered and processed by a web browser.

If you are writing an XHTML 1.1 document, there is a DOCTYPE for it, same if you are writing an HTML5 document.

We say that these elements are essentially semantical rather than functional.


Rainbow Tables: What is the Reduction Used for? This is a follow up from this answer.

The answer is very good, and it put me to thinking and doing some research. I have found another good explanation on this site.

At some point, the author says:

  If the set of plaintexts is [0123456789]{6} (we want a rainbow table of all numeric passwords of length 6), and the hashing function is MD5(), a hash of a plaintext might be MD5("493823") -> "222f00dc4b7f9131c89cff641d1a8c50".
  In this case the reduction function R() might be as simple as taking the first six numbers from the hash; R("222f00dc4b7f9131c89cff641d1a8c50") -> "222004".
  We now have generated another plaintext from the hash of the previous plaintext, this is the purpose of the reduction function.

However, I don't seem to have grasped the use of the reduction as it seems pretty arbitrary. How does reducing a hash to its first numbers help retrieving the plaintext. Is the choosing of the reduction (that is selecting the first few number of the hash) really arbitrary? Could I instead of taking the first six numbers use, say, the last six numbers?

It's a way of making a compromise between storage and computational requirement.

It's an implementation of a hash table: instead of storing all possible unique values in the table (which will result in real problem for storing indexing and searching the result), you simply reduce the number of computation needed to find a valid hash.

Basically, when you build the rainbow table, you create a hash (here called a reduction function because it reduces the size of the key space) of the result for each entry you try. You then store the original value in a bucket that is labeled with the result of the reduce function.

When you use the rainbow table, you do the following: you take the hash value you want to reverse, pass it trough the reduce function and look what inside the bucket that has that tag: you then try to hash each of the elements in that bucket and see if it matches your original value.

As to how to pick a proper reduce function, you will want one that will let you regroup all the data you see in manageable chunks: you don't want to have just a few large buckets or too many small ones. That's where a balance must be found. Other than this, exactly how you select that reduce function is not really important: you should try to use something easy to compute, that will split your data in statistically equal buckets and that will be easy to handle for your environment so, if you'd rather pick the last 6 numbers instead of the 6 first, it wouldn't matter in the end.


How do companies manage resources shared with 3rd parties on cloud platforms? Over the years people at my company have shared resources on cloud platforms with 3rd many parties. This can be files on Google Drive, articles on Confluence, repositories on Github, slack channels, really anything on a cloud platform that allows for collaboration. 3rd parties include ex-employees, clients and ex-clients, partners and suppliers. Over time this is becoming a significant security risk with data such as documents containing trade secrets or personal data shared  with external entities, who no longer have a legitimate need for this data. Some of these documents are still being updated from time to time by people in the company who are unaware who else has access rights! Is this a common situation? How do companies usually manage cloud resources? Is it all down to how diligent (or not so dilignet) the account admins are?

Take Google Drive as an example. The platform allow you to share files with people outside of an organization. As clients, suppliers and employees come and go we've accumulated a large amount of files on these platforms that are shared with people who don't really need to access them any more. The process of going through all our files, and determining who needs access and who doesn't is very painful, and needs to be done on a regular basis. Is there a better way? How do other companies manage this?

When you have a larger organization with a diverse IT infrastructure, then you have to get used to the fact that Identity Management becomes a full-time job. You need someone (or even a whole department) who is responsible for managing user accounts on all the IT resources you have. They (and they alone) are responsible for:

Creating accounts for IT systems
Assigning permissions
Revoking permissions when the functions of people change
Checking regularly if accounts are still actively used and lock them when they are not
Checking regularly for accounts with critical permissions and evaluate if they are still required
Maintaining records of all these activities so you can always tell who had which permissions during which timeframe (critical in case of a data breach)
Slapping people who put company data on cloud services not managed by them

When you want to minimize the work overhead for this, then you might want to consider to centralize and consolidate your IT infrastructure. Instead of distributing your IT infrastructure all over the net, you might want to consider to host more of it yourself. For every product mentioned in the question there is a solution you can install on-premise. This gives you far more control over your company data (have you actually read what you allow Google to do with your company secrets you upload to Google Drive?). It also gives you the ability to centralize the account management in your company. Many products support protocols like Kerberos which allow them to use user accounts from a centralized system. When every employee and business partner has just one account for everything in your company it becomes a lot easier to manage (for you and for them too).

"going through all our files, and determining who needs access and who doesn't" is something you shouldn't have to do. Proper enterprise-scale permission systems should be role-based. You don't get access to /project_x/business_plan_V14.67.docx, you get the "projectx participant" role which gives you access to /project_x/*.


Is brute force a probable threat even if you enable CAPTCHA and rate limit logins? Let's assume CAPTCHA is enabled with account lock out control (after five continuous failed attempts, the account will be locked for 15 min) on a system.

Is brute force still a probable threat?

The protections you describe are good ones that you should consider, but there can still be weaknesses:

Many CAPTCHAS can be solved by robots, or you can easily pay people to solve them en masse for you (there are companies selling that service).
Account lock out is a good idea, but if you do it based on IP someone with access to a botnet could retry login on a single account from different IP:s until they get in.
Offline brute force is still a problem if your database gets leaked. If the attacker has access to the password hash, they can try all they want on their own system. That's why you should use good hashing.


How is a service running at a specific port discovered and how to hide it? I have my Raspberry Pi accessible through SSH and I do not want it to reveal any information to port-scans such as below:

How do port-scanners (I used Advanced Port scanner on Windows 10) get so much detailed information about the service and the OS (not just for SSH - I mean generally). Which part of the target OS reveals that info and how?
How can I make it so that no information is revealed?

How do port-scanners ... get so much detailed information about the service and the OS

Depends on the specific service. For SSH a simple TCP connection to the service is sufficient since the server will reply with this information, i.e.
 $ telnet some-openssh-server.example.com 22
 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1

Similar trivial are information to gain from HTTP since systems commonly announce these information. Of course servers might actually lie about their version and OS, in which case this lie will usually be accepted by the scanner.

How can I make it so that no information is revealed?

The best way is to prevent the scanning in the first way. This can be done by only accepting connections from specific IP addresses, by requiring some port knocking before the port gets opened or similar. One might also try to change the provided details in the server configuration. If this is possible and how it is done depends on the specific server software.


Hardening Linux desktop machine against people from my household I am looking to make a clean install of a Debian system on my home desktop. To clarify, I am switching from Windows and wish to use it as my day-to-day home OS - I'm not going to be running any servers or anything like that.

I also have reason to believe that some members of my household (who have physical access to my machine) would try to gain access to it, and look through my data or possibly even install a keylogger.

For the purpose of this question, please ignore the social aspects, except for the fact that I cannot act openly confrontational, so e.g. locking my room to prevent anyone accessing my PC is not an option.

The people I want to protect against are technologically literate; they know their way around linux even if they may lack much experience with it, and if something can be found with some googling and takes maybe an hour or two of messing around then it's most likely going to get attempted. That said, I am pretty certain that acquiring specialist equipment is not something they would bother with, which means that I don't have to worry about most hardware attacks, e.g. a keyboard keylogger or bug on my mobo / RAM sniffer / whatever.

One other thing is that I have a Windows 7 system to which they have admin access (so it can be considered compromised). This is one of the reasons I am switching to Linux; however, I'd like to keep a dual-boot system rather than removing Windows outright. I am aware that this would allow an attacker to outright nuke my Linux partition, and that is a risk I'm willing to take.

I am not concerned with securing my Windows system. I am aware it's compromised and don't really care what happens to it. As I mentioned, other people have accounts on my Windows system and occasionally use it (for legitimate reasons!). I am certainly looking to secure my Linux installation, but preventing access to Windows has no point unless it contributes to the security of the Linux part of my machine. In fact, I'd rather avoid limiting access to Windows if possible because I don't want to appear paranoid or create conflict in the household.

Full-disk encryption will prevent anyone from actually accessing my data from outside my Linux installation itself, which should then take care of both the Windows system and even make booting from a USB drive mostly useless (I am quite certain that the people in question do not have the resources or the motivation to decrypt a well-encrypted drive). I will also need to password-protect the single-user mode, of course.

What other things would I need to do to secure my system? I am handy with the command line and willing to get my hands dirty, but I have limited Linux experience and fragmentary knowledge of computer security. The choice of Debian is largely arbitrary and I would have no problem trying out a different distro if it would be better in my case. If there's anything I've missed, or if you have tips on things I mentioned (e.g. best practices for disk encryption?), then I would be glad to hear them.

I do not believe this question is a duplicate because all of the other questions I found on securing Linux on this site concern themselves with remote attackers and protection against viruses and exploits. They certainly have good answers but that is not the kind of information I am looking for here.
Another question has been brought to my attention when my post was flagged as duplicate. However, that one asks in general whether their machine is secure when others have physical access to it; the answers to it generally boil down to "Physical access = game over" and provide some tips to mitigate various attacks (including things such as rearview mirrors on your monitor). Many of those tips are not applicable here, since I am aware that unlimited physical access means the machine isn't mine anymore in theory, and hence I provide some limitations to the attackers in my threat model which fit my personal scenario.

Use a strong and difficult password for the root user. Secondly, always login and work from another user with no administrative rights (and also a strong password).

Enable the BIOS password option. Every time you power on your computer, the BIOS itself will ask you for a password before even booting on. It will also prevent everyone from applying changes to the BIOS setup.

Encrypt every partition of your hard drive (check cryptsetup for Debian - if it can't encrypt you Windows partition, too, use TrueCrypt (from Windows for your Windows))

Watch out for external hardware devices connected on your PC (like USB sticks or hubs) that you haven't used before. Someone might have plugged in a keylogger or something.

Always lock or power off the machine when you are away.

Software hardening:
Install gufw (GUI for the iptables firewall which is pre-installed) and block incoming traffic. Also install rkhunter and check your system for known rootkits and other threats from time to time.

That's all I can think of right now. If you have any questions feel free to comment below.


How does LetsEncrypt.org's ACME work? I found the technical paper on ACME's inner workings, but I still feel a bit confused about the ways Let's Encrypt's  Domain Validation works.

From what I already know, verification can be performed over either port 80 or 443. Client connects to the server, which tells the client to put a specific file on the server.

Does the client decide which port is used?
Can the data be put anywhere within the server?
How does ACME actually work in the Let's Encrypt example?

The ACME spec lists a number different challenges:

  Identifier Validation Challenges
  7.1. Simple HTTP
  7.2. Domain Validation with Server Name Indication (DVSNI)
  7.3. Proof of Possession of a Prior Key
  7.4. DNS

If I had to summarize the detailed process (about two screens full) given in section 7.1. Simple HTTP, then I'd say it goes a something like this:

Client: Hey server, my customer number is x, challenge me!
Server: Okay, put a file named y on your HTTP(S) server and sign it with your customer number key.
Client: Done.
Server: Lemme check... Okay, here's your certificate.

There is also a description of that process with screenshots.

  Does the client decide which port is used?

Yes. But you can only pick between http on 80 or https on 443.

There is a long-running discussion about whether to allow other ports.

  Can the data be put anywhere within the server?

No. I think you're bound to this path:

  The path at which the resource is provisioned is comprised of the fixed prefix “.well-known/acme-challenge/”, followed by the “token” value in the challenge.


What to do after being phished for address, DOB and NI number? When someone has given away their details as above, can anything be done to preemptively prevent identity theft?

Address, date of birth and national insurance number are obviously not passwords that can be changed.

National Insurance number suggests you are UK based. For protection from financial fraud you would go for protective registration with CIFAS and ask the three credit agencies (Equifax, Experian and Callcredit) to put notes on your files that all loan applications should be checked with you.

Most serious identity matters which do not use credit agencies will ask to see photo-id proof such as a passport or driving license. For passports these are hard to replace without holding the previous document - it often involves being called in for an in person interview - which offers some protection against fraud. Obviously if you have never held a passport before there is higher risk. Driving licenses are easier to obtain fraudulently. However the DVLA will use your passport photo if available - so it is still difficult to obtain one with an image of someone else.

Other nations have other systems. But in most places there is some form of credit agency which can be notified. Some countries (Estonia for example) use electronic ID cards.


Security Researchers: How do you choose what services or software you are going to audit next? Security Researchers: How do you choose what services or software you are going to audit next?

I am referring to finding vulnerabilities and developing exploits in various applications. I am wandering how decide what software you will target next?

I audit a lot of code, I write exploits,  and I have accumulated more than 50 CVE's over the course of about 6 years of bug hunting.

When I went on my first serious bug hunt I was looking for weak projects that had not be extensively audited by the community(or milw0rm back in the day).  To do this I used SourceForge's Advanced Search,  which has changed a lot.  Basically I was looking for a PHP project that people where downloading and using,  but wasn't very popular.  Lets say around ~1,000 downloads and less than 1 year old.  I found Ultimate PHP Board which turned out to be very insecure.

As time progressed I got bored with insecure projects so I changed my tactics entirely and started going after popular projects.  For example I exploit PHPMyAdmin which is the most downloaded PHP application.

After years of penetration testing and application development you get a kind of 6th sense into how the code works and where the problem areas can be.  You can look at a piece of functionality and write an implementation in your head and pick out where things could go wrong.  So on a penetration test I always ask my self the same question: "What is the worst that could happen?". And then go out and focus my testing based on this question.

I'll give you a good example. I saw an advertizement for Canonical Landscape (Maker of Ubuntu).  In the ad it showed a feature of Landscape where you could execute a command on every machine you own as root.  I thought to my self,  "What if it was vulnerable to CSRF?".  I signed up for a free trail,  and sure enough,  you could gain remote root on every machine using a single forged HTTP request.  Outch!  (I also got remote root on cPanel with CSRF, and I earned a severity metric :)

Another flaw I found in Google Music, I uploaded an MP3 that had JavaScript in all of the ID3 tags.  Sure enough the artist and album names where being printed to the page,  and I got $500 from the bug bounty program with my very first test.  One of the reasons why I chose this input is because i knew it wouldn't be exercised by a dumb vulnerability scanner.  Its as if I knew it would fail ahead of time. That kind of innate understanding only comes with years of practice.


Methods root can use to elevate itself to kernel mode When most Linux users hear "root", they think of the maximum possible privilege on a computer. Some even think that root runs in ring 0. But in reality, root is just a regular user running in ring 3, albeit one which the kernel trusts (many sensitive kernel operations are guarded with checks along the lines of if (!uid_eq(current_uid(), GLOBAL_ROOT_UID)) return -EPERM; to prevent abuse, which simply returns an error if uid != 0).

On most Linux systems, the kernel trusts root so much that it can easily exploit the kernel and gain access to ring 0 at will. However, it is often possible with security tools such as grsecurity, SELinux, etc, to prevent this by reducing root's dangerous abilities, and enforcing these restrictions on the kernel level.

I would like to enumerate a list of methods by which root could exploit the kernel to gain access to kernel mode and ring 0. So far, these are the methods I have thought or learned of by which this could happen, along with potential mitigations:

ioperm() and iopl() can set I/O port permissions and can be abused to write to arbitrary regions of memory, including memory where the kernel resides. These syscalls can be disabled by removing them from the syscall table or with grsecurity.
Root can just modify the kernel image in /boot or through the block device. A MAC can restrict root's access to both of these.
/dev/{k,}mem are designed to allow rw access to arbitrary memory. These can be disabled completely in the kernel config, by using grsecurity, or with a MAC.
Some MSRs can be used to write to arbitrary memory. Denying writing to MSRs either by disabling them in the kernel config or with grsecurity mitigates this issue.
kexec allows root to select an alternate kernel to boot into. This is an optional kernel feature, so simply compiling the kernel without kexec support is enough to make this a non-issue.
sysfs provides low level access to much of the hardware, which can hijack a poorly locked-down BIOS/UEFI on many vulnerable systems to gain ring 0, or even ring -2 access. A MAC can restrict access to /sys, and various tools can detect vulnerabilities in UEFI/BIOS.
If root is allowed to load ACPI tables at runtime (DSDT, SSDT, etc), it can cause the kernel to execute AML, which is ACPI bytecode, and change how the kernel behaves and reacts to the hardware it runs on. I know little about ACPI and AML, but this sounds like an absolute recipe for disaster. Disabling loadable ACPI table support in the kernel should mitigate this.
Loading malicious kernel modules can directly hijack the kernel. This can be trivially defeated by requiring module signing, or by building a kernel without module support.

Obviously, I will be using principal of least privilege for root, rather than trying to blacklist all the possible ways it can break out of its chains. That doesn't change the fact that it is still extremely useful, and interesting, to understand all the ways it can abuse the kernel's trust.

And so that brings me to my question: Are there any other methods which root can use to gain access to ring 0, without using 0days and without exploiting opsec mistakes, which I have not covered here?

I can think of these:

Indirectly modifying kernel image or signed modules by changing update or other system configurations (point update server to yours, add your keys). Or by compromising infrastructure where the updates come from.
n-days. syzkaller reports quite a few bugs and some remain unfixed for a while. https://syzkaller.appspot.com/
Loading firmware onto a device that can directly interact with RAM (e.g. PCIe, firewire devices).


What does Microsoft mean by "Trusted Domain" in relation to Kerberos? In the Microsoft documentation about using Kerberos, it is stated that:

  Both the server and the client computers must be members of the same Windows domain or members of trusted domains.

If this criteria fails then Windows will revert to NTLM authentication.

I understand the concept of a client computer being in a Windows domain will satisfy the criteria for sharing the Kerberos authentication but I am interested in the other part of the OR criteria, "or members of a trusted domain".

How is this membership defined? The definition here is not very clear. More specifically I would like to provide membership to a Linux based machine. Is this outside of the Microsoft's intended design when they designed the definition of a "trusted domain"?

Trusted domains are other Active Directory domains from which security principals can be recognized. For example, a child domain controller can recognize accounts from its parent domain, and principals from the parent domain can be members of security groups in the child domain. In two-way trusts, either domain can recognize security principals from the other. (Parent-child trusts are automatically created two-way trusts, but you can set up any kind of trust you want manually.) Trusts can also link domains that were previously completely separate, i.e. not part of the same forest.

There is a trust password used to set up the secure channel. You can manage trusts with the Active Directory Domains and Trusts snap-in.

Further reading: Trust Relationships


What is the best strategy for handling a compromised private key within the domain of firmware? I have a firmware project that uses asymmetric cryptography for assuring integrity and authority of updates. The private key is stored within the company, and the public key is on the firmware to validate the integrity and authenticity of an update attempt.

Currently, the public key to be used for verifying the signature is 'written' (in NV data) only on factory updates, so the customer can't just overwrite the FW by adding it's own key.

I want to implement a strategy for handling the case of the private key being compromised. Are there any standards or similar documents to refer to?

Some context: The unit with the firmware will not have internet access. A compromised private key would need to have its associated public key replaced manually on-site.

Put multiple public keys in the firmware, with the corresponding private keys stored in diverse locations. Require that updates are signed with all of the private keys, not just one key. Never bring the private keys together, not even for code-signing — instead, move the code around between the locations where the private keys are stored so that each one can sign the code in turn. Then the compromise of one private key will have no impact.


HTML encoding to protect against XSS While going through some references about protection against XSS i found that it is a good practice to encode data (entered by users) before using it to generate a dynamic page. I was not able to find out a detailed explanation of this statement.my question is

How does encoding help prevent XSS?
Does it provide full protection against stored XSS?
Are there any other countermeasures that need to be taken into consideration.

(Copied from my answer on StackOverflow )

No.
HtmlEncode simply does NOT cover all XSS attacks.
Encoding is the correct solution, but not always HTML encoding - you need context-sensitive encoding.

For instance, consider server-generated client-side javascript - the server dynamically outputs htmlencoded values directly into the client-side javascript, htmlencode will not stop injected script from executing.

Next, consider the following pseudocode:

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Now, in case its not immediately obvious, if somevar (sent by the user, of course) is set for example to

a onclick=alert(document.cookie)

the resulting output is

<input value=a onclick=alert(document.cookie) id=textbox>

which would clearly work. Obviously, this can be (almost) any other script... and HtmlEncode would not help much.

There are a few additional vectors to be considered... including the third flavor of XSS, called DOM-based XSS (wherein the malicious script is generated dynamically on the client, e.g. based on # values).

Also don't forget about UTF-7 type attacks - where the attack looks like

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

Nothing much to encode there...

The solution, of course (in addition to proper and restrictive white-list input validation), is to perform context-sensitive encoding: HtmlEncoding is great IF your output context IS HTML, or maybe you need JavaScriptEncoding, or VBScriptEncoding, or AttributeValueEncoding, or... etc.

If you're using MS ASP.NET, you can use their Anti-XSS Library, which provides all of the necessary context-encoding methods.

Note that all encoding should not be restricted to user input, but also stored values from the database, text files, etc.

Oh, and don't forget to explicitly set the charset, both in the HTTP header AND the META tag, otherwise you'll still have UTF-7 vulnerabilities...

Last point, regarding Stored XSS - since you would be doing the encoding during the page generation, on the data output, it is agnostic as to the source of the data, whether from user input (i.e. Reflected XSS) or Database/files (i.e. Stored/Persistent XSS). (So basically yes.)

Some more information, and a pretty definitive list (no longer updated), check out RSnake's Cheat Sheet: http://ha.ckers.org/xss.html


Can you pass C|EH without any hands-on experience in hacking tools I've been in the IT security industry for well almost a year now since I graduated last year and I'm currently thinking about taking up C|EH examination. I've glanced through several prep and review books and found that C|EH seems to be quite straightforward.

I do not have hands on experience on most of the hacking tools listed in the books but I do use some of it on a daily basis e.g. tcp/windump, nmap, wireshark, etc. Plus, I noticed that C|EH is more towards guiding users on how to use the tools which is available in the tools man pages itself. I do not wish to spend too much time learning each and every tool suggested by C|EH.

As such is it possible to pass C|EH exam without any hands-on experience in hacking or hacking tools?

Having taken the C|EH fairly recently, I'd reccomend following their guidelines in knowing the command line parameters and expected output of the most common tools. I think it is 10% of the exam according to their materials and since they don't offer any man pages you can just write off that part if you aren't at all familiar with the basics (nmap, netstat, ipfilter, nslookup, etc.)


Is it a bad idea to let the user responsible for his own symmetric key? I work for a company that provides a web app where we would like to give the user some sort of "digital safe". In this safe, the user can store and download whichever files he wants.

The idea is that the system generates a symmetric key for an user and this key will be used for encrypting and decrypting the files inside the safe. This key will only be generated once for the user and as soon as he downloads it, it will be deleted from the server. If the user wants to see what is inside the safe or wants to put a new file inside, he will have to provide this key. As all files would be encrypted at rest, this should keep us safe in case someone gets access to these files on the server. Plus, if someone manages to steal a users account and password, they still wouldn't be able to see the files unless they also managed to steal the key.

The objective is to really transfer the responsibility of keeping this key safe to the user. We are aware if he loses this key he will never be able to retrieve what stores in the safe again. The idea is to make us less accountable for what he is storing in the safe and to show that not even we, the creators of the web app, have access to his data.

So, summary: disclosure is important. We want to let the user encrypt files and protect them from ourselves and from potential intruders, even if the user's username and password leaks. Letting the user be responsible for his key should make us less accountable.

Is it a terrible idea to let the user be responsible for his encrypted data?

Given the alternative scenario, where you store the key, in order to ensure privacy you need to authenticate the user - so effectively the users password becomes a surrogate for the key.

It's quite possible to implement the key generation and encryption / decryption on the browser - which avoids a potential disclosure of the key in transmission / on your server. This also solves the problem of disclosure requests - working out what third parties are actually able to demand disclosure can be a bit of a problem. On the other hand, there is some value in providing a service where managed disclosure is part of the offering (e.g. individual accounts are set up as part of a group - e.g. a corporate entity - and the corporate entity can establish formal criteria under which the information can be disclosed to another member of the group).

i.e. whether its a bad idea depends on the business model.


Browser cache information disclosure Observing the time needed by a browser to load external resources such as images potentially discloses information about whether those resources have been accessed before.

Explanation:

For example, by embedding the StackOverflow logo within a third-party website via <image src="https://cdn.sstatic.net/Sites/security/img/sprites.svg?v=a1e0cd003b7d"> and observing how fast it loads, this third-party could infer whether or not the visitor has recently accessed StackOverflow.

This is due to cached resources having a much shorter load time compared to resources that are not yet in the browser cache and need to be transferred over the internet.

Load times can be observed by several methods. One of them is to attach a DOM onload event handler and measure the duration from requesting the source until the load event fires.

This method has some pitfalls which need to be taken into account:

HTTP response headers might prevent or limit caching
Initial DNS resolution might take some additional time
The resource URL might contain some variable tokens

Example:

However, it usually works pretty well. The following snippet for Chrome allows to verify if and when a user visited pornhub.com [NSFW]:

function cached(src) {
  return new Promise((resolve, reject) => {
    const img = new Image();
    img.onload = (event) => resolve(src);
    img.onerror = (event) => reject(src);
    img.src = src;
    setTimeout(() => img.src = '', 10);
  });
}

cached('https://bi.phncdn.com/www-static/images/pornhub_logo_straight.png?cache=2018011910').then(
  src => console.log('visited between 24.01 and 28.01'),
  src => console.log('not visited')
);

Now, above snippet is not robust and not complete. By adding more resource URLs together with the range of dates when those URLs where requested by the target website, a pretty detailed profile could be created. Of course, this is a rather extreme example to get the point across.

Question:

Inferring information via browser cache is a known issue, so are there countermeasures available to the user or the web application developer to defend against it? How is this issue commonly addressed?
Are there real-life exploits of such information disclosure?

Browser fingerprinting
The issue you are describing is one technique out of many in the field of browser fingerprinting. There are three main types of browser fingerprinting, often related. In order of amount of research, they are:

Device fingerprinting, which aims to distinguish individual users. It focuses on finding unique identifiers on a browser when the IP address cannot be relied upon for identification. This is the most well-researched, with many proof-of-concepts available, and is the hardest to mitigate. In extreme cases, this can detect unique devices regardless of the operating system or browser.

Supercookies, which are persistent identifiers that a website can inject into a browser. They are not true cookies and so are not deleted when cookies are cleared. This can be implemented with clever cache fingerprinting, HTML5 web storage, HSTS or even HPKP, for example.

History sniffing, which involves one website detecting whether or not a visitor has also visited a different, unaffiliated third-party website. This is similar to supercookies, but relies on the third-party site setting one unintentionally. History sniffing techniques can be used to implement supercookies, but the opposite is not always true. This is what you are asking about.

There is also a type of fingerprinting called TCP/IP fingerprinting, also called networking stack fingerprinting or OS fingerprinting. It involves looking at the low-level structure of the networking protocols being used by your computer (what options are set and in what order, ISN and TCP sequence numbers, etc). Avoiding this requires using a "true" proxy such as Tor (VPNs do not work as they use your own networking stack). This technique is limited in the amount of information it can gather. As this is not unique to browsers, I won't go into detail about it. I suggest you look at an example TCP fingerprinting utility such as p0f to learn more about how it works and its capabilities.
Mitigations
In order to prevent a website from detecting whether or not you have visited a given website, the browser must not keep any persistent information between the time a website is visited and another website attempts to confirm the visitation. In many cases, private/incognito mode is not enough, as it only clears specific identifiers such as cookies. The most effective solution is to have an ephemeral data directory. This is the technique used by Tor Browser, which avoids, across browser restarts, the last two fingerprinting techniques, and makes attempts to limit the first through browser patches.
Using one of the numerous "privacy plugins" and custom configurations is not an effective mitigation. In many cases, they actually add to your browser fingerprint by reducing your anonymity set while not removing all, or even most, of the tracking vectors. A complete solution requires a standardized browser running a standard version, with heavy patching to remove various functionality that can be abused for fingerprinting. Tor Browser does this, but even it is not perfect and there are many open tickets for extant fingerprinting vectors, with varying levels of impact. For example, there are multiple open tickets for several different ways to identify what operating system the browser is running on.
The most effective strategy to mitigate browser fingerprinting in general would be the following:

Use an up-to-date and official version of the Tor Browser.
Set the "security slider" to high, which disables JavaScript (a common fingerprinting vector).
Do not modify any configuration settings or install any plugins.
Restart the browser to clear the fingerprint, as it can only isolate identities between sessions.

This may be necessary even if you only want to avoid history sniffing and do not care about device fingerprinting or supercookies. All other browsers, as far as I know, will keep a certain state even across resetting the profile or invoking private/incognito mode, which can then be used to detect whether or not you have visited a certain third-party site.
Real-world implications
There are various news articles and papers discussing ad networks that have been caught using various forms of browser fingerprinting to track users across sites and users who clear cookies (or browse in private mode). I am not aware of any particular incidents involving the browser cache, but most likely that is because there are other, more robust techniques to use. Ad companies typically use device fingerprinting, with canvas fingerprinting being one of the most common vectors, with more advanced and stealthy techniques such as AudioContext fingerprinting also being used.


Requiring regular password change counterproductive According to

http://www.csoonline.com/article/3195181/data-protection/vendors-approve-of-nist-password-draft.html

  "There have been multiple studies that have shown requiring frequent
  password changes to actually be counterproductive to good password
  security..."

I would like to see some of these studies and would appreciate references.

There was a healthy debate a couple of years back here, I hope it's stickied.  Lets see:  How does changing your password every 90 days increase security? was where we had this.

The NIST itself gathers feedback from industry, government agencies (most specifically: the intelligence community) and provides guidelines to government as to how to secure their systems against nations stealing them.  I realize that's an appeal to authority and not a reference, but hopefully it helps provide context for the NIST.


Best method of retiring hard drives What are some typical ways you guys retire hard drives? We have a hard drive that won't mount anymore (makes clicking sounds when it tries to mount). The data on it isn't necessarily sensitive (no financial records or the likes) but it does contain data that once belonged to an employee. We obviously can't mount it to securely delete the data. So in this situation, what's the best solution to securely and properly dispose of the hard drive?

Edit: Sorry, I didn't know if this was more appropriate here or on Serverfault. Please migrate it if it's more appropriate on the latter.

We use 3 primary methods of media destruction. Which method that is chosen will, of course, depend on any number of factors including; corporate policies regarding data handling, legal or regulatory requirements, corporate policies regarding equipment refresh/retirement, time constraints, physical condition of the device, etc.
Secure Deletion
This would include any number of methods by which we attempt to fiddle with the bits on disk. The most typical is some kind of N-pass overwrite. This has the advantage of leaving the drive intact for use later, can be done in any number of ways, and is relatively configurable. Whether you use DBAN on a desktop PC with 1 or 2 drives or something like an ImageMASSter with expansion sleds and work on 20 disks at a time. This method also works equally well on removable storage such as ZIP or floppy discs. It has already been discussed fairly well at How can I reliably erase all information on a hard drive? Since it sounds as if the disk in question is failing, then this is likely not a reliable option and moving on down to a physical destruction method may be required.
Electrical Scrambling
In the olden days when you had a room packed with tape there were few things better than a big honkin' degausser for making sure that you knew what left the room. As hard drives supplanted tape, their use simply got transferred to the new medium. The biggest advantage to using a degausser to take care of hard drives is speed. Just pass a box through the unit, ignore the jiggling in your fillings, and walk away with clean drives. The downside is the lack of ability to audit data destruction. As discussed in the Wikipedia article, once a hard drive is degaussed, the drive is mechanically unusable. As such, one cannot spot check the drive to ensure cleanliness. In theory the platters could be relocated to a new device and we cannot state, categorically, that the data will not be accessible.
Wanton Destruction
This is without question my favorite. Not only because we demonstrate, without question, that the data is gone, but the process is very cathartic. I have been known to take an hour or so, dip into the "To Be Destroyed" bin, and manually disassemble drives. For modern hard drives all you need is a torx set and time (possibly pliers). While one will stock up on their magnet collection, this method of destruction is very time consuming. Many companies have developed equipment specifically for hard drive destruction en-masse. These range from large industrial shredders to single unit crushers such as this beauty from eDR. I have personally used that particular crusher, and highly recommend it to any Information Security professional who has had a bit of a rough day.


A potential possibility of improvement of PKI for personal communications In countries like Germany each citizen has an identity card that is issued by the registration
authority.

Since the identity of a citizen is, in a sense, created by that authority via
assigning him a
unique number, why not let it also to directly certify the public key of any citizen who desires
to employ asymmetric encryption?

I mean the person would on that occasion have his identity be
once again checked by the authority (presumably much better, e.g. concerning the current validity
of the identity card, certainly not worse than, any common CAs) and then have his public key be
entered (for a moderate charge) into a list of public
keys that is freely accessible to the public at computer terminals of all offices of the
registration authority. This way, the difficult issue of trust on the common CAs (or their equivalents)
could be in the practically best feasible manner avoided IMHO.

You are proposing that, instead of using a standard PKI, where someone (goverment or not) controls a CA that signs certificates, would be simpler to just have a (big) list of government recognized public keys associated with the related person. In other words, a big searchable list of certificate contents. You claim that this would avoid "the difficult issue of trust on the common CAs (or their equivalents)"

First of all, to be sure you are checking the right and trusted list, the search server would need to be authenticated somehow (to fully avoid PKI, that is used in TLS/SSL, probably you would have to put the certificate of the server in your trust it and check out-of-bounds if it is valid). It is not clear how would you solve this in an scalable manner without using PKI. It is possible, of course, but not easier or simplier than the standard PKI trust challanges.

BTW, part of my master thesis work is about how a PKI could be to solve some of the problems of standard PKI, and we use online servers to provide certificate status and discuss many problems with standard PKIs. In many ways your proposal fits with ours, except it is not targeted on solving the trust issues of PKI, but other problems. Part of the work is available here: https://www.cdc.informatik.tu-darmstadt.de/reports/reports/TheNotaryBasedPKI.pdf

While NOT solving the trust issue, your proposal adds many other problems:

1) It is not offline verifiable. One may claim that this is not a problem nowadays, when everything is always online, and while not strictly true, I agree that for most applications there is no big advantage at the offline characteristics of x509 PKI (thats why we proposed NBPKI too)

2) For signature/verification, you need to be able to verify at any time in the future if a key binding was valid when the signature was done. For some scenarios that can take years and decades between the signature and the last needed verification. That means that even if the binding between person x key is lost, the server still needs to at any time in the future be able to give the key that was valid in a certain time in the past. So, the list only grows; That is not good because it wont scale whell, will not be efficient;

3) You have a single trust point to be attacked. Not good at all;

4) To solve all this problems is exaclty why PKI is how it is. Instead of a list, you have proofs of link between each key and each person. Those are small, and actually EASIER to validate (cost less computational power and resources). Those proofs have a presumed valididty usually based on how protected the private key is, and can be revoked if needed using a list of revoked certificates (that tends to be smaller than a list of valid ones, and can be made smaller using OCSP).

You mention the problem that is hard to trust in the common CAs. That is not strictly true, and can be solved by some means: Federated CAs, or TSL (Trusted Services List, used on Europe) or just have a national root CA as is done in Brazil that signs all other trusted CAs, so you need only to trust a single trust point. If thats the main reason to choose your proposal, I don´t see a real advantage between having a single national CA and your proposal. Other than that, PKI has so many advantages over your proposal on real usage scenarios, that explain why it is widelly used until now.

Having that said, PKI have its own problems, but most of them are exactly on the centralization of trust in FEW points, and may be solved by more decentralized approaches. Your porposal is going in the oposite direction, by proposing centralizing even more the trust in a single list.