If a service that I registered with FB/Twitter/G+ is hacked, what mischief can be done with the oauth token?

1 . If the hackers have this token, what can they be able to do with it?

That depends on the individual "social network", but such tokens are mostly configured to expire/invalidate after a certain period of time. Also, the networks you mentioned all have multiple security implementations running to limit such attack vectors by — among other things — linking the token to the IP. Ask yourself how unlikely it is that an attacker will be able to fetch multiple characteristics simultaneously…  I can't say it'll not happen, as Murphy's law would most certainly prove me wrong. ;)

  2 . Assuming that the hackers have gotten a hold of my database, what can I as a developer do, to minimise the effect of the leak? What are the good practices for such login?

Follow the procedures you would follow in relation to every information security incident — apply the 6 Phases of Incident Management:

Preparation
Identification
Containment
Eradication
Recovery
Training

To dive deeper into "incident management", you might want to start out by checking the following infos:

SANS: An Incident Handling Process for Small and Medium
Businesses (PDF)
SANS: FORENSICS PLAN GUIDE (PDF)


Usefulness of token sidejacking prevention mentioned by OWASP JWT Cheat Sheet

if an attacker is able to steal the JWT by performing a XSS attack and access the sessionStorage, the attacker can also send XHR-requests, so the Cookie is automatically send with it

The solution uses SameSite cookies. They won't be sent to the attacker's server.


1.) A router needs to maintain an ARP table.

Every device that wants to transmit to another directly connected device based on the network layer address needs to translate it into the link layer address. A router would either have to route the packet to another router (in this case it needs to look up the link layer address of the other router) or to a device in a network directly connected to itself (in this case it has to look up the link layer address of the device). Since the router receives a packet with a network layer address of a device in a network directly connected to it, it would look up the link layer address in the ARP table and forward the packet accordingly (in your scenarios either directly or via the switch).

2.) A switch may maintain an ARP table.

This depends on whether the switch operates on the link layer or on the network layer. If it operates solely on the link layer it only knows about link layer addresses. It would just remember which link layer address is connected to which of its ports and forward the packets accordingly.

3.) Routing of packets arriving from the Internet via a router-switch combo

Packets arriving from the Internet via your router-switch combo would first arrive at the router, which would know that the packet is destined for a device connected to your switch (or more precisely for a device located somewhere in the network segment connected to the port of the router to which your switch is connected). It knows this since the network layer address of the destination is listed in its ARP table. When the packet arrives at the switch, it would know on which of its ports the device for which the packet is destined is connected. It does so by looking up to which port the device with the link layer address of the destination is connected.

4.) ARP spoofing

Finally, ARP spoofing is done by impersonating someone by making others believe that the network address of your target should be mapped to your link layer address instead of the targets link layer address, i.e. manipulating the ARP tables of other devices. In both of your scenarios ARP spoofing on the local network is possible. This is due to the fact that one can manipulate the ARP tables on the devices connected to the switch / router. The switch / router would then received the packets already with the wrong link layer address set and only forward them to you instead of the intended destination.


Is there a risk of a bootstrap problem when using NTS?

The thing about TLS 1.3 is that both parties do not need to be within a single timeframe to be performing the handshake, or share time-related information at the start. TLS 1.1 & TLS 1.2 however, had a time element in its Client Hello message

TLS 1.1 & TLS 1.2 Client Hello Message,

Structure of this message:

      The client hello message includes a random structure, which is
      used later in the protocol.

      struct {
         uint32 gmt_unix_time;
         opaque random_bytes[28];
      } Random;

Under the gmt_unix_time variable as seen above, here are the documentation for TLS 1.1 Client Hello Message & TLS 1.2 Client Hello Message

  The current time and date in standard UNIX 32-bit
        format (seconds since the midnight starting Jan 1, 1970, GMT,
        ignoring leap seconds) according to the sender's internal clock.
        Clocks are not required to be set correctly by the basic TLS
        Protocol; higher-level or application protocols may define
        additional requirements.

With the above paragraph supports the fact that even with the time involved, it is merely used in a way to randomized the message.

TLS 1.3 Client Hello Message, here is the documentation for TLS 1.3 Client Hello Message

Structure of this message:

      uint16 ProtocolVersion;
      opaque Random[32];

      uint8 CipherSuite[2];    /* Cryptographic suite selector */

      struct {
          ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
          Random random;
          opaque legacy_session_id<0..32>;
          CipherSuite cipher_suites<2..2^16-2>;
          opaque legacy_compression_methods<1..2^8-1>;
          Extension extensions<8..2^16-1>;
      } ClientHello;

The variable gmt_unix_time has been removed in TLS 1.3

Despite NTS using TLS 1.2 and TLS 1.3, initial time would not be an issue!


You can't protect  against your host, be it the OS, the processor or the BIOS.
Also see the Laws #1 and #2 of Security.

This doesn't mean though, that there's no way to defend yourself against at least some software attacks. Please note though: If you really want to protect the key, you have to use hardware-enforced technologies like HSMs, TPMs, smart cards and SGX. The first two methods I'll outline are basic and are done by every somewhat decent cryptographic library, the latter ones are more exotic.
Defense #1: Always clean up behind yourself!
It is generally considered best practice to always clean up whatever mess you create in programs. This also applies to security engineering and thereby you really should reliably zero out every key when you don't need it anylonger. Note that a simple C-style memset(pointer,0,size); won't do the trick because the compiler most certainly will optimize this away, you should use dedicated functions for burning your keys in memory (Windows offers them and you can write them yourself - in assembler or as a simple loop).
Defense #2: Never stop watching your keys!
Modern operating systems commonly ship with a feature called "swap-memory", which is great for the application developers as this can increase the size of the RAM when needed by swapping out pages to the hard drive. This however is really bad for security, because wiping the keys after they have been swapped out tends to be rather difficult and thereby you should tell your OS through an appropriate function call to always keep your keys in (physical and ephemeral) RAM.

