I don't think this is as easy as simply plugging in some DLP product into some arbitrary environment.

I would say it is practically impossible to actually prevent intentional stealing of information by a insiders who needs on the one hand to have access to the code for working and on the other to have some way to communicate with externals (like surfing the web to get information). While one could probably prevent direct channels between the communication part and the code writing part by having these in physically separate networks and systems this will noticeable impact the productivity and is thus impractical for most environments. It is probably especially unacceptable for startups where a high trust in each other is often necessary to achieve the necessary flexibility and high productivity.

Accidental spilling of source code by insiders is a bit different. DLP might maybe prevent that employees post snippets of the code into some external sites like stackoverflow. But this comes at the cost of not allowing to post anything (which again impacts productivity) or by somehow inspecting every traffic (include SSL interception) and comparing posts to parts of the source code - which somehow requires the DLP to get information about the code it should protect. But the question is if leaking small snippets of the code is even a significant problem at all.

More of a problem is likely leaking major parts of the code. Accidentally leaking major parts by insiders suggests that there is some problem of how the source code is handled internally, i.e. it is more a process problem where a DLP does not really help. Thus make sure from how processes are designed and lived that there is not even a need to have source code outside the company, i.e. that there is no need to have source code available on some cloud systems in order to run your product or that source code has to be shipped to customers so that they can run your product. Unfortunately there are not enough specific information about your use case so these can only be very broad recommendations.

Leaking major parts of the code by attackers is a problem where DLP is probably the less relevant part. Instead the usual recommendations apply, i.e. proper security in the first place in order to make intrusion into your network and lateral movement inside the network sufficiently hard, proper monitoring what happens. And then make sure that it is clear who has access to the data and when and how (from which systems) etc. And make sure that it is not only clear but that it gets actually enforced and monitored against unusual usage pattern. And the more restrictive this access is the better - but more restrictions come again with a loss in flexibility and productivity. Zero-Trust concepts like BeyondCorp might help here. But if they can be implemented depends a lot on the specifics of the infrastructure and environment, used applications ... So again, these can only be broad recommendations.


How can a userspace linux process refer to a kernel address?

As a performance optimization, the kernel memory was mapped within the memory space of the application.  The pages are protected, but the page tables were (before KPTI) mapped in so they did not have to load them from memory on each system call.  Now each system call incurs additional overhead to load the kernel page tables.


How to Check Open Source Code for Vulnerabilities?

It largely depends on what it is you are trying to find bugs for. And I can tell you now that there will never be a one size fits all approach to this. Finding bugs in something like OpenSSL will be quite different than finding bugs for a public facing web application.

Since you mentioned bug bounty platform and a number of web scripting languages (maybe not so much C++), I would assume the platform is more for public facing web apps/sites than anything else.

In my experience with hacking web apps, if you have access to the source code, and even if you don't, the best place to start is with the mindset of: As an outside user, how can I make this app fail in ways that are beneficial to me.

You could start looking at what input you can and can't to send to the app. If you have access to the source code, you can kinda cheat and just go look at how the app handles user input. Perhaps the app just appends the input to a mysql query string. That would be a bug worth reporting.

Another place to look could be in how the app serves its content, a lot of web apps use misconfigured apache and nginx instances, but sometimes web apps serve themselves and people misconfigure that often too.

As far as tools go, you may be able to find some general tools for exploiting common web apps (like wordpress), but by and large you'll be writing your own tools. If the app's language and/or framework supports unit tests you could write some and execute it against a running instance of the source code.

The main takeaway from this post should be that there will never be a one size fits all approach to this. and if you want to be a hacker searching for bug bounties in web apps, your best place to start is by thinking: As an outside user, how can I make this app fail in ways that are beneficial to me.


Why is brute forcing DH private key harder than calculating public key?

Computing the public key is a problem of modular exponentiation, which can be done in O(log(e)) steps via exponentiation by squaring.

On the other hand, finding the private key is the discrete logarithm problem, for which no equally efficient algorithm exists. You just have to run through all the possible values and try them all. There are some better algorithms, such as Pollig-Hellman and Big Step-Little Step, but they are generally not applicable for the general case (the former is only efficient for numbers that decompose into small primes, for example)

This means that computing a modular exponent is vastly faster than a discrete logarithm. For a very large exponent, this effectively makes the exponentiation a one-way function.

...unless, of course, you have a quantum computer!


Kerberos - what can an attacker achieve from a replay attack?

You might want to read this PDF, which gives an example of such replay attack. In effect, it's not so much a replay attack as it is a man-in-the-middle attack. That said, part of the reason for having the timestamp and cache is to make it harder for an attacker to perform such a replay attack, and instead they must actually perform a MITM, which is harder. They actively have to block the request to be able to use the authenticator.

As far as the session key, as far as I understand it, and I might be wrong, it's not actually required once you get the token allowing you access to the resource. Again, I'm not sure so better read about it in more detail.


PCI compliance if not storing or transmitting credit card data

As your system is within the same network as the client systems which may handle cardholder data, your system can be included within the scope of the customer's compliance. In this regard you can be considered a connected system. From the scoping page of the PCI DSS: The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment.

It sounds like your system component is within or connected to the cardholder data environment (i.e. the environment within which the POS or other device handling cardholder data is situated).

It sounds like the client should either segment your device at a network level to remove it from the cardholder data environment or include your device with their scope of their compliance. To do this, you should provide the client instructions on how to situate and maintain your device in a secure manner.

As you can log on remotely to your device, you could attack the customer's network internally. Is the Linux device hardened, is it kept up to date, is logging enabled, what user management is in place, is IP tables configured? Does remote access require two-factor authentication? Each of these are questions which a QSA will pose in regards to the security of, and potential threat/vulnerability posed by the device.


nmap with sW only give number of ports open but nmap with -sW plus -sV gives different result which says open and tcpwrappeds

Nmap without -sV (or other options that include service/version detection) makes no effort to determine what sort of service is actually running on a port. Instead, it simply does a lookup against a list of common port/service assignments in order to present a most-likely candidate for the type of service that would be running on ports included in the report.

This is what you're seeing with nmap -sW (for the purposes of this discussion, the -PN is irrelevant). Nmap is giving you a list of all the ports that the Window Scan thinks are open, and telling you what sort of services commonly listen on each port.

However, you should be aware that nmap -sW can be unreliable against targets that don't support the functionality it is designed to exploit. (And targets that do support that functionality are generally rare.) This is mentioned in the Nmap Port Scanning Techniques documentation, and appears to be exemplified by your results. (At least, the small portions you've pasted above - I assume they're truncated.)

The below is copied from the Nmap documentation I referenced above. Emphasis is mine.

  -sW (TCP Window scan)
   [...]
  This scan relies on an implementation detail of a minority of systems out on the Internet, so you can't always trust it. Systems that don't support it will usually return all ports closed. Of course, it is possible that the machine really has no open ports. If most scanned ports are closed but a few common port numbers (such as 22, 25, 53) are filtered, the system is most likely susceptible. Occasionally, systems will even show the exact opposite behavior. If your scan shows 1,000 open ports and three closed or filtered ports, then those three may very well be the truly open ones.

With service & version detection enabled (e.g.: nmap -sW -sV in your examples), Nmap does some extra checks to be more certain of the ports' response states and to determine the type and version of application that's hosted on the open ports. These extra checks are what allow Nmap to provide the "tcpwrapped" determination, instead of just assuming that a responding port is running the service that commonly defaults to that number.

If there are any ports shown beyond the output you've pasted above, which do not report "tcpwrapped" in your nmap -sW -sV scan, it's probable that those are the only ports worth investigating further on the target. However, for more accurate results, you really should be using a different port scanning technique.


Depends on what you are attempting to protect against.

If the password is validated by code that runs on the app, it is subject to tampering, so no amount of encryption or hashing will protect against the ability to execute the (tampered) code without the password.

