Are old API keys in git history a security vulnerability?

Either it's safe to publish an old API key on the title page of New York Times, or they don't actually have a correct invalidation procedure.

Users often stick with API keys for years, almost nobody's going to replace them unless something really bad happened to those keys, e.g. they were stolen or leaked. In this case, a new key would be issued and an old one must not be valid anymore (hence invalidation) for anything API-related from the very moment a new key was issued. Add an hour or, heck, even a day for all sorts of CDNs and caching, it still has nothing to do with deleting a Github repo.

Regarding some suggestions in comments,

  New keys may be computable from old keys

An API key itself is just a random sequence of bytes. A new key should probably be computable from nothing except pure enthropy. Anyway, an old key is a wrong base for new keys. If a new key depends on those old ones, they'd better think once more on the design of their API auth.

  Mailgun may be afraid that people will try the old keys against their server, which would increase the server load.

Anyone can try an arbitrary random sequence of bytes against an API server. Processing an invalid API key once in a while must be affordable for an auth server. There are also methods and even products which help to protect against brute force if it's a real problem. I don't think having an old key leaked will somehow significantly influence the server load (except if their only server is a Raspberry Pi instance).

What if the key isn't leaked but stolen? Do you have to convince the thief to delete an old invalid key from their databases? This is ridiculous. Mailgun has no reason to require that.


Personal Information / Compliance in SaaS for US-based customers

This is a very broad question, but I can provide a general answer.

HIPAA would only be involved if you're storing data related to health care, such as appointments or communication between a patient and health care provider.

However, you'd be in scope for various privacy regulations both extant and proposed, because you're dealing with personally identifiable information (PII).

Notably, there are several states with privacy regulations that this information would be patently in scope for:  California, Nevada and Massachusetts.

The soon-to-be-effective California Consumer Privacy Act (CCPA) would also introduce GDPR-like protections to this data for US-based customers.

Here's a short summary from Wikipedia (https://en.wikipedia.org/wiki/Personal_data#United_States):

California

The California state constitution declares privacy an inalienable right in Article 1, Section 1.
California Online Privacy Protection Act (OPPA) of 2003
SB 1386 requires organizations to notify individuals when PII (in combination with one or more additional, specific data elements) is known or believed to be acquired by an unauthorized person.
In 2011, the California State Supreme Court ruled that a person's ZIP code is PII.

Nevada

Nevada Revised Statutes 603A-Security of Personal Information

Massachusetts

201 CMR 17.00: Standards for The Protection of Personal Information of Residents of the Commonwealth[34]
In 2013, the Massachusetts Supreme Court ruled that ZIP codes are PII.[35]


In the classic client/server architecture, there is the server which serves requests initiated by the client, and the client which makes said requests. An example of the client/server architecture is the web, where a web server communicates with a web browser (the client). A client-side exploit is thus one which attacks or influences the client. It is distinguished from a server-side exploit which attacks the server.

An example of a client-side exploit would be malicious JavaScript taking advantage of a bug in a browser. An example of a server-side exploit would be SQLi, which attacks a server's handling of its database. Client-side exploits are not unique to the web, since there are more client/server architectures out there. Attacking a vulnerability in PuTTY (a Windows program used for managing remote servers via the SSH protocol) would be an example of a client-side exploit that does not involve the web or web browsers.


I would recommend take a look at scapy ( http://www.secdev.org/projects/scapy/ ). While "python for network security" is quite unclear ( ie, for testing network security, for analysis, etc ), I think scapy would be a good tool to add to the tool box of someone learning security.


How to implement encryption/decryption system using IV between mobile app and web service

Initialization vectors aren't meant to be private. The goal of an IV isn't to strengthen the key but to make sure that no two identical (or similar) clear text will result in the same (or similar) cipher text.

It works like this: AES (along with most - but not all - modern crypto algorithm) is a block cipher. It only operate on a fixed amount of data (in AES case, 128 bits). So, in order for identical data blocks within the source data (i.e. using the same key) to be identical, it is usual to specify a mode of operation that introduce some form of change between two data blocks.

In your case, you've selected CBC which basically XOR the clear text of the block N with the cipher text of block N-1 before encrypting it.

This works well except for the first block: there is no previous block to mix it with and therefore, if you don't do something about it, if the clear text starts with the same 128 bits will be similar if the same key is used for encryption. This is a real problem because it is quite frequent for two messages to have the same first 128 bits. Furthermore, depending on the application, it is possible to deduce the meaning of the message without even decrypting it (think of "yes" and "no" answers, for instances).

That what the IV is for: it makes sure that, as long as you don't reuse the IV, you won't have to worry about two messages yielding identical clear text.

Another point worth making is that you could do the same with changing the key. There is two problems here:

Key are often picked up on the fly and therefore only statistically unique (which isn't a problem).
Key are expensive to change: at best, you need to re-negociate a key (for instance, with DH). At worth, you need to re-create a new key and exchange it through a secure channel.


Hack a website using database username and password

Yes, if your database is exposing itself to the internet. A database can be configured to listen on the network in order for other, authorized computers to connect. If it is exposed and all this information is public, then anyone will be able to perform privileged actions on that database even if they shouldn't.

Still, you shouldn't be revealing your database credentials, or other local processes on your server might be able to connect to the database locally (not through the network) if they have been compromised.


Is there any security risk when a certificate authority is used more than all others?

TL;DR: It does not matter much.

The only security "risk" here really is the CA being "Too big to fail", where the browsers cannot distrust the CA quickly. But this is happening to all big CAs, not just the biggest one.

Other than that, the only problem may be the CA being a more tempting target, though all CAs are already very tempting. Having all the eggs in one basket has its advantages and its disadvantages in this situation. Advantage is, that you need to protect just one basket, disadvantage is that if that basket breaks, the impact is somewhat bigger (assuming technologies like CAA and HPKP are used, otherwise it does not matter how big the CA is).


Securing Java web services called by web site in DMZ using web services for communication

You need to block traffic to the port on which your JAX-WS web service is listening from all addresses other than localhost.  You can do this using the Windows Firewall application on Windows, iptables on Linux.


Why is this shellcode execution considered an exploit?

I agree that this is not an exploit, but it is shellcode to be used when injected into an application exploited via other means.  The blog post also only refers to it as shellcode, not an exploit.


How to analyze the netstat log for suspicious connections?

I would actually be suspicious of the fact it is listening on port 53, especially if it is a workstation - Why should it be running a DNS Server? It may be an indication of malicious communications attempting to disguise themselves as DNS / HTTP / HTTPS traffic given, as you mentioned, the connections from port 53 <-> 80/443.

If it were a real scenario, you may then want to poke around and see which process is listening on port 53 (By adding the "-o" option to the netstat command)

Connections to the same address on ports 80 and 443 is not necessarily unusual. For example, a website with mixed content may be serving content over both HTTP (80) and HTTPS (443).


In simple terms Kerberos is a protocol used for authenticating users on a network.

In this example the client may change their password on the client machine, which in turn is saved into the network passwords database - commonly used is Active Directory.

Kerberos protocol requires the user to authenticate first against an authentication server, in this example it would be the sever holding the active directory, commonly called a domain controller.

Once authenticated then Kerberos assigns a ticket that is used instead of the password while wishin the protocol - such as requesting service tickets.


Cross-language primitives against string comparison timing attacks?

Community wiki for further information on the subject:

In Ruby, you can use Rack::Utils.secure_compare or ActiveSupport::SecurityUtils.secure_compare. Source: http://codahale.com/a-lesson-in-timing-attacks/ via https://github.com/thoughtbot/til/blob/master/security/constant-time-comparison.md
https://crypto.stackexchange.com/questions/5529/stopping-timing-attacks-on-aes-why-is-it-important-to-prevent-the-os-from-inter and DJB's 2004 paper.


Creating port-specific SSH authentication for the same user

In fact match expression must be on the same first line. So this should work as expected in /etc/ssh/sshd_config:
Match User XX LocalPort 22
   PasswordAuthentication no
   RSAAuthentication yes

Match User XX LocalPort 12345
   PasswordAuthentication yes
   RSAAuthentication no

Beware that the Match block ends with end of configuration file or another Match directive. Indentation is only there for prettyness. As a result, DO NOT add some Match lines in the middle of existing configuration file. So simply put your Match blocks at the end of the file.
Warning OpenSSH is compiled with hard-coded limit of listen ports, by default 8 (Debian, Ubuntu...) and startup logic appears to open ports in reverse order compared to configuration directives, with consequence to reject to open default SSH 22 port when you declare more ports than allowed... and you have already guessed you just lose your SSH access to your system! If you need more than 8 SSH ports, I recommend to keep only 22 handled by regular service/daemon, and setup your additional SSH ports thanks to xinetd.


Looking for an open risk assessment methodology

My first recommendation for what you're looking for would be SOMAP. Their website claims open source, but I'm not sure it meets your needs entirely.

This question is similar to this other question, but I'll let you decide if anything is of value there.

In the government domain, the National Standards Institute of Technology (NIST) has special publication 800-37, which was originally taken from the FITSAF standard on risk assessments, so it's worth mention.

The book, "Information Security Management Handbook, Sixth Edition", explains that security risk assessments are usually based on a value chain model. Another book, How to Complete a Risk Assessment in 5 Days Or Less, covers the author's FRAAP process. There are a few books coming out very soon that look to answer your question best. One is from Syngress Press and by author Evan Wheeler. Another, by Douglas Landoll, is in its second edition. A recent book from Andrew A. Vladimirov came out, but I have not yet read it.


XSS in options tag without forward slash

You have at least basic XSS:

...
<select><option value="XSS"><input type="image" src="https:\\happyorhungry.files.wordpress.com\2011\10\cookie_monster_original.jpg">Anything</option></select>
...

Where your input is:

XSS"><input type="image" src="https:\\happyorhungry.files.wordpress.com\2011\10\cookie_monster_original.jpg


How much extra security do the Host part of a mysql user account provide?

The client does not "present" anything related to host.

The server sees an incoming connection from a given IP and  this is resolved by your mysql server and then compared to host,  so it is not obvious to spoof. Your DNS resolution would need to have been modified first (or upstream DNS servers would need to have been hacked).

So yes,  there is extra security provided by host.


Best methods to mitigate DDOS with changing IP sources

If you are worried about the amount of IPv6 addresses you can treat whole blocks of /64 or /62 the same way as you treat one IPv4 address. If you are receiving a lot of traffic from different addresses in the same /64 net you can block the whole net for a while to prevent attacks.
You can also use a service like Cloudflare to put in front of your own service to mitigate DDOS attacks. This way Cloudflare will be the public IP addresses of your website, while your own server's IP address can be hidden and can configured to only accept connections from Cloudflare and block all other requests. Cloudflare will mitigate DDOS attacks and can also cache parts (or all) of your website in local CDNs all over the world and provide other techniques to improve the speed of your site as well.


Firefox doesn't support the X-XSS-Protection header as you can see in this compatibility table.

If you want similar protection against reflected XSS as a Firefox user, you can use the NoScript addon. It has an anti-XSS feature that can similarly warn you if it identifies script code in the URL.

You should only see the header as a last line of defense that doesn't replace proper output escaping and the usual anti-XSS measures. Many websites like Facebook don't enable the header at all because it can occasionally cause security problems itself.

On the server side you can also deploy a web application firewall that may attempt to block XSS attempts. But your first security measure should be a secure application that properly filters output itself.


Why is this certificate valid for so many domains?

It seems that this certificate works for so many domains because it's part of a CDN. CDNs, or Content Delivery Networks, deliver files which are always the same (or 'static'). The site's logo, some style rules for the website, those things. The page itself may change, for example based on whether you are logged in, but often images (and such) don't change.

Such CDN is used because the closer a server is, the faster the page will load. However, not everybody has the resources to install dozens of servers around the world, so companies like Cloudflare and Akamai offer their CDN space (and a big network which can handle lots of traffic), just like hosting is being sold.

In order to provide all data securely (and avoid mixed-content errors), the certificate used by the CDN's server must be valid for all domains that it hosts files for. It is a risk to be able to spoof that many domains by stealing a single private key (and you only need access to one of the hundreds of servers), but it seems to outweigh the benefits. It seems it are mostly subdomains too (or perhaps only subdomains, I haven't checked).


Why providing many protected zip files will increase the chance of retrieving the password

The full description reads

  fcrackzip searches each zipfile given for encrypted files and tries to guess the password. All files must be encrypted with the same password, the more files you provide, the better.

Looking at the command-line options tells you the different modes how it guesses the password, which are basically either a dictionary attack or brute-forcing with different password specifications. There is no cryptoanalytic deep magic which would benefit from having more cyphertext.

Let's say the attacker has 20 files. They know they are encrypted with the same password, but they don't know which one. When they pass all 20 files at once, fcrackzip would try to guess the password for the first file, and when it found the correct one, it will try the same password on all 19 other files, cracking them all at once. But when the attacker passes the 20 files one after another, fcrackzip will restart the brute-forcing for each file.


Can Diffie-Hellman Anonymous be used as a cipher for SSL for one-way certifiate-based authentication

By definition, when using the DH_anon cipher suites in SSL/TLS, there is no server certificate -- not certificate at all, indeed, since in that situation the server is not allowed to request a certificate from the client either.

If you want to authenticate the server, then the server you have in mind must have something special which distinguishes it from just any other machine in the Internet. Since everybody can buy the same kind of hardware, that "something special" must be something that the server knows. With a certificate, what the server knows is a private key in an asymmetric key pair (RSA, DSA...). Without a certificate, you can authenticate the server with regards to a shared secret (that both server and client know); see RFC 4279 (when the shared secret is a high entropy secret key) or RFC 5054 (when the shared secret is a password).


How to detect authenticity Of Client and Server Certificate?

You need to trust someone. Certificates that are presented to you are checked by your verification software:

Is the certificate's upstream root certificate in your trust store? (I.e. do you trust someone who is telling you that they trust A's certificate?)
The verification software also checks either the Certificate Revocation List (CRL) or uses the Online Certificate Status Protocol (OCSP) to see if the certificate was revoked before its expiration date.
Verification also includes other checks that are beyond the scope of your question.

