How are server overload and DoS/DDos different? I know that server overloads are caused due to excessive number of genuine requests and DoS due to malicious request. But, my question is, if you have designed a system for Overload mitigation, does it necessarily protect system from DoS? If not why?

Denial of Service is a broad term, describing attacks that "make a computer resource unavailable to its intended users" (Wikipedia). Overloading a server is a form of DoS, but there are many other forms. You might be able to achieve the same goal by using up the server's maximum number of possible concurrent connections, not overloading the server, but using up a resource. Or by abusing a memory corruption bug Wikipedia that makes the server software crash.

So, by protecting your server against overload, you protect it against one form of DoS.


How to decrypt sensitive information with a token and a password In a web app, it's common practice to encrypt sensitive information against a user's password. In this scenario, what's how would you access/encrypt/decrypt that information using token based authentication?

If a user logs into the web app using their username/pw, which gives them access to their sensitive information, how do you create a token (say, for API access), to access/encrypt/decrypt that same information?

I think this question is actually three questions.

Username/password authenticates the user to the application.  This establishes a user identity. If you then issue them an API token, this authorizes them to use particular API functionality.  Encryption should be completely decoupled from these other actions and handled entirely server-side.  An example flow:

User A logs in to example.com. As part of the authentication flow, they are issued a signed bearer token that contains their user identifier and their permission set (standard user).  This user wants to view a private document in their account. Their browser makes an API request and passes the bearer token (plus a CSRF token, etc) with the request.  The API then validates the permission set on the token and the user identifier's access to the resource.  If the authorization check succeeds, the server retrieves the appropriate encryption key (from a secure store) for the resource, decrypts it, and returns it to the user.


What's the point in a proxy server authorizing/authenticating clients? I've implemented a SOCKS5 proxy library, but I just don't get the point of authenticating (or encrypting) connections, which the RFC (1928) seemed pretty adamant about.  Isn't anonymity the whole idea of a proxy?

I also understand that encrypting traffic between the client and server is possible, but that only covers the client-server half of client-server-destination path: isn't that kind of pointless?  Shouldn't the encryption (if it's absolutely necessary) run end-to-end instead?

This is really two questions, but eh...
What's the point of proxy authentication?
Contrary to what you seem to believe, there are many reasons beyond anonymity to use a proxy (and if you want good anonymity, you should use something like Tor rather than a single proxy). A few of those reasons:

Bypassing geographical or IP-based restrictions.
Using the proxy as a bridge between the network you're on and one you want to access (for example, getting from an internal corporate or cloud network out to the Internet, or the reverse).
Using a proxy for monitoring, logging, or filtering network traffic (for your own security, or for the security/control of a company or other entity that wants to limit what you can access on/from its network).
Using a proxy for intercepting or modifying network traffic (for security testing, or for tampering with network traffic).

For many of these purposes, there are good reasons to use authentication. For example, a geo-filtering bypass proxy may be offered as a commercial service, and they want to ensure that only paying users can access the proxies they provide. A corporate proxy wants to ensure that only authorized employees are able to access its network, and possibly also to know which employee is using a particular machine for monitoring and logging purposes. Somebody using a network testing proxy that is opened to other devices on the network may want to make sure that only their own authorized devices can connect to the proxy, rather than allowing arbitrary network users to connect and send requests either directly to the proxy or from their computer.
Additionally, having an open proxy is just risky. For example, suppose somebody used an open proxy that you run to send death threats or upload child porn or something else illegal like that, and it gets traced back to your IP address. That's not a good situation to be in (though I'm not a lawyer and am not sure exactly how much legal jeopardy you might be in there), especially if you don't have any way to demonstrate it was somebody else (such as a proxy's authentication logs).

Shouldn't encryption, if used, be end-to-end?
In general, yes, but that's not always practical and there might be reasons to want to separately encrypt the client-proxy traffic anyway. There's no reason that you can't run end-to-end encrypted traffic, such as HTTPS, through a proxy where your encryption to the proxy is itself encrypted. In fact, if you were using the proxy to conceal your network activity from your ISP or similar, you would absolutely want to do this (otherwise the ISP would be able to see your DNS lookups, the domain names of the sites you wanted to connect to, the amount of network traffic you exchange in each direction with each site and at what times, and so on). Encrypting the connection to the proxy is also obviously helpful any time you want secure authentication, although there are ways to do reasonably-secure authentication over insecure connections (such as SRP).
Also, encrypting the connection only between you (the client) and the proxy is still better than no encryption at all, which would be the case when connecting to a server that doesn't support encryption (such as one that only supports HTTP or FTP, for example). A local network attacker still can't see (or modify) what you're doing (as they could if the proxy connection was unencrypted), even though the proxy server and anybody downstream of it can.


Alternatives to cryptographic signatures I have a program I am developing and am currently using ed25519 to cryptographicaly sign messages. However, even those signatures are longer than I would like (64 bytes + the message).

The messages I am signing are generated from within my system (i.e. I am generating and signing the messages within my program, on different servers/nodes).
What are the implications if instead of encrypting the messages (with any strong cipher), I would limit the overhead of the signature?

The messages currently are 72 bits long (currently to limit collisions of a relatively small number of messages), but I am thinking about increasing that to 104 or so bits, and appending a salt to it (not sure how long is acceptable), and encrypting the salt+message. On the receiving node, I can then decrypt the message, and verify the salt (so it would need to be an acceptable length).