If the purpose of the password is simply to provide a modicum of protection against casual misuse (e.g. don't want your wife opening up the app) then local hash + salt is probably OK.


HTTP security headers on non HTML (images, JavaScript, etc)

Depends. If the website accepts user-submitted content, it's best to keep the XSS and nosniff headers on, in case they provide a loophole.

Lack of HSTS is also fine; however ensure that you have your cookies separated from HTTP and HTTPS, just in case.


Preventing Attacks Scanning for PHPMyAdmin etc

If you're using Apache for such applications, you may want to look into ModSecurity, mod_evasive and/or mod_qos. The latter two are more geared towards brute force and DoS attacks. ModSecurity though has a ton of stuff under its banner.


Creating a secure offsite backup at a friend's house

It sounds like you want a tool like duplicity, which uploads pre-encrypted deltas. It works with multiple backends (from ssh and sftp to AWS) so your friend doesn't need to be running Linux. By using an existing tool you won't need to reinvent anything (except for maybe setting up your own cron job which can access a gpg key for duplicity to use) and you can reuse this solution with cloud (untrusted) providers for smaller sets of data or when it becomes more feasible to upload 6TB of data.


In PSK TLS, how is the key used for encryption derived?

The pre-master secret is encrypted and exchanged in the TLS handshake.  This value is used to derive the master key.  The master key is used to derive all other keying material by passing it into a pseudo-random function (PRF), and combining other pieces of data from the handshake.

Deriving the Pre-Master Secret for a PSK

From RFC427: Section 2

  The premaster secret is formed as follows: if the PSK is N octets long, concatenate a uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself.

If using Diffie Hellman w/ PSK, Section 3:

  The premaster secret is formed as follows.  First, perform the Diffie-Hellman computation in the same way as for other Diffie-Hellman-based ciphersuites in [TLS].  Let Z be the value produced by this computation (with leading zero bytes stripped as in other Diffie-Hellman-based ciphersuites).  Concatenate a uint16 containing the length of Z (in octets), Z itself, a uint16 containing the length of the PSK (in octets), and the PSK itself.

If using RSA w/ PSK, Section 4

  The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key as described in Section 7.4.7.1 of [TLS].  The actual premaster secret is formed by both parties as follows: concatenate a uint16 with the value 48, the 2-byte version number and the 46-byte random value, a uint16 containing the length of the PSK (in octets), and the PSK itself. (The premaster secret is thus 52 octets longer than the PSK.)

Deriving Master Key

Everything that follows does not just apply to TLS PSK; it applies to all key exchange types. From RFC 2246: Section 8.1

  For all key exchange methods, the same algorithm is used to convert the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed. The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary depending on key exchange method.

   master_secret = PRF(pre_master_secret, "master secret",
                       ClientHello.random + ServerHello.random)
   [0..47];

The PRF is defined as combining two different hashing functions.  Section 5 of RFC 2246:

  First, we define a data expansion function, P_hash(secret, data) which uses a single hash function to expand a secret and seed into an arbitrary quantity of output:

   P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
                          HMAC_hash(secret, A(2) + seed) +
                          HMAC_hash(secret, A(3) + seed) + ...

   Where + indicates concatenation.

   A() is defined as:
       A(0) = seed
       A(i) = HMAC_hash(secret, A(i-1))

The function described above is really P_MD5 or P_SHA1.  The TLS PRF is described as follows:

  TLS's PRF is created by splitting the secret into two halves and using one half to generate data with P_MD5 and the other half to generate data with P_SHA-1, then exclusive-or'ing (XOR) the outputs of these two expansion functions together.

So lets claim the following:

L_S = length in bytes of secret;
L_S1 = L_S2 = ceil(L_S / 2);

The PRF is then:

PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
                              P_SHA-1(S2, label + seed);

Derive Encryption Keys

The key derivation is described in RFC 2246: Section 6.3

The entire keyblock is derived as follows:

key_block = PRF(SecurityParameters.master_secret,
                "key expansion",
                SecurityParameters.server_random +
                SecurityParameters.client_random);

Once enough material is generated and stored in the key_block, the key_block is split into the encryption/decryption keys.  Encryption or decryption depends on the direction.  As they're all referenced as write keys.  The key_block is sequentially split into the arrays:

client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

There's some additional computations performed for exportable block ciphers.  You can read those details in Section 6.3 of RFC2246 as well.  Section 6.3.1 gives an example of these computations without the extra descriptions.


Nessus scanner and Red Hat backport security updates

You would need to check the locally installed package version:

https://access.redhat.com/security/updates/backporting

As Red Hat back ports patches, so the Apache version sent by the web server will always appear to be "old" (since it is not incremented unless the entire package is rebased to a newer version, which is rare in Red Hat Enterprise Linux). You can cut down on false positives by setting the ServerTokens to "Prod" for example.

In general simply banner scanning (Apache HTTPD, SendMail, Postfix, etc.) will almost always result in a lot of false positives. It is much better to check the RPM's actually installed for example using the yum security plugin:

yum install yum-plugin-security

then make sure all available security updates are installed:

yum updateinfo list security all

for more information please see https://access.redhat.com/solutions/10021


Value of authentication between services

The benefits are:

If the user is already authenticated, then they seamlessly pass through onto the second system without needing to type in their credentials (i.e., username and password) once again
The user only has to remember a single set of credentials.
The administrator does not need to manage password synchronisation between the two systems.
More secure, because authentication is trust-based using public key cryptography, instead of sharing credentials between systems.


Is it "normal" to find procedures in the middle of a .mov file with a disassembler?

It is kind of cool because the code is way too organized to just be random data.

The only thing that makes this credible is the large amount of x86 jump-like 'opcodes' in the video (7a-7f). What makes it less likely is the memory addresses: the pointers in that piece of disassembly reference edi + > 0x75000000 and - > 0x50000000. This is not entirely impossible, but is highly unusual. If you look at the top instruction, AAD, this is entirely out of place:

  The AAD instruction is only useful when it precedes a DIV instruction that divides (binary division) the adjusted value in the AX register by an unpacked BCD value.
  http://x86.renejeschke.de/html/file_module_x86_id_2.html

So my impression is that you simply have a very forgiving disassembler that will try to make sense of anything you feed it. If you're still unconvinced, give us the file so we can look at it.


Can I say "session data is available on the client temporarily for surfing period but stored permanently on server"?

No, you may not.   Well, you might, of course, if you were so inclined, but that would be incorrect.   Session data, server-side or otherwise, is not ever supposed to be permanent.  I think it may be the absurd overloading of the term "session" which is causing you confusion.

To wit:

A session cookie is something stored on the client side, and does not have an expiration date but expires (and is deleted) when the browser session ends. (The browser is closed, in other words.)
A persistent cookie  has an embedded expiration date which may (amusingly enough) cause it to expire before the browser session ends, or more generally be persisted across multiple browser sessions by saving it to disk for re-use.
Session state (or server-side sessions, or session variables) is data that is persisted for a short time (usually a sliding 20 to 30 minutes, by default) that is associated with a client (browser) session, and referenced by a session id that is both the key for the server side session data object and the value for a session cookie that the client sends with each request.   If the browser does not make a request within the timeout period (again, usually 20 to 30 minutes by default) or even potentially before that, if the application requests that the session for that client end, then that data will be deleted from the server.

Session state data is often stored in memory on the web server, and thus will not be permanently persisted, and in many cases will not even survive a restart of the web server process, even if the sessions are technically still valid and alive.

This can be mitigated by using a dedicated session state process, or storing session state in a database, but in no case is it ever intended to be a permanent data store.


Certificate based Access Control for Pub Sub messaging

Ok, for posterity, here's my eventual approach for anyone coming along later finding this, and wonders what what I ended up doing while trying to to not obscurification the policy payload.

I essentially used the Certificate Policies extention to list the polocies applicable to the idenety.
Each element in the list the containes PolicyInformation the structues the policy identifier with the policy qualifiers.
The policy qualifiers is made to be a list of text strings, with each sting defining a applicable namespace scope using regex like syntax.

I used a nesting of of OIDs to map policy identifier to such actions as allowed/denied subscribable topic namespaces, etc.
ttps://github.com/ros/ros_comm/blob/e8568a493f039e6112884de733af00d289213a34/tools/rosgraph/src/rosgraph/sros_consts.py#L6-L8

When two peers connect, they use the certificate context from the TLS connection to acquire the other node's Certificate Policies extension data. Before the client sends the API request, it scrutinized the server's policy extension to check it is authorized to service the API call. If it is it will proceed, and if not terminate the connection.

When the accepting server parsis the API method requested, it scrutinized the client's policy extension to check it is authorized to request the API call. If is is it will proceed and dispatch it, and if not terminate the connection.

Some minor optimizations are done, such as sorting the qualifier themselves before embedding, and then later searching the dening related policy qualifier for matching namespaces requested in the API call before searching the allowed policy qualifier, as to terminate unwanted connections sooner.

There are some pros and cons in embedding policies into the same certificate used in the transport layer. I touch on that briefly in an additional write up here:
SROS: Securing ROS over thewire, in the graph, and through the kernel.


Can this modified 'Many' Time Pad be made 'stronger' by using an extrememly long key?

It's not a "one time pad" if you reuse the key.

You lose the perfect security properties of a one time pad with any key reuse, period. Your scheme just reduces the security level of the algorithm to your "special calculation", which is simply security by obscurity.


Sell ebook online without disclosing my identity

I think that you are concentrating on the wrong issues.

You want to sell, as in get paid.
You want to protect your personal identity.

Implied with selling and getting paid is “marketing”. It’s unrealistic for a new author to completely provide their own promotional marketing and expect to make any money. There are many ebook sales platforms available to leverage your sales and marketing, Amazon being the biggest, so plan to use one or more.

  I know you said “epub” format and Amazon is “azw”, but converting between them is trivial.

Protecting your privacy involves a “Pen Name”. As long as the purchasers see only the Pen Name that is your primary privacy.

In order to get paid, there has to be a path back to you. It’s just a question of how much privacy can realistically be maintained. Generally this privacy break for money is with the “Publisher”.

Many ebook sellers will provide this publisher break for you, but they will have all of your actual information in order to transfer payment.

If you feel you need another layer of privacy, you can become your own “Publisher”(Not “Seller”, you would still use Amazon or IndieBound or whatever.)

In the US you can create a limited Liability Corporation (LLC), as your “Publisher” (No Tell Publishing). Open a a business bank account under this publisher name, possibly with an additional “Doing Business As” addendum as another custom  name (“Late Night Reads”). Set up all the payments to the business publishing bank account.

The weak link is the money path. Just use a VPN, or Tor if you’re determined, to break the link between you personal machine and the sales platform when uploading books or otherwise interacting. A second computer or a VM or TBB to thwart fingerprinting should be sufficient. All the jumping around with public WiFi is completely unnecessary. A single anonymous email should be sufficient, compared to the money trail.


How important is it to delete disk partitions when wiping devices?

What you are seeing is a cached view of the previous partitions.

If they appear to persist even after a wipe, this is a result of the kernel caching the last known partition table in memory. It does this because it does not expect the layout to change at runtime, so rather than re-read the table each time the partition layout is queried, it reads it once at boot. If you want to force it to re-read the partition table, you can run a command like partprobe, reconnect the drive, or reboot.

The partitioning information is contained in the partition table, which is a small (64 bytes) section of the drive that specifies the location, type, and length of each partition. MBR partitions keep this table at the very beginning of the drive. GPT partitions keep an additional backup at the end of the drive and add support for more features. When you overwrite an entire block device, the partition table is also wiped.

As another answer mentions, the partition layout itself is unimportant and contains no sensitive data. They contain essentially nothing other than the bare minimum of information required to split a disk up into multiple partitions. You can see exactly what is stored for both MBR and GPT tables:

https://en.wikipedia.org/wiki/Master_boot_record#PTE
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_table_header_(LBA_1)


Can HTTPS server configured without a server certificate?

HTTPS is HTTP-within-SSL. SSL is a tunnel protocol: it works over an existing bidirectional stream for data, and provides a bidirectional stream for data. The two parties involved in SSL are the client and the server, which are two roles within the SSL protocol; it is not required that these roles map to the notions of "client" and "server" of the underlying transport protocol.

For instance, a setup can be imagined, in which the client system (C) initiates a TCP connection to the server (S), and then the server initiates a SSL handshake, acting as the SSL client (i.e. sending the ClientHello message, instead of waiting for an incoming ClientHello). This reverses the roles of both machines, and also the security guarantees: the machine S will have a good idea of the identity of the connected client C, but the client C will not be sure of what server S it is talking to (an attacker could have intercepted and redirected the communication). Depending on the context, this may or may not be appropriate.

However, this departs from HTTPS, in which the TCP client is also the SSL client, and that client expects the server to show a certificate, which the client will validate against its known, trusted CA, and which contains the expected server name (as extracted from the URL, see section 3.1). Correspondingly, existing clients (Web browser) do not support reversal of SSL roles. If your situation calls for using browsers, then you must, of course, use only the functionality available in browsers.

SSL does support a few certificate-less cipher suites. The "DH_anon" cipher suites are deemed weak, because they imply no authentication at all (thus, Man-in-the-Middle attacks are possible). The PSK cipher suites imply mutual authentication of both client and server with regards to a shared secret. When the shared secret is of low entropy (say, it is a password), SRP cipher suites are better.

There again, these cipher suites are not (yet) available in mainstream browsers (although some people are working on it). They require a shared secret (key or password), a condition which may or may not be easy to achieve in your specific context.

If knowledge of the server identity is unimportant, then you can give the server a self-signed certificate, along with instructions for clients on how to make their browser accept the server certificate without cringing too loudly (see this question as a starting point). This will map to "normal SSL", which has two benefits:

Existing browsers support that.
When the server presents a certificate, however bogus, it is then allowed to ask, in return, for a client certificate, yielding the kind of authentication that you are looking for. And Web browsers do support client certificates for SSL.

Note that the self-signed certificate contains the server public key. Though this public key won't be validated, it will still be used to power the key exchange, so you must use an appropriate key type and length (say, RSA 2048). Alternatively, use one of the "DHE" cipher suites, in which case the server public key is used only for signatures, not to actually protect the data, so (in your specific case), its size and secrecy becomes unimportant.


Overall, you will need to formulate a proper threat model before any question asking for risk analysis can be answered. If you are dealing with highly-sensitive material in an adversarial environment, you may want to only use specially-certified hardware in secure areas. If you are simply trying to avoid identity theft or your Gmail password being revealed, then avoiding shoulder surfing is your priority.

The primary issue with nearby attackers who are not in physical contact with the device is insecure short-range wireless protocols, such as Bluetooth or poorly-secured WiFi. An attacker cannot exploit a wireless chipset or perform a MITM attack against a local wireless network without being relatively close (often within several hundred meters, sometimes less). This issue can be mitigated by using secure wireless protocols and strong passwords.

Another issue which is typically only relevant to sophisticated attackers is that of compromising emanations. Every electrical action performed in a device results in electromagnetic radiation. Depending on the operations, these emanations can be used to reconstruct the operations themselves. This is a problem when processing cryptographic key material. This subject is very broad and is typically put under the realm of EMSEC, or Emission Security. The capabilities of an attacker range from being able to recover keystrokes from a few dozen meters away to being able to recover key material during cryptographic operations. Note that these attacks are not limited to EM radiation. Audio released as capacitors are charged and discharged can give away a surprising amount of information about a system's internal state and ongoing operations.


what is worth a digital signature based on email address only?

This is essentially the same issue with Domain Validated SSL certificate. A domain validated certificate or email identity certificate asserts that you're talking to a system/someone authorized to use the domain/email address but doesn't tie the address with any real world identity.

A DV or email address only certificate cannot be used to verify whether the owner of the address is a decent person to do whatever business you want to do with them or that the person/entity behind the certificate is who you think they are. You're still left to yourself to determine whether the email address you've got is the correct email address of the person you want to communicate with.

The worth of email certificate is that it simplifies verification of the certificate because part of the checking process had already been done by the certificate authority. The certificate authority has checked that the certificate belongs to the authorized owner of the email address. So all you need to do is to check that the certificate belongs to the person in front of you.

If you meet someone you trust in person and he tells you his email address and where to get his certificate, you can verify that the certificate can be used to send email to the owner of that address without them having to read out the certificate fingerprint in person (as would be necessary with GPG if you don't already have a connection through web of trust).

There are several problems here. If you don't trust the person, then you don't have any reason to trust their assertion that the email address really belongs to them. However you can still be sure that if the person doesn't actual own the email address, he won't be able to receive any emails sent to that address or send any signed email from that address, as he presumably don't have the private key corresponding to that email address, and the certificate authority wouldn't have issued it to him.

If you don't trust the person's assertion of his email address, you can simply send an email to the address with a secret word and if he can read the secret word to you in person, you can be sure that the person standing in front of you had the private key corresponding to the certificate.


GCM is recommended; it is even approved by NIST. However, AEAD ciphers are supported in TLS only since TLS 1.2; see section 6.2.3.3, which is new, when compared to TLS 1.1. The actual GCM-able cipher suites are defined in RFC 5288. Note that TLS 1.2 (and, for that matter, TLS 1.1 too) is immune to BEAST-like attacks when using CBC.

Therefore you will have a hard time finding a Web browser which supports GCM right now (I write these lines in January 2013; hopefully, TLS 1.2+GCM support will become widespread at some point in time). It is still fine to enable it, and if the client supports it, so much the better; GCM will be most lightweight on recent x86 processors with the AES-NI opcodes (these opcodes have been designed specially for GCM, in particular PCLMULQDQ which implements multiplications in GF(2)[X]). Not that the CPU cost of traditional TLS cipher suites is that high, but it is intellectually pleasing to know that each server core could support 5 Gbit/s bandwidth.

But if you want existing browsers to actually, say, browse your server, then you will need to allow for more "primitive" cipher suites as well, if only as a fallback.


Impacts if I assemble many documents in one signature?

Do you want the ability to prove (in court) that Signer A really did sign the collection of documents at some point in time, and that the current version of the documents is the exact same as what were signed?

It sounds like it. Eg you talk about non-reputability.

But if the above is the case, then you need to be very careful about how the signature validation would work in practice. If your software is the only software available to verify the signature against the documents, then you are not in a good place since the opposing party can claim that your software is faulty.

The above is why it is a good idea to ensure that your signed documents can be verified by a neutral third party's sw (eg Adobe Reader for PDFs), MS Word for signed Word files, etc.

A signed XML file that includes multiple documents as sub elements sounds like a poor plan to me if you want to prove the signature(s) in court.

The "easy" issue is to ensure that the current documents can be exactly re-assembled for verification as someone commented.

The hard issue is show the verification process in a very easy and understandable way to a completely non-technical person in court.

If you're just signing the XML as an internal control/audit mechanism, then your idea is fine. But if any of the signers are potentially hostile adversaries (or if someone might try to forge their signatures), then I suggest using very straight forward signing techniques whose signatures can be easily verified with PDF Reader or similar.

If what you want is signed data structures (eg an XML file), you should either verify with commercial off the shelf software, or make a PDF copy of the data and get both the XML and PDF files signed.


How to enumerate PGP keyring e-mails related to a specific ccTLD

A keyserver can't let users query something that will return arbitrarily large amounts of data. If this were possible it would make them extremely vulnerable to Denial of Service.
If you want to find all keys containing emails in a certain domain, you'll have to download the SKS keydumps (for example, from here) and trawl through them.
The keydumps total around 11 GB, so this is no small project.


Can my PC get infected by a shared USB drive?

Simply inserting a genuine flashdrive (as opposed to an attack device that mimics the appearance of a flashdrive) shouldn't ever be a risk. Similarly, browsing the files on a flashdrive, copying them to your local machine (as long as you don't put them somewhere where other programs will expect to find a trusted file), or writing to the flashdrive should always be safe. However, files on the flashdrive should be considered untrusted if somebody else has accessed the device; for example, if there was an executable on the drive its contents could have been replaced with a malicious file but the name, size, timestamp, and other metadata have remained the same. If that happened, running that executable would of course compromise your system. Opening non-executable files from an untrusted flashdrive could also be a risk, depending on how secure the program that opens them is and how much it trusts the files.

Now, with that said, there has been malware that spread by flashdrive before, but only on old or unpatched operating systems. Earlier versions of Windows could be configured to automatically run a program on a flashdrive or CD-ROM, but that no longer happens by default. Security vulnerabilities in how Windows Explorer generated icons when browsing a directory were used to infect computers from flashdrives in at least one notable case (Stuxnet), but that bug was patched long ago. It is not impossible that some other vulnerability may have been discovered, but so long as your machine is running an up-to-date OS and file browser, and you don't open any untrusted files, you should be fine.


There may be some potential for a CSRF attack, where an attacker maliciously saves a key value pair on behalf of your users.  Then the executable JS in the key value pair might be able to be used for a run of the mill XSS attack to steal their cookies and potentially allow the attacker access to the application as the victim.

I agree with Jimmy's comment.  If there's any possibility to properly scrub the user input, that would definitely be my first priority.


... but they used their own infrastructure

It's not really their own infrastructure what they use. They use instead botnets consisting of  hijacked systems. These are systems which they p0wn but definitely not own. And thus it is very cheap for them.

Apart from that any VPS provider who would rent their VPS for DDoS attacks would quickly lose reputation and thus proper customers. And if a VPS provider then specializes on providing VPS for DDoS attacks to make up for the loss of normal customers it would be more easy to block such DDoS because they all origin from the same networks, i.e. simply cut off this provider from having access to major networks.


Retrieving CSRF token cross-domain using JSONP, risky?

In this case, I'm using it for a set of login/registration forms, so there's no information leakage

The existence of a getCSRFToken JSONP API with no other limitation on caller site is effectively a complete bypass for all CSRF protection.

If you think that is not a problem, you should just get rid of the CSRF protection system instead, as it is doing nothing for you.

If you have other forms that should still be protected, then you'd want to remove the protection from the login/registration forms.

If you do need CSRF protection on your login forms you will need to establish a cross-domain session. If site A and site B are on the same server this isn't too bad as you can create a token on one that is readable from the other. If they are separate then you have federated sessions which is a lot more work.

  all they'd be able to do is allow the user to log in, right?

That may be a problem based on how your application works. What would be the upshot if, in the middle of using your application, a user could be silently switched from one account to another by a hostile site in another tab?

If, for example, the user doesn't notice their account has changed and enters sensitive information to be stored on an account that isn't theirs but an attacker's, that could be quite bad.


I think the greatest threat could be Denial of service, you could send so many e-mails you could saturate your SMTP server, your mail server and your user´s personal inbox.


The information you're talking about (UID, GID, timestamp, et.c) is stored in the file's inode. In UNIX systems, the inode is created whenever a file is created and it stores meta information about the file. When copying a file from system A to system B, a new file is created at B, thus a new inode is created for it. This inode now contains information about the file at system B, not about the file at system A. Both inodes can be completely different, depending under what user FTP was running, when it was uploaded, etc.

However, the file itself could contain sensitive information (like David Tonhofer mentioned), so make sure there's nothing like that.


Is it a vulnerability to display exception messages in an error page?

In some cases, error messages induce vulnerabilities. In the area of cryptography, the padding oracle attack can recover a secret key by sending altered encrypted messages, and using an "oracle" which distinguishes between two kinds of failure ("padding was wrong" vs "there was a valid padding, but the resulting data was gibberish"). Detailed error messages have a strong potential for being such an oracle. In a more general, conceptual view, attackers will try to uncover weaknesses by prodding at the system and observing what happens, and more data can only help them. The exception message is not qualitatively distinct from the stack trace, in that respect; so if the stack trace is an "obvious" vulnerability, so must be the exception message too.


Copy SSH Public Key from Windows to Ubuntu

Any ideas on what to do?

1. EDIT Download cmder or use your favorite console emulator. Move your public key (id_rsa.pub) and your private key (id_rsa) to C:\Users\yourUserName\.ssh\ create the .ssh folder if needed.

2. On your windows host via cmder:

cp C:\Users\yourUserName\.ssh\id_rsa.pub C:\Users\yourUserName\authorized_keys

3. On your ubuntu host:

service ssh status Start sshd if necessary

mkdir ~/.ssh/ (if it doesn't already exist)

4. On your Windows host via cmder:

cd C:\Users\yourUserName\

scp authorized_keys login-id@ubuntu-Host-Ip:~/.ssh

5. On your Ubuntu host:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

6. On your Windows host via cmder:

Test if you can ssh into your ubuntu host without login/pw auth. If yes:

rm C:\Users\yourUserName\authorized_keys

(you might encounter difficulties running your ssh-agent on windows, write a comment if so)


Why to place an email as image or replacing "name@email.com" with "name at email dot com"

It's not to be the perfect security, just make spamming harder.

Spammers will have to scrap lots and lots of pages to create a database of email addresses. It's cheaper to get the text, search for a pattern like name@email.com and add to the database than to search for name at server.com, or name at server dot com, or name at server . com, and other variations, parse all, validate all and add to the database.

So the point is to not be the lower hanging fruit. You could use a javascript that needs to solve a captcha, an equation, then asks for clicking on a happy cat to show the email, but if a spammer really wants your email, he will create a bot (or use Amazon Mechanical Turk) to "solve" your riddles.


Should all web applications implement a security feature that stores historical passwords?

To answer your questions:

  Should all web applications implement such a security feature?

This is just another good security feature to help the user so if the application can afford (resources not financially) to have this implanted in their system there is no reason not to.

  Is it desirable that companies store our historical passwords?

Since most users in our days do not understand the importance of not having the same password added with a 123 when changing the password, this is important to force them to change the password to something different so increase security.

  How long are you allowed to store/archive such information or how many recently used passwords are allowed or recommended to store?

Forever. Why do I say this?

If an attacker wants to hack a specific user he will be looking for OSint about the user all over the place and he might even try a password that was used years back by the same user. And since users tend to use the same passwords over and over again this is not good.


How can one secure Exchange 2010 cookies?

A cookie that has the secure attribute set will only be sent over an HTTPS connection, so if the client in future attempts to connect to the server over unencrypted HTTP, the cookie will not be sent with the request, and will not, therefore, be exposed to theft.

As to how to ensure your specific cookie is marked as secure, you will have to consult with the application owners or documentation in order to ascertain what steps you will need to take.


CRIME - How to beat the BEAST successor?

This attack is supposed to be presented 10 days from now, but my guess is that they use compression.

SSL/TLS optionally supports data compression. In the ClientHello message, the client states the list of compression algorithms that it knows of, and the server responds, in the ServerHello, with the compression algorithm that will be used. Compression algorithms are specified by one-byte identifiers, and TLS 1.2 (RFC 5246) defines only the null compression method (i.e. no compression at all). Other documents specify compression methods, in particular RFC 3749 which defines compression method 1, based on DEFLATE, the LZ77-derivative which is at the core of the GZip format and also modern Zip archives. When compression is used, it is applied on all the transferred data, as a long stream. In particular, when used with HTTPS, compression is applied on all the successive HTTP requests in the stream, header included. DEFLATE works by locating repeated subsequences of bytes.

Suppose that the attacker uses some JavaScript code which can send arbitrary requests to a target site (e.g. a bank) and runs on the attacked machine; the browser will send these requests with the user's cookie for that bank -- the cookie value that the attacker is after. Also, let's suppose that the attacker can observe the traffic between the user's machine and the bank (plausibly, the attacker has access to the same LAN of Wi-Fi hotspot than the victim; or he has hijacked a router somewhere on the path, possibly close to the bank server).

For this example, we suppose that the cookie in each HTTP request looks like this:

  Cookie: secret=7xc89f+94/wa

The attacker knows the Cookie: secret= part and wishes to obtain the secret value. So he instructs his JavaScript code to issue a request containing in the body the sequence Cookie: secret=0. The HTTP request will look like this:

POST / HTTP/1.1
Host: thebankserver.com
(...)
Cookie: secret=7xc89f+94/wa
(...)

Cookie: secret=0

When DEFLATE sees that, it will recognize the repeated Cookie: secret= sequence and represent the second instance with a very short token (one which states "previous sequence has length 15 and was located n bytes in the past); DEFLATE will have to emit an extra token for the '0'.

The request goes to the server. From the outside, the eavesdropping part of the attacker sees an opaque blob (SSL encrypts the data) but he can see the blob length (with byte granularity when the connection uses RC4; with block ciphers there is a bit of padding, but the attacker can adjust the contents of his requests so that he may phase with block boundaries, so, in practice, the attacker can know the length of the compressed request).

Now, the attacker tries again, with Cookie: secret=1 in the request body. Then, Cookie: secret=2, and so on. All these requests will compress to the same size (almost -- there are subtleties with Huffman codes as used in DEFLATE), except the one which contains Cookie: secret=7, which compresses better (16 bytes of repeated subsequence instead of 15), and thus will be shorter. The attacker sees that. Therefore, in a few dozen requests, the attacker has guessed the first byte of the secret value.

He then just has to repeat the process (Cookie: secret=70, Cookie: secret=71, and so on) and obtain, byte by byte, the complete secret.

What I describe above is what I thought of when I read the article, which talks about "information leak" from an "optional feature". I cannot know for sure that what will be published as the CRIME attack is really based upon compression. However, I do not see how the attack on compression cannot work. Therefore, regardless of whether CRIME turns out to abuse compression or be something completely different, you should turn off compression support from your client (or your server).

Note that I am talking about compression at the SSL level. HTTP also includes optional compression, but this one applies only to the body of the requests and responses, not the header, and thus does not cover the Cookie: header line. HTTP-level compression is fine.

(It is a shame to have to remove SSL compression, because it is very useful to lower bandwidth requirements, especially when a site contains many small pictures or is Ajax-heavy with many small requests, all beginning with extremely similar versions of a mammoth HTTP header. It would be better if the security model of JavaScript was fixed to prevent malicious code from sending arbitrary requests to a bank server; I am not sure it is easy, though.)

Edit 2012/09/12: The attack above can be optimized a bit by doing a dichotomy. Imagine that the secret value is in Base64, i.e. there are 64 possible values for each unknown character. The attacker can make a request containing 32 copies of Cookie: secret=X (for 32 variants of the X character). If one of them matches the actual cookie, the total compressed length with be shorter than otherwise. Once the attacker knows which half of his alphabet the unknown byte is part of, he can try again with a 16/16 split, and so on. In 6 requests, this homes in the unknown byte value (because 26 = 64). If the secret value is in hexadecimal, the 6 requests become 4 requests (24 = 16). Dichotomy explains this recent twit of Juliano Rizzo.

Edit 2012/09/13: IT IS CONFIRMED. The CRIME attack abuses compression, in a way similar to what is explained above. The actual "body" in which the attacker inserts presumed copies of the cookie can actually be the path in a simple request which can be triggered by a most basic <img> tag; no need for fancy exploits of the same-origin-policy.


Signal messaging app / How does sync on connected devices work?

Signal Multi-device Support
Each linked device in multi-device treats each other as a different recipient. Encrypted messages are kept on server until they are received by the recipients. For each linked device, the server holds a queue of 1000 most recent undelivered messages so the device has to come online often enough to prevent overflowing of queue. The server also deletes undelivered messages that are older than 60 days even if the queue is not full.
Linked devices cannot sync chat history in order to prevent compromise of earlier messages that were received before the devices were linked. They start from fresh and their e2ee session is also separate. The only things they have in common is UserId and Identity keypair.
When you send or receive message, the message is replicated by the sender for all of your linked devices. It behaves like group messaging but messages for the linked devices are sent to self.


AD-DS: Why Hide the last logged on user?

If you have no credentials or physical access, getting valid user IDs (for example at the logon screen through an RDP session) is a step forward in gaining access to the machine. Some of the users might have weak passwords which are easy to guess or brute-force. Missing the info about which users are valid makes these attempts much harder. You could also gather valuable insights about which individuals work at certain computers, and thereby determine which people might be interesting targets for social hacking attempts.

As you said, if you already have access to the box through proper credentials or physically, it doesn't help at all. But in a scenario where you don't, it certainly makes sense.


Predicting the Entropy of the entire Password Database

I have the impression this is an invalid line of questioning the problem.

Rule C * number of people does not define the entropy, the algorithm used for encrypting the password does. Unless the passwords are kept in clear text the password database as such will only show entropy against the algorithm.


What's the best web application security program to learn XSS?

OWASP's security shepherd is really good for learning, and you can configure it to only show challenges for specific types of vulnerabilities if XSS is all you're focusing on right now. You can download a VM here and get it up and running in less than 10 minutes. If you're looking for less structure, there's BeeBox, which has pages where you can play around with vulnerabilities at different difficulty levels. That can be downloaded here.


How do I prevent copying of my PDF files?

As far as I know there is no feature like that in Adobe Reader. But even when there were such a feature, it couldn't be effective.

PDF is an open format, so they could just use another PDF-capable program to view it which doesn't support this feature
They could create a copy of the file before opening it. Adobe Reader couldn't know about that second copy, so it wouldn't be able to encrypt it too.
They could make the file write-protected which means that it can't be encrypted after opening it
They could log the generated print-job in the printer spool of the operating system
They could use a custom printer driver which outputs each printed document to a file
The printer itself could cache the print-job (likely it does by default - professional printers often come with quite large hard drives)

Bottom line: When you want to print a sensitive document, either find a copyshop you trust or print it yourself.


Why would Chrome not display a padlock icon at all on an SSL site?

Your certificate only contains a sha1 signature, probably with a lifetime past 1 January 2017.

These are deprecated, and Chrome therefore removes the appearance of security. See https://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html for more info.


Is it secure: unsecured Wi-Fi + social network authentication to access the web?

One of the points of social media login is to avoid password entry by resuing your existing loggged-in state with the social media.

If you have not already logged in to the social media site in your browser, simply do that over mobile connection and then connect to this wifi.

Some social media may want to verify your password before you can approve an association, but they will almost always pre-fill the username and may even display your profile picture. This is currently not possible with normal phishing. And as always, check HTTPS and the domain in the address bar before entering the password.


Google+ Sign In - One Time Code Flow vs Pure Server Side flow

It seems like the only security advantage is that if using one-time code flow, browser component and server component of the client each get their own token. In pure server side flow, only server gets the token and web application flow only client gets the token. Sending token from client to server, and vice versa, exposes end user to a certain risk. Using one-time code flow there is no sending token from client <--> server and the risk of tokens being compromised is less.


Is using the same RSA key pair for both (signing and encryption) & (signing and encryption) a bad idea?

There's no technical or cryptography-based reason why you wouldn't want to use the same key for both. The only reasons why are:

it limits the exposure of your keys -- i.e. you don't have to have the same key available to the people who perform what may be separate tasks
ancillary legal reasons -- there might be legal requirements around electronic signatures in your country
damage control in the case of compromise -- i.e. if your private key gets out, then the less that key is useful for the fewer problems it will cause


Diffie-Hellman is not stronger than the Discrete Logarithm problem in the multiplicative subgroup of integers modulo a prime p. A larger prime p makes DL harder. Current record (in academic circles) is for a 530-bit prime modulus. Though it took quite some computational effort, the lesson is that 512-bit DH is breakable with existing technology. An attacker observing your traffic could thus (at a price) break through the key exchange mechanism, recover the session key, and decrypt your data. Also, DL-breaking algorithms tend to be cumulative, i.e. breaking ulterior sessions with the same modulus would be easier.

Current recommendations from various bodies (including NIST) call for a 2048-bit modulus for DH. Known DH-breaking algorithms would have a cost so ludicrously high that they could not be run to completion with known Earth-based technology. See this site for pointers on that subject.

You don't want to overdo the size because the computational usage cost rises relatively sharply with prime size (somewhere between quadratic and cubic, depending on some implementation details) but a 2048-bit DH ought to be fine (a basic low-end PC can do several hundreds of 2048-bit DH per second).


Difference between DNS flood attack and DNS amplifier attack

DNS Flood

  A type of Distributed Denial of Service (DDoS) attack in
  which the attacker targets one or more Domain Name System (DNS)
  servers belonging to a given zone, attempting to hamper resolution of
  resource records of that zone and its sub-zones.
  Incapsula

 DNS Flood

DNS Amplification attack

  In a DNS amplification attack, a large number of DNS request are sent
  with a spoofed from-IP-address to one or more DNS servers. Depending
  on configuration, these DNS servers will send a response back to the
  IP address that the request appeared to originate from.
  SimpleDNS.

 DNS Amplification DDoS Attack

Although, US Cert and CloudFlare both have good definitions I felt they lacked simplification. However, I have included them as citation because they include technical workings.

DNS flood attacks use the high bandwidth connections of botnets to directly overwhelm the DNS servers via DDoS attack. The volume of requests from the botnet devices overwhelms the DNS provider’s services and prevents legitimate users from accessing the provider's DNS servers.

DNS flood attacks differ from DNS amplification attacks. Unlike DNS floods, DNS amplification attacks reflect and amplify traffic off unsecured DNS servers in order to hide the origin of the attack and increase its effectiveness. DNS amplification attacks can use devices with smaller bandwidth connections to make numerous requests to unsecured DNS servers. The devices make many small requests for very large DNS records, but when making the requests, the attacker forges the return address to be that of the intended victim. The amplification allows the attacker to take out larger targets with only limited attack resources. Although DNS amplification is not reserved for low bandwidth, it is the ideal attack method if high bandwidth is not available.


pcap files for simulated attacks on SCADA systems?

If you want pcaps from scada traffic you can go to http://www.netresec.com/?page=PCAP4SICS. On the other hand, if you want to simulate a specific attack probably the best option is to use scapy to generate the (modbus, mqtt, coap or whatever) traffic yourself.


How to send authentication token via SMS for a REST API

By storing the token in the database and sending the (encrypted) id of it to client you've just created new token. Forget about JWT tokens, you new token is the encrypted integer ID in the database.

You shouldn't use ID as the new token: IDs are usually incremented (and therefore predictable), and in some encryption schemes flipping the bit in cyphertext flips it after decryption in plaintext, so attacker can increment the ID without being able to read its plaintext. You can skip the whole encryption step and just use a (cryptographically secure) random number. Better yet - use longest acceptable string of random characters that are valid to transmit in SMS.

Encryption is a bijection between plaintexts and ciphertexts, so encrypting a random number doesn't make it harder to guess. Also encryption can't check that cyphertext wasn't modified before decryption unless you've added MAC to the protocol, but MAC would be too long for your case.

Also you shouldn't rely on the sender's phone number to identify the sender (or on confidentiality of SMS), SS7 is pretty vulnerable to eavesdropping and impersonation attacks. However everyone acts like it's secure for some reason...


Does revealing two factor codes reduce security?

No. Thats the whole point of TOTP/HOTP. That it should be infeasible, given any sequence of valid codes, to generate future codes or recreate the seed.

The reason is that the TOTP/HOTP algoritm, use HMAC-SHA1 as hash, given the "challenge" (either current UNIX time or a counter of usages) and the secret "seed" as key. The resulting hash output is then truncated according to a very specific rule.

This would mean, in your first case, it would be impossible to do, as multiple valid keys will come up with the "correct" 6-digit code but will turn out to be incorrect as future codes from these "valid keys" will be invalid.

To successfully mount a bruteforce attack against a seed, you would atleast need 2 valid auth codes, possible more, and even in that case, its infeasible (eg, practically impossible) to do it.


What is the serious security flaw with this authentication protocol?

This is vulnerable to a MITM.  All Eve has to do is sit in the middle and forward traffic from C1 to S1, and from S1 to C1.  This entire handshake could occur, and Eve could still be communicating with S1.


Dealing with a vulnerability outside the scope of penetration test

It is not possible to answer this completely without knowing a lot more detail.

However, in general, the first thing I'd want to know is how good a relationship you have with the client. By the sound of the restrictions placed on you, I'm guessing not so good which limits your options. The "best" thing would be to talk to the client as soon as you come across something. But as the likes of Snowden and others have discovered, this is not always a wise move.

Ultimately, this comes down to your contract. Any pen-test contract should have clauses that cover you for situations where vulnerabilities outside scope are discovered as a consequence of your in-scope work.

However, to deal with contract and legal complexities, you must consult a suitably knowledgeable legal expert. If you are a member of a trade group, they may also be able to assist. This forum obviously cannot give legal advice even if anyone here wanted to.


Way of categorising and organising types of security issues and areas

NIST has two documents which cover Information Security categorisations and subcategories.

The CyberSecurity Framework (NIST CSF - see https://www.nist.gov/cyberframework) is the more simple of the two but certainly provides what you're looking for at a high level. The main categories are Identify, Protect, Detect, Respond, Recover and each of these has some subcategorisation. The CSF covers just over 100 items which makes it very approachable.

The other document is Security and Privacy Controls for Federal Information Systems and Organizations (see http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf). Security controls are enumerated in Appendix F.

Where you have findings which don't fit with the above categorisations, you can create your own miscellaneous section. However, by adhering to NIST, at least you're presenting findings using a recognised industry framework which can be used for various clients and ensure you're speaking a standardised language.


In CitizenFour, what was Edward Snowden mitigating with a head blanket?

The Background

The general situation was Snowden entering his password at that time, and he wanted to mitigate visual surveillance, let it be by observation or (hidden) cameras. It seems, Snowden didn't trust anything but his own laptop (if at all) during these first day(s) of contact with the journalists.

He also offered the blanket to the others in the room when they were entering their credentials into their laptops, but they refused, probably regarding this as being overcautious.

The Exact Scene

(Original footage from Citizenfour by Laura Poitras)

  37:35 [Snowden pulling blanket over his head/laptop]
  37:44 Greenwald: Is that about the posibility of...
  37:47 Snowden [still under blanket, interrupts] visual, yeah visual collection
  37:50 [Greenwald looking around the room, seems not rather sure what to think and say]
  37:55 Greenwald: I don't think at this point there is anything in this regard that will shock us. [laughter in room]

Some general chit-chat about never leaving devices alone any more follows.


How can I store information securely when I can't use crypt or a hash?

Have the client application send an encryption key that was randomly generated during the initial authentication process. Depending on how often you want the user to login, the key could be generated for single session or globally for the client device.

For the server application hold two copies of the authentication tokens - the first copy is encrypted by client key for persistence, the second is unencrypted but transient in the server memory. The second transient copy is deleted after the client hasn't be heard of in a while or has logged out/uninstalled.

This way a hacker with client device access doesn't have the OAuth tokens and can only abuse your specific service. A hacker with server access doesn't have decryption key and hence the OAuth tokens are useless.

However a hacker could simply alter the server application to harvest future OAuth tokens. So the web server should prohibit hot-swapping application deployments without reboot and require a console-supplied password for the server SSL certificate on boot - which the client application explicitly checks instead of the standard catch-all CA trust store.


Can an application modify files that are in a password protected folder?

Yes, absolutely, a malicious application could easily modify the files placed in a directory “protected” like this. The reason for this is that the method outlined in the article, doesn’t provide any protection whatsoever. All that’s happening here, is that when you ‘protect’ the folder, you set a marker that prevents windows from showing the files (it sets the ‘system’ and ‘hidden’ attributes). After you enter the correct password, this 'marker' is removed again.

This gives the illusion of protection because by default windows is set up so that ‘hidden’ and ‘system’ files are not shown to the user.

However, in fact your files are not protected at all – they remain accessible all along. Applications completely ignore the system & hidden setting. Users can enable "show hidden files" and disable "hide protected operating system files" to make the files appear again. Once this is done, they can use the files at will, completely bypassing the password protection in literally a few clicks.

Properly password protecting files without additional software so that no one (whether human or application) can access/modify them (without the correct password) is a feature that Windows simply doesn’t have, so the only way to actually password protect your files is to use additional software. If you are looking for an easy-to-use solution, I would suggest Safeplicity (https://www.safeplicity.com), but I am biased, so don’t take my word for it and be sure to check out some alternatives. If you’re looking for a free open-source solution, VeraCrypt is probably the best.

One last word of caution: when choosing the software, make sure that it not only password protects your files, but also encrypts them. Password protection without encryption (like the one suggested in the article) can be bypassed by any computer-savvy person (or well written app) with ease – we have seen many lives ruined because of this. Password protection with encryption cannot be broken by anyone (unless you believe in conspiracy theories).


How did this email list a fake recipient?

When mail is sent via SMTP, there are two separate places this sort of information goes, the Envelope (things that are set with SMTP commands) and the Header (the first block of text under the SMTP Data command, ending with a blank line).  So, for example, here is an SMTP transaction where the Envelope disagrees with the Headers.  The message will get delivered per the Envelope, but the recipient will see the headers.

mail from: <evil@evil.com>
250 2.1.0 Ok
rcpt to: <victim@example.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
From: "Apple Store" <apple@apple.com>
To: orders@apple-store.com
Subject: We just received your purchase...

Mail body goes here.
.
250 2.0.0 Ok: queued as C5E251FFE2
quit
221 2.0.0 Bye
Connection closed by foreign host.

The fake recipient goes in the header "To:" line, but the mail is delivered according to the value set in the SMTP "RCPT TO" command.  And indeed, the recipient sees the Header that the attacker wanted them to see:

Now, there is some protection against this.  If you tell your mail client you want to view the full mail headers, you'll note that the mail server injected an several headers that tell the true story:

From evil@evil.com Fri Jul 27 14:45:21 2018
Return-Path: <evil@evil.com>
X-Original-To: victim@example.com
Delivered-To: victim@example.com

But, of course, mail clients always hide this level of detail by default, and interpreting headers correctly can be difficult.  The key to remember is that they are prepended by servers as they go along, so the ones that the top are put in by your server; if you see "Return-Path" at the bottom of the headers it's likely forged by the attacker to try and misdirect you...  Since the original message 'data' contains headers crafted by the sending client, they can put whatever they want in there before the servers start prepending.

As per how to do it -

The first rule of email recipient forgery is, expect it to fail miserably.

The second rule is, use Bcc: for the recipients you want to get it, and To: for recipients you want to be seen getting it.  This is the standard way of doing this with a mail client, and generally works with everything from mailx to gmail.

But mileage may vary unpredictably.  For example, if you leave To: blank, many mail servers will stuff the contents of Bcc: into To: to make up for it.  20 years ago I spammed thousands of "hidden recipients" with each other's addresses that way, sending out a contest update to the list of applicants.  OOPS.


Is this code vulnerable to dom based XSS?

The snippet that you pasted above is not vulnerable to the jQuery XSS vulnerability that you probably have in mind (Bug #9521) since it does not affect version 3.3.1. The jQuery selector bug was fixed in version 1.7.


It is not a Chrome popup; it is a MacOS X popup. Chrome delegates certificate management to the underlying OS. You get this popup only with Chrome on MacOS X (on Linux you will have the Gnome certificate viewer, on Windows the Windows certificate viewer).

The OS X certificate viewer shows the "Key Usages" which are defined in the "Key Usage extension" as specified in RFC 5280, section 4.2.1.3. This (optional) extension describe the usages for which the public key contained in the certificate may be used. OS X translates the combination of flags into a combination of "usage words" and there is not a 1-to-1 mapping. You get "Derive" when the keyAgreement key usage is specified (which is normal for a SSL server certificate with a RSA key); to get "Encrypt", you need either the dataEncipherment flag, or the combination of keyAgreement and keyEncipherment. keyEncipherment triggers "Wrap". You also get "Encrypt, Verify, Derive" if the key has type RSA and there is no Key Usage extension at all.


Is there a crypto system which detects decryption somewhere between sender and receiver?

No system currently exists that does what you need.  The reason is that detection of reading implies writing data somewhere.  All parties would need to adhere to this principle -- be it through goodwill or because they all use the same cryptographic program/protocol.

Think of this as read-receipts in Microsoft Outlook.  You can try to send an email from Outlook to a gmail account requesting a read receipt, but it will be completely ignored by the gmail receipient.1  However, depending on policies employed on the Exchange server/Outlook client, sending a read receipt request may or may not be guaranteed.  So the challenge that you require is to get everyone on the same platform.

Of course, Quantum Cryptography does have the effect you are looking for.  The effect here is that there is an unintentional information "write" operation occurring when you perform the read.  This characteristic is merely a physical way to capture read receipts without allowing someone to opt-out.

1The email header does, however, show the systems the email traversed before arriving at its destination. This is part of the protocol adherence though it doesn't actually need to be there.  That is, one hop in the network could opt to completely ignore this part of the protocol without any failure in later hops.


Server compromised for 2nd time, cannot locate source of attack

Some techniques for trying to find how your attacker got in:

Look at the timestamps on any files you know the attacker changed then look through all your logs for entries as close to each timestamp as possible.  As others have said, the web access logs and web error logs are the most likely to hold the evidence of the original attack vector but other log files may hold clues as well.  Error logs often hold the best clues.  The logs of all network-accessible daemons are also good places to look.
It may also be worthwhile looking for other files with timestamps close to the ones you know.  /etc/passwd is an obvious one but even log files can be suspicious if they have an unusual timestamp.  If logrotate runs at the same time every day and one of your log files has a timestamp that doesn't match this time, it was probably altered to cover his tracks, and now you know a little more about what he did.  Don't forget the .bash_history files in user's home directories.  the find command should be able to handle this for you.
Run scalp over your web access logs.  The original attack may have happened some time before the files appeared.  Scalp will produce false positives but it should narrow down the potential suspect log entries for you to manually analyse for irregularities.  It may also miss the attack entirely - it's not perfect - but it may help.

Don't spend too much time on forensics in the compromised system.  As others have noted, the attacker has had the opportunity to remove all evidence of the original attack and to add a rootkit to hide his continued presence. If he has missed something or if he has not even tried, the above tasks may work but if he has hidden himself well then you would be just wasting valuable time.

If you fail to find the source of the attack, wipe and re-install the server in question but with some additions in order to catch him next time.

Ship your logs off to a different server using some variant of syslog.  (rsyslog and syslog-ng are the recommended choices)  Preferably, this server should do nothing but receive logs and should not share login keys or passwords with any other server.  The goal is to make sure your logs cannot be tampered with or deleted.
Add extra logging beyond the default.  Jeff already mentioned AppArmor and since you are using Ubuntu this will probably be the best choice.  Make sure its logs are sent to the logging box.
Install and turn on the audit daemon.  Make sure its logs are sent to the logging box.
Run an IDS such as Snort, PHP-IDS or mod_security. (or more than one, these tool don't all do exactly the same job)  Some hardware firewalls come with IDS/IPS modules.  Make sure the logs from the IDS are sent to the logging box.
Add a file integrity monitoring system such as AIDE or Tripwire.  Make sure the logs from these tools are sent to the logging box.
Monitor your logs.  Falling short of a commercial SIEM system, something like Splunk can be installed for free and can analyse a limited quantity of logs.  Set up rules to match what is normal for your servers and filter them out.  Whatever is left is worthy of closer inspection.

There is much more you can do if you have the time and the money, such as full network packet captures, but realistically this is about all a lone sysadmin can be expected to handle. If the attacker shows up again, you will be much more likely to find the attack vector and much more likely to detect him as soon as the attack is made.


What is the PCI requirement for tracking software installation on workstations?

I agree with Shane Andrie. Dev machines considered in PCI scope is quite scary. I'd rather look in to moving them out of scope irrespectively of logging requirements.

To answer your question: Yes, storing logs centrally is a PCI requirement. Please refer to requirement 10.5 (excl 10.5.5).

10.5.1 Limit viewing of audit trails to those with a job-related need.
10.5.2 Protect audit trail files from unauthorized modifications.
10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter.
10.5.4 Write logs for external-facing technologies onto a secure, centralized, internal log server or media device.


CIS hardening of alpine based docker container

The CIS Docker benchmark primarily relates to the configuration of the Docker engine instance that you're running.  There are some checks relating to running containers however

The area of the benchmark you want for this is Section 4. Container Images and Build File. Most of the recommendations in there would apply to your case of building an image, 4.5 might not as that's more a engine level setting.

what I would say is that many of the recommendations in that area (things like only installing required packages) can't really be checked automatically (as what's required varies for case to case) so it's more of a case of reviewing the Dockerfile and built image manually, for that sort of thing.


curiousguy is correct that Tor doesn't actually obfuscate the protocol other than HTTPS. Of note, however, is that Tor (using something like Tor Browser or Vidalia) does proxy DNS requests through Tor.

Some captive portals work only by redirecting default DNS to a login portal. If this is the case, the combination of encrypted communication and third-party DNS could subvert the captive portal. That said, changing DNS manually to something like 8.8.8.8 (Google public DNS) and browsing HTTPS pages, using a VPN, SSH tunnel, etc, would also subvert this portal.

Tor isn't doing anything on the protocol level to fool a captive portal, but it's certainly possible that when used in the way you describe that it could allow a way out of the walled garden.

  how would I prevent it when setting up a captive portal?

Most captive portals will not be vulnerable to this type of attack. All you need to do is successfully block all egress requests other than HTTP, which is forwarded to the portal login page; basically, nothing should get through the portal unless it's an authenticated client.


Some vendors sell systems that work like you describe. The biggest problem is lack of active cooperation from vendors; there is no reliable way to build a list of hashes of "allowed binaries" since:

What looks like "an application" from the user's point of view may be a collection of many executable files (to a large extent, that's what DLL are).
Any software update will break the hash values and require recomputing them. This is especially an issue with applications that auto-update automatically on a daily basis (as is typical of some modern Web browsers).
Some applications rely on on-the-fly generation of executable files, e.g. to optimize things with regards to the local hardware (I think Adobe Reader does that). Notice too that the .NET framework comes with a C# compiler (csc.exe) and  that compilation process can be invoked programmatically (this is what powers ASP.NET Web pages, and it is rather mainstream).

So, in practice, systems that work that way are coupled with a learning phase (where information is gathered about what files are executed by a given user on a "typical day"), explicit exceptions for corner cases, and a streamlined process by which the user may request addition of a given application to the whitelist.

Be warned that if you apply such a system, your users will hate you thoroughly, because they will feel it to be an intolerable intrusion in their private world. User hatred has its own cost, security-wise (security works much better when users are willingly collaborating), so this had better be counterbalanced by a net gain from the whitelist system.

Also, consider that malware is not necessarily a .exe or .dll file. Word macro virus are a well-known example.


Using last four digits of Social Security number as password

The risk is that anyone who guesses your password can now also find your full SSN.

The first three digits of your SSN are based on where you were born (public information), while the next two are based on when you were born (also public information).  This leaves only the final four digits as secret information.

In normal usage, this isn't a major problem: an employer or bank isn't going to let you hand in thousands of fake Social Security cards until you come up with one where the name and number match.  But with the system you describe, an attacker can sit in front of a terminal, patiently entering numbers until they succeed.


Encrypt Android app data and send to web service

Public / private keys seems the logical way to do, but you may not want to code from scratch.

Look at how TextSecure does it: https://github.com/WhisperSystems/TextSecure/

It does all the things that your app would (encrypt data / send to web service).

You should probably use the encryption libraries / code directly from their codebase although the license (GPLv3) may be restrictive depending on your use case.


Is it safe to store passwords in a Browser?

We are used to store passwords in Browsers for online login accounts. Where and how those passwords are saved and I hope it is encrypted ?

This depends on the specific password manager. Some might encrypt and some might rely on the systems security. Some might store passwords local only and some store it in the cloud in order to sync between different systems.

  Normally, the browser prompts for credentials (local) when we try to retrieve a password manually (eg : Chrome).

This also depends on the password manager. Some ask you if you want to fill in the data, some do it without asking. Some have a master password you need to enter while others do not.

  I have seen there are tools such as Poison Tap where it can exploit browser sessions in a locked machine. Can these tools enhanced to exploit saved web credentials in a Browser?

If the password is filled in automatically (i.e. without asking the user) it might be possible. How exactly depends on the site but with HTTP sites tools like PoisonTap might help. In this case it does not matter much if the system locked or not as long as the traffic can be intercepted and modified. When HTTPS is used it might be possible to do the same if there is an XSS exploit for the site.

  Generally how safe it is to save online credentials in a Browser?

It depends on the quality and behavior of the password managers and also on what the alternative would be. If the alternative is to use the same password for all sites because you cannot remember another one then most password managers probably provide a better security.

See also the paper Password Managers: Attacks and Defenses for deeper information.


What is the thought process behind, Endpoint protection is better than firewalls?

The answer to this question is not easy.  Holistic security is the only answer.  If you're going to be Internet-connected, you need both, plain and simple.  There are ways to minimize exposure but you need to understand threats and how they pertain to what's important on your network.

If you try to rely exclusively on endpoint protection, what about your devices that don't/can't have endpoint protection?  ...printers, cameras, phones, etc. are examples of devices that are commonly exploited in a network where you probably can't layer on endpoint protection.

Conversely, a firewall only protects you at the boundary.  Once an attacker is inside, they often have uninhibited access to the internal network and can then laterally move or escalate to effect whatever outcome they're after.

Each business needs to understand what's important for their company. An ecommerce site has their intellectual property (IP) out in front of the world.  So they leverage reverse proxies, firewalls, code reviews, as well as host-based protections.  A political organization where the users and their information are important would probably focus more heavily on email encryption, attachment sandboxing, disk encryption, AV/AM solutions, etc.

The real answer is that there is no one panacea for security.  It's all about evaluating risk and leveraging resources according to what's important to each organization.

My personal opinion is that architecture is the best answer:  for non-ecommerce companies, keep everything you can on a closed network that never touches the Internet and for those services that require it (email, web, etc.) that be accomplished in a thin/zero client, non-persistent OS that doesn't have access to the corp net.  Any files that need to traverse the Internet-to-closed-net boundary be done by IT staff via a very deliberate process (download, scan, compare hashes, sandbox, move to closed net).  This suggestion has its limits but considering the ratio of attacks and vulnerabilities originating from being connected to the Internet, cordoning it off as much as possible, in my opinion, is the best answer.


I was the one who wrote the comment you quoted.
Quick answer: A 0day is burned when the exploit is used too often or haphazardly, resulting in it being discovered and patched. Virtually every time a 0day is used, it risks being burned. Using a 0day more sparingly and cautiously can increase its shelf life. The idiom intends to compare a 0day to a non-renewable resource like combustible fuel that loses its value when used up.
This likely originates from the idiom burn your bridges:

To destroy one's path, connections, reputation, opportunities, etc., particularly intentionally.

What is a 0day?
A 0day is an exploitable vulnerability that is not publicly known. When a 0day is discovered, it can be turned into a working, "weaponized" exploit. Like all vulnerabilities, if it is discovered in public, it will usually be patched and fixed, making it so the exploit no longer works. Every time you use an exploit, you necessarily transmit valuable information to a system that you do not control (yet). If the system is being extensively monitored, the exploit technique may be discovered and with it, the necessarily knowledge to fix the vulnerability and roll out patches to all affected systems.
What does it mean to "burn" one?
I was the one who wrote the comment you are referencing. To "burn" a 0day is slang for using it either too often or using it in a high-risk situation where it is likely that it will be discovered because of its use. Like combustible fuel, once used up or "burned", a 0day will no longer hold the same value (both in monetary terms* and tactical terms). It stops being a 0day once it is no longer in private hands.
Friends may let you "borrow" a 0day to use yourself, under the condition that you do not burn it. This means they are telling you that you can use it, but they are trusting you to be very careful not to use it in a way that makes it likely that it will be found and fixed, depriving access to it.
Someone might decide to disclose the 0day suddenly in public. Especially when it's not done using coordinated disclosure, it's often called dropping a 0day, which will also burn the 0day. This is a bit uncommon but not unheard of. A few years ago on IRC, a guy joined and informed us of a remote code execution vulnerability in TeamViewer that involved sending malicious WinHelp files (which contain Visual Basic code) or something along those lines. Since the first place he disclosed that was in the middle of a general security-related IRC, he was burning a 0day by dropping it.
* 0days usually have literal monetary value. A 0day can range from a thousand dollars to upwards of a million, depending on a variety of factors such as exclusivity, applicability, reliability, specificity, conditional nature, etc.
How much are 0days worth?
Exploit brokers often buy or sell bugs with promises of exclusivity. For example, you can sell a bug under the condition that it is sold for the highest price to only one person, not to multiple people. That reduces the chance that it will be discovered, but it means you only get paid once. Alternatively, you could sell an exploit to as many people who want to buy it. You would have to sell it for a lower price because it will be burned very quickly, making its shelf life rather short. Obviously, when a 0day is burned, it is no longer nearly as useful since it will only work on outdated systems. The actual value depends on quite a few factors. They are worth more if they:

Work on a variety of systems.

Do not depend on a specific configuration.

Are reliable and work every time.

Are silent and do not leave traces in the logs.

Are sold to only one or a limited number of buyers.

Many contractors that deal in exploits will pay you the complete price in small sums over a period of time. If the 0day is discovered before you are paid in full, they will stop the payments. This behaves as disincentive to selling it to multiple contractors or using it frequently yourself. It essentially forces you to guarantee to them that it will remain a 0day, or you simply will not be paid in full.
Additionally, 0days are bought for more by government contractors than by random exploit brokers. You might be able to sell a complete Chrome exploit chain complete with sandbox bypass and local privilege escalation (LPE) for hundreds of thousands of dollars to Raytheon SI. The same exploit would net only a fraction of that price if you sell it to J. Random Broker on IRC. The reason is simply that corrupt governments want to be non-competitive and have ample money from tax payers to obtain exclusive vulnerabilities so they can drone strike journalists protect their nation.

How do 0days get burned?
There are many activities that can risk burning a 0day. A few examples:

Using an exploit that is unreliable and may create a coredump.

Using an exploit that is conditional and only works for some configurations.

Using an exploit that results in an event being logged.

Using an exploit against a sophisticated and paranoid target.

Simply using an exploit too often, increasing its exposure.

Giving it to or trading it with a friend who is not responsible with it.

I do not condone selling 0days to governments or government contractors.


DDos prevention systems behavior for corporate networks

"ok we got so many requests from this IP, lets ban it"

Yes, you are right. More than the ip addresses,  Cloudflare scan to see what resource they are requesting, what payload they are posting, how frequently they're making requests, etc.
So, to answer your question Cloudflare doesn't just blacklist an ip address of possible DOS, instead they apply a complex algorithm to determine if the sourcing address is a bot or legitimate user. But it is safe to agree that even thousands of requests from multiple internal systems to a (cloudflare) protected web application is easily handled without bottleneck due to their caching policy, updates the cache for your web app every hour.
Also understand that after implementing cloudflare or similar services to your Web-Application, the request for resources reaches your Web-Application only if the Cloudflare doesn't have it cached. By the time the 10th request is made , It is already cached in their data centers around the world and the next subsequent requests are distributed to close hop Cloudflare data centers from there onwards.
I urge you to read through this post in Cloudflare ( click HERE ) to understand the technical details.
I hope this gives u a gist of Cloudflare like service implementation. And these days a few hundred-thousand requests from a single ip-address is not treated as a threat but are only analyzed more for possibilities (as they are aware that it might be an intranet of systems requesting services from the same Web Application)