To answer your question a different way (using your example scenario):

It should be very hard to steal the private key for server's A certificate. For digital signatures, (my company's focus), the private keys are usually stored in a dedicated hardware appliance that includes anti-tamper switches. If someone opens the box, everything is erased.
If someone does indeed manage to steal A's private key, then yes, they can masquerade as A until either someone discovers the theft and has the CRL/OCSP system updated or until A's certificate expires.

It is for exactly the reasons that you ask about that digital signature certificates for people should be tightly controlled. A Secure Signature Creation Device should be used.

[Disclosure: I work for CoSign]


What cellular network is used for automobile theft recovery? Can that be used for PCs and mobile devices?

MobiTex is still in use. As far as I recall (at least in EU) the frequencies are lower than "regular mobile frequencies" and hence the coverage is much better. Also, a lot of companies offer a combination of GPS and GSM/GPRS units to track and send/receive commands.

It's possible to re-use the cellular tech used for theft tracking for any device that can signal, e.g., take the iOS features, but obviously you'd either have to trust that devices signalling capabilities or add hardware to it.


Is Dual Factor possible during boot with whole disk encryption on Mac FileVault 2

Unfortunately, it's not currently possible.

From: http://training.apple.com/pdf/WP_FileVault2.pdf

  Two-Factor Authentication

  As discussed earlier, when using FileVault 2 (FDE), the initial authentication takes place as part of the EFI pre-boot authentication
  process. At this very early stage of the boot phase, none of the
  OS-reliant services are able to load because they’re dependent on the
  OS running. This means that alternative authentication mechanisms
  other than password-based  authentication aren’t supported at this
  time.  Any support for additional two-factor authentication
  mechanisms, such as smart cards or one-time passwords (OTP), requires
  further development of those services in the highly restricted space
  and execution of EFI. If an organization needs to use smart cards for
  authenticating and unlocking access to encrypted storage, use of
  container-based Legacy FileVault should be examined more closely.


How come this is in the email?

OpenVPN does not care about application layer, which means that it did not introduce such content to the email. This means that this content is either introduced by the sender or by the mail server.

While you offer only a few information about the mail itself let me just guess:

there is a hostname openvpn.
there is some attachment (image or whatever) in the mail.
this attachment/image is included in the mail like this (raw mail/MIME):

--some-boundary
Content-type: image/png (or something else)
Content-ID: {a long hexadecimal number}@openvpn
Content-Transfer-Encoding: base64
...

And then this Content-Id is referenced somewhere in the mail with something like

 <img src="cid:{a long hexadecimal number}@openvpn" ..>

If this is the case then you simply deal with normal HTML mails with inline images or similar, see RFC 2392. And the long hexidecimal number is just a unique id for this attachment.

  Should I be concerned about privacy?

Probably not about this. But if you look at the source code of the email and especially at the Received-Headers you might find other privacy relevant information to worry about.


Are there open databases or sites similar to xssed.com, not necessarily about XSS?

You are probably looking for xssposed.org, a successor website for xssed.com (actually they imported the old xssed database), and which was renamed to Open Bug Bounty a few months ago.

They list XSS and open redirects.


Allow only specific devices to be connected to USB