My overall goal is to be able to verify the message is valid, and retrieve the message (does not matter if it's visible or not) with the smallest overhead possible, with both endpoints under my control, but the communication is always stateless and easily modified by a third party.

My overall goal is to be able to verify the message is valid, and
  retrieve the message (does not matter if it's visible or not) with the
  smallest overhead possible, with both endpoints under my control, but
  the communication is always stateless and easily modified by a third
  party.

You don't seem to require encryption, since it "does not matter if [the message is] visible." Rather, you seem to just require an integrity check on the message.

So, instead of encrypting you can use a Message Authentication Code (MAC) that is appended to the plain text message. However, in order to avoid the adversary tampering with the MAC, you still need a shared secret key on both endpoints. In this case the key is an "integrity key" not an "encryption key."

There are well-known methods for creating a strong keyed MAC, one of these well-known methods is called "HMAC" (see Wikipedia for brief description).

If use use a SHA256-based HMAC then the overhead will be 32 bytes (256 bits).

Update: As mentioned in the comments, there are alternatives to the SHA256 hash function that can be used--HMAC can be used with any hash function, but for your purposes a cryptographically secure hash function (like SHA256) should be used. Also, the commentator mentions that the HMAC tag can be truncated from 32 bytes down to a smaller length such as 16 bytes. This is true. The trade-off is that truncation makes it easier for the attacker to forge a tag, but for your purposes the difference in attack difficulty in forging a 16 bytes tag vs a 32 byte tag may not be an issue.


Fingerprint FTP services without Banner message I want to write a python script that is able to fingerprint ports on a server to identify the FTP client running on the port.

While there is often a Banner message upon connection, this message is not reliable or can be removed easily.

Is there any tool / database etc available which can help to identify the different clients by behavior? e.g. by digging through source code i noticed that the PyFTPd Server uses the message "I'm going to ignore this command..." which can be used to identify that service.

I am happy for any help, as many FTP commands are supported and included in all daemons so it is difficult to find all the differences... I am trying to distinguish between

vsftpd
pureftpd
proftpd
pyftpd

The standard tool on Kali is nmap, specifically with the -sV or -A option.

If that doesn't detect your application or version properly, you can contact the developers.

You may be able to dig through the nmap source code to figure out how their detection works, but consider yourself warned: detection routines almost always includes a massive pile of regular expressions to puzzle through.

I've found nmap to be fairly reliable, but we don't run any of the daemons you've listed so I don't know if it can detect those.


Securely granting local administrative permissions I’ve been researching the best method of securely granting local administrative permissions but I’m really struggling to reconcile the security, operational, and cost implications.

I’ve devised a few options:

Create a domain security group (PC Admins), add the required domain user accounts, and use Group Policy to add the domain security group to the local security group Administrators:

Pros:

Centrally-managed.
Auditable.
Free.

Cons:

Vulnerable to credential theft and lateral movement attacks.

Option #1 but using separate domain user accounts (<original username>.admin):

Pros: Same as #1
Cons: Same as #1. Authenticating a UAC prompt creates a logon cache which can be exploited.

Option #1 but disabling cached logons:

Pros:

Centrally-managed.
Auditable.
Free.
Not as vulnerable to credential theft and lateral movement attacks in that there are no logon caches to exploit but credentials can still be captured via other means (keyloggers, etc).

Cons:

Users will be unable to logon if there’s a problem with the domain, there's a problem with network connectivity, their PC is offsite, etc.

Deploy Microsoft LAPS and issue users with the unique, local administrator credentials:

Pros:

Centrally-managed.
Not vulnerable to credential theft and lateral movement attacks.
Free.

Cons:

Non-auditable.
The default administrative user account is an easy target.

Add the required domain user accounts to the local security group Administrators:

Pros:

Auditable (to an extent).
Not as vulnerable to credential theft and lateral movement attacks.
Free.

Cons:

Not centrally managed.

Implement MFA:

Pros:

Centrally-managed.
Auditable.

Cons:

Not free.
Still vulnerable to credential theft and lateral movement attacks (according to https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models).

Implement a system that uses TOTPs and/or only temporarily grants administrative permissions as-and-when needed:

Pros:

Centrally-managed.
Auditable.
Not vulnerable to credential theft and lateral movement attacks?

Cons:

Not free.

Is there a general best practice?

I can't help but get the feeling that there is no one correct technological answer and that these risks are mitigated by simply trying to ensure that no one can or will (1) use an administrative user acount on a day-to-day basis or (2) run malware.

Use protected users

When a user logs on to a Windows machine with the NTLM protocol, his hash is stored in memory in the LSASS process. An attacker can dump this memory to steal these credentials.

To overcome this problem, a good solution is forcing Kerberos authentication for administrators and banning the plaintext credentials. You can do this with a mechanism called protected users.

/!\ You will need Windows Server 2012 R2 to create the Protected Users security group and hosts must run Windows 8.1 or later to provide client-side restrictions for Protected Users.

When an account is a protected user's member:

default credential delegation and Windows Digest (plaintext credentials) are not cached even when the Allow delegating default credentials policy is enabled
NTLM hash is not cached
Kerberos configuration is improved
Sign-on offline (the cached logon verifier) is not created

Your first option is the good one

  Create a domain security group (PC Admins), add the required domain
  user accounts, and use Group Policy to add the domain security group
  to the local security group Administrators.

That's exactly what you have to do. And your PC Admins group will be a member of Protected Users group.

Bad options

  Deploy Microsoft LAPS

LAPS automatically manages the rid 500 (local administrator) password on domain joined computers, so the password is:

unique on each managed computer
randomly generated
stored in existing AD infrastructure

However, local administrator accounts should not be used to administrate computers over the network. In an Active Directory, these accounts must be considered as backup accounts, in case of loss of network connection.
So LAPS does not fit your needs.

Moreover, it is vulnerable to credential theft but not lateral movement attacks.

  Implement a system that uses TOTPs and/or only temporarily grants
  administrative permissions as-and-when needed

For same reasons as MFA, it is still vulnerable to credential theft and lateral movement attacks.


False positives in OpenVAS I recently ran the 1st vulnerability scan in my offices network using OpenVAS.
We received a great deal of false positives.
Mostly I saw that (at least some) tests are unaware of internal patches in a system.

For example we were alerted to these: CVE-2016-6515, CVE-2016-6210 on an Ubuntu 16.04 system. OpenVAS recognized the system to run OpenSSH 7.2p2 but these were updated in 7.2p2-4ubuntu2.1 and we are using something later still.
I can see it was patched in the changelog.

We intend to scan again in the future, and not only with OpenVAS. Is there a way to avoid them without increasing the odds of false negatives? Will using an authenticated scan be better? Is there a way to handle the sources for the tests to such an end?

The NVT is doing a check for both CVEs remotely are not showing a vulnerability against a Linux system by default. If they are showing up I can think of two possibilities:

You have configured your filters to show results of NVTs with a low "Quality of Detection (QoD)". See [1] for a description of the QoD and [2] for the "default" value of 70 in your filter which you might have set to a lower value.
For some reason, the system was detected as Windows and thus a higher QoD is assumed.

I guess the case 1. would be the first thing to check as the "a great deal of false positives" could be a good indicator for this.

While 2. is very unlikely you still could check the "Log" output of the NVT called "OS Detection Consolidation and Reporting" with the OID 1.3.6.1.4.1.25623.1.0.105937 what OS was detected at that host.

Disclaimer: Answer of an NVT Developer @ Greenbone


Drawbacks to only using TLS 1.2 ciphers in OpenSSL I understand you would not want to do this as it would limit compatibility for older devices and platforms. However if someone were in an all TLS1.2 environment, say a very well managed internal corporate network with all up to date browsers, is there any reason to keep TLS1.0 enabled?

At the moment, the only drawback is compatibility. But if that's not an issue for you then you're golden.


When signing email with GPG, how does verification by the receiver work? I use GPG to sign my outgoing emails.

I understand how it works when I encrypt mail to send to someone else. Then I need his/her public key, encrypt it with that, and only he can decrypt it using his private key.

What I understand from signing my outgoing mail, I use my private key to do this. The receiver doesn't need to use GPG (to read the mail), and I don't need their public key. I suppose my public key is used by the receiver to check if the signature is legit, but maybe I misunderstand.

How can they use my public key to verify that my signature is valid?

There is a unique association between public and private key. That is, if the sender uses a certain private key to sign a message and you verify the signature using the corresponding public, then the signature verification will succeed only if the message has not been altered.¹

The verification procedure and nature of the association between public and private varies with the cryptosystem you are considering (RSA, DSA, etc.), but the statement above holds true for any asymmetric scheme.

What really matters is that the sender is the only one that can produce a valid signature because he/she is the only one who knows the private, but anyone knows the public, so anyone can verify the signature.

Upon signing, GPG adds a token to the text message which can be used to verify that the message has not been altered in transit: that's the signature. You don't need GPG to read the message because the text itself is not encrypted, there is only an extra token, which could be either a radix64-encoded blob at the end of the message or a text attachment with a similar structure.

GPG does not directly sign the message², it signs a cryptographic hash (SHA-1 or SHA-2 usually) of it. What happens upon verification is that the signature is verified using the public key of the sender to make sure the received hash was actually originated by the sender. If the hash calculated by the sender is considered authentic, it is compared with the hash calculated by the recipient. If both phases succeed, then the message is correctly signed.

[¹] actually, there is a theoretical possibility to break this rule by generating a so-called hash collision. That is to say, a different message with the same hash (see the last paragraph). Collisions have been generated for MD5, while finding one for SHA-3, SHA-2 and SHA-1 is considered unfeasible, although the security margin over the last one is becoming so thin it's advisable to stop using it now.

[²] for some cryptosystems, like DSA, signing a hash is the only possibility.


Should users be allowed to reset their password to the current one? I've been trying to answer the following question but can't seem to find a clear answer...

  When a user resets their password after forgetting it, should they be allowed to change it to the password that it's already set to?

I understand that the whole reason behind the user resetting their password is they forgot it, but in terms of security, wouldn't it make sense to have them change to a different password? In the Forgot Password Cheat Sheet and Authentication Cheat Sheet, I can't find any mention of reusing old passwords.

If this rule should be used, would this be a proper error message for it?

  Password must be different than the existing one.

I think the application of restricting users to reuse passwords will largely depend on the application and their risk acceptance. "Best practices" of passwords is probably one of most divisive topics in Information Security which is likely why those cheat sheets don't make mention of it.

For organizations that have a password policy that requires users to change their password every X days, restricting the user from changing their password to something it's already been makes sense. The logic behind this is that requiring users to change their password on a regular basis reduces the chance that an old password, if compromised, could be used in a Password Replay attack.

With such a policy, a "Remembered Passwords" value is likely set. This policy will remember the previous users X number of passwords to ensure that they are complying with the password policy and not re-using old passwords. The reuse of old passwords would effectively render the password policy useless. It is in this instance you would want to force a user to set a new password if they're clicking the "forgotten password" option. Without forcing them to do so, a user could just use the "forgotten password" function in your application to ensure they can always have the same password, without being forced to change it to something new.

Taking it one step further, it is also common for there to be a password "freeze" time where users cannot change their password for X days after it was changed. This is to prevent people from quickly cycling through 3 changed passwords to be able to utilize the one they like. This way if the password a user like expires, they can't quickly change their password X times to get back to the one they like.

EDIT : Take of this what you will, but NIST has issued a guideline recommending against password policies requiring users to change their passwords.


Theft of data via live boot disk I have been working with live boot disks recently and I know that it gives you access to the computer's processing power, internet, and various other tasks without the hassle of a username/password.

Is it possible to obtain files created in another OS (e.g. Windows XP) that are saved to the "My Documents" or similar folders in that OS's filesystem? If so, how is this done, and is there any way to stop an attacker from doing this?

Yes - live booting via removable media can enable the adversary access (read-only or read-write, depending on drivers) to the local HD.  Without going into too many details, an OS can only provide protection while it's loaded.  So if you bypass the OS, then the data is not protected.

With that said, you can protect against this type of situation by implementing physical controls.  You can lock down the BIOS/firmware on a PC to disable boot from removable media and network (PXE boot).  However, if the adversary has physical access to the system, they can easily walk away with the HD or perhaps the entire system and pop the HD into another PC.

Alternatively or in conjunction with the above, you can also protect the data through encryption.  You can selectively encrypt data or you can use Full Disk Encryption.  FDE encrypts all data on the HD with the exception of a small boot loader.  FDE makes it much more difficult for an adversary to access the data, even when they have physical access to the PC.  The only way the adversary can decrypt the data is by entering the correct authentication token (i.e. password, USB key, smart card, etc) or in rare instances, weaknesses in the FDE implementation (but this is extremely rare).


What's the most secure way to send information from one device to another? I need to send sensitive information from one piece of hardware to another. I was thinking wifi, but if someone obtains the password, it wouldn't be encrypted. I don't think you can use ssl unless it's a website, but I may be wrong. I don't know if it makes a difference, but it only needs to be one way.

Depending on your available resources you could look into encrypted short burst radio transmissions.

http://en.wikipedia.org/wiki/Burst_transmission

That would definitely be the most secure one-way method.

With smaller means, just use regular internet connection and encrypt your file sharing. If the question were more specific, I could provide a more specific answer.

Web RTC possibilities seem interesting.

Or you could just encrypt the files and then send them with FTP, properly encrypted, it doesn't matter if someone intercepts them.


Are open ports dangerous? I have forwarded port 80 to WAMPServer and 25565 to the MineCraft-server running Bukkit.

Am I vulnerable to attacks. Can hackers attack me if WAMP-server is running or if it is not running, or will it be easier to hack me than if I hadn't opened the port at all? I have tried to learn about how people hack and how to protect myself from it. Do you know where I can read about it?

I have forwarded port 80 to WAMPServer and 25565 to the MineCraft-server running Bukkit. (http://www.bukkit.org/)

I assume that you're talking about forwarding those ports from a router / firewall / NAT box to your own machine rather than forwarding them to some off-site instance. Usually we call this "opening" a port.

  Am I vulnerable to attacks. Can hackers attack me if WAMP-server is running or if it is not running, or will it be easier to hack me than if I hadn't opened the port at all?

Yes, you are more vulnerable by running a service than by not running a service. Adding more services increases attack surface. That doesn't mean by that you're vulnerable by definition, but an increased attack surface increases is one of the factors that increases your risk.

  I have tried to learn about how people hack and how to protect myself from it. Do you know where I can read about it?

The more time I spend here, the greater resource I find this site to be. I've never found a really good comprehensive guide to how to be secure. There are books like the Hacking Exposed series that talk about a lot of technical aspects to security and some of the mindset. As much as the CISSP might be railed upon, trying to study up for that exposes one to most of the different knowledge domains that a professional should be aware of. I think that reading questions on this site is a great way to learn.

The challenge is that security is a mindset. The technology and even some of the fundamentals of it are an evolving realm. You learn by exposing yourself through trial and error. It is helpful to make as much of that exposure as possible vicarious -- learn from others' mistakes.

Security as an equation works like this:

Decide what you need to offer -- you have a need to provide something with a WAMP server and Minecraft game server.
Limit everything you don't need to offer and do it in depth.

When I say in depth, I mean that only offering those services is a start. Try to make sure that the programming code on your website is written securely. Then, pretend it has been compromised and consider what can happen from there. Is the Apache process prevented by the operating system controls from writing files anywhere? Do you have a method to detect compromise? Keep asking those questions and finding layers of answers so that if you are hacked, you mitigate your risk.


Example of reflected client XSS which is not DOM based XSS Given that I categorize XSS in a matrix of {client,server}x{stored,reflected} and treat DOM XSS as a subset of client XSS, can there be a reflected client XSS which is not DOM based? I cannot find or think of an example because all reflected values I can think of are accessed using DOM methods.

From those categorisations:

  Client XSS occurs when untrusted user supplied data is used to update
  the DOM with an unsafe JavaScript call.

(em mine)

Therefore for it to be client XSS, it has to involve updating the DOM.

Although, the article goes on to say:

  DOM Based XSS is simply a subset of Client XSS

I believe this is referring to the actual source being from the DOM rather than the server.

e.g.

foo.innerHTML = document.location.hash;

Rather than

foo.innerHTML = ajaxResult;

This is because the definition of DOM based XSS is as follows:

  DOM Based XSS is a form of XSS where the entire tainted data
  flow from source to sink takes place in the browser, i.e., the source
  of the data is in the DOM, the sink is also in the DOM, and the data
  flow never leaves the browser.

So reflected client based XSS which is not DOM based is where the data itself is from the server (reflected in the response from the HTTP request), but the code is rendered on the page via JavaScript.

Example:

Request:

http://example.com?name=<svg onload=alert(1) />

(Name would be % encoded, but I've left it unencoded here for clarity.)

Response:

<script>
var name = "<svg onload=alert(1) />";
$('#output').html(name);
</script>

<div id="output">
</div>

Takeaways

What is probably important when it comes to XSS is the following:

Any type of stored XSS is mostly higher risk than any form of reflected XSS. Browser XSS filters cannot stop them (except if a Content Security Policy is in place and is sufficiently locked down).
When an XSS updates the DOM in a reflected XSS attack, this bypasses browser XSS filters too (same caveats in regards to CSP).
Server reflected XSS  is less risky as it requires user interaction and there's also a good chance a browser XSS filter will block it.


Should I be concerned if my website throws stack information? I have a simple login form on my web page and the URL looks like this:

example.com/signup/signup.php?q=1

If I try something like this:

example.com/signup/signup.php?q=1&()

I'm redirected to a stack dump that looks something like this:

exception 'DOMException' with message 'Invalid Character Error' in /<mydirectory>/a_xml.class.php:74
Stack trace:
#0 /<mydirectoy>/a_xml.class.php(74): DOMDocument->createElement('()')
...
#6 {main}

Is this a big problem in terms of security? Are there any attacks a malicious user can perform that will allow him to deface or steal my database? Or is this relatively benign and I can ignore it?

On production (contrary to development) environments, stack traces and error messages should be logged to file instead of dumped on screen. This is because an attacker may learn things about your system that could help compromise your system.

Information such as operating system, web server version, PHP version and more. Some stack traces may contain system/environment variables that should not be made public!

The user/visitor should get a nice looking HTTP error page instead of a message that is of no use to the visitor.


Is allowing root login in SSH with "PermitRootLogin without-password" a secure method? I have set my live IP in /etc/hosts.allow, and deny all other hosts. I have also set PermitRootLogin without-password in /etc/ssh/sshd_config.

Is that a secure method? Can an attacker crack my key and login to my server? If yes then please explain how it is possible.

This is a common misunderstanding for the PermitRootLogin feature. The without-password option does not mean there is no authentication and anyone can get in without a password. All this option means is that logging in is only possible using a fallback method, such as public key authentication. Even if an attacker knows your root password, they will not be able to log in unless they have your private key.

It is actually better to use without-password if you need to log in as root, since it ensures that the root account cannot be brute forced. If you were to log in as root with a password, it could be subject to being remotely attacked, whereas public key authentication ensures you can only log in with the proper credential files. This is better than logging in as a different user and using su to elevate to root, as a compromise of that other user would result in a compromised root, since the user can monitor any keystrokes entered into its shell. This is explained in detail in the answer to Which is the safest way to get root privileges: sudo, su or login?.

If you do not need to have root, then using another, dedicated user would be fine. In this case, setting PermitRootLogin no would be beneficial, as there is no reason to have root access if not required.


Is this an attempted SQL injection? Looking through error logs I found lots of requests to a web-app where the URL contains:

/if(now()=sysdate(),sleep(10),0)/*'XOR(if(now()=sysdate(),sleep(10),0))OR'"XOR(if(now()=sysdate(),sleep(10),0))OR"*/

I read that could be a part of an attack on websites developed in PHP which we don't use. Also we're using an ORM to query to our databases.

So is this an SQL injection attempt?

This is most likely a blind SQL injection, testing whether you're vulnerable to SQL Injection by checking whether your server takes the specified time or more to reply to the request. This is not actually doing any data edit nor exposing anything; it's just checking whether you're vulnerable.

It's also worth noting that this specifically targets MySQL databases, as the if and sleep syntaxes are the ones of that db engine.

If the attack is isolated, you were probably "probed" by an automated vulnerability scanner that is preparing a large-scale attack, so if your webapp is not vulnerable you have nothing to worry about.

However, if you recieve more weird requests with different attack patterns, you could be the specific target of those attackers, and should take actions to prevent all attacks that may succeed.

See Time-Based Blind SQL Injection Attacks for more information.


What are the risks associate with accessing Same web application with two different URLs? We have done vulnerability analysis with third party security team. They have mentioned one point as critical findings but i don't understand risk associated with it and suggested remedial action also bit confusing.
Finding : Same web application can be access by two different URLS.
Ex: http://1.1.1.1/abc, http://example.com/abc
Remedial Action : Upgrade PHP Version and
Modify the HTTP ETag header of the web server to not include file inodes in the
ETag header calculation.
Third Party Security Team Explanation : Users may confuse and they may victim of phishing attack
Could you please tell me someone what are the risks associated with accessing same application with It IP address and Domain name?

There's a couple different parts here which seem somewhat jumbled.  First, the remedial action listed here seems to correspond to a different vulnerability than the finding.  It sounds like the finding is the one you're confused about though, so I'll try to answer that.
Specifically, this relates to exposing a web application both on a vhost and directly on an IP.  Here are some of the possible issues as to why this is considered bad security practice:

Probably most importantly, users' browsers are going to consider these two separate origins.  That means that if they visit one after the other, then password managers (both built-in and external) will not recognize it as the same site, and refuse to auto-fill the password.  Coincidentally, that's also a great way to recognize phishing sites - you go to faceb00k.com and your browser doesn't auto-fill the password - red flag!  So now your users are confused and have to manually dig out and copy/paste their passwords.  This is probably the main issue the reviewers have a problem with.
Similar to the above, this will cause issues with CORS.  Bonus points if your developers are hardcoding domains in API calls - now you have a site plus a subtly broken site.
If the site is on the public internet, listening directly on the IP means that it can be discovered by anybody with an IPv4 scanner.  If you listen only on the vhost, now an attacker has to find out your domain before they can start attacking.
The IP address version likely does not have a valid certificate (it's not impossible to get certs for an IP, but extremely rare).  Now your users accessing the IP version have to accept a security warning, and can't detect MITM attacks - you just defeated one of the two main advantages of TLS.
Lastly, sites that are listening directly on an IP address are often configured in a hurry by administrators that leave the web server bound to the default IP of 0.0.0.0, which means all IPs available to the server.  If server has IPs in multiple network regions (internet, DMZ, internal LAN, secure segment, etc) that means that this web application may be exposed to hosts that aren't supposed to be accessing it (e.g., if the server is in the DMZ but the application is supposed to be only internally accessible).

So, recommendation:  configure your web server to only expose the site on a vhost.


Server client verification When writing a server sofware, what are the methods used to verificate the user connected to the server is actually using the official client program ?

This is to prevent the access to the server through the port that the client is using so the server is always listening to the port and harmful things can be done in through this port.

So I am just a beginner to this subject so please forgive my ignorance and please explain like I am 5. I made a server and client that serves as a basic chat program with python. When verificating, I made the client send a certain string that would serve as a key, if the first data that arrives to the server is not that key, server cancelled the connection. So this was my first idea at this subject. Are the real security methods basically derive from this principle ?

Thanks in advance!

Most services do not validate the application being used as it is extremely hard to get a relatively reliable answer.  Therefore what they can validate is the user through authentication and possibly their location through the IP address.

That said, some servers do validate the application, but because there is always a way to reverse engineer and bypass the verification, they have to constantly update it.  An example of those would be certain poker applications that use multiple levels of obfuscation and regularly (almost daily) do updates that change the security codes and their location in the program to make it very hard to find before the next update.

Because of the effort needed and the remaining impossibility to be 100% sure, I advise you against doing that.

In any case, you should do validations on the server based on the data that is received to determine if it appears legitimate or not, never relying on what seems to be happening on the user's machine.


Key generation and decrypting SSL 1.2 Finished message I can't seem to correctly decrypt a SSL 1.2 Finished message.

I have correctly generated the master key, and therefore I am confident that my PRF implementation is correct.

To generate the keying material:

PRF(master_secret, 'key expansion', seed)

I take 16 bytes (128 bits) for client_write_MAC_key (MD5)
I then take 16 bytes (128 bits) for server_write_MAC_key (MD5)
I then take 5 bytes (40 bits) for client_write_key (RC4-40)
I then take 5 bytes (40 bits) for server_write_key (RC4-40)

I extract the encrypted handshake from Wireshark and attempt to decrypt it using RC4 with a 5 byte key (EXP-RC4-MD5). The decrypted output is not formatted as expected. The first byte of data I should see is the content type, which should be 14 for the Finished message, I do not see this. Is there anything incorrect about what I have said thus far?

The key generation function described in RFC 5246 is not applicable to this cipher suite, which is why I was unable to decrypt the message. Having reimplemented the key generation function described in RFC 2246 (TLS 1.0) I am now able to successfully decrypt the Finished message.


How does Google store passwords for remote IMAP/POP services? It is possible to add non-Google accounts to Gmail and retrieve their mail messages via POP or IMAP. As part of the setup process, one has to provide the login username and password for these accounts.

Since POP/IMAIL requires plaintext credentials, they must be stored by Google in a reversible manner.

Is there documentation on how these credentials are protected?

I didn't find any such documentation. Hence I had to make internal communication about this vulnerability to my users.

Moreover, at time of (pop|imap)/tcp connection, these passwords are in clear within the Gmail servers (which are acting as clients in this process). They are also travelling the Internet in clear.

The inherent weakness of such a service should be better documented by Google, and appropriate warnings should be provided to users which are not security aware.


Filtering network access on a user/group/process basis I am interested in peoples thoughts on what the best approach would be to controlling access to network interfaces at a user/group/process level for a Linux based host. The scenario I have in mind is a multi-user, public, linux ssh login server with 2 network interfaces. One is connected to the internet for external access (public interface) and the other is connected to an internal management network (management interface) that is NOT directly connected to the outside world. Traffic/connections over this interface should ideally only be by admin users or specific processes.

Obviously traffic needs to be allowed in and out over the management interface for mounting remote filesystems, host monitoring and access to the machine when the public interface is disabled. Whilst this can be controlled with a firewall, the problem is that a firewall makes no distinction between connections to hosts on the management network from a regular user or an admin user.

I have been reading about SELinux and its network ingress/egress functionality here - http://paulmoore.livejournal.com/5536.html but I'm still investigating SELinux so I'm unsure if the access control at such granularity is even possible with this method. In my case I would be interested in the egress controls to stop connections from users or processes that are not authorised to hosts on the management network. Hopefully this would stop users from having access to hosts that need to be on a common management network but should only be visible/accessed by admins.

What other takes on such user/group/process level network access control is there apart from SELinux? Has anyone had any success with SELinux network ingress/egress controls?

I have no experience of SELinux, but it is not necessary if you want to filter network access by users and groups. You can use the owner module to iptables, with rules like -m owner --uid-owner guest or -m owner --gid-owner staff.

There are several examples on our Unix sister site, in particular:

How to restrict internet access for a particular user on the lan using iptables in Linux
SELinux outbound access to other sites with restrictions
Dual network connection


What is the difference between "Incident", "Attack" and "event"? In the Computer and network security incident taxonomy what are the differences between "Incident", "Attack" and "event"? Where does "threat" fit with them?

Assuming that you have looked up the official terms and wanted further help:

An event is something that has triggered notice. An event need not be an indication of wrongdoing. Someone successfully logging in is an event.

An incident is something that indicates a problem, however you define "problem". It carries from an event but has a layer of interpretation on top. Someone successfully logging in when they are on long-term sick leave and should be unable to use a computer is an incident.

An attack is an incident with malicious intent. Someone brute-forcing the credentials of someone on long-term sick leave is an attack. A manager asking the person on long-term sick leave for their password so that they can gain access to the person's work product for the benefit of the business is not an attack. It might be an incident, depending on your policies.

A threat is anything that has the potential to cause an incident. People, weather, machines, etc.


Server SSLv2 enabled on non-webservers Using Nessus I'm scanning our internal network for vulnerabilities and exploits. I've found a large number of instances where SSLv2 is enabled and is as a result, being flagged as a vulnerability.
I understand the limitations of SSLv2 and even the limitations of SSLv3 so I'm quite happy to proceed with disabling SSLv2 on our Windows 2008 R2 boxes.
My question is that if these servers are not web servers and have no reason for clients to attempt to initiate a HTTPS session is it an exploitable vulnerability? Could an attacker still use a 'roll-back' attack and connect with SSLv2?

SSLv2, enabled on a SSL server, is a potential vulnerability only if all of the following are true:

There is some client who wants to connect to that server and exchange sensitive data through that SSL tunnel.
The client agrees to use SSLv2 too.
The client and server don't implement the version rollback detection system described in RFC 2246, section E.2.

Under all these assumptions, then an attacker may force server and client to use SSLv2 even though both support SSLv3 or more. This in turn may imply some weakness depending on the underlying protocol (the biggest issue with SSLv2 is lack of verified termination, so attackers can force silent truncation, which is a problem if the underlying protocol is not self-terminated).

Given what you say, it is highly improbable that these "SSLv2 support" is a problem in your case.

However, a more interesting question is: what are these servers anyway ? Why would a machine operate a network service, ready to do SSL, if there is no intended client at all ? Why not switching off these unused services ? The issue is not a question of SSLv2 vs SSLv3, but more a question of having network-capable services open for no good reason.


How do sites detect credential sniffing, and what is the purpose of this attack? I just got an email from the Unsplash service telling me that someone had logged into my account via credential sniffing:

Five minutes later I get three more emails, each one notifying that a (generic) photo just uploaded to the account had been flagged.
The news doesn't surprise me because the password is a weak throwaway that I know is in several public databases, and this latest attempt is possibly linked to last week's Cit0 service leak, which I am in, but I'm curious about two things:

How exactly Unsplash detected the credential sniffing attempt so quickly

The motivation of the hackers for logging into a free account on a stock photos service and uploading a bunch of generic images

We can't know how Unsplash detected it unless they tell us.  However, many large websites have some sort of abuse tooling to automatically detect patterns.  For example, Unsplash may import compromised credentials from public databases and match logins on those accounts from certain shared IP addresses.  Clearly they've seen this pattern before since they have a pre-canned email about it.
In general, any site of reasonable size that has a social aspect where there can be likes or ranking of items is subject to abuse from bots who sell paid likes.  As for who would want this, consider being able to put on your resume that you're one of the top ten most popular photographers on Unsplash.  That would be very appealing indeed.  It may also cause search engine rankings for your user ID or name to be better, especially if they show up on a favorites or top photos page.
As for why the attackers uploaded images, because it's very easy to find empty accounts that only give out likes.  If a user engages in a variety of types of activity, it makes it seem less suspicious, so the site is less likely to catch on to the pattern.  They also may like unrelated accounts to make it less obvious who's paying them if they do get detected.  Most sites don't permit gaming the system in this way (or using automated systems to do this) and the attackers' service wouldn't be very popular if many of their customers' accounts got cancelled.


Best Firewall Zone Settings for Security Gli-net Routers I believe many will benefit from this as there is not clear answer online and I keep making my policies too strong and locking myself out from accessing the LAN admin panel.

What would be the absolute strongest security settings without locking myself out on the Firewall Zone settings.

The settings go as follows and the options are either accept, reject, or drop. Could someone explain each of the categories so I know what is happening in each and what it is used for? I want to specify that I want to block all inbound connections as I do not have a need for them (close all uneccessary ports and exterior ports that are for inbound connections/remote connections)

This is the panels format:

Zone. Input Output Forward

LAN.  Option Option. Option

WAN.  Option. Option Option

Guest Option. Option Option

OVPN. Option. Option. Option

Some routers understand zones differently, but I hope you will be able to distinguish:

LAN: Accept | Accept | Reject

WAN: Drop| Accept | Reject

Guest: Reject | Accept | Reject

OVPN: depends on what you want.

The reason for WAN inbound DROP rule is to lower the load in case of an unlikely event of DoS


Secure no-login REST API for very few clients I'm designing a very simple data collection device for a research project. Because we are logging, among other stuff, the GPS position of actual vehicles, we need to protect the data. Since we manually deploy every logging device, there is no need for registrations or logins.

I have set up a web server (Node.js), a database (MongoDB), an app (native iOS), and a data format (JSON). The client regularly sends JSON to the web server with the following command:

PUT/store/[deviceId]/?hash=[hash]

(with the actual data as a POST variable)

Where the deviceId is a simple identifier, for now just a number (0, 1 or 2), to make me choose which MongoDB collection to store the data in.

The hash is a hash of the HTTP verb, the url, and the device's secret (just a random string hard-coded into each device), inspired by this answer.

My concern here is how secure such a system is. I am using HTTPS to protect the data transfer, and the device secret to make sure it's actually one of our devices, and not the neighbor's son trying to hack us.

Is that enough?

To answer your question you have to first gather some information:
- What risks are there you want to mitigate through security?
- What Prevention techniques do you want to employ, and how much money are you willing to spend on them?
- Do you have any form of intrusion detection?
- Do you use a firewall?

for the rest, HTTPS is a good step, but for this type of "research" a verification with client-side certificates might be apt. this means not only is the data secured in transit. but only clients that know your "secret" way of communicating with you can (e.a. the client certificate has to be valid or the server won't even listen to the request)

for storage of critical data mongoDB is not the best solution (it can loose data or even not store it at all) But that is a discussion for another thread (like programmers or sysadmin stackexchange).

On the looks of things, for a wide scale use its not that bad. just add some intrusion detection and misuse detection (no one should be trying random strings on your back-end without getting banned y your firewall for at least 10 minutes after each try, incrementing exponentially with each try, or other security methodology).

Also, at the moment you have no protection against replay attacks. add some time sensitive part to your data that locks out after some time (like a session cookie does or a CSRF token does). a counter that increments after each request send could do this trick already.


Create a unterminable process in Windows I am a student, and am genuinely curious about unterminable processes in Windows.

For educational purposes, I would like to create an application (possibly in VB6?) which cannot be terminable by a user from task manager or taskkill. What are some strategies and exploits that such applications employ to make this possible?

Contrary to what a lot of people believe, there are actually several ways to do this. Some of them are common, some rarely seen. Some of them are weak, some strong. It all depends on how you do it.

Let's go through a collection of them:

1. Pre-NT RegisterServiceProcess trick
Windows 9x, and other pre-NT operating systems, had an undocumented API in kernel32.dll called RegisterServiceProcess, which (as the name suggests) registers the process as a system service. Once a process had called this function, the operating system considered it critical and would not allow task manager to kill it. This function was removed when NT came around, so it doesn't work on XP or higher.

2. Process naming tricks
Back in WinXP, the Task Manager executable contained a hard-coded list of process names that it would refuse to kill, instead displaying a message like the one you mentioned. These basically covered the critical system services such as smss.exe and rpcss.exe. The problem was that the path isn't checked, so any other executable with the same name would result in an un-killable process. This trick doesn't prevent the process from being killed, per se,  but rather stops the Windows XP Task Manager from being able to kill the process. It is still possible to use another tool to kill the process.

3. Keep-alive processes
These are by far the most common. Two processes are created, and repeatedly check for the other's existence. If one is killed, the other resurrects it. This doesn't stop you from killing the process really, but it does make it annoying to stop the process from coming back.

Task Manager includes an option to kill the process tree, which allows you to kill a process and all child processes, which may help fix this issue. When a process is created in Windows, the OS keeps track of the process ID that created it. Kill process tree iterates through all processes and looks for those who have a parent ID equal to the process ID that you're killing. Since keep-alive processes usually work on a repeated polling, you can kill both processes before they notice anything went wrong.

A defence against this is to create a dummy process that spawns the keep-alive process, then have that dummy process exit. The main process passes its ID to the dummy process, and the dummy process passes its ID to the keep-alive process, but the chain is broken when the dummy process exits. This leaves both the primary and keep-alive processes running, but makes it impossible to use Task Manager's kill process tree function. Instead, you'd have to write a script to kill them off, or use a tool that allows you to kill multiple processes simultaneously.

4. User-mode hooks via loaded DLLs
It is possible to inject a DLL into a running process. In fact, Windows offers a feature to have any DLL loaded into all processes that import user32.dll, for the purposes of extensibility. This method is called AppInit DLLs. Once a DLL is injected, it may manipulate the memory of the process. It is then possible to overwrite the values of certain function pointers such that the call is redirected to a stub routine, which then calls the target function. That stub routine may be used to filter or manipulate the parameters and return values of a function call. This technique is called hooking, and it can be very powerful. In this case, it would be possible to inject a DLL into running processes that hooks OpenProcess and TerminateProcess to ensure that no application can gain a handle to your process, or terminate it. This somewhat results in an arms-race, since alternative user-mode APIs can be used to terminate processes, and it's difficult to hook and block them all, especially when we consider undocumented APIs.

5. User-mode hooks via injected threads
This trick works the same as with DLLs, except no DLL file is needed. A handle to the target process is created, some memory is allocated within it via VirtualAllocEx, code and data is copied into the memory block via WriteProcessMemory, and a thread is created in the process via CreateRemoteThread. This results in some foreign code being executed within a target process, which may then instigate various hooks to prevent a process being killed.

6. Kernel-mode call hooks
In the kernel, there's a special structure called the System Service Dispatch Table (SSDT), which maps function IDs from user-mode calls into function pointers in to kernel APIs. This table is used to transition between user-mode and kernel-mode. If a malicious driver can be loaded, it may modify the SSDT to cause its own function to be executed, instead of the proper API. This is a kernel-mode hook, which constitutes a rootkit. Essentially it is possible to pull the wool over the OS's eyes by returning bogus data from calls. In fact, it is possible to make the process not only un-killable, but also invisible. One issue with this on x64 builds is that the SSDT is protected by Kernel Patch Protection (KPP). It is possible to disable KPP, but this has far-reaching consequences that may make it difficult to develop a rootkit.

7. Direct kernel object manipulation (DKOM)
This trick also involves loading a malicious driver on the OS, but doesn't require alteration of the SSDT. Processes on the system are stored as EPROCESS structures in the kernel. Keep in mind that this structure is entirely version-dependant and is only partially documented by Microsoft, so reverse engineering is required across multiple target versions in order to make sure that the code doesn't attempt to read the wrong pointers or data. However, if you can successfully locate and enumerate through EPROCESS structures in the kernel, it is possible to manipulate them.

Each entry in the process list has an FLink and BLink pointer, which point to the next and previous processes in the list. If you identify your target process and make its FLink and BLink pointers point back to themselves, and the FLink and BLink of its siblings point to each other, the OS simply skips over your process when doing any housekeeping operations, e.g. killing processes. This trick is called unlinking. Not only does this render the process invisible to the user, but it also prevents all user-mode APIs from targeting the process unless a handle to the process was generated before it was unlinked. This is a very powerful rootkit technique, especially because it's difficult to recover from.

8. Debugger tricks
This is a pretty cool trick that I've yet to see in the wild, but it works quite well. The Windows debugger API allows any process to debug another, as long as it has the permissions to do so. If you use the debugger API, it is possible to place a process in a "debugged" state. If this process contains a thread that is currently halted by a debugger, the process cannot be killed by Windows, because proper thread control cannot be guaranteed during termination when the thread is blocked. Of course, if you kill the debugger, the process stops being debugged and either closes or crashes. However, it is sometimes possible to produce a situation where a chain of processes exist that debug each other in a loop. If each process halts a dummy thread in the next, none can be killed. Note that it is possible for a power user to manually kill other threads within the process, rendering it useless, but it still won't be killed.

9. Windows 8 DRM
This is a new one I've only heard of recently, but I don't know much about it. There was a bit of a rumour going around on Twitter about it, and I've seen snippets here and there on various technical sites, but I've yet to see any concrete research. I think it's still early days. Essentially, the story is that Windows 8 has a mechanism that allows "trusted providers" to register processes as DRM critical, preventing them from being killed or manipulated by the user. Some people have speculated that the mechanism for checking trusted providers is weak, and may be open to attack.< - Looks like this one was bogus. So much for the rumor mill!

Update: Harry Johnston pointed out in the comments that Windows 8.1 introduces protected services, which are designed to be used by AV and DRM to protect against being manipulated or attacked by lower-privileged code on the system.

10. Tool manipulation
This one has probably been used a lot in the wild, but I've never seen it done properly. Essentially this trick involves targeting specific tools, e.g. Task Manager, by editing the executables on disk in a way that alters functionality. This is very similar to the user-mode hook tricks I mentioned earlier, but in this case they persist on disk and have wider-reaching consequences than simple API hooking. Of course, one issue is that Windows File Protection (WFP) prevents alteration of certain critical system files, including the task manager. Amusingly, though, it is possible to alter the default task manager executable path via the registry. So, instead of messing with the task manager executable file, just dump your own version somewhere and make the OS use it.

All in all, there are plenty of ways to achieve this, with varying degrees of robustness. The above represents a majority of them, but isn't exhaustive. In fact, many of the tricks I described can be achieved in alternate ways, using different mechanisms or APIs to achieve the same goal.


Writing keylogger and viruses in python So recently I have been working on some projects one of them is keylogger and the second is SYNflood (both in python). I want to know if ,is it a good practice to use python language for such purposes? (Maybe you know from your own experience)

About writing tools like this SYNFlood, python is as good as any other language you feel comfortable with. There is an excellent book called "Violent Python" where you will learn to write security auditing tools and malwares. From network scanners, login bruteforcers, FastFlux behavior to mimicking botnet functionalities, you will learn a lot about them.

Writing malware in python can make your life easier (in a part) as it is very quick and easy to code. Python is really an uncommon choice for viruses and the like because it needs an installed interpreter to run. You may overcome that by turning the script into a windows executable using available tools (like py2exe), but that tends to produce big executables (maybe 5MB, depending on the imported modules) and as malware tend to survive on its subtlety, it may be spotted sooner than you expect, not only because of executable size but also memory footprints.

Compiled python scripts can be turned back to its script form with great ease, using modules like uncompyle2. Once it is found, that will allow the malware analyst to quickly know what it does, how it does, where the command and control servers are, etc., making it extremely fast to uncover your whole operation and reducing the effectiveness of your malware as AV vendors push your signature into their products.

On the other side, as someone said in this reddit post about a Bluecoat report (linked below), AV detection rate for scripted languages tend to be low, as many installers use them to deploy softwares.

Doing some more research, i heard about the Flame malware and according to the article, it was 20MB in size, including libraries, sqlite databases and all. So, size may not be "that great burden" after all...

Here is a report from the security company Bluecoat about a python malware that relates to the Hangover operation in 2013.

Most malware are written using C/C++/C#, VB, Assembly, .NET, etc., but that is not a law. These languages have advantages, but also does python. Everything depends on your goal. Balance what you want with what you need and take your shot with what feels the best option to fulfill them.


Why doesn't Apple prevent iPhone jailbreaking by encrypting iOS and installing it on an independent chip? Why doesn't Apple prevent iPhone jailbreaking by encrypting iOS and installing it on an independent chip?

With this I mean iOS will be encrypted with AES or any other very strong encryption algorith to prevent jailbreaking. It would also have its own storage chip, where the OS is installed. Any attempt to access this OS chip would result in the OS being deleted and the iPhone being useless if attempted. Only certified apple technicians could then fix your iPhone.

So why doesn't Apple do it to prevent jailbreaking?

...very strong encryption to prevent jailbreaking...

Encryption does not magically prevent jailbreaking (the same way HTTPS does not magically make some website secure). Jailbreaks use bugs in the operating system to escalate their privileges to a system user. This way they can write to the system the same way as other high privileged system processes can do, no matter if encryption is used or not.


Best practice to secure an API of unknown structure that can come from end user device or server I'm trying to create an API with minimum forced structure. The messages can come from end user device or from a backend server.
I'm ok with opening separate API for end user traffic and from servers.
The client are web and mobile companies that can send their data to the API.
(Think google analytics for websites, mobile application and events from web servers)
What will be the best practice to know that a http request to the API got from a trusted client?
If there is any good article in that manner, that what be great also.

-- EDIT --
What will be the best practice to authenticate the client (not the end user)

You cannot trust the client, ever.

A malicious user may abuse legitimate client software (theirs, or someone else's)
An attacker may reverse engineer enough of the API to pretend to be a legitimate client

Instead of trusting the client, work to ensure that the client's input is trustworthy.

input validation
input sanitization
schema compliance
velocity checking

Do these things at your end, which you do control, to provide security for your system.  Don't waste your time imagining you can control the remote endpoints.


What does browser do when it queries xxx.example.com and it gets a certificate for yyy.example.com(top level domain is same)? The question is actually about what level of validations browser does when it gets certificates of some other domains like
case 1: Accessing abc.google.com and got def.google.com
case 2: Accessing *.abc.google.com and got abc.google.com
case 3: Accessing abc.google.com and got abc.facebook.com

Also, What about programatic calls, for example with JAVA?
I know that accessing domain and the domain present in Certificate should strictly match, But i'm not sure if both have same top level domains.
Any help would be highly appreciated.

The hostname in the subject (common name or subject alternative names) must fully match the name given in the URL. This means that none of the cases you provide will match.

The common browsers and most current command line clients and programming languages properly check for the name by default. But older clients often do not check the name properly (like only against CN, allow multiple wildcards...), don't check the name at all or don't do any certificate validation by default. Also, often developers disable validation partly or fully just because it is in the way of testing.


Can Blind SQL/Boolean Based SQL Injections not contain break characters or comparisons? I'm using a scanner which passes subtraction attack traffic such as (1-1), (3-2), (5-2), etc. There are no break or continuation characters such as semicolons or &&, nor is there a comparison using an equals sign or similar (and not function call). These are submitted using POST as part of a form. Is this possible?

It's important to remember that a scanner's job isn't to exploit a vulnerability - it is to find a potential vulnerability.  Imagine code like:

sql_query("SELECT * FROM `table` WHERE id=" + request.get('id'));

This code is vulnerable to SQL injection.  You could imagine doing your typical fancy SQLi payload which joins some tables from the information_schema database, tries to figure out column names and add them into the response, etc...

The problem with that course of action as a first step is that a complicated injection payload may get blocked by a WAF or similar technology.  As a result, you may end up moving on without realizing that there is an actual vulnerability there.  Also, getting reliable output back out can be quite tricky and application dependent, and often beyond the "smarts" of an automated scanner.

In contrast, (5-3) is a pretty simple payload comprised only of standard ASCII characters, has a high chance of bypassing a generic off-the-shelf WAF, and likely gives simple output that a scanner can easily understand.  Consider the results of three requests:

https://example.com/widget?id=2 (200)
https://example.com/widget?id=34343 (404)
https://example.com/widget?id=(5-3) (200)

This is boolean based SQL injection.  Which, to boil it down, means that the goal is to get a simple and easy-to-understand true/false out of the application.  Especially since most systems will return a 404 for a non-existent page, it's quite easy for the scanner to try to detect the success condition.  That last result becomes especially interesting when the scanner compares the full response body of #1 and #3, and discovers that they are identical.  The scanner can now report with high confidence that there is an SQLi vulnerability on the id parameter of the widget endpoint.

In contrast, if there was not an SQLi vulnerability, then (5-3) would most likely be treated as a string, the underlying SQL query (id='(5-3)') won't match anything, and https://example.com/widget?id=(5-3) will return a 404.

Of course, this injection payload is very useless and won't help with an actual exploit, but as one of many possible tools to try to find vulnerabilities with a minimum of false negatives, it can be useful.  The scanner might then follow up with more complicated payloads.  If those get rejected then you can move on to the more fun task of trying to put together a WAF bypass.


PHP functions for preventing XSS Is there a proven library with functions for preventing XSS attacks? Many people don't realise that htmlspecialchars is not enough to prevent XSS attacks. There are various contexts that need their own escaping (html properties, Javascript, more?). Is there a proven library that will provide functions for me to escape in all of these contexts?

Yes, there are several such libraries.  The choice of library depends upon what language/web programming framework you are using.

First, you need to start by reading about XSS.  I recommend the following document:

OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet

Next, once you have familiarized yourself with that, I can point you to a few libraries that provide well-tested escaping functions:

OWASP ESAPI
Microsoft AntiXSS

However, let me warn you that using these functions properly requires developer knowledge, and is potentially error-prone.  There are many different parse contexts where dynamic data might be injected into HTML, CSS, or Javascript content; each parse context may require a different escaping function (or sequence of escaping functions) be applied.  The developer needs to make sure to apply the correct escaping function(s) each time he/she injects dynamic data into such content.  This requires knowledge of the XSS risks and how to defend against them.

This approach (manually escaping data everywhere it is used) is also error-prone.  It is easy to forget to apply an escaping function.  If you have 100 places where you include dynamic data in the document, it would be easy to remember in 99 places and inadvertently forget to escape in one of them.  We're only human, and those kinds of mistakes are easy to make.  Libraries of escaping functions don't help developers avoid this problem.

A better solution is to use a web programming framework that helps developers avoid this problem.  The state-of-the-art is context-sensitive auto-sanitization.  This works particularly well with frameworks that provide a HTML templating system.  In such a system, the template engine is responsible for automatically escaping all non-static data that is interpolated into the template.  Because the template engine can identify the parse context where the data is being dynamically inserted, the template engine can automatically select and apply the proper escaping function.

The primary issue with context-sensitive auto-sanitization is that only a few web programming frameworks currently support it.  Some web frameworks that do support context-sensitive auto-sanitization: Google Ctemplate (Closure templates), GWT, Google Clearsilver.

For more on this topic, I can highly recommend the following research paper:

A Systematic Analysis of XSS Sanitization in Web Application Frameworks, published at ESORICS 2011.


Should I use a Certificate Revocation List? I've been trying to provide security to my API.

I will issue certificates to my clients to access my API through a TLS channel. So it'll be a SSL-Client Authentication.

I'm wondering, should I use CRL on my server? Why?

Note: I'll use my own CA and communication will be between machines so a browser won't be used.

There is an exception for my question. Some day, if my ca root key is compromised, I can create a CRL list, add my old ca root key and implement to my server simply.
So, please ignore this case.

An Image from Websense Community

First of, CRL do not cover root CA. By definition, a root CA is a root: it has no issuer except itself. A CRL conveys revocation information, which is a way for a certificate issuer to announce that a previously issued certificate should be considered as invalid even though it looks fine and its signature is correct and everything. Thus, a CRL that talks about a certificate C is something that comes from the issuer of C. Since a root CA has no issuer, it cannot be revoked.

In other words, if your root CA is compromised, you are in deep trouble. This is why people who are serious about certificates use a three-level structure:

A root CA is created and maintained on an offline machine, that is kept in a safe or some shielded room. It is powered regularly (say, on a monthly basis) to sign a CRL, but that's about all.
An intermediate CA is awarded a certificate by the root CA, as a one-time procedure.
All user certificates are issued by the intermediate CA.

If the intermediate CA is compromised (which is conceivable, since it is used often and thus is probably part of a network), then the root can still issue a CRL that revokes that intermediate CA.

That being said, you should consider that there are two PKI instances at work in your case. With SSL/TLS and client certificates:

The server owns a certificate, that the client validates.
The client owns a certificate, that the server validates.

These two certificates may live in separate world, issued by distinct CA.

For the server certificate, you need the client to have access to all information required to make sure that the server certificate is valid, and this includes regularly issued CRL or something equivalent (OCSP responses...). I suppose here that you do not issue that certificate yourself; instead, you buy an "SSL certificate" from some commercial CA, because the root CA is already distributed in all client systems, and that CA issues and publishes CRL.

Now let's see about the client certificates. These certificates are to be validated by your server. And you are also the one who will decide which certificates are to be revoked. In other words, any CRL here would be a mechanism by which you will agree with yourself. In that sense, this is entirely your business and you can fulfil that functionality in any way as you see fit. For instance, you could maintain, on the server, some SQL table that lists the thumbprints of client certificates that are to be rejected, and revocation would simply be adding an entry in that table. When you talk to yourself, you do not necessarily need to sign your mental messages !

Regardless, you still need the ability to revoke certificates, or something similar. At this point, you must understand that there is a difference between authentication (making sure that the client who talks to you is Bob) and authorization (deciding what Bob should be allowed to do). Suppose that Bob's private key is compromised:

Since Bob's key may be in the wrong hands, you can no longer accept Bob's certificate as a proof of Bob's identity. That certificate should be "cancelled" in some way (e.g. revocation).
Since certificate revocation is asynchronous, you also need a "fast block" system that will keep any purported Bob out of the system immediately. This is done on the authorization layer: you temporarily "disable" Bob's account, or set his access rights to "nothing".
Bob is still Bob, though, a (possibly paying) customer. He will want to connect again, and it should work. Therefore, Bob's access rights will have to be enabled again. However, you should do that only when Bob has been issued a new certificate (with a new public/private key pair, of course) and Bob's old certificate is now rejected by your server.

Therefore, you really need, in all generality, a way to reject certificates that would otherwise look fine. Revocation is such a way; another one is to issue only very short-lived certificates (valid for, say, one week at most), but this requires pushing new certificates to clients on a daily or weekly basis, and client software is not necessarily up to such a task. The normal method is thus to issue long-lived certificates to clients (valid for one or a few years) and to maintain, on the server side, a mechanism that allows arbitrary rejection of certificates. Conceptually, that mechanism is as simple as having a list of "undesirable certificates" that the server consults. A CRL is a standard formatting for such a list, that the issuing CA signs to allow transport over unsecured mediums. However, as explained above, this list is to be transferred between your CA and your server, which may be the same machine, and do not necessarily need such a signature.


Can back up servers be used to defend against DDoS? Would having back up servers which kick in instantly when the primary server goes down kill a DDoS attack or just delay it? How many networks, distributed, would a midsize company need to withstand a DDoS attack?

Maybe. It depends on whether or not you have a single point of failure that is the target of the DDoS.

If you have a domain, an IP, an ISP, and a server farm all serving your business, and this gets attacked, then, standing up a new domain, IP, ISP, and server farm will help to mitigate the attack, as long as the attack does not change to target your new location.

If you do not change all those things, like the domain, then the attack could automatically switch over to the new IP, ISP, and server farm once you redirect the domain to the new location. Same thing for each element.

So, yes, given the idea that a DDoS attack is limited in scope, then yes, setting up resources outside that scope could work (until the attack retargets).  But, any single point of failure could bring your mitigations down.


Can an SSH tunnel substitute TLS? I've a device that's running an HTTP server. It doesn't have a fully qualified domain name, and installing a self-signed certificate on every client is tedious. In other words, no HTTPS.

I've blocked ingress traffic to the server's HTTP ports, and am currently connecting to it via an SSH tunnel.

When using an SSH tunnel, from my client device to device A, to access and use plain-text HTTP forms on a web server running on that device A, are my communications secure?

Yes, they are secure. The known_hosts will protect you from a Man-in-The-Middle attack by checking the remote servers fingerprint (assuming you have not deactivated this check), and the communication is encrypted using an algorithm such as AES128 (may vary).

The fingerprint check serves as a proof that the server still possesses the private/public key pair from when the host was listed as a known_host. Without the private key it is not possible for an attacker (MiTM) to forge the fingerprint and pass this check. This check only works, of course, if you can guarantee that you were connected to the right host when it was listed as known, and not to a man-in-the-middle.


Not replacing SSL cert on a rebuilt, formerly rooted Unix Server If a server was rooted, to the point that we know a Perl script which creates a remote shell was placed on the filesystem remotely, and the server was rebuilt entirely, patching the original Apache vulnerability that allowed that exploit, but the same SSL cert was used for the new Apache config (I know this is foolish); Assuming the web server just makes some PDF files available over HTTPS, what scenarios other than being able to possibly decrypt HTTPS traffic from that server via MITM are now likely (due to the fact an intruder may have the private key, csr, etc)?

TL;DR how much damage can be done theoretically on a well patched and well firewalled Linux server serving PDF documents over HTTPS if an attacker has the private key being used?  I understand that they can perform MITM and decrypt SSL traffic.

If the attacker has the private key, they can fully impersonate you.  They can perform MitM attacks on your traffic stream, they can redirect requests to your server in a manner undetectable to the client, and so on.


In which ways could a javascript making a cross domain HEAD request be a threat? I was just reading this answer to the question Why is the same origin policy so important?

  Basically, when you try to make an XMLHttpRequest to a different
  domain, the browser will do one of two things:

  If it's a GET or POST request which meets certain limits (which the makers of the standard have determined to add no extra risk for CSRF
  attacks) then the browser just passes the request through.
  Otherwise, it does what's called a "preflighted request", where it first sends an OPTIONS request instead and only does what you
  requested if the checks pass for the OPTIONS request.

But a HEAD request won't receive anything other than headers and a status, which I would believe to be at least as secure as an OPTIONS request, yet it would effectively be blocked.

Reading this section of the draft on the Principles of the Same-Origin Policy it mentions that the Location interface is available

  There are some exceptions to this general policy.  For example, some
     parts of HTML's Location interface are available across origins
     (e.g., to allow for navigating other browsing contexts).

Is there a security reason why HEAD is effectively blocked by the same-origin policy?

There's two issues with cross-domain requests: whether a request makes it to the server and whether a response is visible to the client script that issued the request. So-called "simple" requests (which use a "simple" method and include only "simple" headers) are guaranteed to make it to the server, but their visibility to the client script still depends on appropriate CORS headers. Non-simple requests are not immediately sent to the server; first, the browser sends a "preflight" request (using OPTIONS) and uses the headers in that preflight response to decide whether to send the actual request. This is because non-simple requests might alter server state, and thus could cause damage even if the client was forbidden from seeing the response.

Let's be clear that the result of a preflight OPTIONS request is never made available to the client script. It is only used privately by the browser to decide whether to perform the actual request initiated by the script:

If you wrote a script that tried to make an actual (i.e., client-visible) OPTIONS request, it would be subject to normal CORS rules:

var xhr = new XMLHttpRequest();
xhr.open("OPTIONS", "http://cors-enabled-server.example.com/");
xhr.onload = function(e) { console.log(e); }
xhr.send();

This request will generate a preflight (because OPTIONS is a non-simple method) and the request will fail, unless the server sends a Access-Control-Allow-Methods: OPTIONS response. Note that this generates a preflight OPTIONS request, but that preflight OPTIONS request is never made visible to the script. The script can only see the "actual" OPTIONS request/response, which comes after a successful preflight.

Second, you ask:

  But a HEAD request won't receive anything other than headers and a status... yet it would effectively be blocked.

This is not true: the visibility of the result might be blocked, but the request is not. This is because the HEAD method is a simple method according to CORS and thus does not necessitate a preflight, just like GET and POST:

  A method is said to be a simple method if it is a case-sensitive match
  for one of the following:

  GET
  HEAD
  POST

A simple cross-domain HEAD request still requires an acceptable Access-Control-Allow-Origin response, but it does not require a preflight. Therefore, a simple HEAD request (i.e., one that has no special headers necessitating a preflight) will always be sent directly to the server.

OPTIONS, on the other hand, is a non-simple method and must be approved by Access-Control-Allow-Methods in a preflight response. Do not confuse a preflight OPTIONS request (which is never subject to CORS, but is visible only to the browser, not the script) with a JavaScript OPTIONS request (which is visible to the client, but only if it passes CORS requirements).

To answer the title question in your title, "How could a JavaScript making a cross-domain HEAD request be a threat?": it's a threat roughly on the order of allowing a cross-domain GET request, since HEAD should be --according to the HTTP spec -- the same as making a GET request, but without the response body. There's still the potential for lots of sensitive data to leak through headers and status codes.


What hashing algorithm does VirtualBox use for passwords in its config files? To authenticate with RDP, VirtualBox allows to set a password using this command:

VBoxManage setproperty vrdeauthlibrary "VBoxAuthSimple"
VBoxManage modifyvm "VM name" --vrdeauthtype external
VBoxManage setextradata "VM name" "VBoxAuthSimple/users/<user>" <hash>

Where the <hash> is given by:

VBoxManage internalcommands passwordhash "secret"

The documentation writes:

  Oracle VM VirtualBox uses hashes to encrypt passwords

But there are no details about what kind of algorithm is being used. What algorithm do they use? Is it secure?

See the source code for vboxmanage internalcommands. The command passwordhash is mapped to the function CmdGeneratePasswordHash near the bottom of the file. Above the function definition, there is an elaborate comment detailing all the algorithm's properties:

  Generate a SHA-256 password hash

So it is a plain SHA-256 hash. No salt, iterations, or memory-hardness. And it's not encryption, so they are not encrypting your password: they are hashing it. But not very well.

SHA-256 by itself does not protect your password very well because it is fast to brute force. Only a very strong password is secure and will not be recovered from the configuration file, so a randomly generated password (stored in a password manager) is recommended. If you don't use a very strong password, consider the configuration to pretty much contain your password in plain text.

Testing the theory, the documentation you linked also mentions an example hash:

  2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b

Googling the hash, we find not only the documentation page, but also that this maps to "secret".

While looking this up, I also found a passlib page mentioning virtualbox. I didn't know of that project, but it seems this might be useful for similar questions when you want to know what hash is used by various software.

Note that when generating your password with vboxmanage, your password will be saved in your command history. To avoid this, you could use the following:

$ read -s pwd
$ VBoxManage internalcommands passwordhash "$pwd"

After the read command, with the -s flag to not show the password, you type your password. When you press enter, the prompt will return and you can enter the second command. If you would do echo "$pwd", you will see that this variable contains your password.

Better yet, generate a password randomly instead of entering it:

pwd=$(</dev/urandom tr -dc a-zA-Z0-9 | head -c 16);
echo "Password: $pwd"
VBoxManage internalcommands passwordhash "$pwd"


Cannot build a ROP chain My ROP exploit crashes with segmentation fault for unknown reason.
This is a vulnerable code (compiled via command gcc h2.c -no-pie -fno-stack-protector -m32 -o h2):
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

char string[100];
void exec_string() {
    system(string);
}

void add_bin(int magic) {
    if (magic == 0xdeadbeef) {
        strcat(string, "/bin");
    }
}

void add_sh(int magic1, int magic2) {
    if (magic1 == 0xcafebabe && magic2 == 0x0badf00d) {
        strcat(string, "/sh");
    }
}

void vulnerable_function(char* string) {
    char buffer[100];
    strcpy(buffer, string);
}

int main(int argc, char** argv) {
    string[0] = 0;
    vulnerable_function(argv[1]);
    return 0;
}

I followed this example: https://medium.com/@nikhilh20/return-oriented-programming-rop-chaining-def0677923ad
In addition, there are no suitable gadgets of pop pop ret pattern (actually, there are, but pop [some reg] pop ebp ret, which messes up the stack as well as gadgets with leave instruction).
I've tried two different stack paddings for an exploit: the first one is identical to the primer in the link I provided above. The second one is (top - higher addresses, bottom - lower addresses):
address of exec_string
garbage value
0x0badf00d
0xcafebabe
add esp 8; pop ebx; ret <-- gadget
address of add_sh
0xdeadbeef
pop; ret gadget <-- gadget
address of add_bin <-- compromised instruction pointer after BoF
AAAA
....
112 'A's to overflow the buffer and overwrite ebp (108 + 4)
....
AAAA

Let me explain the add esp, 8; pop ebx; ret gadget. There are no gadgets like pop [some reg]; pop [some reg, not ebp]; ret for chaining calls from add_sh to exec_string functions, so I've tried to make a little hack. I've chosen add esp, 8; pop ebx; ret gadget to pop out 0xcafebabe and 0x0badf00d via add esp,8 then pop out garbage unreferenced value via pop ebx and then ret to exec_string. Does it suppose to work at all? Correct me if I wrong.
Moreover, when I've started debugging, it results with:

Cool, it looks like I owned an instruction pointer, I need to replace it with add_bin function address to jump to it and start a ROP chain.
But...

SIGSEGV in 0x91c2b1c2? I've entered a correct add_bin address, ASLR, PIE and canaries are disabled. I thought that maybe there is an undefined reference to string that vulnerable_function gets, but in primer in the link provided above it was ignored, so it confused me a lot.

If you fix this issue, I believe you will be successful.

gef➤  ropper --search pop
[...]
0x0804901e: pop ebx; ret;
0x080491c4: pop edi; pop ebp; ret;
[...]

These gadgets don't "mess up" the stack in this case; they clean it up a bit after the overflow so that you are able to return to the next function in the chain. The gadget you picked instead is close, but would need to be an add esp, 4 instead of 8, or without the additional pop. You'll see why if you step through it in the debugger.

So, instead use the pop; pop; ret from above.


Should every website or web-application have a Responsible Disclosure Policy and what are the drawbacks of having such a policy? The Dutch National Cyber Security Centre, NCSC* (daughter of the Ministry of Security and Justice) published a news article* regarding a Responsible Disclosure Guideline in the beginning of 2013.

The guideline* (pdf) is called "Policy for arriving at a practice for Responsible Disclosure". A website with an example text, policy template* was also launched. After Googling around using snippets of this policy template, I found that a lot of websites are using this policy already.

Should every website or web-application have a Responsible Disclosure Policy and what are the drawbacks of having such a policy?
Won't this have the opposite effect and attract attackers?

* Documents and texts are all written in English, the Dutch versions of above hyperlinks can be found here NCSC, news article, guideline (pdf) and policy template.

Would this attract hackers? Yes, of course, that's the point of it. Good hackers, bad hackers, grey / white / black / multicolor hat hackers. They will come and inspect your server's front-door.

Should you be afraid of it? Normally, your security posture should not rely on the absence of any attacker, otherwise you indeed have a big problem to solve. When you put such policy in place, it means that:

You are sufficiently confident in your server security, you have setup the proper mitigation and monitoring systems,
You have people in measure to directly handle potential security incidents,
You have the right to take such initiative (you are not renting your server to an external service provider who could take the initiative of suing the discloser),
You have established the proper communication around this (a lot of companies rightfully fear about loosing competitiveness when uninformed customers and partners may have to choose between a company publishing information regarding its security issues and a company showing no security issues).

As I understand it, while you engage yourself to not sue people testing your security in the perimeter defined by your policy, you do not have any commitment to open all the doors to make their investigations easier (as it may be done upon contractual assessment to speed up the process and ensure a deeper coverage of the targeted application, for instance by disabling a web application firewall to focus the tests on the application itself).

All you defenses remain nearly the same, all threshold are still active. If a tester is blocked for a few minutes, if he gets Captcha to solve, etc.: all this is to be expected and is part of the game.

The only difference is that, instead of working only from time to time, your first-level defense mechanisms will be triggered on a far more regular basis, with certainly some people trying to maliciously abuse them, but also benevolent hackers analyzing them and ready to contact you in case of any flaw has been found.

So to summarize:

Without any responsible disclosure policy:

Malicious bots and attackers try from time to time to hack your server,
Your defense systems are triggered occasionally.

With a responsible disclosure policy:

There might be an higher amount of malicious attackers trying to hack the server, but this is not even sure since it is usually the sign of a sane security posture (the fact that you advertise that there actually is a security team may put your server out of the low hanging fruits),
Your first-level defense systems will be triggered on a regular basis,
In case of failure of these defenses, there is a high probability that you will be contacted by a benevolent hacker informing you about the issue.

So, all-in-all, I have the impression that the latter gives a better security feeling that the former.


Can Google's administrators be trusted with Google Authenticator? Suppose there is an evil Google administrator who has full access to every server or network at Google. Will such a person be able to abuse the Google Authenticator technology to gain access to non-Google services which uses the Google Authenticator technology for access?

In other words: Suppose I setup Google Authenticator for website-A of company-A which is not hosting any Google services.  However I choose to use the Google Authenticator authorization mechanism to "improve" my security.  Will mr. Google Administrator (who supposedly has the ability to monitor all communications via the Google Authenticator and/or can manipulate the tokens/keys of the service to his advantage) have same sort of way to get access to my account at website-A?

Could someone with unfettered access to Google's systems and malicious intent compromise non-Google accounts via Google Authenticator alone? No.

Could they compromise non-Google accounts via several other Google services which someone using Google authenticator is likely to also use? Probably.

Firstly, Google authenticator is used to implement multi-factor authentication. The whole point of this is that if one method of authentication is compromised then the other authentication method should prevent the attacker from gaining access. Furthermore these authentication methods are typically designed to be isolated, so someone who is able to compromise something you know (eg. a password) should not also be able to compromise something you have (eg. a physical device) at the same time. Even if Google authenticator was compromised an attacker would not necessarily also have the password.

Secondly, Google authenticator implements TOTP. The secret is communicated only between the service requiring authentication and your device, so unless Google is the service then there is no need for the secret to be communicated to Google.

Now of course the assumption that the secret won't be communicated to Google is dependent upon the integrity of the client. It is possible that the App you have installed has been compromised to capture the secret and send it to the attacker. Google Authenticator is open source, therefore you could theoretically verify that the code does what it should then compile it yourself. In reality if an attacker has the ability to arbitrarily compromise software on your device then they could probably compromise any form of 2FA involving the device (for example SMS) and Google Authenticator would not pose an additional risk.

Aside from this, if someone at Google wanted to attack you there are probably more effective avenues which don't involve Google Authenticator. For example given that the Play Store on an Android device is signed by the same certificate as the system it can access permissions to install software without your explicit permission. If you used gmail they could also most likely access non-Google accounts by resetting passwords.

TLDR; An attacker with unlimited access to Google's systems would almost certainly be a threat to non-Google accounts, but not because of Authenticator.