The following defenses are more advanced and it is less likely they are deployed anywhere. They are however listed in Schneier's Cryptography Engineering and can defend you in some circumstances. Let the tinfoil hattery begin!
Defense #3: Encrypt all the things!
You may have heard about "cold-boot attacks". Basically they are the (unlikely) scenario, that an attacker can get hands on your machine, cool it down (more or less) and extract the secret cryptographic keys for several seconds or even hours. It is very hard to defend against such attacks (which also include (automatic) memory dumps). This is why the Boojum (this is the actual name!) was invented.
Say, you have secret keys k,l,m,n, each of length 128-bit. Now you create another secret key i, which you use to AES-encrypt k,l,m,n in CTR or GCM mode (authentication doesn't matter too much here). Now whenever you need k,l,m,n, you just AES-decrypt it and use it and re-encrypt it or wipe the temporary copy. The question now becomes "How to protect i?" With the Boojum, you create a random string R in RAM at a physically distant memory location than i. You hash R and XOR it with i and store that. Whenever you need i, you hash R again and XOR it with the stored value to recover it. Of course this isn't too secure if you keep R the same all the time, because the RAM will eventually "learn" the value and keep it longer, so you need to update this often. You update it, by (optionally) selecting  a new memory location and generating a new R' and storing R' XOR R at the (new) location in memory. Now you unmask i using R's hash and hash the "new" R and mask i again. Of course you delete the old R. It is recommended to repeat this update process frequently, e.g. every second.


Why don't security conscious websites use a combination of private unique identifier and password to secure their logins?

I am unaware as to a name for this model, but would say that the main reason for lack of uptake is its unwieldly nature if the user is not already employing a password manager.
In this setup the Private Unique Identifier (PUI) appears to be acting as a second password, one that is specified to be secure in the event of database breach. Assuming the PUI is of recommended length for a strong password (using Protonmail's of 15 characters as an example) this will be nigh impossible for end users to remember for multiple sites. As such they would have to use a Password Manager to effectively use this system, but in the event they do this they can already use passwords of sufficient length and randomness.
In addition the PUI is not a 'full' implementation of MFA as the PUI is not a different type of proof (such as something you are like biometrics or have like Authy app). Consequently I do not think the added security is as great as encouraging users to use 2FA.
The other, more mundane reason is that this change would involve changing many tables or files (if using NoSQL) in your DB! As to implement this you may have to change the Primary Keys of tables it could be a very hard security addition to add to an existing site.
As for attacks, as (assuming I understand the concept like you) the PUI acts as a second password, it would be suspectible to the same attacks. If it is also created with your initials or another deterministic prefix this might make it easier to break.


Linking mail server with application database

There's also a 3rd option to consider: an authentication framework.
Instead of having separate user credentials for the database and mail server that need to be kept in sync, have a central authentication service that the database and mail servers defer to when a user attempts to authenticate.  There's quite a few options to choose from, but you'll probably want to start with things your applications currently support.  From what I can gather, both MongoDB and postfix support LDAP and SASL, so those would be two options to look into.

As for security issues to the methods you suggested: even if you got secure password transmission figured out, you still have to deal with synchronization.  If an error occurs at an inopportune time (e.g. a user changing their password while postfix is unavailable), you'll end up with mismatched credentials on each service.  It could be fixed, yes, but comparing the credentials on the two servers would involve transmitting at least some sensitive data.  In a more nefarious situation, consider what would happen if credentials de-synchronized when a user was banned.  They could end up retaining partial access to resources that they should have no access to at all.


SMMP is used to manage low-end devices, they usually have only rudimentary networm stacks. No firewall, for one.


cvedetails.com provides CVE feeds which can be filtered by product. Just access them from the product page.

PHP feed
Apache feed


Large number of spurious retransmission - is my server under attack

To be clear, a packet capture won't tell you anything about a malicious payload. I suppose if you work with malware enough, you can see a pattern for particular malware byte code, but probably not.

Network analysis should be done based on a baseline. That's when red flags are apparent. If you've never done a base line before, it's hard to tell what is normal and what is worth investigating.

Spurious Re-transmission

This blog gives a good rundown, and since I don't need to re-write the definition, from the blog:

  Basically “Spurious Retransmission” means that data was sent again
  that the receiver had already acknowledged, which is something that we
  used to call “needless retransmission” in our own expert system.

At this point, this question is not really for Information Security. It's damn near impossible for anyone here to give you security answer about a system they cannot directly analyze.

That being said, I would suggest you up date you question to trying figure out what's causing the Spurious Re-transmission, rather than thinking it's something else.

Here's a reference link to ask wireshark which may be of use. I'd move this to the networking or wireshark community.


How do I verify, parse and process the results of the HTML5 keygen tag?

The keygen docs at Mozilla, and the keygen docs at w3 don't specify a return format after the POST. What should I return?

The reason this information is not listed is because the KeyGen element sends an SPKAC to the server and once a CSR (Certificate Signing Request) is generated and sent to a reputable CA (Certificate Authority) an x.509 signed client certificate is to be sent back to the client that created the private key.

A typical procedural event for handling SPKAC's from the KeyGen element would be as follows:

User specifies a unique 'challenge' which gets encoded within the KeyGen generated SPKAC (signed public key & challenge ASN.1 value).
The KeyGen element generates a Private key which is then stored within the browser certificate store.
A public key is then derived from the private key.
The derived public key & the user submitted challenge is then encoded as an ASN.1 SPKAC formatted string (see the 'certificate request format' below).
A CSR is then created (see below) and sent to a reputable certificate authority.
The CA generates an x.509 certificate which can the be used for pass-wordless authentication (as long as the web server is configured to do so)

Essentially setting the 'Content-Type' header to 'application/x-x509-user-cert' will force the browser to load it into it's certificate store.

  After keygen is run, (see links at the bottom of this page) I don't see a certificate in my local store. Where is it?

KeyGen does not generate a certificate. It generates a private key. The public key is derived from the private key (which is not accessible from the browsers certificate store, nor through the JS engine API) then encoded as an SPKAC.

The SPKAC is to be used within a CSR (Certificate Signing Request) and an example of which would look like the example below, the more traditional CSR can be shown here, and see here for references:

SPKAC=MIIBXjCByDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3L0IfUijj7+A8CPC8
EmhcdNoe5fUAog7OrBdhn7EkxFButUp40P7+LiYiygYG1TmoI/a5EgsLU3s9twEz3
hmgY9mYIqb/rb+SF8qlD/K6KVyUORC7Wlz1Df4L8O3DuRGzx6/+3jIW6cPBpfgH1s
VuYS1vDBsP/gMMIxwTsKJ4P0CAwEAARYkYzBkZjFlYjctMTU0NC00MWVkLWFmN2Et
ZDRkYjBkNDc5ZjZmMA0GCSqGSIb3DQEBBAUAA4GBALEiapUjaIPs5uEdvCP0gFK2q
ofo+4GpeK1A43mu28lirYPAvCWsmYvKIZIT9TxvzmQIxAfxobf70aSNlSm6MJJKmv
urAK+Bpn6ZUKQZ6A1m927LvctVSYJuUi+WVmr0fGE/OfdQ+BqSm/eQ3jnm3fBPVx1
uwLPgjC5g4EvGMh8M
CN=Joe Snuffy
OU=Snake Oil, LLC
O=Department of pricing
L=City name
ST=State or province
C=United States
E=joe.snuffy@snakeoil.com

  My understanding is that Keygen is used to create a Browser Certificate. What logical steps do I need to complete in order to finish this process?

The entire process for using a keygen element for a practical client certificate authentication within web applications is as follows:

Within an administrative panel of a web application (using an existing account) the user has the option to create a client certificate (x.509) to use for authentication. This loads the SPKAC KeyGen element along with a form providing the following attributes (everything in the parenthesis corresponds to the above CSR example):

organizationalUnitName (OU)
organizationName (O)
localityName (L)
stateOrProvinceName (ST)
countryName (C)
emailAddress (E)
commonName (CN)

Once the form is provided to the server a CSR is generated. This is to then be provided to a CA (Certificate Authority) for signing.
Once signed the client is notified to log back into the web application at which time the x.509 header 'content-type' can then be used to force the certificate into the browser's certificate store.
As long as the web server is configured to do so, it can force the client to send any x.509 certificates for client certificate authentication. The apache web server documentation provides this information.

Some additional notes regarding the SPKAC; the challenge string provided should be unique to each users client certificate. An example of setting this based on user input would be the following snippit:

<script>
/* Gather up our form & its elements */
var form = document.getElementById("myForm")
  , challenge = document.getElementById("challenge")
  , spkac = document.getElementById("spkac");

/* Add an event handler to move the value from the 'challenge' input
   to the keygen element challenge attribute */
form.addEventListener("blur", setSpki, true);

/* Our function which sets the challenge */
function setSpki(){
  spkac.setAttribute('challenge', challenge.value());
}
</script>

This is essential because once the signed client certificate is in the browser store anyone using that browser potentially has access to their account.

The challenge provided during the initial SPKAC should be used as a secondary form of proof of ownership for the private key corresponding to the private key used for the SPKAC.

As an example; the user logs out, closes the browser destroying the authenticated session. A malicious user sits down at the same terminal and attempts use the x.509 to provide authentication and is then prompted for the challenge.


Mobile Device Management (MDM) Software is enterprise software that covers the management of applications and device security. MDM software varies in capabilities depending on the operating system (Android, iOS, Windows) you are supporting.

Some commercial MDM solutions will include the ability to manage multiple operating systems while others are tailored to specific operating systems.

Some commercial MDM solutions include:

AirWatch
Good
MobileIron

Operating Systems offer different levels of control, but most MDM software will allow you to:

Preinstall and restrict uninstallation of enterprise applications
Enforce password policies
Deploy client SSL/TLS Certificates
Deploy WPA2-EPA Certificates
Physically locate or remote wipe devices


Export non-extractable private key from Keychain on OS X

I was able to extract non-extractable private key from macOS High Sierra 10.13.6 using this tool chainbreaker. It requires Python2 with hexdump and pycrypto packages. This README file in the tool's repo explains how to do that README-keydump.txt.

In general:

sudo pip2 install hexdump pycrypto pyOpenSSL

git clone https://github.com/n0fate/chainbreaker

cd chainbreaker

python2 chainbreaker.py -f ~/Library/Keychains/login.keychain-db -p 'YOUR_KEYCHAIN_PASS'

# After the command has finished running, there will be a new folder
# exported with 3 more folders for certs, keys and key-cert pairs
ls exported/associated

# This will show you folders with found key-certificate pairs as numbered
# subfolders and separate files there. Those files are in DER format, so,
# for example, to convert those to PEM:
openssl x509 -inform DER -in exported/associated/1/3.crt -out exported/associated/1/cert.pem
openssl rsa -inform DER -in exported/associated/1/5.key -out exported/associated/1/key.pem


That should never happen.
Without any code samples which I can look it, one reason I can envision that happening is an authentication workflow as shown below:

In the following diagram, /login POSTs to /member, where the authentication check takes place.

If authentication passes, the pages continues to send the 'logged in user' content. This makes this page (/member) appear into browsers history. Anytime you click back/forward button on your browser to come to this page, it will ask you if you want to POST the form content on this page. In this case, the date is login credentials.

  WRONG WAY:

  +---------------------------+          +------------------------------+
  |   Login Page (/login)     |          |   Member Page(/member)       |
  |---------------------------|          |------------------------------|
  |          +--------------+ |          | if creds wrong               |
  | UserName |              | |          |   redirect_to /login         |
  |          +--------------+ |+-------->| else                         |
  |          +--------------+ |          |   "Welcome Back,             |
  | Password |              | |          |    Here is your super secret |
  |          +--------------+ |          |    member area where you can |
  |                           |          |    check out the cool stuff" |
  +---------------------------+          | end                          |
                                         +------------------------------+

Instead you should have this kind of authentication flow:

Login page posts to a /verify (or /auth whatever you call it) page.
The verification page does not have any http output. Based on whether the creds are good or bad it just redirects to the appropriate page. If login is good, it sets a cookie flag indicating a valid session.
Member page validates the session by checking the cookie value and redirects to /login page if session is expired/not-set.

In this workflow, /verify page never appears in the browser history and there is no way user can 'click refresh' on that page to trigger POST data getting sent again.

   CORRECT WAY                POST        +-----------------------------+
                            +------------>| Verify page (/verify)       |
                            |             |-----------------------------|
  +-------------------------+-+           | if creds wrong              |
  |   Login Page (/login)     |<---+---------+redirect_to /login        |
  |---------------------------|    |      | else                        |
  |          +--------------+ |    |      |   set_session_cookie        |
  | UserName |              | |    | +-------+redirect_to /member       |
  |          +--------------+ |    | |    | end                         |
  |          +--------------+ |    | |    |                             |
  | Password |              | |    | |    +-----------------------------+
  |          +--------------+ |    | |
  |                           |    | |      +------------------------------+
  +---------------------------+    | +----->|   Member Page(/member)       |
                                   |        |------------------------------|
                                   |        | if session_cookie not set    |
                                   +-----------+redirect_to /login         |
                                            | else                         |
                                            |   "Welcome Back,             |
                                            |    Here is your super secret |
                                            |    member area where you can |
                                            |    check out the cool stuff" |
                                            | end                          |
                                            +------------------------------+

This is the common Post/Redirect/Get model. You can check this wiki page for prettier pictures: http://en.wikipedia.org/wiki/Post/Redirect/Get

Also, if you want to prevent the browser to cache certain HTML pages, you can set the cache-control HTTP header to 'no-cache' for those pages.

  Cache-Control: no-cache


How to store user credentials in browser securely?

Anything stored client side (and not encrypted) can be seen and/or modified by the user.

The usual way of implementing a "Remember Me" functionality is to set a cookie with an encrypted username, sent from the server.

The server will encrypt the username with a secret key, known only to the server, and set a cookie with that value.  When the server later receives that cookie, it can try to decrypt it, and if successful, log the user in.  This cannot be tampered with by the user, as they do not know the secret key.


Is Tomcat session ID generation FIPS compliant?

There is a FIPSMode configuration option in Tomcat's APR Lifecycle Listener, which looks like it would fulfill your requirements. As observed in this very similar StackOverflow thread, and Tomcat/APR Lifecycle Listener documentation, it's really about the operating mode of OpenSSL, not Tomcat.

On a not-unrelated note, Tomcat isn't FIPS-certified, due to the cost, time and red-tape involved in FIPS-certification, however, there are some commercial offerings that have tested Tomcat with FIPS-compliant JSSE providers, which may be sufficient for your purposes.  Additionally, Oracle and IBM both provide documentation on enabling FIPS mode/compliance with the JSSEs they provide, so it may not be necessary to use a 3rd-party offering, again, depending on your requirements.

On the specific question on Tomcat's Session ID generator, since it's open-source, we can check, and it appears that Tomcat's SessionID Generator uses Java's SecureRandom library, which "[...] complies with the statistical random number generator tests specified in FIPS 140-2, Security Requirements for Cryptographic Modules, section 4.9.1."

public class SessionIdGenerator {

/**
 * Generate and return a new session identifier.
 */
public String generateSessionId() {
byte random[] = new byte[16];
// Render the result as a String of hexadecimal digits
StringBuilder buffer = new StringBuilder();
int resultLenBytes = 0;

while (resultLenBytes < sessionIdLength) {
getRandomBytes(random);
for (int j = 0; j < random.length && resultLenBytes < sessionIdLength; j++) {
byte b1 = (byte) ((random[j] & 0xf0) >> 4);
byte b2 = (byte) (random[j] & 0x0f);

if (b1 < 10) buffer.append((char) ('0' + b1));
else buffer.append((char) ('A' + (b1 - 10)));

if (b2 < 10) buffer.append((char) ('0' + b2));
else buffer.append((char) ('A' + (b2 - 10)));

resultLenBytes++;
 }
 }

if (jvmRoute != null && jvmRoute.length() > 0) {
 buffer.append('.').append(jvmRoute);
 }

return buffer.toString();
 }

/**
 *
 */
 private void getRandomBytes(byte bytes[]) {
SecureRandom random = randoms.poll();
 if (random == null) {
 random = createSecureRandom();
 }
 random.nextBytes(bytes);
 randoms.add(random);
 }

 /**
 * Create a new random number generator instance we should use for
 * generating session identifiers.
 */
 private SecureRandom createSecureRandom() {

SecureRandom result = null;

long t1 = System.currentTimeMillis();
 if (secureRandomClass != null) {
 try {
 // Construct and seed a new random number generator
 Class<?> clazz = Class.forName(secureRandomClass);
 result = (SecureRandom) clazz.newInstance();
 } catch (Exception e) {
 log.error(sm.getString("sessionIdGenerator.random",
 secureRandomClass), e);
 }
 }

if (result == null) {
 // No secureRandomClass or creation failed. Use SecureRandom.
 try {
 if (secureRandomProvider != null &&
 secureRandomProvider.length() > 0) {
 result = SecureRandom.getInstance(secureRandomAlgorithm,
 secureRandomProvider);
 } else if (secureRandomAlgorithm != null &&
 secureRandomAlgorithm.length() > 0) {
 result = SecureRandom.getInstance(secureRandomAlgorithm);
 }
 } catch (NoSuchAlgorithmException e) {
 log.error(sm.getString("sessionIdGenerator.randomAlgorithm",
 secureRandomAlgorithm), e);
 } catch (NoSuchProviderException e) {
 log.error(sm.getString("sessionIdGenerator.randomProvider",
 secureRandomProvider), e);
 }
 }

if (result == null) {
 // Invalid provider / algorithm
 try {
 result = SecureRandom.getInstance("SHA1PRNG");
 } catch (NoSuchAlgorithmException e) {
 log.error(sm.getString("sessionIdGenerator.randomAlgorithm",
 secureRandomAlgorithm), e);
 }
 }

if (result == null) {
 // Nothing works - use platform default
 result = new SecureRandom();
 }

// Force seeding to take place
 result.nextInt();

long t2 = System.currentTimeMillis();
 if ((t2 - t1) > 100)
 log.info(sm.getString("sessionIdGenerator.createRandom",
 result.getAlgorithm(), Long.valueOf(t2 - t1)));
 return result;
 }

}


Detecting Hardware keyloggers... elegant solutions?

Anyone with physical access to the ports on the computer can do a lot of damage. The elegant solution is to physically secure access to those ports. Endpoint solutions can usually detect software keyloggers, but hardware keyloggers are tough.

  would it be possible to continue monitoring the keyboards when the
  computer is turned off?

When you turn off a computer, you cannot monitor its activity.


How safe is it to use older/unknown Encryption methods for plaintext?

Your method cannot be completely unknown, since both sender and receiver know it. Moreover, they run it; so either it is simple enough that they use it in their heads, or it exists as some piece of additional software, in which case the method is also known to their hard disks, the method designer and implementer, and github.

In fact, unknown methods do not exist.

Old encryption methods, however, do exist, but they are cumbersome to use and invariably inefficient. Enigma had no character for space... In his time, Edgar Allan Poe had made a specialty of breaking substitution ciphers, and boasted that none could resist the onslaught of his magnificent brain (to my knowledge, he was not proven wrong in this time).

Actually there is one old method that would ensure security: the good old One-Time Pad. But using it properly requires having, indeed, random pads at hand. Both sender and receiver would have to keep a booklet of random pad on them, and dutifully cross out the used elements. If you hold the book in your left hand and the pencil in the right hand, you will need to strap your smartphone on your knee and enter the message with your nose. Physical comedy notwithstanding, I fail to see how this could qualify as usable.


Is there an internal equivalent to fail2ban?

You can use fail2ban for this also. It is very configurable. In this case, you would need to write a new filter to watch your auth logs. You can use the <HOST> shortcut to match usernames, too, since those ought to conform to "hostname" parameters. You would also need to write a new action to perform the kick. The fail2ban manual has lots of good information to get you started.

As another example of extending fail2ban, I set up a filter to watch fail2ban's own logs. If any 1 host triggers any combination of bans more than 4 times in a month, they get a month-long ban.


SSL Handshake takes much longer in LAN than in WAN

Usual suspects for overlong SSL handshake are rebuilding of certificate chains and CRL checks. A SSL client will validate the certificate from the server, which may entail obtaining the issuing CA certificate and/or downloading a CRL which covers the said certificate; both operations follow URL found in the certificates themselves. When a certificate has a local-only URL in it (e.g. an ldap:// URL which makes sense only in a given site), the relevant machine may need some time before noticing that the URL cannot be used, and, in particular, it may stall on a DNS lookup.

I suggest you run a network monitor tool (e.g. Microsoft Network Monitor) on both client and server, to see what happens during one of the overlong handshakes. This tool will be able to show you the individual handshake messages, but also other network activity -- DNS queries which fail after two or three seconds would appear there. (Knowing how a SSL handshake works can help; see this answer for a primer.)


How to make access to a remote program without that the user has the possibility to run any Linux command?

You can do this using the ForceCommand option in sshd_config:

ForceCommand
Forces the execution of the command specified by ForceCommand,
ignoring any command supplied by the client and ~/.ssh/rc if present.
The command is invoked by using the user's login shell with the -c
option. This applies to shell, command, or subsystem execution. It is
most useful inside a Match block.

You can specify a Match block that is specific to the user or group you're trying to control.


Is using a self signed certificate safer than a free ssl certificate?

SSL certificates provide two things:

Authentication of the organization to whom the visitor is connecting (the organization is verified to be www.foobar.com)
Confidentiality of the communication (data is encrypted using the public keys in the certificate)

Concerning point 2, there's no difference in using a self-signed cert, a certificate issued from a free CA such as CACert, or a paying CA, since the strength of the encryption depends on the characteristics of the key pair you generated (a default 2048-bit or 4096-bit RSA is fine).

Therefore what it interests us is point 1, since it's the CA who verifies and certifies the identity of the remote website. It all boils down on how the CA verifies these websites. In this regard, using an external free CA untrusted by browsers doesn't make much difference from using a self-signed cert. Therefore I would go for a self-signed cert in this case, as you can generate it yourself without hassle (just make sure you're doing this properly!).

You can safely use a self-signed cert if your website is for internal use, say your friends, or a group of people. (From what I understood from your question, this is your case.) However, if your website is public-facing and you want to do things in a proper and professional way, you should buy a SSL cert from a recognized CA.


The kernel normally gets its first 'base' time from the RTC or Real Time Clock
so while it won't be as accurate yet as after the NTP protocol has updated the time. it is sufficient to validate a signature of a certificate.
you can set this value normally in the BIOS before ever booting an OS.


No, there are many different requirements for handling information at various levels of classification.   What is more, these requirements are going to vary by country, but they include not only the encryption used, but they often need to live in different systems on different networks.  Software and hardware products may also be certified for use with information up to a certain level of classification and not beyond.  The physical security requirements for an environment increase as the level of classification increases.  The screening requirements for personnel who have access increase with the level of classification.  These are only a few high-level examples of the differences.


How does a firewall software intercept network communication?

It is not the packet filter which gets the kernel to listen to it, it is the kernel which entrust network data to the packet filter.

The packet filter and the kernel must be compatible, technically speaking the kernel must offer specifics hooks used by the packet filter to do its job.

On Linux for instance, behind iptable front-end you will find that the Linux kernel offers hooks allowing the Netfilter framework to register callback functions:

If the firewall is not enabled, there will be no callback registered so the kernel will handle everything by default,
If firewall is enabled, Netfilter will have registered its callback functions so the kernel will be able to call them when appropriate.


Are NTP servers without monlist still dangerous?

I think that the monlist is used for amplify the attach basically, so no the case of amplification attacks I don't think is a problem, however, the NTP servers could still be used for DoS attacks but not with amplification capabilities.


Parties can never fully agree in a situation where a message may or may not be received by either party because there will always be a difference in state between the two parties.

This is also the "girlfriend's cellphone stopped working" conundrum. The best solution is to have an agreed-upon protocol that is followed so that you know the other party is probably doing one of a limited set of reasonable tasks which end in failsafe protocol. As a failsafe, one must make sure that updated failsafes don't create conditions where the previous failsafe doesn't result in a solution.

Also, you can't find an ideal solution because there is an impossibility proof saying that there is no ideal solution. See the bottom part of Two Generals' Problem Wikipedia Entry that you cited and its references. The rabbit hole goes on to include Byzantine fault tolerance and its related articles.


Why does SSL/TLS use message authentication code instead of digital signature?

Message Authentication Code (MAC) are based on symmetric cryptography. Digital Signature are based on asymmetric cryptography.
Using the existing algorithms, symmetric cryptography is by far computationally cheaper than asymmetric.

It means that you can create and verify a MAC for each packet on a network traffic with a reasonable increase of calculation, i.e. without slowing the traffic to much. With digital signature, the cost of signing and verifying each packet will surely create a bottleneck slowing drastically the traffic or needing a huge amount of computational power.


It has to be the FQDN of your mail server. This would be what your DNS MX records point to, e.g. mx.mydomain.com.

A mail client will find to which system it needs to send an email based on the mx record associated to the domain of an email address, e.g.

john@test.com: what's the MX record of test.com? mx.mailserver.com

Then and only then will TLS enter the picture. It will connect to mx.mailserver.com and validate it is really talking to mx.mailserver.com via a signed TLS certificate.


Its AES in CBC mode with PKCS#7 padding.

The IV in CBC is XOR'ed with the plaintext. This results in the following value in hexadecimals:

043e1e461f5d6563503050155d7f5b5d

and "Marvin: \"I am at" is:

4d617276696e3a20224920616d206174

so the IV will be the two values XOR'ed:

495f6c3076335f4372797074305f3a29


What kind of attacks do Javascript WebWorkers protect against?

It looks like WebWorkers are not a security feature, but simply a way to run background threads on the client side of the web application. This means they don't protect you from any existing attacks but they may instead introduce new attack vectors :(

Of interest in this regard might be the communication between the workers and the main thread: they are reusing the postMessage interface which was originally used to communicate between different frames. By using the same interface it also adds the same security issues. This means you should check for the origin of a received message in your message event handler. The example code you will find for web workers usually does not do this.


I still can use CDs I've burned down over 10 years ago. There are papers from thousands of years ago as well, so it's really a matter about how good are the conditions where the CD or the paper are stored.

Anyway, why limit yourself to just either of them? Use both.


Why can't search engines reach the dark web?

Assuming you are talking about Tor hidden services, then the answer is they can, but only indirectly. There are various "portal" sites which provide a gateway to hidden services. These gateways are normal websites with regular domains, but are running tor2web software, which uses the Tor client to relay traffic between non-Tor and Tor users (but note that they provide no anonymity). These can be indexed at will.

There are several reasons why Tor hidden services are not indexed frequently:

As someone else pointed out earlier, it's very disjointed. Very few sites link to each other, limiting crawlers' ability to find new sites and new pages. It's like the open internet from the 90s.
It uses its own protocol, so without portal/gateway sites, they would be unable to connect. Try connecting to a .onion domain in a normal browser. You'll see it won't even resolve.
There are not that many hidden services out there. The myth that it is "vast" is ill-founded, based on a misunderstanding of the terminology. In reality, it is really quite small.
Some sites are blocked by portal/gateway sites for legal reasons, so they can only be accessed using the Tor protocol. As search engine crawlers don't use this, they can't access the sites.

There is no single "database" of hidden services as there is for regular domains (root nameservers). A hidden service is based on an encoded, truncated hash of the server's public key. The client uses the service's domain name and looks up the hidden service's descriptor in a semi-public database, which contains its public key and a list of Introduction Points (relays chosen by the server). The client selects a random relay as a Rendezvous Point and sends that relay's ID to the hidden service over the Introduction Point. The server and client then meet through the Rendezvous Point over their own three-hop circuits.

Through a complex protocol, the client and server thus manage to form a connection without either of them needing to reveal their real IP. Because there is no IP address that the domain resolves to, a regular search engine can't reach it using standard HTTP with TCP/IP. In order for a search engine crawler to connect to these sites, it would have to use this protocol. That is not very practical for them.


That is because listening for a beacon and not getting it just might mean that the network has a private ("hidden") SSID. From this article (emphasis mine):

  The 802.11 standard allows APs to beacon with the SSID field set to
  null - this is referred to as a hidden SSID. A client that wishes to
  associate with an AP using a hidden SSID must first send out a Probe
  Request that contains the SSID of that network, which will then cause
  the AP to provide a Probe Response. For any client that does not
  provide the correct SSID, the AP does not respond.

I believe that probing can be deactivated in Linux; not sure about Windows, but given their history I'd wager that probing is on by default, and may perhaps be disabled through some obscure registry hack.


Short answer: No. The attacker needs the private key too.

The SSH protocol uses encryption to secure the transmission. So, it will employ a public and private key. It's possible to someone to send you a spoofed public key, but without the corresponding private key, they will not be able to decrypt the communication, the handshake will fail and your client will disconnect.

But if the attacker have both the public and private keys, they can intercept every communication between you and the server.


Some googling pointed me to this source code file which, when compiled, should generate MD4 collisions using Wang's method (published in 2005). This is not the fastest collision attack for MD4, but it is enough to produce thousands of them.

However, tools like John the Ripper are for finding passwords from their hash; collisions are no help at all for such a task. Finding a collision is about computing two distinct strings m and m' which, when both hashed, yield the same value. For collisions, we do not care which hash value we actually obtain, as long as we get the same for both messages. For cracking password, you work over a fixed hash value which you cannot choose (you found it in a database or a similar source), and you try to find a string p which hashes to that specific value (and none other): this is a preimage attack.

MD4 is also academically broken with regards to preimages; an attack was found by Leurent in 2008. Mind the "academically" term, though: the attack has cost 2102 evaluations of the hash function. This is millions of times faster than the robustness expected from a hash function with a 128-bit output (which should resist up to cost 2128); however, this attack is still way beyond that which is technologically doable right now (a very big organization with lots of computers and money, like Google, might dedicate its vast wealth to the problem and perform about one billionth of the work within a few years, but no more).

For cracking passwords which were hashed with MD4, the best known method is still a "dictionary attack", also known as "brute force": try potential passwords until a match is found. If the hashing process did not include a per-password random element (a "salt") then the brute force effort can be shared through the use of precomputed tables (e.g. rainbow tables) but the tables still have to be built at least once.


Is encrypting something more than once safer than hashing more than once?

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

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

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


Steps to recommend after people connect Android devices to questionable open WiFi access points

To properly expand your thesis, you should probably read the rest of the article you posted.  Under "Android and Google Service Mitigations" it explains the current posture of Google to deal with these threats.  While the best solution is naturally to patch the OS at the lowest level the bug exists, it is effective enough to patch the apps in userland that enable the vulnerability, in order to make it nontrivial to exploit.  This is why the apocalypse of "a billion unpatched devices" that many experts have been promising has never come to fruition, and the only users at risk are those that ignore numerous warnings and install unvetted apps from unreliable sources.

So, to answer your question: if you are asked, simply remind the user that they should be wary of strange prompts on their phone when connected to unknown networks (since all exploits in the wild start this way), always keep their apps up to date (follow prompts to do this while on a home network) and if strange behavior does start to happen don't enter any personal information like usernames/passwords until you have a chance to reboot the phone on a trusted network.

Rooting your device, unless it's a model specifically designed to allow it like some Google Nexus variants, is always a bad idea from a security perspective. You are purposefully removing a layer of security, with code that has almost certainly not been vetted by any reliable source, so after this happens ALL bets are off.


Check if there is a new firmware for you router. If there is, get latest version and test again (the manufacturer may have patched it already). If the vulnerability still exists or there is no version newer than yours, then yes, report it.

Usually, in the mid-to-low models, updates are more rare and vulnerabilities are patched only at large time intervals.


Is there any reason a password and pin combination isn't more popular?

Some banks actually do this. The issue is the same as with just generating a random password for the user and not allowing them to input one. They will inevitably write it down. Also, using a pin as username frustrates targeted attacks but for short pins and large sites, attackers can pick a random pin and chances are it will belong to some user. You would need to make it longer to be effective.

Finally, if the pin is ever leaked, it can be difficult to change, if it acts as the username.

At the end of the day, pin and password are the same type of authentication: using something the user knows. Therefore anything you can do with a pin, you can also do with a password, just append the two for a longer password. Using it as username unnecessarily complicates things.


Android devices are unable to connect to Rogue Acces point created using Airbase-ng

The answer is right in the logs:

Mar 03 12:32:49 kali dhcpd[3813]: ** Ignoring requests on wlan1.  If this is not what
Mar 03 12:32:49 kali dhcpd[3813]:    you want, please write a subnet declaration
Mar 03 12:32:49 kali dhcpd[3813]:    in your dhcpd.conf file for the network segment
Mar 03 12:32:49 kali dhcpd[3813]:    to which interface wlan1 is attached. **

Your wlan1 interface is on 192.168.1.0 network, and you are trying to start a DHCP server on 192.168.5.0. Change that and it will work.

You are learning Linux, so remember this: ALWAYS read the logs. They will (usually) tell you what is wrong, what was expected and what you should change.


Why should double submit CSRF tokens be cryptographically strong random numbers?

Short answer: To prevent brute forcing the CSRF token.

Let's take a trivial example: let's say your token is a single digit, accepting values from 0 to 9.
Now sure, an attacker cannot read this value from the cookie or header, but she does not have to - she can just have the attack send 10 CSRF requests, one with each possible value. One of them will be correct.

Using a cryptographically strong random value will prevent this, and can prevent the attacker from trying to scale up this attack (by having the attack send e.g. 1000 requests instead of 10, or 10,000, or... )


Which ciphers produce random cipher text?

All modern ciphers aim to produce what looks like random data - it's one of the core principles of information theory.

Ciphers that don't produce apparently random looking data tend to have fairly serious flaws, since this provides an avenue for attack - going back to pre-computer ciphers, enigma had this issue, and fell, in part, due to pattern recognition (specifically, someone spotted that A could never map to A, reducing the search space significantly, among other issues).

Any reasonable modern block cipher should be both fast and generate apparently random data, if used properly.


Are there advisories on how actually to use a password safe?

Password safes should be used like security vaults, meaning that they should not rely on any other layer for authentication or protection.  So using AD to access them is not advised.  What if your AD credential is compromised?  Other than that, here are my guidelines:

Use a safe that is either known open source or from a reputable, known vendor
Use a pass phrase for authentication that is used nowhere else
Be sure the encryption is applied to the entire safe file, and that it is at least AES 256
Avoid cloud safes if possible (where the safe is provided as a cloud service, even if encrypted with a key they generate for you).  There is too much risk with these new services.  But it's ok to store your key file in the cloud as long as your client software encrypts/decrypts it (this is why Apple keychain is ok too)
If you're trying to do this for multiple users in an enterprise (for root/admin passwords, for example), use an enterprise vault solution like Cyber Ark, not password safe software;  Then also be sure to enable the multi-factor authentication that they all provide (to avoid the AD compromise issue above).


Is using VPN appropriate method in my case?

Yes and no

(you) -> (isp) -> (vpn servers isp) -> (vpn server) -> (vpn servers isp) -> (example.com isp) -> (example.com)

your VPN's ISP could tell example.com that you connected to the VPN and that the VPN connected to example.com

Your ISP would only know that you connected to your VPN server.


Nessus runs a set of plugins that you define and you can choose to disable.  If you need to show a scan with zero findings, you should disable the checks that you don't care about and mitigate or resolve the findings you do care about.

The simplest way to do this would be to disable ALL of the checks and run Nessus.  Some people (myself included) would consider that cheating.  That's why it's important to consider the thoroughness of a test along with the result.


How can I embed iframe securely without restricting its functionality?

The sandbox attribute will prevent top navigation by default and can be configured to allow scripting using allow-scripts. The same origin policy in all current browsers should prevent any iframes that have content from a different origin (host) from accessing your application using JavaScript, the sandbox attribute will do it even for same-origin iframes.

So in short, sandbox should fulfill your requirements, although you would need to test if _blank works as expected.

However, you should be aware that not all browsers support the sandbox attribute, and the ones that don't will treat the iframe as a non-sandboxed one.


Is defending a server from BFA with 2 WAFs possible and common?

This is not common at all, but certainly possible.

When you choose a set of protections for something, you have to balance the costs and benefits against the risks and threats that you have identified.

In this case, you would have to weigh the costs of installing, configuring, and running a 2nd WAF against the possibility of the first WAF having an unknown bug. Typically, this is seen as too costly for the risk. But you have to make that calculation for yourself.

The thing for WAF is that you would have to place them in series (one after the other), which means the 2nd WAF isn't going to be doing much protecting at all under normal conditions, but still needing to do all the work of the 1st WAF.

So, if you want to add protections in case one WAF fails, I'd look at other options (like alerting) instead of a 2nd in-line WAF.


I don't think that the code you are marking is the one achieving to exploit the bug:

  s.send(struct.pack('>I',len(buff) ))

What this line is doing is sending the length of the buffer he is going to send right behind in the proper endiannes (Big Endian or network endiannes).

I believe that the exploit itself will have to do with the lengths of the "buff" variable sent which will be probably badly managed:

  A stack buffer overflow occurs when copying a user supplied input to a stack buffer of user supplied size.


Resigning the root CA as a subordinate CA is indeed possible.

Theoretically you don't even need cooperation of the "offline root" and its private key. The new über-CA just emits a new certificate containing the ex-root's public key and name, and that's it; this information is public anyway (they are in the ex-root's certificate, which is public). However, in practice, the über-CA may prefer it if it receives a certificate request signed by the ex-root itself, thus using its private key.

Normally, you should be able to make such a request file with certreq.exe (which should already be present on your machine). Use certreq -new with a policy file which contains the KeyContainer and ProviderName properties to point at your existing ex-root's private key. be sure to specify the exact same subject DN as the one used in the current ex-root's certificate: the condition for the new ex-root certificate to be acceptable as a substitute for the current one is that it uses the exact same DN and public key.

Once you have the certificate request, transport it to the über-CA, submit it, and use your administrative powers to authorize the issuing. This assumes that the über-CA accepts to produce sub-CA certificates, so you may have to edit and/or enable the relevant certificate template in that CA.

Once this is done, the new certificate exists, and clients may use it to validate certificates issued by the ex-root even if they trust only the über-CA. However, this works only if the said clients see the new sub-CA certificate. You can push it forcibly in the "intermediate CA" store on client machines. Alternatively, you may want to put it on a Web site referenced from the issued (end-entity) certificates themselves.

Indeed, any given certificate usually contains an Authority Information Access standard extension which includes an URL pointing to a place from which the issuing CA's certificate can be obtained. This is the basis for path building when the relevant intermediate CA certificates are not readily available. Chances are that your ex-root currently issues certificates with, as AIA, an URL pointing to its own self-signed certificate (on a Web site, in some LDAP server...). If you want clients to automatically obtain the new sub-CA certificate issued for the ex-root, then it should be sufficient to replace the ex-root self-signed certificate (wherever it is stored) with the new sub-CA certificate.

Note that the ex-root must still keep on with issuing CRL as per its policy.


The Gutmann method is not useful for any modern device, whether a hard drive or a solid state drive. The fact that you cannot safely wipe a solid state drive due to wear leveling is irrelevant. For any modern hard drive, the best way to erase data on it is to wipe it once with a random pattern. For modern solid state drives, there is no effective way to wipe it without using SED or TRIM.


Long lived auth session for native mobile app

TL;DR: Refresh tokens are your best bet. StackOverflow has some ideas on how to improve the security.

If I understand you correctly, what you need is a mechanism by which the user can authenticate themselves to the app for whatever they need to do.
You feel that access tokens can possibly be stolen by some other app or root user so you want something different.

There are two main approaches that you can take when authenticating users for their requests:

Ask the user to authenticate every time
Store some proof of authentication and use it

Clearly the first option is not going to be useful to you as you want a long lived session and its bad UX as well.

So you definitely need to store something somewhere. Instead of storing a user's actual credentials, I believe storing tokens that refresh is always better. You can read some relevant reddit and StackOverflow posts.


Is there a way to process a credit card transaction asychronously and be PCI compliant?

RAM is volatile and is not considered storage for PCI-DSS purposes - so long as the device that contains the RAM is otherwise PCI-DSS compliant.

In a similar fashion, temporary storage of the CVC/CVV on disc is not considered "storage" if the storage is highly volatile. For example, the operating system's swap space.


Defense in depth vs single security architecture

If I look at a presentation about the topic it does not look like replacing defense in depth, but replacing a heterogeneous environment containing lots of different mostly independent and sometimes incompatible security solutions with a more structured environment where all parts work together to better detect and deal with the risks. It still contains defense in depth, i.e. the idea is not to restrict the risk management to a single perimeter. But the major point is that the different security layers now work with each other so that information collected at one layer might be used to optimize protection at another layer.

Example: different layers detect different kind of suspicious behavior. While each of these information separately is not enough to detect an advanced attack, it could be detected by combining the information.


Creating subkeys for an existing OpenPGP key

If you're (somewhat) sure that the key is not compromised, I'd simply create a bunch of subkeys and move whatever keys you want to smartcards or other offline places. Adding subkeys is easily possible by using gpg[2] --edit-key and the addkey commands.

The usage flags are stored in a signature subpacket, so changing them does not change the key (with respect to it's key ID, which would invalidate all certifications). Yet, editing the usage flags in GnuPG is not possible (but by hacking the code). From a message by Resul Cetin on that mailing list thread:

  Ok, it was quite easy to do (not clean, but it could be done in a fast and
  hackish way). Just searched for gnupg-1.4.9/g10/getkey.c:parse_key_usage and
  changed p to non-const and always set (*p) &=~2;. Afterwards I started my
  new compiled hackish-gpg --edit-key and set the expire of my master key. After
  this procedure I had only the Cert flag set. Thanks Christoph - you are my
  personal hero of the day :)

Personally, I would not care too much for the master key's usage flag. If an attacker gets hold of the primary key, he would be able to change the usage flags, anyway.


What type of attacks can be carried on for an web application

There are a huge number of possible attacks. The ones you mention cover most of it, but things like session management problems, DOM injection, misconfigured AJAX cross-domain policy, etc. are all problems too.

Check out the OWASP Top 10 project, and the OWASP Cheat Sheets for a more comprehensive list.


How dangerous can a file be with no detected malware?

It is entirely possible for a file that is not detected by any scanner to still be malware. In fact, I would expect that most new malware starts out that way! Keep in mind that the bad guys have access to antivirus software too. And they will absolutely take advantage of that by making adjustments to their malware until no antivirus software detects it. (Granted, they wouldn't be able to test with Virustotal or any online scanner that would send their file to antivirus companies for analysis, but they can still go a long way testing with offline scanners.)

After the malware is released to the world and gains meaningful distribution, antivirus companies will eventually notice it and add it to their databases. But if you're unlucky enough to be among the first few people to encounter a new piece of malware, it's quite possible that no antivirus software will detect the file as malware when you first encounter it.

It gets worse. Sophisticated attackers (e.g. nation-states) often distribute malware to a very small group of select targets. By intentionally limiting distribution, it can take years or more before any antivirus company catches on. Most people will never be the target of sophisticated attacks like this, but if you happen to be one, antivirus software will be very ineffective.

In conclusion: If many antivirus programs flag a file as malware, it's a good sign that it's malware. If no scanner flags a file as malware, you cannot conclude anything.


What's the difference between "Trusted Root Certification Authorities" and "Third-Party Root Certification Authorities" Windows certificate stores?

The Third-Party Root Certification Authorities is a subset of Trusted Root Certification Authorities.

The Trusted Root are all the Microsoft certificates and the certificates for your organization plus the certificates in the Third-party Root.

The Third-party Root has all certificates that are not from either Microsoft or your organization.

For more information please check this website.


If your OS has up-to-date security, what does a virus scan accomplish on Linux

The misconception here is that exploitation isn't always a part of an infection. When an os is being patched it is being protected against a bug that might allow an attacker to infect a computer. But an attacker doesn't need to use a bug to gain access, and if he does use a bug it isn't necessarily part of the os (might be in an installed service, browser, app). Think about using social engineering, using a password you obtained somehow, or even using a browser exploit which is agnostic to the os version as you only exploit the browser's process.

Virus scanners add another layer of protection, if the malware was installed using credentials, social engineering or maybe even a zero day, if it is known you will still stop it.

As a concept security is always built in layers, assuming that the more obstacles you put attackers will have a harder time, which assuming you are not a high enough value target will make you an undesirable or practically safe.


Can my employer see what websites I visit at home on my personal devices?

The other answer is technically correct in saying that it is possible to monitor your network from a device on the network. Sure, any adversary controlled device could potentially be used to pivot and attack other parts of your network, including monitoring.

But, the key word there is adversary. A legitimate company would not be actively attacking your home network from your work laptop. This would likely be illegal in nearly every jurisdiction. If you have evidence that your work laptop is performing malicious activity, that's an (unlikely) different story.

Simply put, your work should not be monitoring any traffic besides what is going through their corporate VPN. Why would they care what you do on your personal network, regardless of during work hours or not? Their concern seems to be resource use of the company network.

So, if you are not watching Netflix on your work computer, then it is likely a mistake on their part, or some other misunderstanding.  This boils down to more of an HR issue than a technical one.

My only other thought: do you live in a complex with other residents, all sharing the same internet connection (and public IP address)? If so, maybe somebody else also lives there who works for your company and is misusing the company VPN.


Why does OpenVPN use two channels and not just TLS?

There's some truth in the other answers, but the primary reason is different:  because OpenVPN was designed as IP-over-UDP, while TLS runs over TCP.  Futhermore, the initial versions of OpenVPN did not have key exchange at all, but already had their own (better designed than TLS) data channel protocol.  So when TLS was added, it made sense to stick to that for the data channel.

(Nowadays there's DTLS that runs over UDP, but that didn't exist when the OpenVPN protocol was created.)


multiple private keys for single public key

What you can do in this situation is to use hybrid cryptography, in which you encrypt the message with a symmetric algorithm and encrypt the symmetric key with the recipient's public key. You can easily adapt that to send a message to many clients, each with their own public key. What you do is encrypt the symmetric key with client A's public key, and with client B's public key, and with client C's public key, and so on; you then stick all of these "symmetric key encrypted with client X's public key" tags on the front of the message, and each client can then decrypt the symmetric key and then the message. This way, you don't have to send 20 copies of the message, just 20 copies of the symmetric key.


What L7 traffic patterns can make it easier DoS an Apache web server?

Denial of service and traffic overload are two different things, so using a traffic generator isn't really the way to go. Traffic generators are great to model real-world usage of a resource (e.g. users coming at random times (Poisson distribution), random or recorded navigation templates, common searches and errors...). Most DDoSes are little more than GET / HTTP/1.0, but in job lots. Large job lots. That's not real "traffic".

If you want to see what happens when the system gets DoSed and exhausts its resources, you can e.g. disable SYN half-open protection (SYN cookies) if present, and use some DoS utility to fake opening connections. Or keep the connection open through, say, a Perl script.

Or you can send requests to those endpoints with a higher system load (e.g. that need database querying).

Malformed data will in all likelihood be intercepted at the outer layers of the Django router (if not by WSGI itself) and generate the least load. It depends on the malformation, of course.

Slowing down the send rate should stress Apache more than the rest of the stack (Django sends its output in fire-and-forget mode), while pulsing requests should hit Django more heavily, especially if they're crafted against the more expensive endpoints.


How does one typically monitor their privileged admins encrypted SSH & RDP sessions?

Check out Gartner's Guide for privilege access management. There are large number of vendors in this field that provide capability to monitor "Privileged session". Due to significant maturity of this space, I have not seen any large company rolling out a custom solution.

It is pretty rare for third party devs to have access to prod environment. In most of the places that I have been involved with, the access to developer (including third party) is limited to dev boxes. The UAT and production boxes are only accessible to system administrators. In UAT and in very rare scenario in production, developers may have read only privilege to specific directories to allow them to review logs and configuration files. In most of the prod servers, a privilege session management solution records all the keystrokes and depending on the sensitivity of servers, these keystrokes may need to be approved by a manager on daily basis.


How does Replay attack works on SSL/TLS authentication?

According to this reply attack in case of SSL/TLS authentication is difficult but possible. My question is then how it works?

According to the statement you cite replaying is possible if the attacker manages to decrypt the SSL/TLS traffic. In my opinion this should not be read as the attacker  replaying the original SSL/TLS traffic but instead the attacker is creating a new SSL/TLS connection and encrypting the original (not encrypted) data inside this connection and sending these to the server. Thus, it is not a replay attack against SSL/TLS since it counts on having the plain (not encrypted) data in the first place.

There are several ways to get to the plain data when SSL/TLS is used but all of these involve somehow compromising client or server or relying on security vulnerabilities in these. This could for example be an active man in the middle attack, a compromise of the server certificate or a compromise of server or client.

Thus in summary: replay attacks against SSL/TLS are not possible and this is also not claimed in the text you cite. The text instead talks about having the original plain (not encrypted) data and sending these inside a new SSL/TLS connection - but this is not a replay at the SSL/TLS level. As for why replaying SSL/TLS is not possible see Are SSL encrypted requests vulnerable to Replay Attacks?.


Why would Chrome return non-deterministic bytes for a versioned release?

Chrome is not returning non-deterministic bytes for a versioned release.

aszlig wanted to update a nix manifest to check from the network if there were updates. However,  there's no such function in Nix. Why not? Because you're not really supposed to do stuff like that in the Nix paradigm which is all about determinism.

Nix only allows you to download if you already know the contents of the file in advance (in the form of its hash).

He made such a package that tries to download the Chrome update and results in the boolean information about whether the update was available. But the result needs to have the same hash in both cases. That's where a hash collision comes in handy.

This build script uses a couple of well-known PDF files that both have the same SHA1 hash. If the update exists, it gives PDF 1, otherwise it gives PDF 2.

The update script then depends on that hack package. It "installs" that package, and then checks whether it actually contains PDF 1 or PDF 2, and now it knows whether the Chrome update was available or not.

(based on mbrock and grhmc answers)


How AWS access key id and secret access key are generated internally

From the documentation [0][1], we see that you prove to AWS that you know the Secret Access Key using HMAC, not using Digital Signatures. This means that when verifying the authentication, AWS must be able to generate the exact Secret Access Key for your Access Key ID.

Thus, their promise to never show you the Secret Access Key again is a matter of policy, not a truth about the underlying technology. If it was public key cryptography and the Secret Access Key was a private key that corresponded to the Access Key ID which was a public key, and they only stored the public key, they truly would not be able to regenerate and show the private key. But that would require the client to generate a private key signature to authenticate requests, which is slow and less portable than HMAC.

I have no evidence for this, but I believe the Secret Access Key is generated using HMAC from the Access Key ID, using a key that is available only to Amazon. Stealing that key without Amazon noticing would enable you to forge anyone's Secret Access Key given only their Access Key ID. If ever the AWS key is stolen, AWS would have to invalidate all keys and cause massive global downtime while everyone generates new ones on the AWS console and redeploys. I don't know what safeguards they took to make this unlikely, but I assume the key can't reside on a single HSM per Availability Zone, because it is required to process every non-public request.

Alternatively, the Secret Access Key might be random and stored alongside the Access Key ID in the AWS authentication & authorization system, which is replicated to every availability zone. That would mean that to cause a catastrophe, someone would need to exfiltrate a big chunk of data, not a single secret key.

0 - https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader

1 - https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#RESTAuthenticationExamples


Is there an encryption algorithm that allows for a single payload to have two different outputs based on the password?

The theoretical question here is a size/entropy question. The key rule is that the entropy of the encrypted message is the same as the entropy of the initial message. If the algorithm involves no compression, the size of the encrypted message is the size of the original message.

For the encrypted message to be decoded in two different ways depending on the key you need that it contains 2 different messages. A way would be to encrypt a real message with one key and a fake message with another key, and combine both encoded messages (after padding the shorter) for example with one byte from each. Provided you add a known id at the beginning of the messages before crypting them, at decode time, the algorithm could only give back the message that had the correct initial ID.

The problem is that there two different messages + some additional info. And having an encrypted message longer than the initial one is not that plausible...

That's the reason why I know no algorithm implementing plausible deniability, but only containers, that is a complete encrypted filesystem. This was implemented in the excellent TrueCrypt before its support was discontinued. Fortunately, a fork of the project still offers it, VeraCrypt.

VeraCrypt actually offers hidden volumes. In fact a part of the empty space of a normal volume is used to store a distinct volume with a distinct key. When you present a key, an attempt is made to find a hidden volume, if not to find a normal volume. When you open the normal volume in normal mode, nothing allows to guess that it also contains a hidden volume, simply it has some unused space which is no surprise for a file system. Of course, if you write a lot of data in that mode, you will overwrite and definitely destroy the hidden volume data. But a special mode exist to give both keys and use the external volume with no risk of overwriting the internal one.

Above was the technical part. But plausible deniability also requires the content of the external container to be worth it, because the capability of hidden containers is a well known feature. IMHO, there are two acceptable ways:

Sort your information in 3 classes, simple, sensitive and secret and store them accordingly: simple outside the container, sensitive in the external part (use the double password access) and secret in the hidden part. That way as the external container contains more than innocent files the existence of a hidden container is not evident. But you must actually use the external container, at least as much as the inner one and be prepared to disclose its content
Use the external container as your main storage. That is a common usage on corporate laptops, because it ensures that in case of theft or loss of the laptop, no confidential information are immediately accessible (addresses the confidentiality part of security...). The backside is that you should mount the container as a single one at boot, and in normal usage immediately unmount it to remount it manually in dual mode.

And depending of who the adversary is VeraCrypt pages about plausible deniability and security requirements for hidden volumes has additional advices, such as only using the hidden volume when booting from a read only CD/DVD...

As usual technical security is only a part of global security. If the information is sensitive enough that you can fear for your physical integrity, you should use physical security measures and not rely of plausible deniability alone: it is a nice tool that can help to hide secure information but not a magical silver bullet. Only Snake Oil Company can provide those...


Online brute force attack which will continue in background

Offering such a service to the public could be abused for illegal purposes. So you won't find anyone offering such a service for free to anonymous users.

When you are penetration-testing a system with permission of the owner and you explained the side-effects of such a test to the owner (a high-bandwidth online brute-force attack can cause a denial-of-service due to resource exhaustion), then you could rent a cloud server for that purpose.


What is a secure mechanism for wireless communication between Android and Ubuntu?

Set your desktop Ubuntu to act as wireless access point (if you haven't one already, you may need to add a Wifi card or Wifi USB token to your desktop, but these are cheap nowadays) and configure your mobile device to connect to this access point.

If your mobile device is already configured to use a Wifi network on that location to access Internet ressources, then you may want to configure your desktop to act as a gateway for your mobile device.

On one side (Wifi side) there will be a private LAN allowing your mobile and your desktop to communicate securely,
When your mobile requires to access some Internet resource, he can go through your desktop to fetch them.


My WCF application uses 2 way certificate message encryption - does it still need SSL?

In a word: yes.

All message encryption does is make part of the communication confidential. SSL makes sure you're talking to the right server and makes sure nobody listening in can figure out who you're talking to.


It isn't unheard of. I have setup many that way. It depends on how sensitive your systems are.

I like that you said "from a design perspective". Part of security is good design, whether something "theoretically shouldn't happen" doesn't make it impossible. Hacking happens. Layering and segregation is one way to introduce choke points, as well as make firewalls easier to audit, and finally, to protect against human error and misconfiguration.

DMZ is not only for inbound services. Extremely sensitive systems also restrict outbound Internet access, so if you have a separate group of servers that need outbound access, you
d want to put them on a separate DMZ to segregate them rather than mixing ACLs and potentially exposing your private network.  At minimum, consider separate VLANs.

Many sensitive financial, medical, telecom and government systems are on private networks that are not NATed or routable to the outside whatsoever. Some have front-end application servers on a DMZ that have firewall rules that allow punching through from the DMZ -> Private, but some don't even have that much.


How is it on some removable media, when enabling/disabling password protection the changes happen immediately?

It is possible to achieve an "instant password change" with an encrypted disk. The idea is that the disk is really encrypted with an internal secret key K. K is a fat, random key that you never see; it was generated when the disk was first powered, and it never changes. K is then stored in a specific slot, encrypted with a second key K', which is derived from your password. When you unlock the drive with your password, the disk firmware recomputes K' from your password, then decrypts K, and then uses K to read and write data to the disk.

When you change your password, K is reencrypted with the new K', but that's fast because K is, say, 128 bits, not 128 gigabytes.

A disk which does encryption that way also often offers a fast "wipeout" feature, by the simple expedient of generating a new K: the previous K being lost, every contents which were encrypted with K (the whole disk) are as good as cleared. (Thus, "K never changes" is not completely true; rather, K does not change when you change your password.)

Now this does not mean that your specific disk uses encryption, only that it could still use encryption, even if it offers fast password changes. There indeed are disks with "password protection" which is only a simple firmware-based lock, without actual encryption of the data, and that can be bypassed by changing the electronic board. If unsure, try to obtain the disk specs from the manufacturer: if actual encryption occurs, then the manufacturer will state it proeminently on the disk datasheet.


Does git use the ssh user keys or the repository's deploy keys for encryption?

tl;dr: No, this will not work. The fact that the server knows your public key does not authenticate the server, even if you try to keep the public key secret.

  This seems to be preventable if git uses the repository's deploy keys or the user's ssh-keys for encrypting the connection

Several issues here:

git has no such concept as a "repository deploy key", this is part of GitLab. It appears to be simply a public key configured to allow read-only access to the repository, intended for use in code deployment (you may already understand this, but your question isn't fully clear to me).
Using your ssh key to connect to something authenticates you by proving that you have the private key. It doesn't authenticate the server. This is why host keys are necessary.
ssh keys aren't used to encrypt the connection, only to authenticated an already established secure connection (establishing the secure connection is a separate part of the ssh protocol)

Public keys are called public for a reason, you should never assume it to be private even if you just generated it to add to GitLab over HTTPS and don't use it anywhere else.

ssh authentication involves sending the public key to the server to see if it is allowed (called "public key blob" in RFC 4252 section 7). This is done after establishing a secure connection so that it can't be intercepted, but that doesn't matter if the session was established with a malicious server. An impostor could simply reply with "Why yes, I will accept that key to authenticate that user!" and fool you into thinking it's the legitimate server. The only correct way to authenticate a server with ssh is by using its host key.


Back button navigation problems because of CSRF token?

There's no need to create a new token with each request. Instead, as per the OWASP CSRF Cheat Sheet, create a token for each session. As the same session is used for both test1.jsp and test.jsp, the back button will no longer be a problem.


Storing and reading user's credentials on their machine

No. Not without user input such as a passcode or passphrase used to encrypt and decrypt the credentials.

Even so, the malicious developer could sniff the credentials after decryption anyways.


Validate individual hardware components process

Nothing that can fully validate all components which exist in a general use system.

That is because components such as hard drives and video cards have their own firmware which they run. This firmware is the target of the attack, and there is no standard verification which all components in order to validate their state.

Chromium and the line of Chromebooks are one step better than secure boot. They offer something called verified boot which does a great job of detecting tampering.

https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot

The downside is how limited Chromebooks are as general purpose computers.


Is Array.Clear() in C# suitable for zeroing sensitive byte arrays?

You are definitely correct, in that sensitive information should be cleared out of memory, but I would recommend against implementing anything that close to the cryptographic primitives.  I always recommend using a well vetted library to implement any cryptography.
There is a list of decent libraries
in this other SO post (https://stackoverflow.com/questions/1180365/recommended-net-encryption-library), with BouncyCastle being the reference implementation.  One of these libraries should take handle the clearing of memory for you.  Cryptography is one of the easiest things to screw up, so it's best practice to go with a out-of-the-box solution, which handles the easy to screw up parts for you.


File security when encrypting files directly with the openssl command / and what about SHA1 hashing password first?

See the end of this answer: what OpenSSL does to convert the passphrase into an encryption key and IV is weak, because it is just a couple invocations of MD5, which is not slow enough. There is no way to simply change that within OpenSSL (no appropriate command-line option, this is hardcoded).

Pre-hashing you passphrase would not change things much. Doing a lot of nested hashing would enhance things a bit, but not to ideal levels since the salt would not be taken into account until the very last steps (a lot of shareable precomputations would still be doable by the attacker). Password hashing, with configurable slowness and salts, is not something which tolerates improvisation. At that point, it is much safer and simpler to ditch OpenSSL altogether, and use a better tool. I suggest GnuPG: the command-line tool, with its -c flag, does password-based symmetric encryption, and does it much better than openssl enc.


User names are predictable. I would prefer using random value as a salt. An attacker could begin the generation of precumputed hash table targeting one user (admin?) even before obtaining the hash&salt to crack.

So, you should NOT.

Edit:

The main purpose of having a salt is that rainbow tables are useless. From my point of view, using a guessable value (even with static value added) as salt is bad practice as you allow an attacker to "prepare" the hashes before obtaining your database.

In some scenarios : if you distribute your code and you have a default "admin" account, an attacker will be able to reuse the rainbow table against all the installations of your software.

Other example from @Anti-weakpasswords : Pyrit, "a WPA/WPA2 cracking tool, tool advantage of the WPA/WPA2 protocol using the SSID (username equivalent) as the salt to allow the precomputation of reasonably sized dictionaries against common SSID's - linksys, dlink, 2WIRE047."


Is it possible to have a text message that I didn't send appear on my smart phone making it look as if I did send the text?

It is possible, even without a hacker's technical skills but with a bit of planning ahead.

Multiple apps allow you to remotely control your own phone, which implies that you must install them yourself to your phone. Let's call your client Alice and her husband Bob. Let's assume Alice owns an Android.

It's fair to assume that Bob knows the PIN/gesture to Alice's smartphone: they have lived together after all. I certainly know my girlfriend's gesture from mere observations. Bob used to have access to the device and could have installed an app and left it dormant on the phone for long.

Then, he could have used that app to remotely send texts from the device. Those apps quite literally ask for the permission to send texts, so the texts do are sent from the device. I just tested sending a text from my computer with AirDroid, and I do see my sent text on the phone as well. I am also able to uninstall AirDroid from the computer to erase my traces.

The obvious warning...

This goes beyond opportunistic nuisance, as it requires a bit of planning on behalf of Bob. If Alice and Bob have been away from one another for months then you must take the time to consider how likely you think such a scenario is, but I'd assume you're much more aware of this than I am.

What to do?

You'd need to look if there is any information in the Google Play account of Alice or on her device on apps that were previously installed -- I'm actually unsure of this. As you are a lawyer you may also be able to contact Google and ask for a history of the device and installed apps, which is something they might be expected to keep. As a last resort, ISPs and websites have to keep a history of connections from any IP address so you could try to trace back whether any connections to such remote texting apps' websites were made from Alice or Bob's devices.


How to exploit this SQL injection vulnerability?

Usually when exploiting logins you want to inject something that prevents the password field from ever validating. This can usually be accomplished by putting syntax similar to the following as your password:

myphonypassword' OR 1=1;--

This will claim that you are the admin user, terminate the string in the actual query and make the query don't care if you wrote a legal password or not as the OR 1=1 makes the query always true.

There is many differnet variations you would have probably have to try to make this exploit work (especially if it is a blind SQL exploit). You can see many more examples in this SQL Injection cheat sheet specially for login bypassing.

In your specific example you probably have to edit the field called txtPassWord, however it is unclear by the little details you have provided.

Edit: since this is a post only parameter you cannot attack via URL only. You can intercept the request with a proxy and modifiy the post parameters that way or craft a new request with Curl like in the other answers suggestion


(custom software) Security rules on each record when using user-groups per application

Beside ACLs another common approach is to use rules. So you don't define the rights on a per record level but based on characteristics of records.

BaseRight: read postings

Rules: postings with x upvotes, posting created by current user, all postings

Those rules consists of a name and some program logic. They can be very flexible, for example fragments of SQL queries. In the software I develop at work, even administrators can define new rules.

The actual rights are now a combination of base rights and rules with optional parameters.

I recommend to default to no access and to avoid negative rights because it makes the implementation a lot easier and therefore less error prune: You can simply iterate over all rules and as soon as one rule says "okay", you are done. For obvious reasons special care has to be taken when this is done in SQL, but the performance improvement on queries with huge results sets may be worth the trouble.

Examples

For example the anonymous user pseudo role may get this right:

Right: read high quality postings based on

BaseRight: read postings
Rules: postings with x upvotes
Parameter: x=3

A site admin will get this right:

Right: read all postings based on

BaseRight: read postings
Rules: all postings


"Alert" type is the default one that can be used if you want to generate that kind of event when the signature matches.
Based on your need, and to customize the use of the application, you might want to not be alerted all the time, for example.

You might want to set "log" type for some rules that might be too noisy, so that you can analyze them once a day, with some analytic methodology.


What information can be leaked via unencrypted STUN transmission?

STUN is designed to discover client's Public IP Address if the client is sitting behind NAT.

From wikipedia:

  STUN messages are usually sent in User Datagram Protocol (UDP) packets. Since UDP does not provide reliable transport guarantees, reliability is achieved by application-controlled retransmissions of the STUN requests. STUN servers do not implement any reliability mechanism for their responses. When reliability is mandatory, the Transmission Control Protocol (TCP) may be used, but induces extra networking overhead. In security-sensitive applications, STUN may be transported and encrypted byTransport Layer Security (TLS). The standard listening port number for a STUN server is 3478 for UDP and TCP, and 5349 for TLS.

It means that your connection with the STUN server may or may not be always encrypted. It depends on the type of application.

Once the client has discovered its public IP and behind what type of NAT it is sitting at, the connection with the STUN server is terminated to save network resources. STUN uses 2 IP Address.

How do peers communicate then?
The work of STUN is over and now it's time to start a session between peerA and peerB. For P2P communication, Session Initiation Protocol (SIP)  like VoIP & Session Description Protocol (SDP) are used.

  If the STUN isn't encrypted, does that mean any protocol communicating through the UDP also won't be encrypted?

No. It doesn't depend on whether or not have you used secured channel for communicating with STUN. The session between both the peers will be end-to-end encrypted regardless your secured/unsecured connection with STUN. It is the responsibility of P2P service provider to ensure encrypted & secured channel for your P2P session.

If your connection with STUN is not private then the only information that can be captured is your public&private IP, external and internal ports and the type of NAT you are using.


Security Audit on AWS - question on findings

The EC2 findings refers to: AWS Security Group for your EC2 instances have an unknown or too permissive CIDR origin allowed for inbound/outbound traffic. This audit rule expects another Security Group reference as originator or destiny of the traffic that pass through it.

When an unknown CIDR is found, the Unknown CIDR caption is added to the report, which facilitates detection of EC2 security group rules that whitelist network traffic from untrusted IP ranges.

ref-link-1: https://github.com/nccgroup/Scout2/wiki/HowTo:-Use-with-a-list-of-trusted-CIDRs

=========================================================

The IAM findings refers to: IAM Role Policy Too Permissive

Inline group policy allows iam:PassRole
Inline role policy allows iam:PassRole *
Inline role policy allows sts:AssumeRole *

NOTE: You've probably set an IA policy something like the ones show below

"Statement":  [
{
  "Action": [
    "iam:PassRole",
    "iam:AssumeRole"
  ],
  "Effect": "Allow",
  "Resource": [
    "*"
  ]
}
  ] ,
"Version":  "2012-10-17"

"Statement":  [
{
  "Action": [
    "iam:*"
  ],
  "Effect": "Allow",
  "Resource": [
    "*"
  ]
}
  ] ,
"Version":  "2012-10-17"

Ensure that the access policies attached to your IAM roles adhere to the principle of least privilege by giving the roles the minimal set of actions required to perform successfully their task.

Providing the right permissions for your IAM roles will significantly reduce the risk of unauthorized access (through API requests) to your AWS resources and services.

PassRole: To pass a role (and its permissions) to an AWS service, a user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, you must grant the PassRole permission to the user's IAM user, role, or group.

AssumeRole: A trust policy for the role that allows the service to assume the role. For example, you could attach the following trust policy to the role with the UpdateAssumeRolePolicy action. This trust policy allows Amazon EC2 to use the role and the permissions attached to the role.

ref-link-2: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html

AWS Security Audit Open Knowledge bases:

kb-link-1:
 https://www.cloudconformity.com/conformity-rules/

kb-link-2:
 https://github.com/cloudsploit/security-remediation-guides


What is the best resource to learn malware analysis?

The Practical Malware Analysis book itself comes with hands on exercises for each chapter with solutions in the back of the book.  It's a great resource that you should probably invest in.

If you're not familiar with reverse engineering topics then I would suggest learning x86 Assembly, Windows Programming, and Windows Internals concepts.  Pick a debugger a learn it like the back of your hand:

Windbg
Ollydbg
Immunity Debugger

Pick up a free version of IDA Pro.  There are various tutorials on IDA's site.


How can I protect myself from "ransomware" attacks like the one that affected Transmission users?

There is no longer such a thing as a "Trusted Source". Probably never was. You are only one exploit away from infection. If the software producers get compromised or the automated scanning for the app stores get bypassed, you will be infected.

Security is often an illusion created by forward motion in patching and upgrading. We've had several fantastic near misses in the last six months in infrastructure maintenance, server maintenance and endpoint maintenance.

The only real protection is multiple versioned backups. And hope you can step back to a preexploit version.


Sucpicious process running in CentOS server

Things to look at:

/proc/PID/exe may be a symbolic link to the program binary, or it may be a broken link (eg. if the program binary was deleted, or if it's a kernel process).

/proc/PID/cmdline should be the command line used to start the program.

/proc/PID/maps may contain interesting information, since programs and their libraries are usually loaded by memory-mapping the disk files involved.