Buy a PS2 to USB adapter for keyboards+mice (important: both need to be in one usb port to make sure it's not a naive straight-through connector).

They have logic and cost about $10 USD at time of writing.

Then buy USB to PS2 adapters for both mice and keyboard (separate adapters).

They have no logic, just internal wiring to each connection and they cost less than $5 USD at time of writing.

Put them altogether. Yes, it looks funky, but the devices will still work as-expected. Now, even if one of the user-reachable cables is spliced, they can't add new hardware other than generic mice and keyboards.

Nice things about this:

cheap
simple
hardware-implemented
protects against unknown devices
OS-independent

UPDATE:
I manually verified, twice, that there is no continuity between USB's data-/data+ pins and the PS2 data/clk pins (or any other ps2 pins) on a two-in-one adapter. There is continuity on single-port adapters though, but that's not important as long as one of the adapters implements some kind of logic like the two-in-one does. Plugging in the empty adapter to a windows box should cause the "USB insertion ding"; otherwise it's a naive physical adapter.

The dual PS2-USB adapter I specifically tested was an "ez-pu21", available still on amazon.

UPDATE #2, 2 things:

there are usb keyboard attacks, so you need to lock down the OS properly to maintain security.
one can get inside bios with a keyboard, and i'm not sure how risky that is to exfiltration, or if all they can do is "break" the computer.

UPDATE#3:
After using the double-inline adapters for about 24 hours, I can say they work, but not quite 100%, maybe 99%.  When I was doing serious programming (typing) I noticed that keys held down for about 1/3rd of a second repeat. This is before my typematic repeat about 2/3rds a second after press, and it only repeats once; leading to stuff like "biig" instead of "big". I only noticed it a few times, late at night, but I wanted to mention it. I didn't even notice it until after hours of use, but if you were writing a novel, it might be frustrating. It could just be the cheap adapter i used, the really long cables i'm using or something else nobody will experience.

BONUS: (related but OT): I just realized these cheap usb switches don't connect the data pins, they are too cheap to switch all 4 wires, thus making a cheap "USB condom" for those who desire such a thing, thought i'd share. cheap condoms, how can you go wrong?


Understanding nmap output / author explanation ...(Scapy)

So I can take a swing at this, but I'm essentially guessing at the motivations of the author, the only person that can definitively answer this.

What he appears to be saying is, in the case above the filtered result might make you believe that a firewall rule is in place blocking access to port 22/TCP on 192.168.9.3 as such you might not think it possible to use that host and port for your own services (assuming you're the attacker here), but in reality access to that host isn't blocked, the IP address just isn't assigned.

It's true to say that to get the best out of tools like nmap, you need to understand what they're telling you.  "filtered" for TCP services really means "I didn't get a response".  Now if you're only checking hosts that have responded to some kind of pinging behaviour (the default with nmap) then that answer probably makes sense, as the host is present (it responded to ping) but it doesn't respond on that port (thus the filtered result).

In his example above I'd guess that the scan was run with -PN or similar so that nmap would scan hosts even with no response to ping.  In those circumstances "filtered" means "I got nothing back, that host may or may not actually be there"


If you receive mails which are encrypted with your certificate than these mails are still safe against decryption by others since only you have the private key. This is also true for signatures you create with this certificate since in this case the private key is used for the signature so that other could verify the signature with the public key contained in the certificate.

But, if the attacker compromising the CA managed to get another certificate for your identity then he could try to claim that this is the real certificate (and not yours). This way the attacker can sign mails with your identity and also receive encrypted mails which are sent to you as long these use the attackers certificate. The attacker can also work as the man in the middle in this case, i.e. receive mails for you with but encrypted with the attackers certificate, modify the mail and re-encrypt it with your certificate and then forward it to you.


Which Extensible Provisioning Protocol (EPP) status-values provide sufficient protection against domain hijacking?

Generally speaking, the EPP codes will not help prevent domain theft/hijacking, at least in generic top-level extensions.

Before 2006, it was possible to steal .com/.net (possibly other extensions) as long as a) they were not locked and b) the rightful domain owner would not object to it. b) in particular could happen when the registrant E-mail was out of date, had lapsed or the notification mail is spam-trapped.

With the introduction of the EPP code the practice of stealing/hijacking domain names has become more difficult.

The following applies to generic top-level extensions (ccTLDs often have different rules):

In order to transfer a domain name to another registrar, you need the so-called EPP code, and the registrar-lock status must be lifted. Which translates to lifting the clientTransferProhibited status.

The EPP code is often sent to the registrant E-mail address but can sometimes be retrieved online. It depends on the registrar. The registrar is also where you lift the transfer lock.

Valuable domain names are stolen sometimes. It often involves taking over the administrative E-mail account. If a hacker can take control of your E-mail address he can a) reset your password at the registrar (security questions may apply depending on the registrar), b) take over the registrar account, c) unlock the domain and retrieve the EPP code, d) transfer the domain away - or just mess with the DNS settings, for example to perform a malicious redirect.

The EPP status is a moot point actually. Just because a domain doesn't have any flag set, doesn't mean you can mess with it. If you can hack into the registrar account on the other hand, it's almost certainly game over.

To sum up, the best way to protect your domain names, is to make sure the administrative E-mail is secure and up to date and choose the registrar carefully.
Some registrars have enhanced security features like like 2FA, automatic E-mail notifications, while others may still be storing passwords in plain text and should be avoided just for that reason.

It goes without saying that the user account at the registrar should be protected with a password that is unique and hard to guess, and it doesn't hurt if the username is not too predictable as well.

One final note: the administrative E-mail is displayed in the whois record, as such it is public information. It is therefore a good idea to use an E-mail address for your registrar account, that is different than the one listed in the whois record.

Reference:
ICANN: EPP Status Codes | What Do They Mean, and Why Should I Know?


What can stop a browser to cache data from ProtonMail conversations?

ProtonMail use the following header in his replies :

Cache-Control: no-store, no-cache, must-revalidate, max-age=0

According to the standards :

  no-store

  The cache should not store anything about the client request or server
  response.

Thus, the data downloaded should not be cached.


If an attacker has the ability to modify data transferred over an Internet connection, can he or she affect TLS?

Yes, and this is exactly what the SSL Strip attack did, while using the unsecure HTTP connection it transparently turned all HTTPS links in to HTTP links and proxied the connection, if you did not notice that you where not on a HTTPS connection you could easily send confidential data over a unsecure connection.

As a web site admin you can combat this by setting HTTP Strict Transport Security, what this does is once you connect to the site once all future connections to that site will be via HTTPS till the header expires or the client's cache of HSTS sites is cleared, any attempts to connect to HTTP will automatically be redirected to HTTPS.

However this does not protect you if the clients very first connection to your site was intercepted, but it does help you in situations like you describe in your question where the browser tries HTTP if you don't have any prefix added1, HSTS will automatically force that HTTP link in to a HTTPS link if the site is stored in the client's HSTS cache.

1: It is not that the browser that automatically checks for HTTPS if it can't find HTTP. The way it works is the HTTP page will just be a redirect page to the HTTPS page if you hit it.


Could a cracked password run as a command on the attacker's system?

This is like many other questions which can be simplified down to "could x be vulnerable to y", where the answer may boil down to "yes, it is possible, but unlikely". For example, I highly doubt that well-known and reputable password cracking software is going to straight up try to run the cracked passwords as commands (side note: it is unlikely that password in particular would be cracked unless it was in a dictionary).

However, it could be possible that a single attacker somewhere has glued together multiple scripts and made a mistake where a variant of your password would actually work. The password, as it stands, shouldn't pose a threat unless it is passed directly to a command line or call to exec(). Let's say the attacker has cracked your password and pastes it as an argument to a hypothetical program with one of these variants:

# ./hack_user_with_password_i_just_stole --user you@example.com --password rm -rf / --no-preserve-root
# ./hack_user_with_password_i_just_stole --user you@example.com --password "rm -rf / --no-preserve-root"

Both of these are harmless; although the first one won't likely work since the program will probably trip up on the spaces. But this could happen if it was pasted without paying attention.

To give the password some teeth, we can prepend it with ;, && or || so the shell treats it as a separate command:

# ./hack_user_with_password_i_just_stole --user you@example.com --password ;rm -rf / --no-preserve-root
# ./hack_user_with_password_i_just_stole --user you@example.com --password ";rm -rf / --no-preserve-root"

If you were unlucky enough to run the first command, the malicious command would indeed execute since the shell treats everything after ; as a separate command from the first. The second command won't work, however, since the quotes cause the entire password to be passed as a single argument to the program.

Now, while pasting a password like this is unlikely, there are a couple other ways where it could happen. Maybe the attacker has a script that takes cracked passwords from a file and passes them to another program for purposes of credential stuffing, like you said:

cracked_passwords.txt:

user@example.com,password1234
<snip>
you@example.com,;rm -rf / --no-preserve-root
<snip>

hack_script.py:

#!/usr/bin/env python3

import os

with open('cracked_passwords.txt') as f:
    for line in f:
        user, password = line.split(',')
        os.system("./hack_user_with_password_i_just_stole --user {} --password {}".format(user, password)

If the attacker is naive and doesn't plan for spaces in the password, the payload would work here. Even if they surrounded the arguments with quotes, it could be defeated by using additional quotes in the password. That said, each of these hurdles would require your password to be even more complex, reducing the likelihood that it would be cracked in the first place.

As you can see, while technically possible, this scenario is rather specific and unlikely to happen.


Resources/materials for implementing secure web services?

Most of the OWASP top 10 still applies to web services.  A more detailed resource would be the Mozilla WebAppSec Guide.

"RESTful" web services should not have a "session token".  Related:  "Do sessions really violate RESTfulness?"  However at the end of the day you need a some kind of token for authentication purposes.

In short,  if you are writing a session handler to solve a real world problem you are doing it wrong.  The last thing we need is yet another reinvention of the wheel.  If you are writing a session handler for the purposes of education,  then that is a great learning tool!  The Mozilla WebAppSec Guide and the OWASP Session Management Cheat Sheet have detailed requirements for a secure session handler.


What is the attack tree to intercept traffic on Wimax?

I spoke at DefCon about WiMAX security a couple times, and I know coderman pretty well, and the idea is pretty simple. WiMAX femtocells exist, and are not as expensive as you might think. You buy a cell, configure it to look like a clear tower, and people will connect to it, no questions asked. You can then do with them whatever you want.


Why can't I generate my own JWT to fake authentication?

Simple: A JWT must be properly signed or encrypted with the private key of the authenticating server.
If you don't have that private key then you would have to sign/encrypt with your own private key. You can do that, and thus generate a valid JWT, but the application you send it to will easily be able to tell it was signed with the wrong key, and thus will refuse to accept it (assuming that there aren't mistakes made during the JWT validation process).


You don't.

However you can put in some basic controls, such as disallowing all outbound traffic, or analysing all outbound traffic for any nasties.

What the use of applications like these boils down to is trust, assurance or confidence. You use an operating system, right? How do you know it isn't doing this? (Actually, you probably know it is doing something like this, if you use Windows or iOS, or Android, or various others)

So, at one extreme, you can avoid all computers, and hide your face, and only use cash etc. or you can use the things that make modern life comfortable and accept there is an element of risk, but try and learn what risks are more likely and worry about them.


techniques of sql injection (boolean based, UNION query-based, stacked queries and time-based blind)

Boolean based sql injection is useful when the server doesnt return any information to you which is often the case. If you can determine that the response is different based on whether the sql statement returns true or false, there are ways to get the information your after even if the server doesnt return it to you.

For example, if a password field is vulnerable to boolean based sql injection and you type in the correct password then ' And 1 = 1 -- on sql server, you will be logged in. If you do the same thing with 1 = 2, it will say invalid password.

If you try to put a select statement in that attack vector, you will get nothing back, it just wont let you in.

This is where boolean based sql injection is useful. You can craft an attack vector to say

Sql Pseudocode:
And ( the first character of the first column in the database has an ascii value greater than 25)

If it logs you in, you can say, is it greater than 55, and so on, until you get the character. You can then do the same thing with the 2nd character, until you get the full column name.

I cant go throug every technique but there are loads of resources out there. I think the best way to train is to spin something up thats vulnerable.  Then run sqlmqp and proxy the traffic through burp suite or something. Then you can see exactly what the tool is doing.


How to response to Meterpreter HTTP Request sent from client

As far I understand from your post, is not clear some points, you want to simulate the responses of the Meterpreter. If this is the case, my recommendation is to pcap traffic to a Meterpreter server and see what are the responses. After that is trivial to include that responses on your python server so you will be able to simulate some of the functionality.


If I have a valid certificate for xxxxx.github.com, can't I read *.github.com's cookies?

If you have a valid (i.e. accepted by clients) certificate for a domain and you can redirect the traffic to the domain to your own system, then you can be in most cases a man in the middle and read and modify SSL encrypted traffic for the domain. This also includes reading cookies, usernames, passwords ... - i.e. everything which TLS was supposed to protect. But if you can actually read a cookie for example.com if you have a certificate for subdomain.example.com only depends on the domain attribute set on the cookie. By default a cookie will only be send to the exact domain which it was issued for, i.e. a cookie set on example.com will by default not be sent on subdomain.example.com.

As a "normal" user you typically can only control traffic inside the local network, i.e. redirect it using ARP spoofing or DNS spoofing or intercept the traffic by having full control over the gateway (router) used by the users in the network. If you are an ISP you could redirect/intercept the traffic for more users and some government agencies have this kind of ability too - in some countries for example all internet traffic goes trough government controlled systems.

Protection against this kind of attacks is done with methods like certificate pinning, certificate transparency or similar - see also Can a nation-state adversary perform a MITM attack by compelling a CA to issue them with fake certs?.


How can I determine if a malware sample is morphic? (polymorphic, metamorphic, etc)

It depends on whether you want polymorphic or metamorphic.

Polymorphic usually means the malware which is capable of changing itself while distributing itself. So first thing to determine is whether malware is actually making copies of itself (most typically writing into network folders). Then you can see whether those copies are different. This could be confirmed either by static analysis (such as disassembly - time consuming) or dynamic analysis (emulation or sandboxing - faster). This is relatively rare nowadays.

Metamorphic usually means the malware is changed at the server, and everyone downloading it gets a different binary, even though all those binaries implement the same thing. This is very common nowadays. A specific sample you downloaded will always remain the same, and will make the same copies. However a sample someone else downloaded would be different from yours. Trying to download several copies, including different source IPs (ideally via local connectivity, less ideal VPS, much less ideal VPN) and spread in time (i.e. every few hours) would get you lots of samples.


Advice on selecting programming languages to concentrate on? (2nd year IT security student)

If you want to learn about virus design, you will need some knowledge of assembly -- preferably for at least two or three distinct architectures (x86 is already two architectures, with the 32-bit and 64-bit modes; add ARM, Mips or PowerPC to that and you'll be all set). C++ is nowhere near low-level enough for that.

If you know assembly, you can grasp how C works (and why it works that way), and at that point all other languages become easy. And then you understand that the specific programming language is an illusion; it is not very important for security -- the concepts are important. Programming languages are just a way to express these concepts. The more languages you know, the less you will be distracted by the peculiarities of any particular language.


JSON API response flagged as XSS by vulnerability scanner. Is this a false positive?

An XSS vulnerability usually consists of two components: A backend which reflects user-provided strings without filtering them and a frontend which puts that input into a HTML document without filtering it.

So you don't just need to look at what the server does, you also need to look at the application which consumes that JSON response.

Is there a possibility that it will inject the path into a HTML document as-is without escaping any HTML tags in it first? Or that it processes that JSON document not with JSON.parse but with eval which would allow the server to pass exectuable code to it?

If that's the case, then the first priority would be to fix the consuming application. But as part of a defense-in-depth strategy you would also be well-advised from preventing the server from passing strings which contain valid HTML to the client. A good approach is to encode < and > as &lt; and &gt;.

Also make sure that the JSON response doesn't get malformed if the user-provided string contains a ". That might not just be annoying, it could also be abused in some scenarios to confuse the tools which consume the response.


You'll want to load into tool such as OllyDbg and you'll have instructions and you can modify them to do the same sort of job as alternative instructions then save them to executable so byte signature against your file would be bypassed.

You can rewrite code to do same job. Let's make a really basic scenario.
Imagine you seen in executable. I'm going to pretend this is x86 executable:

004CFF64 - B8 05000000           - mov eax,00000005
004CFF69 - B8 07000000           - mov eax,00000007

So, 10 byte in total.

You could rewrite that as:

004CFF64 - B8 05000000           - mov eax,00000007
004CFF69 - 90                    - nop
004CFF6A - 90                    - nop
004CFF6B - 90                    - nop
004CFF6C - 90                    - nop
004CFF6D - 90                    - nop

Which is still 10 bytes in total but the signature has now changed.
Reason why we used a NOP (No Instruction Preformed) is because it does nothing but use space.

Now, in real world situation you won't come across it as easy as that you'll have to use code-caves and so on. For example let's say you needed to write more than 10 bytes of code then you really can't do it since you would overwrite next instruction which would corrupt the executable. Well, what you do is use JMP instruction to free space in memory which then you'll do all code there and you'll use JMP to get back to normal execution of code.

Byte signatures are generally do on whole file and static parts of the executable.
For example .text (Sometimes known as .code etc) which is the executable part of the code and the memory regions are not writeable so they won't change although you can override the permissions with VirtualProtect API.

I could go into much more detail about obfuscation, how byte signatures works and so on but I hope that answers your question if not leave a comment and I'll expand my answer.


Is php DOMDocument::loadXML completely secure?

for XXE please read:

http://www.ubercomp.com/posts/2014-01-16_facebook_remote_code_execution
http://blog.h3xstream.com/2014/06/identifying-xml-external-entity.html

i can confirm a similar attack worked on Java/Tomcat

And then there is a Billion Laugh - Attack ( i think this was what Bruno referred to)

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


As an end user on a network, how can I avoid being MITM'd by an SSID-spoofing device?

As a client your basic countermeasure is to use a VPN.  Since you don't have a good way to baseline anything about the multitude of Wifi access points you might have to use, your ability to spot a real one vs a Wifi Pineapple is pretty minimal.  Your only hope, really, is to immediately route all traffic through a properly authenticated VPN which will resist attack (or at the least, fail and indicate your traffic is being heavily manipulated).

If you are the Wifi operator, you have a number of additional options to mitigate, most of which include just basic channel use awareness since a Wifi Pineapple or similar device is only going to work by displacing your existing infrastructure (or operating so close to the border that it can lure some users away) and in either case, you simply need to be running your own counterintel (watching open Wifi activity from a listen-only station with a good antenna) in order to spot an attack in progress.


You could end your script element and start a new one:

%0A</script><script>alert(/xss/)//

There will still be a syntax error in the original script (none of it up to this point will run), but the added one will still execute (including anything that comes after it). Demo. As you can see, disallowing quotes is not a valid defense against XSS, escaping is the way to go.

(And in case you're wondering, the attack is possible even if the call were wrapped in a function or eval.)


Data Security on a Malicious WiFi Network

From what I've read, using https:// is safe. Is this true for networks set up for malicious purposes?

If done right https is still safe. But, if you (actively) accept any kind of untrusted certificate (self-signed or signed by unknown CA) an active man-in-the-middle attack is possible. If the attacker owns a public root-CA or some intermediate CA or managed to issue specific certificates it is even possible to mount such attack without needing the victim to actively accept the spoofed certificates. While this is unlikely it was actually done.

If you are connecting to a site which uses public key pinning or certificate pinning (like access to google.com from Google Chrome) you are still safe in this case, but only for accessing these specific sites.
If the attacker instead managed to steal some high value certificate or issue such certificate for sites not protected by pinning, than it is possible to do harm on other sites too, because high-value sites like google-analytics.com, jquery.com etc are often included as script into other sites.

  If I visit websites where I'm already logged in, and thus don't enter any passwords, can my credentials to these websites be compromised? What about session hijacking?

For HTTPS you should be safe (see above). For plain HTTP it depends a lot on the site. Some sites not only use a random session cookie but also add browser fingerprint into it. This makes session hijacking harder but usually not impossible. Other sites instead let you change the users password or the reset e-mail without asking for the old password. In these cases a permanent takeover of the account is possible.

EDIT to summarize the good comments here: any security collapses when you use unencrypted HTTP (or FTP). From then on sslstrip, script or HTML injection etc make it possible for an attacker to hijack anything. So you better disable HTTP and FTP , which could be done by setting the relevant protocol proxy to something non-existent.


Should you really check user uploaded files for malware/shells?

There's three different concerns that get conflated a lot:

You need to make sure the server can't be tricked into executing code.
You need to make sure the server can't be tricked into serving a user-uploaded file with a Content-Type (html, svg, xml) that allows Javascript to execute within the site's origin when a user accesses the file.
Optionally you might want to stop users from accidentally sharing malware by blocking it from being uploaded.

Part 3 is optional. You can imagine the extreme case where you're literally making a website for people to upload malware samples for inspection. In that case, you wouldn't want to implement #3 at all. That server shouldn't do any filtering and shouldn't prevent any files from being uploaded. Files are just bytes; as long as nothing is executing them, they aren't inherently unsafe to store or process. For regular sites, #3 is a nice-to-have, but it should be prioritized after #1 and #2 and can not be done instead of them. Parts #1 and #2 are always necessary.

The main way #1 can be failed is if you're using PHP and you save the files to a directory where PHP is enabled. Then if the user uploads a file with the extension .php, the server will executes it if the user requests it. You can prevent this by disabling PHP on the directory that uploaded files go into. You could also have an explicit whitelist of extensions which doesn't include .php. You should test your application by trying to upload a php file that contains some php code (<?php phpinfo();) and verify that the upload is either blocked, or shows up exactly as you uploaded it.

To solve #2, you need to make sure files are only served with specifically-allowed "Content-Type" headers. Most web servers default to choosing the Content-Type header based on the file extension, so you either need to override that so all files get a safe Content-Type ("application/octet-stream" is a good default that tells the browser to download the file) with maybe a few content types whitelisted (mainly just non-svg images), or make it so there's a whitelist of allowed file extensions. You should test your application by uploading an .html file and making sure that it does not display as a web page. It needs to be blocked, or prompt your browser to download instead of viewing in-place when you access it.


What happens when an x509 CA certificate expires?

Signing is done with the private key. The matching public key to verify the signature is inside the certificate. You can renew a certificate (change the expiration) while re-using the existing key pair. Thus the signature will still be valid even if the certificate itself got changed.

For upgrading the quality of the key you create a new key and create a new CA certificate based on this. New certificates will then be issued by this new CA certificate but the old CA is still usable to verify existing certificates and can be thrown away once all these older certificates expired.


Is it secure to use pbkdf2 for both password hashing and key generation

Since PBKDF2 could be use to generate as much bytes as you want/need, you can of course use it for both master password hashing and key generation. You don't even need to use different salt, just generate a n bytes hash, then generate n+m bytes, discard the first n bytes and use the other m bytes as key.


Extracting the PGP keyid from the public key file

You can use gpg --dry-run to prevent changes.

Following line will print the key id in its output (can be modified using the usual modifiers like --with-colons for further processing). A4FF2279 is the key ID in here.

$ gpg --dry-run --import pubkey.asc
gpg: key A4FF2279: public key "[User ID not found]" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: no ultimately trusted keys found

Just tried it, the key did not get stored to my keychain, but the key ID was printed. But watch out with --dry-run, the man page has a warning:

   --dry-run
         Don't make any changes (this is not completely implemented).

A more in-depth discussion of multiple variants for human-readable, machine-readable and very technical output for different versions of GnuPG is found in the Stack Overflow question How to display gpg key details without importing it?. All of them will also present the key ID.


Is it safe to add IP address to SPF record

What can be done depends how much control you have over this IP address. Adding this IP to the SPF record means that any mails originating from this IP address are allowed to use any email address within your domain as sender within the SMTP dialog. If there is only one application which runs there and you trust it this might be fine.

If instead you must fear that this application might misuse your trust to send mail from different users in your domain or that other applications on the same IP address might send mail then you should probably not allow this. In this case it might be better that the application instead delivers the mail via your own infrastructure where you have better control which mails are send and can add the appropriate restrictions.


service metasploit start failed to start metasploit service

#/etc/init.d/postgresql
service --status-all
service postgresql start
service postgresql status

#/usr/bin/msfconsole
msfdb init
msfconsole
msf > db_status


Convince the company not to store credit card numbers in our webapp

Storing card numbers means you must comply with the requirements of PCI-DSS, or you risk fines and breach of your merchant account contract. PCI-DSS has an enormous set of requirements - some sensible, some onerous, some of questionable usefulness - and the cost of complying with it, and certifying that you've complied with it, can be very high.

Download the PCI-DSS 2.0 standard and be afraid.

In particular, neither of the suggested approaches are PCI-DSS compliant. Keys mustn't be stored unprotected or in the same place as the cardholder data they protect.

If you must implement this in-house, you need to isolate the components that touch card numbers from everything else, so that PCI-DSS only applies to a limited number of systems. Look at tokenisation solutions to help you keep your cardholder data exposure to a minimum. If you don't do this right you can easily drop all of your servers (or even all your corporate desktops!) into PCI scope, at which point compliance becomes difficult-to-impossible.

Authorize.net offer automated recurring billing services. For the love of sanity, use that.


Is this a good scheme for storing encrypted user credentials?

You don't really describe this step very well:

  If user login credentials are confirmed, a symmetrical AES-128 key is generated from their unencrypted password and their unique salt and attached to their session to decrypt the credentials of the third party accounts stored in the database.

Exactly how is that 128-bit key created? That should be a very slow process, otherwise you are providing a side-channel to brute-force user passwords. The way it would work is an attacker gets their hands on your database. Rather than try to brute force the bcrypt hashes, which would be very time consuming, they get to work on the encrypted passwords. They simply brute-force the user password to get keys that appear to work (ie: the decrypted text looks like passwords, whatever that means). This will be a fast attack because encryption is fast.

You need to make the 128-bit key creation a slow process. The best way to do this is probably to use bcrypt. But, as you have probably figured out, you don't want to use the bcrypt value that you've stored in the DB for authentication as that would not be a safe way to store encryption keys. I suggest that you keep a second salt for each user. You then use that salt, plus their clear-text password, in a call to bcrypt to generate the 128-bit encryption key.

When a user changes passwords, you should either wipe or reencrypt all of the encrypted passwords. This is needed because users frequently change passwords when they are concerned that their password has been compromised. So you better wipe the data that was encrypted with the compromised password. Though this, of course, won't help if the attacker already got a copy of the database before the password change.

Another security measure you could add is to pepper (search for "pepper" in this answer) the encryption key. The pepper should be a truly random bit string (no, your cat's name doesn't qualify) that you store someplace else. That is, it is not in the database. Use of a pepper will prevent an attacker who gets both a copy of your database and a user's password, from decrypting the user's data as they will still need the pepper. Remember that a pepper is only as helpful as it is secure. Putting it in your source repo is probably a bad idea.


What is the equivalent of "forgot password" in password-less login applications using FIDO2 / Webauthn or later?

There are legitimate reasons for why a user may not have their authenticator with them, such as:

They have lost access to their authenticator (lost, stolen, etc...)
Their authenticator broke
Their authenticator is not compatible with the device they try to access your site from

There are several possible ways to react to this now, and it's best to offer the user several options:
Sign-in With a Different Authenticator
That could be a Time-Based One-Time Password (TOTP), as is supported in multiple "authenticator" apps, or a hardware-based key like a YubiKey. Certain mobile phones also support similar hardware-backed solutions.
This solution works well if you encourage you user to register several different methods, so in case one is unavailable, another one can be selected. However, if your user only registered, say a TOTP app and then their phone takes an unexpected fall, that may be an issue.
Offer Printable Backup Codes
One option several platforms offer is to create a set of "backup codes", which are long, automatically generated codes. Users are encouraged to print them out and keep them in a safe place. The advantage of this is that it's pretty low-tech, so it's hard for a piece of paper to break or get hacked, and users themselves can choose how many copies they'd like to make. More copies offer higher availability, but also increase the risk of an adversary gaining access to the copies.
Of course, this solution also requires the user to be prepared beforehand. Hindsight is 20/20, as they say.
Sign-in On Another Device
If you are authenticated on your mobile device and wish to authenticate on, say, a desktop device, then one possibility is to let the already authenticated device generate a one-time code. The process works as follows:

User "foobar" wishes to log into example.com on their laptop
User does not have any compatible authentication methods on their laptop
User selects to authenticate with an already authenticated device (e.g. their phone)
Application generates a link like example.com/auth/5GH8D3
User types this link into their phone, where they're already authenticated
The website returns a one-time code like 8DFG 66TN
User enters this one-time code in their laptop and is authenticated

The advantage of this is that, as long as at least one device has access, other devices can gain access again as well, which allows the user to register more authenticator options.
Offer to Contact Them Via Already Verified Channels
Some users may simply be out of luck and only have one authenticator, and that may break. In that case, contacting the user via already verified channels, such as e-mail, may be an option. However, users should expect significant delay here, like one week or so. In this case, users should first be notified via every possible means that an account-recovery process was initiated and that, if they did not initiate that, they should immediately contact support.
After 7 days or such, users contacted by support must show some sort of proof that they own the account. This differs from application to application, but Steam for example asks you about your last purchases.
Naturally, this will also allow malicious actors to gain access to the account, so it should be possible for the user to disable this option. Just make sure that you add a big, bold warning sign like WARNING! IF YOU DISABLE THIS OPTION AND LOSE ACCESS TO YOUR AUTHENTICATOR, THERE IS NO WAY TO RECOVER YOUR ACCOUNT. BY SELECTING THIS OPTION, YOU EXPLICITLY ACCEPT THE RISK THAT YOUR ACCOUNT MAY BE LOST WITHOUT ANY RECOVERY! You know, something like that...


What are good free opensource tools for helping in manual source code reviews?

I'd suggest looking at Agnitio which sounds like a good match for what you're trying to do.  Another option might be Dradis although it's a bit more of a general information sharing/organisation tool.


Is it possible to read a text file inside a password-protected zip file without the password?

No. There are two ways of zip encryption, a classic one, which is weaker, and a newer one based on AES.

In both cases the password is needed in order to decrypt the contents (i.e. it's not just UI, where you could be asked for a password without the program actually requiring it to read the file). So the process would involve breaking the password (which would be more or less complex depending on the algorithm used and how the password was used).

At most, you would be able to obtain without decrypting, in addition to the filename, the CRC32 of the plain file. But although that would help if you already suspected what the content was, it probably won't be helpful here, even if it is just a line of text.


Unknown Requests on URL Web Filter Proxy

Looks like someone has the kali.org blog page open, which has an embedded Twitter widget on. This will make requests approximately every 30 seconds, checking for new tweets from the @kalilinux Twitter account.

The following screenshot from Burp, whilst the page https://www.kali.org/news/kali-linux-20171-release/ is open shows this - the final column is the time of the requests, and can be seen to occur every 30 seconds. Depending on the browser being used, the frequency might be adjusted based on whether the tab is visible or not.

The responses have a content-disposition header, so could be triggering a SIEM which looks for unexpected downloads - the content type should be application/json though.


PGP-encrypted Email or SSL/TLS Webform for Responsible Disclosure Communication?

When we are working with Responsible Disclosure Communication, we need balance security and convenience.

Convenience for whom?

For security researchers.

You need to think a few things before choose:

Do you need the reports so safe that you can wait to receive them?

Sometimes the security researcher finds a security bug, but he is not with his PGP keys. And if he is traveling? You will wait a few days (or more) to receive the reports. Is it expected? Sometimes it is not.

What is best, address a bug quickly, even receiving the report through insecure channels, or take slightly longer to address the bugs but be sure that the reports are send and stored in the safest way?

Just you can answer this question.

I worked managing a Bug Bounty Program recently, and I can say to you that a few researchers will choose send the bug through the HTTPS form (fast), others will e-mail you in plain-text (faster) and others will never talk with you without exchanging PGP keys.

And you never can say that one type of security researcher will send better reports than others (the PGP guy, the HTTPS form guy or the plain-text e-mail guy).

So be careful with your choice, I would choose the option 3.

In my opinion is better receive a report than not receive it, independent of how I received it.


Weird IP addresses showing up on my server

This is totally normal. There are thousands of bots on the internet that have the sole purpose of scanning every single IP address and attempting to infect it.  Any information they discover will be put into a database somewhere, and there's nothing you can do about it. If you change your IP then that one will be discovered too unless you enable a firewall like ipchains on *nix and block all but known IPs, which is what you should be doing unless you need the internet to have access to your system.

Also, make sure your system and all the software on it is kept up to date. Be pathological about that as most attacks use well-known and patched vulnerabilities.


How to limit web API microservice communication to specific list of machines?

IP Spoofing, successful three way handshake (which used by TCP protocol) is not at everyone's fingertips. Yes TCP have security issues and also there is spoofing techniques but I believe your level of interest does not require that much attention. HTTP works over TCP.

Would you want to have one of the following solution.

If you are using a cloud provider, use their "security group" configuration for restricting access of website. Use outgoing ip address of that website. If this website is service provider, they will provide outgoing ip address.
If this application stored at a hosting firm, you don't have much choise, migrate this app to cloud or search for "php firewall"
If you have your dedicated server (virtual or not) and does not have firewall, you can check services like CloudFlare, Sucuri etc.
If you are looking for enterprise grade integration between them, deploy a tunnel for that communication (both parties need to install / configure)


The ChaCha20 algorithm is simple enough that if you're curious about how it works you could just write your own implementation (but don't use it in production!).  RFC 7539 is a simple reference that also comes with examples so you can easily check for correctness as you go along.  But the way it works is that you XOR the message with a keystream that is generated as a set of 64-byte blocks, where each block is "named" by three arguments:

The key (secret);
The nonce (not secret);
The block counter (not secret).

The block is initialized with these values and some constants in the way that your code snippet shows.  Then the block is scrambled with the doubleround operation ten times (ten double rounds = twenty rounds, that's why there's a "20" in the name).  And now, critically, the initial state of the block is added into the result of that, and this step requires the key again—so if you erased it you wouldn't be able to carry out this final step.

After that final addition the key should not be easily recoverable from the resulting block (or otherwise the cipher is completely broken!).  But nevertheless the block's content is a sensitive secret, because an attacker who sees it can decrypt the corresponding ciphertext block.

All you've got at this point, however, is one 64-byte block, which is good only for encrypting or decrypting one 64-byte block of the message.  Unless 64 bytes is the largest message length you'll ever encrypt, you're going to need the key again and again to generate additional blocks.  So you can only erase the key and blocks after you've encrypted or decrypted the whole message.

Since both the key and the keystream blocks are secret data, you'd want to use your operating system's facilities to prevent that memory from being swapped out to disk.  And you'll want to safely zero out that memory after you're done with it.

Similar considerations apply to other ciphers, but the details are different.  For example, many ciphers (but not ChaCha20) have a key schedule, i.e. a sequence of "subkeys" that are derived from the secret key.  Often it is the case that after you've generated the key schedule you don't need the key any more, so you could zero out the key at that point, but the subkeys need to be protected, and you need to hang on to them because you reuse them for each block that you process.


How to communicate Credit Card details to customers when instantly approved in PCI-DSS compliant way?

IANAQSA, and you seem to be getting into the Issuer business.  You really need a QSA.

You are asking about the requirements upon issuers (most PCI-DSS questions are from the POV of merchants, acquirers, and processors; the other side of the equation).

Issuers are also held to the PCI-DSS, but obviously they have different constraints.  For example:

  3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only
  personnel with a legitimate business need can see more than the first
  six/last four digits of the PAN.

For an issuer, it is a legitimate business need to communicate a cardholder's card number to them.  Most commonly, this is done by shipping a plastic card to the cardholder's mailing address.  So Issuers clearly get a pass on the requirement to Mask per 3.3 when business need requires them to disclose the full card number.

You're asking about virtual / electronic only cards, and there is precedent that Privacy.com displays full card data - PAN, expiration, and CVV - as soon as a user allocates themselves a new card.  So my best answer is - yes, you can display those details per business need.

To address followup from the comments:

QSA is Qualified Security Assessor; the auditors recognized by PCI as authoritative.  Since I Am Not A QSA (IANAQSA) what you get from me are opinions, but not worth anything when audit time comes.

All the MFA/2-factor requirements in PCI revolve around administration, not end users or customers, so that should not be an issue.

Privacy issues legitimate card numbers; I believe they do fall into pre-paid bins, but they aren't really pre-paid cards, as they're backed by ACH and can have sophisticated limits.  But, yes, to a merchant they look like pre-paid cards.


Is a password manager better than an encrypted file for storing passwords?

Having an encrypted text file with passwords in it is certainly better then having common/reused passwords or an unencrypted file.

A good password manager is, however, incrementally better, in the following ways (off the top of my head)

Better memory management - it can prevent passwords being left in computer memory which can be snaffled by other processes/users.
It only exposes the needed password, not all of them.
(Sometimes) Browser integration makes life easier
Many eyes - a program designed specifically for password management, and audited, likely has stronger processes in place to ensure good hygene.
Cross-platform compatibility, arguably easier to merge records and manage in a cloud environment/from multiple locations.

You might want to look at Keepass and other variants, and the kdbx format.  (And how well its supported).  I use that under Linux (I assume you use linux as you mention APG)


Intercepting proxies and web traffic interception

Intercepting proxies are tools used to analyze, modify, and in some cases inject traffic into the normal session created between a client and server.

One common example where this is used is in testing the security of a website using a tool like Burp Suite which acts as a proxy connecting your own web-browser to it, frequently using a plugin similar to foxyproxy but this can also be done via manual configuration, then having Burp Suite initiate connections to the web server on the clients behalf.

This allows Burp Suite to control a connection that was requested by the web browser and allows for a large number of tools and testing methodologies to be inserted into the connection. It should be noted that there are some browser plugins which can perform many security tests but by utilizing the hooks to connect to a proxy it removes many of the software limitations and allows for much easier testing of the web server.

Finally it's worth mentioning that these allow for dynamic testing of the application which is very different than what you might do by simply analyzing traffic between the client and server. Likewise there are lots of other types of intercepting proxies used for other types of testing (not just for security).


OAuth & SAML integration or better approach

So most application are going to use SAML or OAuth, not both.  And SAML is a lot more involved than a simple cookie.

If your primary focus is authentication for multiple systems, and you don't have a federated auth provided in place today that will give you the infrastructure for SAML, I'd stick with OAuth, and if you need a authentication/profile provider that is more heavily specified than the bare OAuth spec, I'd look into OpenID Connect, which is a additional standard on top of OAuth 2.0.


Is there a way to get information out of the router

Look at wireshark with an card on the network listening in promiscuous mode.  Additionally, some routers will have a feature to log/see traffic going through directly; most home routers will not.


Something is wrong in your risk assessment process if you are finding new risks every day. It could also be that your risk identification was done at the wrong level of abstraction.

My guess is that you are doing this on a very low level and you should move up to understanding business impact. Risk is basically something of consequence that could go wrong. A technical vulnerability is not a risk. If you discover a new weakness in your webserver, that is a vulnerability and not a risk. The risk is, for example, that customer data could be stolen, or that your service could become unavailable.

If you view it like that, then discovering a new vulnerability would not create a new risk, it would affect the rating of an existing risk, and that is how it should be. So your server has more holes than you thought, that increases the potential frequency of loss, or whatever risk assessment method you are using (in FAIR, for example, it could reduce Resistance Strength).

Even if you uncover entirely new ways in which, say, personal data could be lost, the risk still is the loss of personal data. You just discovered a new attack path, not a new risk.

This doesn't directly answer your question, but it would solve your problem. I'm fairly certain that your existing Risk Register would serve you good enough if you thought of vulnerabilities as changing parameters in existing risks instead.


snort ignores packets with matching src/dest IP address

Preamble: I wanted to just add a comment first, as it's still rather unclear what might be causing your problem from the information you provide, but I ran out of space reserved for comments, so here goes my suggestion (no guarantees it's actually the case):

On what kind of a capture file you're trying to run Snort rules through is rather unclear both from your question, as well as your later comments. It's however possible that you're running your replay in a single packet capture mode, but from a file with many pcaps. That's what flag -r implies (is the same as using -pcap-single=<file>) and your comment that it works on some rule and not the other suggests this might be the case also (if in one instance the first packet capture would match your rules, while in another the pcap that would match your rules might not be the first one in the list of many). To make Snort replay process multiple pcaps from a single capture file, use -pcap-file=<file> instead.

To be sure this is the case, you could test that with a -pcap-no-filter flag and see if it iterates through all of them in the output. Other command line arguments relevant to your use-case are listed here.

Alternatively, you could change your rule to match all packets, and see how many results it returns:

alert udp any any -> any any (msg:"This should match all UDP packets in an input file";)

Other than this, I don't see any problems with your snort rule you gave in the example, and it follows Snort rules form properly.


How does Amazon Fire TV know my name/account?

The Amazon Fire TV is pre-configured with your account:

  Pre-registered to your Amazon account so you can enjoy favourite titles and personalised recommendations

They configure this with your details taken from the account you used to order the device.


Is Western Digital external HDD encryption still flawed?

To answer to your last question: definitely.

I would never put trust in a piece of crypto software of which you cannot determine how it works, as is the case with most of these closed firmware security functions within hard drives, or shipped utilities. Please research the Kerckhoff's Principle why this is so important.

Open sourced cryptography software is not an absolute guarantee of a proper cryptography implementation, however it makes it more easy to spot issues, and even more important, to correct them. Veracrypt (and its precursor Truecrypt) are well tested and audited, so can be trusted with your secrets.


I've discovered https://www.mailvelope.com/, looks interesting.

It's a browser extension which keeps keys on the client. Although primarily designed for encrypting messages on webmail, it also supports signing. It also seems to expose an API, though I haven't found anything in the API pertaining to message signing in particular.


How does a firewall doing HTTPS inspection verify the servers certificate?

... because firewall does not have trusted root certificates.

The firewall does have a set of trusted root certificates. They are not necessarily exactly the same as the client has in the browser but there will be overlap for the commonly used CA. And it might even be intentional to let the firewall trust  less CA then the browser does.


Strategy for updating stored passwords to more secure hash?

I don't see a reason why it should be problematic to take the existing hashes, take them as input for a more secure hash function and migrate all existing users at once. Extensive discussion on the approach can be found here. You will have to store both old and new salts, of course.

In combination with a good password policy (force your users to change passwords after a reasonable period) you can slowly phase out the 'legacy' passwords.


In the sense that you can cause the program to act in a way that it shouldn't, then yes this is exploitable. To exactly what degree you can exploit the process entirely depends on the process itself.

Causing the process to terminate with an error (Denial of Service) is easy, just write 4 random bytes to a random location and you'll probably trip it over.

A 4byte overwrite allows you to supplant a 32bit address value. The first thing that comes to mind is to subvert program flow, either a return, a call, or a jump.

If you can find a piece of code that does something useful to you, typically by looking at the libraries that are loaded, you can jump to that. You might even be able to make a system call if you can find a situation that has the correct arguments loaded onto the stack before a program flow instruction.

You could overwrite the value of a pointer on the stack to point at something else, this could easily lead to information disclosure. Such as altering the pointer that points to your username string so that it points to a secret key, or a password hash, and then interacting with the program such that it would usually echo out your username string.

You could alter an entry in the Global Offset Table to supplant one function call with another function call globally across the process. This would allow you to, for example, remove a wrapper function by making all calls to the wrapper actually calls to the inner function, potentially removing a security feature, such as a parameter check, which you could later exploit.

I could go on, but the idea is either to;

Make the program do something that is desirable to you.
Alter the program such that it is vulnerable to exploitation some other way.


Should a VPN user be allowed to bypass a SSH jump host?

If I implement OpenVPN alongside my existing OpenSSH setup, end users would have two methods to gain remote shell access--the SSH key and the OpenVPN TLS key. I am afraid this complicates authentication for my users, increases the attack surface of the network, and increases the difficulty of access auditing and intrusion detection.

The answer to all of this is yes.  Obviously opening up another method of access to a network is going to increase the attack surface.  The real question is if the benefits are enough to justify the added risk.  You ask if the VPN server is really a good idea, but alternatively, if you have a VPN server, do you really need to keep the SSH server available?  As mentioned in one of the comments, the VPN is a more robust and secure method to provide access to the network-but requires more setup and maintenance.  Keeping things simple, or familiar, for your users is always a nicety to consider, but security should generally overrule convenience.

It sounds like you are dealing with developers who should be competent enough to understand there is generally some give and take between security and convenience, so you need to figure out where that balance lies for your client's specific needs.  The questions about reusing keys and collating audits all depend on the needs of the client, the security policy in place, the level of protection desired for the information, current network architecture and implementation, etc... Re-using a key between two disparate systems is not going to provide the highest level of security, and it comes with more risk.  But depending on the level of protection you need, it might provide ENOUGH security for your implementation, without the more complex and costly setup of a true Single Sign-On system.


How can a critical Adobe Acrobat security update, only available as an unsigned executable over plain HTTP, be verified?

You're right. If you go to Adobe's website the update is transferred over HTTP and not HTTPS, which give any hacker in the network to hijack your update file with a simple Man In The Middle Attack and inject his/her malicious file instead of the legitimate Adobe's update.

However if you go to the same page and instead of clicking the download now button you copy the link and add HTTPS as a prefix to it. The file will transferred securely over HTTPS.

here is the direct link: https://ardownload.adobe.com/pub/adobe/reader/mac/11.x/11.0.06/misc/AdbeRdrUpd11006.dmg


How to hide real IP from browsers while using VPN?

The geolocation API which allows websites to obtain your location from your web browser is supposed to be opt-in. The standard specification says that it must not be enabled without the users permission. For that reason it can be switched on and off in the settings of most web browsers.

When you don't trust your web browser to respect that preference, then you should use a different one. When you run software you can not trust, you've already lost any security you could have.

That being said, you could build a setup like most corporations do. Set up a LAN where the workstations have only a local IP address and no internet connection. Then set up a proxy server on your LAN which is the only machine with both a LAN IP and a WAN IP. Install the VPN client on the proxy so it uses the WAN IP only to tunnel to the VPN provider. Have the web browsers on the workstations connect to that proxy using the proxys LAN IP address. That way you could do web browsing while your browsing machine isn't aware of the WAN IP (and not of the VPN provider either, for that matter). As a side-effect you have also succesfully firewalled your workstation against any internet communication which isn't supported by the proxy.


My opinion is that you are trying to use quite a full set of security/anonymy tools. Still my opinion is that few flaws if any could allow to identify you from a remote host. Now if the question is is it enough to guarantee my anonymity my opinion will be no.

Fingerprinting methods could allow to identify your connection practices. No way to identify who and where you are till now. But if other evidences could make a legal inquiry suspect you, the knowledge of both how your computer is configured and what were the connection pratices could add evidences that your machine was used. And as you speak of China, my advice is to never underestimate rubber hose attack.

Of course if all what your need is that little cousin cannot guess that you hacked if facebook page, that is probably too much.

TL/DR: as said by Shroeder in its comment, you must first define what are the threats you want to address and only them setup a security system relevant for them.


I am not aware of any public crypto library with countermeasures against side-channel attacks based on power analysis against AES (or any other symmetric cipher). There are 2 good reasons not to even think to write them:

Loads of techniques are patented. You may receive a take-down notice very quickly.
With power analysis, you must have physical access to the device and in most cases you also need to be able to run arbitrary code on the device. For smartphone apps, it is much easier for the attacker to lift the key via traditional means (e.g. jailbraking).

Simply put, don't use important AES keys in an Android phone (or iPhone) if your attackers have physical access to it. Note that in the video the first attack was mounted on a weak implementation of ECC, not on AES.

You may prefer to address more likely side channel attacks where the attacker operates from remote, like timing attacks, cache attacks, or padding oracle attacks.

Effective countermeasures can be done at the protocol level, independently of the AES library. Otherwise, you could consider using the Android NDK and the NaCl library.


What header & footer to use when storing RFC3161 token in PEM format

Pick whatever you want.
The label only serves humans to be able to identify what the data is, without having to decode it and parse the DER data. As such, labels like -----BEGIN TIME STAMP RESPONSE----- would work perfectly fine.


Would it be possible to have a javascript observatory, stricter sandboxing and stricter CSP (Content Security Policy) for Tor?

The SSL Observatory works by sending the SSL certificate to a 3rd party to confirm that it is valid. Doing the same for Javascript has two problems.

The first priorities of TOR is anonymity and privacy. If the TOR browser would send all Javascript to a 3rd party to validate it, that 3rd party would be able to create a detaile usage profile. Sure, there might be ways to work around this problem, but if anything it will increase the attack surface to deanonymize users.
You can not automatically scan Javascript for maliciousness. There are just too many ways to hide bad behavior. If that would be so easy, there would be browser plugins to do so (in fact there are, but their detect rates are abysmal). All you could do is maintain a whitelist of known harmless Javascript code. But that would require a team of security specialists to check each script manually. It might be worth the effort for some very frequented mainstream websites. But these are usually not the kind of websites the average TOR user is interested in.

Stricter sandboxing to prevent Javascript from doing things its not supposed to do is of course always a priority. None of those things you mentioned should be possible according the the Javascript specifications, so if any of that is possible, it's a bug which should be fixed in Firefox mainline and not just in TOR browser.


How to mitigate Meltdown in Docker images?

The patch against Meltdown is kernel only. Docker containers run within the kernel of the host system. This means the resistance against Meltdown depends on the host kernel only. In other words: you don't need patches against Meltdown in the docker image and you cannot patch against Meltdown in the docker image.


Is it possible to Decrypt two different encrypted text to the same identical text value?

Yes, you can decrypt both to "Hello".

However, you must always set the IV with a random value that you will use only once. You should also use a high level library, not the encryption primitives directly, or else you are most certainly bound to make mistakes that will break the security properties of the encryption.


X.509 certificate attack (small sha1 private key)

The fact that SHA1 was used is trivial; if you have the private key used to encrypt the hash digest, you can make any changes you like, recompute the digest and push it out. You don't necessarily have to break SHA1 if what you're after is the RSA private key.

By "small", how small are we talking? The largest RSA modulus ever factored (thus indicating that that key bitsize can be feasibly cracked) was 768 bits in length (232 decimal digits long), and it used the General Number Field Sieve method that is the current gold standard for RSA cracking. Most certificates have been using 1024-bit keys or better for years now (what's 1KB between friends, especially with broadband Internet?), with the current minimum being 2048 bits (considered impossible with current knowledge of the pace of technology, but possibly vulnerable to a new type of hardware or uncovered vulnerability) and 4096 bits being the gold standard (considered impossible even if a future vulnerability or quantum leap in hardware reduced cracking time complexity by half).

Also, do you know what padding was used? Vanilla RSA, without any padding scheme, is vulnerable to certain mathematical attacks, which is why nobody's used vanilla RSA for a while now; most RSA encryption is performed either with PKCS or with OAEP padding schemes which reversibly obfuscate the plaintext before encryption (making various types of known- or chosen-plaintext attacks much more difficult).

Lastly, if the CA was using such a small key size, the CA certificate that signed the one you have may well be expired (meaning cracking it is a moot point; anything you generate won't be accepted because one or more certificates in the trust chain have expired).


Use linux firewall rules for windows too

What you are looking for is probably a tool like Firewall Builder
that lets you design your rules once, then deploy to different platforms.

Note that the project on Sourceforge does not seem to be active/maintained anymore:

  After working on Firewall Builder for many years it is with some
  sadness that Vadim and I are announcing that we have suspended all
  development activity for this project. Firewall Builder has been a
  great project to work on and we have truly appreciated all the support
  and positive feedback that the user community has provided. Without
  you we wouldn’t have been able to keep things going this long.

Source

But there seems to be a fork on Github: https://github.com/fwbuilder/fwbuilder.
I used FB a bit in the past but I have not evaluated recent versions.

Some people have mentioned Ferm or Capirca as possible alternatives. I can't advise on those packages.


The "stealth operations" you speak of not only require the ransomware to be able to modify open files, but to be able to modify the data stream returned to the application (in order to hide until it springs the trap).
Either you are talking about a shared library injection into every running process owned by the current user (which can just use the existing open handle to the file to access it), or you are talking about a rootkit (which intercepts file access at the filesystem driver layer).
What might save you is if the malware hasn't performed privilege escalation and the current user doesn't have file-level access to the database, only a client/server architecture accessing it through system services running as a more/differently privileged user.  The mere fact of the file being open is no use at all.


How secure is the Windows event log, and how is it secured?

While ACLs are indeed the main way that the event log is secured, it does implement some other security features.

When the event log is cleared from the event viewer, a new event is added which contains the username of the user that cleared it.

Windows also keeps event log files open while the operating system is running, locking the files in such a way that they can only be written to by the event log process[1]. It is however possible for tools to inject malicious code into the event log process to circumvent this. One such tool is WinZapper, though you do need Administrator access, and I haven't played with this since Windows XP - so no idea if it still works on Windows 7.

It is sensible to ship your logs to a remote, hardened server. A number of free tools, such as Snare, support forwarding Windows logs to a syslog server. Most SIM/SIEM tools also support this either by using locally installed agents to push logs to the remote server, or by the remote server pulling logs from source systems over WMI (less scalable way). You can also use the Windows Event Collector.


Are HTTPonly cookies secure enough for implementing "remember me" functionality?

There are some problems with this scheme.

You should never store the actual password in the cookie. Store a temporary session token that is associated with the account (on the server) and then you can delete that token when the user logs out. If you're just storing the user's credentials, there's no way to end a session (on the server side) without ending all the sessions (by invalidating the creds).
Storing the password in the cookie means that anybody who gets access to the cookie (for example, another user on the same computer) will always be able to log in as the "remembered" user by looking at those credentials, memorizing them, and taking them to another computer. Session tokens should be long and random, and ideally short-lived.
HttpOnly does NOT provide protection against XSS. It's not even close. All it does is prevent script from reading the cookie. Somebody can still take over the session of the logged-in user's browser, and take any action the user could take, and send the attacker everything that the user can see. In fact, there's an entire exploit framework that explicitly does this, essentially letting the attacker remote-control the victim's browser session. You still need careful XSS protections.
HttpOnly won't protect at all if there's any page that reflects the cookie's values back from the server. An XSS could just read the server's response. In fairness, you didn't say there was any such page, but I just wanted to highlight how threadbare the "protection" of HttpOnly really is. Anything that you think "this wouldn't be secure, except for HttpOnly" is almost certainly not secure even with it.


Do software systems become more secure every year?

Biggest vulnerability in any computer system is the human user, and human users don't get better at security over the years. In fact, since computer systems' prevalence increases (even my mother now uses a computer occasionally -- hello, Mom !), there are more human users than ever before, which I choose to read as: there are more targets. In that sense, overall security decreases (steadily).

However, we can say that attackers have professionalized. In the 1980s and early 1990s, attackers were mostly bored youngsters, amateurish and exuberant. They were hacking for fun, not profit. There were some pro attackers, usually on the payroll of various governments (they say that Bulgarians were uncannily good at this), but not a lot of them. This famous movie captures the ambiance of that era quite well.

Nowadays, everything has changed. Attackers are organized, efficient, and petty; they act for money; most no longer worry to justify their lifestyle with elaborate notions of ethical liberalism. There used to be a lot of quite crazy intellectual constructions about how hacking into computers was a tribute to Marx, Darwin or Salvador Dali, or even all at once; this was quite entertaining; but these days are gone. Now, most attackers are just after a quick gain, they hijack machines just to send spam, and this is boring. A few groups try to maintain a politically aware outlook (e.g. when so-called "Anonymous" try to grab attention) but it often is a disguise prudishly thrown over less glamorous actions.

So, no, systems are not "more secure". But the heroic, flamboyant era of intrepid adventurers is done. Now InfoSec is just a business.


Mystery text message connected to a Chinese news site?

More than likely, the domain 21cn.com has been compromised and is being used to send spam. Bear in mind that spam does not always have to have a message body and can many times be sent from an unsuspecting victim accounts that were not secured properly or suffered a breach of any kind.

In regards to the date changing, that may be because of a new message being sent. Apple has odd quirks when sending 'iMessages'. For instance, I can open up iMessenger on my macbook and send a 'blank' text from my account to anyone (by simply pressing return).

Alternatively, this could be the result of some sophisticated virus (or perhaps a simple bug with IOS). I find the virus assumption unlikely, but it is still theoretically possible.

I would just delete it and perhaps block that contact (pubdma@21cn.com) and perhaps report the spam


Visitors logs show \x80w\x01\x03\x01 the HNAP1

The following is part of SSL's initial handshake. If this was a legitimate request, it is likely they were trying to connect with HTTPS to an HTTP server.

\x80w\x01\x03\x01

The HNAP is Home Network Administration Protocol, as outlined in Terry Chia's answer.

Unless you have reason to believe this person has gained unauthorized access, these things are quite normal to see in logfiles. There are thousands of systems throwing bogus requests at the wall and seeing what sticks. I am not telling you to not worry, but that it is common and not a sole indicator of an intrusion.