Is it safe storing revision history on production servers?

As I read this post, I'm shaking. Probably because I ate way too many carbs after avoiding them for a while, and I'm experiencing a bout of hypoglycemia... but probably because the idea of this genuinely terrifies me.

Remember, this is an Information Security site. Sometimes the answer you get isn't the answer you want.

You claim to be working for the government.
You're using your real name on this website. A little digging shows exactly who your employer is, among other things. Further digging, I'm able to find extra information on other things.
You're thinking of a potentially insecure setup, and this leads me to worry about the fact that you might be able to touch production servers in such a way, and checkout/import from PRODUCTION servers which may have been hit by malware previously.

You might be well-served by visiting a wikipedia article on Operational Security.

Why can this be a problem?

A production environment is usually front-facing, meaning that's what your customers/clients/users will see. Let's assume you have the following environments:

Development
Testing
Production

Checking out the code from production, which could've been modified in the event of a successfully exploited vulnerability - either in your web application(s), or your web server itself - and then debugging it locally, means that you may end up infecting your entire enterprise.

Your development team usually has access to a lot of critical things. Now that you're debugging it locally, you may be able to spread hidden malware across your entire infrastructure! Development, test, production, etc. From there, your attacker can do pretty much anything they want.

You need clear separation of concerns. Putting your repository onto your production server is just asking for trouble. If your production server gets hacked, you may be able to mitigate the damage if it's limited to just itself.

However, as soon as you let it break out of it's little closed environment, you could be in for a world of trouble. Keep in mind, attackers are looking for any tiny thing they can exploit. This is why I genuinely believe you should not put your SVN on your production server.

Example Pwnage Diagram

I made a crappy diagram in MS Paint to explain this better. Assume that once you debug, an infection occurs and starts propagating.


Web Application Firewall Rule Optimization

Well, the way I read the difference between those two regular expressions,

\bgetparentfolder\b

\bonmousedown\b\W*?\=

is that the first one is just matching the string "getparentfolder", while the  second one is matching the string "onmousedown" appended with anything but letters, digits, and underscores, lazily matching the previous item (the appended character) zero or more times. I believe this would match both ways of using the onmousedown javascript event:

In HTML:

<element onmousedown="SomeJavaScriptCode">

In JavaScript:

object.onmousedown="SomeJavaScriptCode"

This page from the ebook ModSecurity 2.5 mentions how onmousedown could be used in an XSS attack.

Oh, and as for the first of those regexes, "\bgetparentfolder\b", I don't find it in any Javascript or JScript references, but after Googling it, I can see that functions and methods of that name appear in a number of languages, like VBScript, for example.

So it is clear that the two rules are looking for very different implementations of the same class of attack (XSS). So I think it would not make sense to combine them into a single rule with a single, combined regex.


Is this "secure email" mechanism my bank wants me to use best practice?

You ask about best practice.
Best practice would be to have you use your normal account login on the normal website and select a "submit forms" option from there which takes you to an upload page for submitting your scans.
For your experience
The pre-arranged link via email method is slightly less secure, but the exploit window is narrow.
Assuming your bank's domain name is represented by xxxyyy.com using the domain name securemail.xxxyyy.com submission is good form.
the poor user experience on that domain is just poor UX, not inherently insecure.
But yeah. the over-all user experience (starting with the phone conversation) trains users to trust links in emails.  and this seems to have the potential to harm the bank, and its customers.


Generating debian SSH keys with Python (paramiko library)

cryptography.hazmat.primitives.asymmetric.ec.SECP256R1 does ECDSA on SECP256R1 (RFC 5480).  ssh_host_ed25519_key is based on Bernsteins's Curve25519.  They are different curves, so the keys are incompatible.  You can possibly try inserting the alternate curve to the generate function, but you should also keep in mind that you don't have to have every key type -- it just gives you more flexibility.


Limitations of TLS Inspection when using Diffie-Hellman

Both of your approaches essentially describe the same thing: There is some intermediary system which terminates TLS and you have essentially two TLS connections: one from this middlebox to the client and one from the middlebox to the server.

The only difference is that in your second scenario the middlebox has access to the certificate and private key of the server and thus can fully impersonate the server without changes to the client. While you don't describe the first case in more detail my guess is that in this case certificates gets created dynamically by the proxy and signed by a CA explicitly trusted by the client. This first case can be usually found at a firewall which should give a client access to many sites on the internet while the second case is used to protect a specific server (for example by using a web application firewall).

Since in both cases you have two separate and independent TLS connections there is nothing special with DH, i.e. both connections can use DH key exchange.

But, there is a third scenario where an intrusion detection system (IDS)
gets the traffic exchanged between client and server and should passively detect attacks against this server, i.e. without being the TLS endpoint. In this case there is only a single end-to-end TLS connection between client and server. And to decrypt the traffic for analysis the IDS needs traditionally have access to the private key server - but this works only with RSA key exchange. To make such passive analysis possible with DH the IDS would need to have access to the master secret of each new connection, i.e. somehow the server must provide the IDS with this information. And this is far more complex than just providing the IDS with the static private key of the certificate.


The common configuration of a HTTP proxy is to have a plain TCP connection to the proxy. This means HTTP only traffic will not be additionally encrypted, while HTTPS traffic stays encrypted (but not additionally encrypted). This provides a similar visibility to the ISP as without proxy, provided that the ISP uses deep traffic inspection (DPI) to analyze HTTP traffic. Given that the server name in most TLS handshakes (SNI extension) is not encrypted (i.e. no ESNI) this also means that the original target hosts can be seen from both HTTP and most HTTPS traffic, no matter if a HTTP proxy is used. Note that DPI is more expensive to employ than simple DNS based analysis and blocking though. This means that the ISP might not use DPI or might restrict DPI to some clients only, like to the client with suspiciously few DNS requests.
Some HTTP proxies though offer access by HTTPS instead of HTTP and this is supported by modern browsers. In this case all traffic between client and proxy will be encrypted, i.e. plain HTTP traffic and also HTTPS traffic (resulting in double encryption). Since this will also encrypt the original plain HTTP requests and original TLS handshakes, it will hide the original target host from deep packet inspection.


First off, you need to realize that you're asking for anonymity and confidentiality. Those don't always go together, and if you don't keep both goals in mind, you will wind up with confidentiality (which is what SSH, SSL, and OpenVPN are more designed for) but miss out on anonymity.

Second, you really need to read some documentation on whatever solution is recommended to you. Only you know your exact requirements, and this stuff isn't actually terribly difficult to figure out if you take the time to understand it. I'd hate to give you advice based on a paragraph of explanation when it sounds like there may be real consequences for you if things go badly.

With that said:

Look at Tor - https://www.torproject.org/ - to start with. There is a lot of documentation on the site about what it can and cannot do. There's also a lot of the principles of anonymity on the site that will be good background reading for you.

You could also look at anonymizing web proxies, like Anonymizer and Proxyfy (disclaimer: I haven't used either in years). Again, read about them.

Finally, realize that anonymity is difficult to ensure. If you use an anonymizing service whose servers are in a jurisdiction that cares about you (e.g., if you're American and you use an American proxy), the government can just go to the proxy with a subpena and a gag order and you'll never find out until it's too late. The jurisdiction question is more complex than I'm making it sound, too; you have to consider which countries would be willing to work with each other. That's not a straightforward topic.

There are some good wikipedia articles on the subject of anonymity, e.g. https://secure.wikimedia.org/wikipedia/en/wiki/Anonymizer, with linked references.

Finally, if you really do care about both anonymity and strong confidentiality, you probably need to combine anonymization techniques with a VPN of some sort, or with SSL if you're very careful. It's wise to expect anonymizing proxies, Tor, and the rest to be monitoring and even tampering with anything you do, so for anything important, I'd definitely use crypto. SSL is the most natural fit, but be very sure to validate certificates properly, since there are SSL-snooping proxies out there that play games with certificates.

If you're interested in rolling your own solution and you have enough cash, you could get virtual private servers in a few different, orthogonal jurisdictions - very carefully - and knit together an openvpn or SSH tunnel from end to end. Just remember that traffic from the last hop ("exit node") to the final destination is always going to be unencrypted and non-anonymous, in the sense that it can be traced directly back to the exit node (but no further if you're careful).

I'll repeat one more time - this isn't something you should just get advice on from a stackexchange post. If this is meaningful to you (and it sounds like you're concerned about meaningful consequences), you should spend the time it takes to get comfortable with the issues involved.


School installs something on my Mac in order to connect to the school network. Should I be concerned?

They have also installed a certificate to get rid of the annoying SSL errors that pop up when attempting to access a webpage.

This indicates that they're running an HTTPS man-in-the-middle proxy - any data you send over the network (including passwords, even if you've got the green padlock) can be read by your network admins, and often the proxy server will not verify the certificate provided by the remote server, so you may be in danger of getting MITMed by an attacker and not noticing. Similar to the recent Lenovo Superfish scandal, if you want to read more on why this is bad.

I wouldn't use the network for anything remotely private unless my traffic was going through an extra VPN, and I didn't have their certificate installed.

This is before you look into what the actual software package does:

inventory hundreds of objects, including Mac addresses, serial numbers, and purchasing information for each computer
Email notifications for administrators on restart
and backup actions
CMDB/syslog compliant

At least they don't claim it includes a keylogger...


How secure is HTTPS with weak ciphersuites?

RC4 is now not considered secure, there are documents that explicitly forbid its use in TLS: RFC7465.

You should not use RC4 currently.

post updated as obsolete information about crypto is dangerous

Obsolete information, as posted in 2012:

RC4 is secure, in fact, if you're not using TLS 1.2 then you should be using RC4 to protect against BEAST.

MD5 is insecure, but if it's used as a MAC function it's not yet broken

To their credit, if you have disabled MD5 hash, it will negotiate with SHA-1, in fact, if you disable RC4 it will negotiate AES: https://www.ssllabs.com/ssltest/analyze.html?d=mtgox%2ecom&s=72%2e52%2e5%2e67


If I write an nmap job into crontab from PHP code to run background, how can I get the status of the nmap cronjob?

I'm not sure if there is an easy way to do that, but if you output the nmap results to a text file, and you use the nmap -v parameter for more verbose output, you could search the output text file for the information you need.

Fore example, the first time the phrase "Scanning x hosts" appears, refers to the total number of hosts you are trying to scan. The second time "Scanning x hosts" appears refers to the total number of hosts that are up (if nmap is doing the default ARP ping scan). Then you could look for lines that start with "Completed SYN Stealth Scan against" (if you are doing a scan with default parameters) to see which and how many hosts were scanned. You could look for the line that starts with "Nmap done" in order to see if the scan has finished. The precondition to all this is that you always rewrite the output file when you do a new scan.


OpenVAS is not an application scanner. It is a vulnerability scanner. It is worth reading Greenbone's documentation on it here.

If your web application has a vulnerability that OpenVAS has in its database, and you scan the IP address and port that the web app is on, then yes, it should be found.

Greenbone also gives you the progress of scans by IP (but not by port, as far as I can remember)


What is it common to only say "username or password is incorrect" in case of login errors?

Because you would be giving the attacker information.

If you say "The username is incorrect" or "The password is incorrect" then the attacker knows that one is correct. So, for example, once they guess a username, they can now focus on guessing the password. Rather than 2 unknowns, you have reduced it to just 1 unknown.

Also, for a site where the username is your email, you can determine if people have an account there. If I go to a site and insert your email address and it says "The username is incorrect", then you don't have an account. If it says "The password is incorrect" then I know you have an account there. Now imagine the site is some form of pornography site and you can start to see why this could be a bad approach in terms of what you are revealing to an attacker.


Can I "hide" the private key, while still allowing it to be used?

You are focusing on securing the keys on the client side. I would recommend that you take a look on the server side.

On the server, you can limit what they key is allowed to do and what servers it may be used from, by editing the authorized_keys file for the target account. Here's an example of a key with limits:

from="their.workstation.only.example.com" no-port-forwarding ssh-dss AAA....

You can use IP addresses instead of an FQDN if you like.

In order to prevent the users from tampering with the authorized_keys file, you can move it to a location where they do not have write permission. It will still work as long as they have read permission. This can be done by editing the sshd_config and changing

AuthorizedKeysFile .ssh/authorized_key

to e.g.

AuthorizedKeysFile /usr/local/authorized_keys/%u

The %u gets replaced by the username, so when someone connects to ssh with the username foo, ssh will look for the keyfile in /usr/local/authorized_keys/foo. As long as foo has read access to that file, the connection will work.

Edit: Instead of moving the key, you could simply set the file to immutable, like this:

sudo chattr +i /home/user/.ssh/authorized_keys

Once you've set up the source IP limitation, and you've secured the key file against tampering, it won't matter if the private key gets leaked - it still won't be usable from any other system.

There are a lot of other things you can do to limit the users when they connect with keys - see the man page for sshd. There's also been some questions about this at Serverfault, for example Limited SSH access for log retrieval.


Is iPhone's fingerprint signature a one-way hash?

Fingerprints cannot be hashed. Well, you can hash any sequence of bits, but that would not be interesting at all. Fingerprint readers, like all biometric applications, make physical measures which are never exactly reproducible. Instead, the reader must detect the positions of some "characteristic points" on the finger image (where ridges meet, mostly), and then look for a match with fingerprints recorded in the phone. The match is never exact, due to the limited precision of the measure and unavoidable threshold effects.

Bottom-line is that the phone necessarily stores the information about the locations of the "characteristic points" in a reversible way, not as a hash. This may not be the complete finger image, but it would be enough to design a fake finger which would fool your iPhone.

Now that should not be that much a concern. The iPhone may contain some information about your fingerprints, but its case is also covered with a lot of accurate copies of the same fingerprints, simply because you hold the phone with your hands. If someone steals your phone, then he can have your fingerprints without even bothering to power up the phone.

More generally, you leave your fingerprints everywhere, e.g. on the knob of every door that you go through. Your fingerprints cannot be considered secret (correspondingly, their use for unlocking a computer or a phone has always seemed to be a rather poor idea to me, at least from the security point of view).


Wireguard doesn't really have a key "re-exchange" like SSH does. It's just the same handshake over again. Each handshake's key is valid for a certain timeframe (say, 3 minutes). If you go to send a packet and the key has less than, say, a minute of life left, another handshake will be started, so that a new key is ready by the time the old one expires. Peers usually keep track of up to three handshakes at a time: the last successful one, the one before that (because some packets using the old key may arrive late), and the one in progress (if applicable).


Find Buffer Overflows at a target you want to gain access

As schroeder has already pointed out, to identify buffer overflow vulnerabilities, you'd need to test the application locally with a debugger. It seems to me that you haven't actually gone through the process of learning to identify and debugging possibly vulnerable applications to buffer overflow.

Instead of walking you through the basics of the process here, I will attach what I believe to be excellent starting points, so that you can study and get the 'gist' of buffer overflows on your own.

Understanding what you're working with (ASM)

x86 Assembly Wikibook: Excellent and thorough resource for getting into assembly. If you don't already know how to detect interesting parts of the code, then you should start from this. It might seem daunting at first, but once you get into it, it will seem much clearer.
Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software: Chapter 4 is a brief "Crash-Course" in disassembly, which I consider an absolute must!
Modern C: This is an excellent book (and free) for the C programming language. The author also provides the code examples used in the book.
Pointers in C - A Hands on Approach: This is a great book to understand pointers and memory management in a program.

Getting the right tools

The tools that you'll need are almost always going to be included in VMs used for memory debugging/reverse engineering, but you can always download the ones you prefer. My approach for learning something and understanding it for the first time, is to go "full manual". A good debugger for this is the GNU debugger (GDB). There are other debuggers which are more automated/advanced, but I do not recommend those for beginners, because you learn better by doing it the hard way.
GDB PEDA is an awesome extension for GDB, to make your life easier.
GDB Guide/Cheat sheet

Taking Action

Do stack buffer overflow is really good for a beginner, because it gives you a vulnerable application and there is
also a PDF that guides you through the process. Highly recommended.
Security Exercises: It is another great repository to get you started with buffer overflows, shell-code injection, etc.. It also includes a walk-through.
Vulnhub: This website has all sorts of vulnerable VMs (including ones designed specifically for Buffer Overflows), which you can download and experiment at your own pace.

There is an abundance of tools, guides, VMs and other resources to get you started, and others that can challenge even experienced people. You have to put a lot of effort into this and if something seems a bit unclear, just look for more resources to help you.

If you had access to the source code of an application, then you could just read the source code and see which parts would be vulnerable to a buffer overflow. We usually don't have that and production applications are not compiled with debug symbols (unfortunately). This is where debugging comes in (and reverse-engineering).

You run your executable in a debugger and try to figure things out. Do check the resources I've posted and get ready for a lot of work! And don't give up when things get tough.


So, hashing the user password before entering it into the query is a coincidental security feature to prevent SQL injection, but you can't necessarily do that with all user input. If I'm looking up a Customer by their Name and I have a query like

Select * from Customer Where Name like '%userInput%'

If I set userInput as a hashed version of what was typed in, it wouldn't work correctly even if Name was also hashed in the database, it would only work for exact search query. So if I had a Customer with Name "Sue" and I typed in a search for "sue", it wouldn't work. I also wouldn't know the name of the customers unless there was an exact match in my search, which isn't practical.

The way you want to prevent SQL injection is to not make your queries like above, you'll want to process and parameterize inputs into a query, stripping out things like =s and other symbols that don't make sense in context of the input. A good guide for preventing SQL injection can be found here.


Protection of Keys/Passwords on Virtual Hardware (XEN, KVM, VMWare, etc.)

To me it seems clear, just by considering hypotheticals, that a virtual server has no practical technical protection from the administrator of the real host.

I'll try to be specific. It doesn't have to be impractical to crack a virtual server, given control of the real host. Here's the kind of strategy that I would imagine. Disassemble the virtual machine host software and locate the virtual keyboard driver. Then modify, not necessarily the VM host software, but perhaps a dispatch table in the operating system kernel. In that way, some sequence of system calls that is characteristic of the virtual keyboard driver could be made to trigger a logger for the virtual input keys. The result is a keylogger for the virtual server that can't clearly be detected from the virtual side.

A host system that would prevent this kind of manipulation probably wouldn't work very well. It's hard enough to debug and monitor software without intentionally adding obstacles for analysts.


Is there a way to identify the location of a person trying to intrude your wifi network? my wifi router is picking up his attempts

The user isn't trying to attack over wifi.  They're trying to attack over the Internet.

Aug 30 20:28:09 dropbear[6799]: Child connection from ::ffff:5.10.69.82:38463
Aug 30 20:28:11 dropbear[6799]: login attempt for nonexistent user from ::ffff:5.10.69.82:38463
Aug 30 20:28:12 dropbear[6799]: exit before auth: Disconnect received

::ffff:5.10.69.82 is an IPv6-mapped IPv4 address, specifically 5.10.69.82.  The log shows the attacker connecting to an SSH server on your router, trying an invalid username/password pair, and disconnecting.

This is probably a part of the distributed SSH brute-force attack that's been going on for years.  MAC filtering and WPA2 will do nothing to stop it, since it isn't coming in over the wireless connection.  Rather, you should take the appropriate precautions for dealing with an attack on SSH.


What are rainbow tables and how are they used?

Rainbow Tables are commonly confused with another, simpler technique that leverages a compute time-storage tradeoff in password recover: hash tables.

Hash tables are constructed by hashing each word in a password dictionary. The password-hash pairs are stored in a table, sorted by hash value. To use a hash table, simple take the hash and perform a binary search in the table to find the original password, if it's present.

Rainbow Tables are more complex. Constructing a rainbow table requires two things: a hashing function and a reduction function. The hashing function for a given set of Rainbow Tables must match the hashed password you want to recover. The reduction function must transform a hash into something usable as a password. A simple reduction function is to Base64 encode the hash, then truncate it to a certain number of characters.

Rainbow tables are constructed of "chains" of a certain length: 100,000 for example. To construct the chain, pick a random seed value. Then apply the hashing and reduction functions to this seed, and its output, and continue iterating 100,000 times. Only the seed and final value are stored. Repeat this process to create as many chains as desired.

To recover a password using Rainbow Tables, the password hash undergoes the above process for the same length: in this case 100,000 but each link in the chain is retained. Each link in the chain is compared with the final value of each chain. If there is a match, the chain can be reconstructed, keeping both the output of each hashing function and the output of each reduction function. That reconstructed chain will contain the hash of the password in question as well as the password that produced it.

The strengths of a hash table are that recovering a password is lightning fast (binary search) and the person building the hash table can choose what goes into it, such as the top 10,000 passwords. The weakness compared to Rainbow Tables is that hash tables must store every single hash-password pair.

Rainbow Tables have the benefit the person constructing those tables can choose how much storage is required by selecting the number of links in each chain. The more links between the seed and the final value, the more passwords are captured. One weakness is that the person building the chains doesn't choose the passwords they capture so Rainbow Tables can't be optimized for common passwords. Also, password recovery involves computing long chains of hashes, making recovery an expensive operation. The longer the chains, the more passwords are captured in them, but more time is required to find a password inside.

Hash tables are good for common passwords, Rainbow Tables are good for tough passwords. The best approach would be to recover as many passwords as possible using hash tables and/or conventional cracking with a dictionary of the top N passwords. For those that remain, use Rainbow Tables.


What happens if a secure token is provided to a trusted party that gets compromised

There's not really enough information to determine the specifics here, but there are some general answers that can be provided.
In your scenario, the assumption by default should be that node A has had the ability to access and modify account X within the scope of the permission of its token.  This is, generally, why tokens are usually limited to certain scopes, so that, for example, if node A needs to access directory information about account X, it cannot abuse that to also modify other information on the account.
This is also why automated tokens tend to be time limited—so that the abuse of account X by node A is limited to the life of its tokens—and why credential issuance is usually logged—so that any misuse can be easily determined and the extent of access can be readily discovered.  If tokens are issued using sufficient entropy, it is also common to log their access using a hashed version of the token so that actions taken by a bad actor can be determined.
Whether, in this situation, it means that account X is compromised (that is, under the control of the attacker) depends on what data the attacker had the ability to access or modify, both due to the scopes and duration of the token and the design of the system.  If, for example, the token grants the attacker the ability to do only cosmetic changes, like change personal names or avatars, then the account is, while potentially defaced, probably not compromised.
If your system permits the issuance of additional tokens to node A, then you may well provide it additional tokens.  That, of course, depends on the design of the system.
To detect compromises, you will generally want to have some sort of automated measurements or metrics that detect indicators of compromise.  What those are depend on the system.  For example, if you know that nodes are generally only supposed to handle about 20,000 accounts per day, you may set up a dashboard or an alert to detect large numbers of issued tokens or tokens issued for many accounts, so you notice it's acting strangely.  You may also monitor other indications of compromise, such as loading of additional kernel modules, unusual usage of sudo, or access from or connections to unexpected systems.  All of this depends on what you know about your instances and systems and requires that you build in suitable metrics and monitoring that are appropriate for your scenario based on suitable threat modeling.  You will need to balance good detection and prevention of threats with gracefully handling the occasional anomalous but harmless traffic pattern and avoiding major inconvenience for staff.


How signature validation would be checked on server side?

First off, the use of the term signature here is improper. I know that they are using it in the Twitter documentation, but that's not the correct name. "Signature" normally refers to digital signatures which are part of asymmetric cryptography; i.e. RSA, DSA... Here, we have a MAC.

It is not "SHA-1" which is used, but "HMAC/SHA-1". HMAC is a MAC algorithm which is built around an underlying hash function (here SHA-1) as a building block, but there is more to HMAC than simply a hash function. HMAC is a MAC, which means that it uses a secret key which the Twitter documentation calls the "consumer secret" (yet again, that documentation uses the term "key" to designate something different, which is a great source of confusion). This secret key is involved in the computation; it is needed to produce the HMAC output but also to verify it. This secret key is known to both the client and the server, but to none other (it is "secret"). HMAC is so that each HMAC output is specific to a given input message, and it is not feasible to forge a valid HMAC output for a new message without knowing the secret key, even if many other pairs message+HMAC output are observed.

To sum up, the server can verify the "signature" from the client by using the "consumer secret" which is known to both client and server. When the server sees a valid HMAC output, it knows that the message comes from someone who knows the "consumer secret", which can only be the client, or the server itself. The server knows that it never produces messages with that exact format, so it must come from the client -- the specific client who knows that specific "consumer secret". The client is thus authenticated.


How can http data be compromised on a secure network?

They can snoop on the traffic between the two secure networks. They can redirect traffic to their own network rather than the secure network.


Correct metasploit search usage (or bug?)

This behavior changed in December 2016. search now returns an intersection of results for multiple keywords instead of a union.


Recommended key usage for a client certificate

TL-DR SSL client cert doesn't need KeyUsage but if present it should be digitalSignature except for very-rare-if-ever fixed-*DH.
Caveat: You tagged SSL so I assume by "path that requires a certificate" you mean SSL/TLS or something over SSL/TLS (not necessarily HTTP/S). If you mean something more like CMS or S/MIME, or XML-sig, or even PGP, the answer may be different.
I'm surprised you don't find other references since X.509 certs are so widely used. My first page of google X.509 key usage extension gives PKIX rfc5280 which is the currently effective Internet spec and (the text form of) its predecessor rfc3280; the not-terribly-good wikipedia article; and https://access.redhat.com/documentation/en-us/red_hat_certificate_system/10/html/administration_guide/standard_x.509_v3_certificate_extensions which has (possibly over-) specific instructions for several cases including SSL client. Quoting the relevant part of 5280 (which your IBM site more or less copies):
   Bits in the KeyUsage type are used as follows:

      The digitalSignature bit is asserted when the subject public key
      is used for verifying digital signatures, other than signatures on
      certificates (bit 5) and CRLs (bit 6), such as those used in an
      entity authentication service, a data origin authentication
      service, and/or an integrity service.

      The nonRepudiation bit is asserted when the subject public key is
      used to verify digital signatures, other than signatures on
      certificates (bit 5) and CRLs (bit 6), used to provide a non-
      repudiation service that protects against the signing entity
      falsely denying some action.  In the case of later conflict, a
      reliable third party may determine the authenticity of the signed
      data.  (Note that recent editions of X.509 have renamed the
      nonRepudiation bit to contentCommitment.)

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key
      transport.  For example, this bit shall be set when an RSA public
      key is to be used for encrypting a symmetric content-decryption
      key or an asymmetric private key.

      The dataEncipherment bit is asserted when the subject public key
      is used for directly enciphering raw user data without the use of
      an intermediate symmetric cipher.  Note that the use of this bit
      is extremely uncommon; almost all applications use key transport
      or key agreement to establish a symmetric key.

      The keyAgreement bit is asserted when the subject public key is
      used for key agreement.  For example, when a Diffie-Hellman key is
      to be used for key management, then this bit is set.

      The keyCertSign bit is asserted when the subject public key is
      used for verifying signatures on public key certificates.  If the
      keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension (Section 4.2.1.9) MUST also be asserted.

      The cRLSign bit is asserted when the subject public key is used
      for verifying signatures on certificate revocation lists (e.g.,
      CRLs, delta CRLs, or ARLs).

      The meaning of the encipherOnly bit is undefined in the absence of
      the keyAgreement bit.  When the encipherOnly bit is asserted and
      the keyAgreement bit is also set, the subject public key may be
      used only for enciphering data while performing key agreement.

      The meaning of the decipherOnly bit is undefined in the absence of
      the keyAgreement bit.  When the decipherOnly bit is asserted and
      the keyAgreement bit is also set, the subject public key may be
      used only for deciphering data while performing key agreement.

This is necessarily somewhat general because X.509 (and PKIX) certs were designed to be used for a range of things, not just SSL/TLS, although that's the only usage most people know about. It does distinguish several types of signing, encryption, and keyagreement (which in practice is used for encryption).
5280/3280 only mandate KeyUsage for CA certs, implicitly leaving it optional for EE certs. I don't have actual X.509 but AFAIU it says if KeyUsage is not present it is treated as all bits set, because that is compatible with v1 and v2 before there were any extensions. CABforum baseline explicitly specifies it as required for CA certs but optional for "subscriber" (meaning EE) certs.
TLSv1.2 (or its predecessors) requires a client cert "allow ... signing" except for the fixed-DH and fixed-ECDH key-exchanges which no one seems to use at least on the public net, and related sections explain how except for fixed-DH the client key is actually used only for signing handshake data to prove possession by and thus authenticate the client.
This means if KeyUsage is present for SSL client it must include digitalSignature, and since in general a crypto key should not be used for multiple purposes without strong justification, KeyUsage for SSL client should not include anything else. If the client cert does not have KeyUsage or has a non-restrictive KeyUsage, a conforming SSL/TLS implementation will still use that key and cert only in the way specified by the protocol, which except fixed-DH as noted is only signing/verifying data that is not a cert or CRL.


Setting Access-Control-Allow-Origin: * when session identifiers are injected in the HTTP headers

This means that if an external malicious code tries to make a call to this URL it will be able to see the response, but this will be an authorization error anyway.

Yeah, that is correct. To be able to get anything of value out of it, the attacker needs to get the credentials. If these are stored in local storage, in JS variables or whatever they will be protected by the same origin policy that the browser enforces.

So there is no major problem with your CORS policy in of itself. But there are many related issues that you need to think about: Is the authentication scheme good? I assume third parties are supposed to use the API since you want to enable cross origin requests, so how do the third parties get the secrets? And so on.


One way to get some data on this is to weigh the success/fail rate of ASLR for this particular OS by implementing it in a testing environment, and then running attacks against the non-ASLR version, and the ASLR version. Of course, this would be very one sided being that it is only being tested by a specific entity instead of a community. However, you will achieve a rough idea of how effective ASLR is, how accurate that number is depends on how sophisticated the attacks are.

Not one protection measure will succeed in blocking all attacks. Given time, resources, and persistence, an attacker will eventually succeed. ASLR sets the bar higher for the skills needed to fully take over an OS, but it doesn't make it impossible.

Consider Defense in Depth as an arguing point for ASLR, solid security designs utilize multiple defenses before an external user actually reaches an application. It's there to protect the OS if someone was smart enough to get around the inner defenses. What if the individual is just a script kitty who got lucky with getting into the network, but has no idea how ASLR works? Attack thwarted, or at the least greatly reduced its impact. What if the attacker were a professional? Utilizing ASLR certainly doesn't make their objective easier for them, they might keep persisting or just tire out and take what they can get.

Of course, since this OS is proprietary, it certainly wouldn't look good on the developer(s) if someone were to compromise it, then have it be revealed that no protection measure was ever implemented at the core of the OS. This is almost like a bank using residential locks on a money vault.


Synology logs SMB "Read" event false positives

Your file manager probably reads the files to find metadata - such as Office document tags, EXIF thumbnails and so forth. You have no way of differentiating such automated reads from a user opening the file on this level.
To me it sounds like a X-Y problem. What do you want to achieve? An audit trail whenever a user opens a file?


It may be possible to trace your identity, yes, or at least to detect sensitive information (such as user name, computer host name, or timezone, which may pass through from the host to the virtual guest, depending on settings). Instead, you should use a tool designed for the job, like the live bootable Tails operating system. It is designed to leave no trace on the computer it runs on and will not insert anything sensitive into documents that you do not explicitly want to include. It additionally uses the Tor anonymity network, negating the risk of leaking your IP address when you distribute the document.


Network security: Public and Private keys

So, In this scenario confidentiality do matters that's why in later scenario of Pretty Good Privacy,

  Confidentiality is observed with one-time session key. So, Receiver decrypts the shared session key with the help of his private key. Then, uses this session key to encrypt the rest of the message. Then, matches the hash of the message with the digest created by the Sender.


Does GRE Tunneling "really" hide your main IP?

Going through a GRE or other VPN tunnel does in fact obfuscate your IP address on the internet, provided the tunnel is acting as your default gateway and no other gateways are specified in your routing table.

When this is done, the normal means of gleaning one's IP address such as checking netstat/connection information, checking server logs, or querying it through whatever protocol will reveal only the VPN IP address.  Your "real" IP address should not leak at all through the tunnel under normal circumstances.

However, this is not the be all and end all of obfuscating your IP address.  Some client side applications may detect and send your real IP address to the server as well (although typically this will be a local IP address and not useful for an attack, per RFC1918).  Some javascript on web sites might contain an element that attempts to maliciously pass on your real IP address.  So, there are many caveats here.

Also, of significant note is that governments and private investigators armed with subpoenas will probably be able to easily track you despite use of a tunnel.  This due to their access to privileged locations on the internet, and ability to even subpoena the VPN provider.  From a technical standpoint, they can correlate traffic sent from the VPN IP to traffic sent back over it, and determine your real IP.   Or they can just get it by subpoenaing the ISP etc for logs.  Thus part of the reason Tor exists.


Is it safer to use a port other than 21 for FTP?

It is not safe to use ftp over any port. Those who have a malicious intent to get in your network or system will not scan your system for port 21 but for all ports, and will figure the other port in virtually no time.

You are better with sftp as your file transfer tool.

On the other hand, you have the option of adding some security to your ftp transfers and ports if you run it over a VPN tunnel instead.


Building access card that has an identification role

I do not see an issue with not having a corporate logo on your access card  nor do I see an issue with not having  "a drop in any mailbox" message on them. The reason being that if someone loses their card, it will be impossible or very hard to find out for which building the card is used.

Also in the event someone wants to perform a targeted attack, forging a logo on a key card will be the easiest thing to do.

There are other points which are more important. For instance if someone loses a card, can you block it? Normally these cards just hold a token which is checked at the door against a list of authorized tokens.  It is imperative that you can track all cards and block them immediately in case of theft or when someone loses them. So when a card goes missing you need to immediately remove the token from the authorized tokens list.

I think people thinking you aren't an employee if you only have the key card isn't necessarily a bad thing if you are supposed to have two forms of id on you (employee and key card).


How does someone know i clicked a link in an email? URL spoofing? JSON?

Remember that crime is now commoditised and supported by a large framework of services. Any single email you receive might be part of a dozen different criminal services.

So, what is happening exactly here is not going to be known without access to the services used. We can only speculate.

The first hop is the easiest to guess. SOME_LETTERS_AND_NUMBERS is likely some sort of a UUID that is an index to the email campaign, the service, your email, the date, and any other metadata useful to the phishing service. The relevant metadata is passed on to another service. By using the link, you register with the service that you interacted with it, even if you did not click it from your email client or computer.

That what the admin77 could reference. This could be the username of the customer of the phishing service or the link processing service. Or anything else, really.

Why embed all this stuff in a URL? Ease and convenience. No need to use POST data or API calls, when you can just use URL parameters.


How to best limit SQL injection attacks that are being funneled through an Apache proxy I control

Now I am thinking of hardening my code by adding some time sensitive
(hindering) factor into the equation. The idea is to send them a
redirect to somewhere else (fbi?) for a set time period, after an
initial warning; provided they reach that emails code.

Most attacks are automated, so it's likely that your warning will not be seen or taken into consideration. Besides, the bad actors should normally be hiding their real IP address and using some proxy/VPN.
If I understand this right, the Apache server acts as some sort of reverse proxy. I would set up the front-line defense on the Apache server first instead of the IIS server.
What I would do is simply block the IP addresses at firewall level, automatically. In Linux this can be done with tools like Fail2Ban or CSF+LFD. These tools work by watching log files in real time and add firewall rules to ban offenders from making any further connections until the ban expires. They are mostly used to watch failed SSH attempts but also monitor other services such as POP/IMAP/SMTP/FTP etc.
You may need to add a custom rule and point to a specific log file but that shouldn't be too difficult.
Plus, Apache has a WAF module AFAIK. There may be some tools already available for the purpose.
Bottom line: don't contain the attackers, block them. You can have fun with the wannabe hackers and frustrate their efforts but I feel that blocking them is more straightforward and will save server and network resources.
At some point, your server may have to handle hundreds or thousands of concurrent malicious requests and your server could literally be overwhelmed fending off the attacks.


Is PCI - DSS required to store only card number

Yes - if you store, process or transmit cardholder data you need to comply with PCI DSS.

I’d really question your decision to store the 16-digit PAN (credit card number) in the database - Stripe has some great options that may enable you not to do this, criminals love databases containing cardholder data.


TPM: signing key or Attestation Identity Key?

AIKs are only allowed to perform two signature-based operations:

TPM_Quote, which generates a signed statement of the state of the PCRs using an AIK; this is the operation used in remote attestation.
TPM_CertifyKey, which generates a signed statement that another key (not the AIK) is in the TPM's storage hierarchy and is non-migratable. (Obviously, the key being so certified must have these properties.)

In particular, AIKs cannot be used in TPM_Sign, meaning it is impossible to sign arbitrary data. Otherwise, it would be possible to generate a fake quote, and remote attestation would be broken.

(Conversely, TPM_Quote must use an AIK; it cannot use a signing key.)

TL;DR: if you need a key to sign arbitrary data, use a signing key. If you're doing remote attestation, use an AIK.


One thing that comes in my mind by seeing this url is that maybe this: ?bob=1u1bga1mm1b0 is an unique ID that is related to this email, so when the person click on the email he/she will notify the spammers and tell them that they actually clicked this link or maybe they are trying to set some cookies to track activity or trying to initiate "man in the browser" attack, this are things we can just guess on, but maybe you can try and check if this domain is blacklisted, check if there are another hosts that are hosted on this server's IP address and check if they are the same blank pages, this may help you identify if this whole server has been compromised or maybe even notify the owner of the server in some way that something wrong is going on.


You won't be able to do this with the stock firmware. You should change over to openWRT to do what you want.

Download the .iso from here. (I recently installed the Attitude Adjustment iso). Go into troubleshooting (I think) and on the right hand side it says update firmware. Just point it to the ISO and you will have a much more flexible router.

From here you have great control over logging, firewalls, interfaces etc. iptables will be installed by default and you can use that to do almost anything you need.

See the openWRT page for more.

From here you can set up port mirroring with iptables and send it to an IDS/IPS like snort or suricata. If you want to use a central logging system (to forward the logs from the IDS you might use something like ossec). Note that all of these tools come with security onion if you prefer ubuntu.


What's the difference between trusting a key and signing it?

Trusting a key means that you will accept signatures from it. Signing a key means expressing that you have checked that the user really belongs to that key.

So, for example, if I sign your key, I am saying (to myself as well as to others) that this really is your key. That doesn't necessarily mean that I trust a signature from you on someone else's key. That only happens if I mark your key as trusted.


How to learn programming from a hacker's prospective

To address your first concern. Understanding the code you linked to would be difficult to understand your first time through. You would have to digest the entry point, payload, exploit, and other nuances. This isn't wimpy code that multiplies two numbers and returns the result. It makes sense that someone with limited experience is unable to understand it.

Unfortunately, mastering the basics is not enough. For example, mastering the basics will not allow you to understand the code you linked to. Modern programming languages are designed in such a way that the basics are understandable to people who don't fully understand the language.

If you want to fully understand the exploit, the payload, the code, and learn the most about exploits, then you will need to fully understand a few things.

How memory works (character encodings, the stack, and buffer overflows)
C
The platform the exploit is for. Do you plan on writing your shellcode for windows or Linux?...because there is a big difference.
Understanding what happens when you compile and run a program

If I were you, I would start with the K&R C book. This will help you learn about memory and C. I would then read Programming From the Ground Up. This will help teach you about what happens when a program is ran and the connection between the source code you write and the instructions your computer executes.

Although I believe this is the best way to get started, it is certainly the hard way to get started...The material is very dense and difficult to understand. Understanding this stuff takes a lot of time and effort. Also, your knowledge-base will still have glaring deficiencies. Even so, if you get through this you will easily be able to understand what the exploits you find are doing and how they work after some examination


Isn't HTTPS insecure over a hacked router?

Browsers do not accept verification from just any third party; if they did the whole exercise would indeed be pointless. In order to be accepted as valid, the certificate presented by the website must be digitally signed by a trusted certificate authority. The default list of trusted certificate authorities, which you can see in Chrome by going to Settings->Advanced->HTTPS/SSL->Manage Certificates->Trusted Root Certification Authorities, is limited. Getting on this list requires going through an extensive vetting process with browser/OS developers.

Additionally, there is no need for the browser to ever send a request to the certificate authority to verify the certificate. The browser already possesses the public keys of those trusted authorities (in Windows just click View->Details to see it), and a public key is all you need to prove that a certain entity signed a message (which in this case is a certificate). Read up on how digital signatures work if you want to understand the logic behind this. Just like a signature on paper, a digital signature allows you to confirm that an entity has approved of something without actually having to contact that entity.


Can Router logs give us information of which apps are interacting with each other?

Yes, “enterprise-class” routers can collect traffic information in multiple ways:

An access-list could be applied to log all (or selected) traffic.  (this could adversely impact the router’s performance depending on the amount of traffic being logged)
The router could export “netflow” data to a netflow analyzer, which can generate reports on traffic.  In high bandwidth situations netflow export is often “sampled”, allowing bandwidth reports but less useful for forensic analysis.
The router can mirror data out a monitoring port, where a sniffer can analyze and/or store the packets.
Some routers and firewalls have “application inspection” capabilities, allowing them to analyze traffic beyond the protocol/port/IP-address basis.
Some routers have a “lawful intercept” feature-set, which I presume includes the ability to capture a subset of traffic.

Frankly, an easier way to see who is using a particular application is to set the DNS server (advertised in DHCP and IPv6 router advertisements) to a monitoring DNS server (such as openDNS).


How can I determine the common cryptographic suites I need to enable on my browser for common websites?

To see which cipher suites are used by the browsers have a look at the client tests at SSLLabs (you need to look at the details for each browser). But it might be better to simply use known good configurations like the recommended configurations from Mozilla.


Need help understand ARP spoofing attack?

In order to execute the attack we needs to have IP address of other local hosts. Which I just can't seem to have.

As you're using PPPoE, most likely you don't actually connect to the same L2 Ethernet as other customers. The switch is configured to isolate customer Ethernet ports so that they can only talk to the PPPoE server (which might indeed be the switch itself, or something further away). This is a common feature within Ethernet switches, and is something I would definitely expect an ISP to do on their customer-facing ports.
Once you establish the PPPoE connection, it only gives you a layer-3 tunnel – it doesn't carry Ethernet layer-2 headers and there is no ARP inside a PPP tunnel, because there's only one way a packet could go ("the other end of the tunnel") so the L2 addressing would be redundant. You cannot perform ARP poisoning on networks which do not use ARP.
(This also means that the PPP tunnel doesn't really have a subnet as such, and its "subnet mask" might not reflect the addresses of nearby customers at all, and might confuse IP scanners which expect the network to be a contiguous /24 or similar, while it's more like a collection of arbitrary /32's in reality.)
Generally the same applies to most VPN tunnels as well. Ethernet-like L2 VPNs do exist, but aren't the standard choice.

The book mentions default gateways as a target. So what exactly is a default gateways (for my setup), And how does it work?

"Default gateway" is shorthand for the gateway (i.e. router) that's specified in the "default route", which is the 0.0.0.0/0 route (or the ::/0 one for IPv6).
PPPoE is relevant here as well. Because L3 tunnels don't use L2 addressing or ARP, routes over L3 tunnels actually don't need a gateway address – it wouldn't make any difference to the packet headers.
So it's quite possible that your default route via PPPoE has no "default gateway".

Since we can poison the ARP cache to add entries to it, Is it (asking from a security perspective) possible to create entries to addresses that aren't local!! For Example. Let's say we have the IP address of 192.168.1.12 having mac 00:00:00:01, and a Facebook server has IP address 10.0.0.23. Is it possible to send a ARP response i.e. it will poison the ARP cache of a local user to make it seem like the address 10.0.0.23 is at mac address 00:00:00:01. Then would the packet sent over to the Facebook IP be delivered over to us? Or would it be filtered by the router?

It wouldn't even get to that point.
The ARP cache is consulted only if the routing table says it should be consulted. A host or a router won't bother looking ARP for addresses if it already knows that those addresses are non-local.
For example, if your routing table was like this (a very typical home Ethernet host),
192.168.1.0/24 dev eth0
0.0.0.0/0 via 192.168.1.1 dev eth0

then the host would know that only 192.168.1.0/24 is local and should be ARP'd (because it's a device-only route), and it would know that everything else is non-local. When the matching route has a "gateway" specified, that directly implies that the destination is non-local and so the only ARP query is made for the gateway, not for the actual destination.
(The only situation where this would work is if the network was configured with Proxy-ARP in mind, where the default route also has no "gateway" address (but it's still a regular Ethernet and so ARP is still in use, unlike in the PPPoE case). This would indeed make every host directly make ARP queries for any destination, with the gateway answering on their behalf. Such LANs have existed in the past, though I can't imagine them being common nowadays – they were used to achieve router failover, something which VRRP handles much better now.)

What is the address of the first node (to me) where my data is sent over to? Like for most users it would be their router (at a basic level), but since I don't use one, what would be the first node through which my data goes?

In terms of IP (layer 3) nodes, in your case that would be the ISP's system which handles the other end of the PPPoE tunnel. You might be able to see its IP address from traceroute or tracert results.
(Again, it's PPPoE that makes you seem to get different results than the rest. If it weren't in use, you would just have a normal default route, and the first node would simply be the ISP's router whose address shows up in your routing table.)
Still, in any case, the next node for an IP packet (if it's not the final destination) will be a router. If it's not your router, then it will be the ISP's router.


The signature algorithm used in the root certificate is not used to establish trust against the root certificate because a root certificate is trusted by the virtue of a copy of the root certificate is installed in the browser, either included in the browser as part of the installation, or added later by the user to their certificate store.

For the rest of the trust chain, including intermediate and end certificate, a root certificate asserts the authority and encoded data in the intermediate certificate by cryptographically signing the signature of the intermediate certificate with its private key. Likewise, the intermediate certificate asserts the authority and encoded data in the end certificate by cryptographically signing the signature of the end certificate. There can be more than one level of intermediate certificates.

If an intermediate or end certificate has a weak signature, then it is possible that an attacker can generate two certificates with the same signature with different encoded information (e.g. looks-harmless.com and your-bank.com). The attacker can then ask a certificate authority to sign one of the certificate (looks-harmless.com) then copied the signature to the other certificate (your-bank.com).

The problem with SHA1 is that it has flaws that renders it feasible for an attacker with sufficient resource to find such collisions.

In your example, if intermediate Certificate 3 has SHA1 signature, then it is vulnerable to this attack. If the scanner didn't flag this chain as untrusted, then it should have.


You could try some of the following:

python sqlmap.py -u http://redacted.com/api/v1/endpoint --headers="Authorization: Bearer xxxx" --data='{"end_date":"00:00:00*","start_date":"2018-8-26","success":1}' --sql-query="') union select 1,user(),version();--+" -v 3

By using the astersisk you can tell sqlmap where to inject.

python sqlmap.py -u http://redacted.com/api/v1/endpoint --headers="Authorization: Bearer xxxx" --data='{"end_date":"00:00:00","start_date":"2018-8-26","success":1}' -p "end_date" --prefix="')" --suffix=";--+" -v 3

You can use prefix and suffix (as well as combine them with the asterisk) to precisely tell sqlmap where to put what in you injection attempt.
Maybe that solves your problem already. Also you can have a closer look here.


What are the disadvantages of implementing HTTP authentication in a web application?

Basic authentication has a number of drawbacks, one of which is that the username and password are passed in the clear with every request.   This is clearly unsafe under HTTP, but is somewhat less vulnerable under HTTPS.   However, because the credentials are submitted with every request, it's still worse than any other method (including digest) that does not have this limitation.  The primary reason is that now every single request can be a target for cleartext credential theft, not just an initial login request.  In most systems, after login, the most an attacker can hope to retrieve is a session or authentication token.  With basic auth, any request is an opportunity to steal the user's password.  This is not ideal.

Digest auth is somewhat better in that it sends an MD5 digest of some various bits including the username, password, and a nonce (among other values) and not the cleartext credentials...A password cannot be extracted from a captured digest.

With HTTP authentication (in any form) you're also dependent on the client to provide the authentication user experience, which can have its own issues and so needs to be well tested with the clients you expect to be using your application.   IN the past, for instance, I've seen specific browsers fail to authenticate because of certain special characters in a password, for instance.  With application based authentication UX, you have control over this.  With HTTP auth, you do not.

Another attack (and its a very minor one) is that if you display user-generated, externally hosted content on your site, you open yourself up to very subtle 401 phishing attacks.  Since your users are used to the client's chrome for HTTP authentication, they won't necessarily notice if they get an authentication prompt on your site for a slightly different domain.  Depending on your application, this may not be a valid threat at all, but it's certainly something to consider if you go down the HTTP auth route.


Can a meltdown attack also violate data integrity of other processes or is it just violating data secrecy?

Meltdown is an attack that allows overcoming memory isolation completely by providing a simple way for any user process to read the entire kernel memory of the machine. Attacker can get password, private keys and valuable information. You can access the research paper here.


How to restrict plugins/tools like Netcraft and Builtwith to detect server side technologies?

Look into how these tools work. Some information may be easy to remove, by e.g. setting the headers for your web server to report more restricted information. This can hide exact version. However, it's far harder to hide that you're running Apache than that you're running Apache 2.4.35, as it may reveal itself in how it reacts to certain inputs.

Sanitize all web applications, and rewrite paths so they do not reveal applications. For instance wp-content is a dead giveaway for Wordpress. This is a large task, and realistically includes rewriting parts of the application, probably waving good bye to official patches without modification.

Hiding platform you host the system on is even harder, as different kernels implement the TCP stack in slightly different ways. Abstract things, such as TCP sequence numbers, may reveal information about the platform. TCP Syn cookies may reveal information. And so on. Completely obscuring the platform is likely to be hard.

And what do you gain, in terms of security? You spend a lot of resources to hide information. Why not spend that on securing your application, so that it does not matter if an attacker knows that you're running Apache 2.4.35?


Several processes are listening to the same interface: any problem?

Assuming the network stack was competently programmed, no.  An interface in monitor mode should hand off a copy of each packet to any program that wants it.


Downloadable Autonomous System contact information

Contacts of an AS or an IP network are stored in databases of the respective regional Internet registries. Each database is available for download on a RIR Web or FTP site. For example, here's all the data for the Asia/Pacific region.

Note that a contact data may change as time goes by. You'd probably want to update those once in a week or so. Also, from my experience, a huge portion of this contact data is just outdated garbage, and even ISPs which do maintain correct abuse contact data mostly won't help you to mitigate the network flood.

Moreover, in a specific case of a DDoS attack (since it's mentioned in the question tag) IP sources might be just spoofed, so there's no point in reaching arbitrary ISPs anyway.


How is this web resource hidden from the user?

The font files are loaded via CSS using code similar to this:

@font-face {
  font-family: 'Modern Brush';
  font-weight: normal;
  font-style: normal;
  src: url('/url-here/') format('woff');
}

I'm not convinced they have tried to hide this at all. The woff font file loaded shows up under the fonts tab in FireBug ok. The preview fails though as it doesn't factor in the URL parameters Key-Pair-Id, Policy and Signature which obviously make a difference, and presumably therefore these are components of their DRM implementation.


In theory, this can be done with an additional layer of encryption:

Generate a key of appropriate length
Encrypt the message (file) with a symmetric-key algorithm using this key
Encrypt this key with an asymmetric-key encryption using Bob's public key

If you then send the encrypted file and encrypted key to Bob, he will be able to decrypt the key and then the file using this key.

This approach is implemented in most cryptography software. From the user's point of view, you choose the file and the key of the recipient, and get the encrypted file which usually contains metadata (e.g. public key hash), so the recipient (or any other  person) may check whether he has the correct private key without actually decrypting the data.

This scheme combines the obvious benefits of public-key cryptography with the speed of symmetric-key encryption (asymmetric encryption is considerably slower).

As A. Hersean pointed out, you should not implement this scheme from scratch (unless this is your homework assignment, or you are just curious), but rely on widely-used packages like GnuPG. This software often includes GUI, so it can be used by a beginner.


Is storing the private key and public keys in same directory on server recommended, like OwnCloud does?

Well the public keys are fine to store there. Thats why they are public. Anyways, you should seperate the private keys and make sure nobody else gets access to them. So probably storing them on another server would be good practice.


How to use the standard (non-dictionary) brute force attack on FTP in THC-Hydra?

If you want to perform a brute force attack without a dictionary use "-x MIN:MAX:CHARSET", i.e "-x 3:3:a"

The -x switch defines the character set that will be used, instead of the -p switch which would have pointed at the dictionary.

  -P "try password PASS, or load several passwords from FILE"

To launch the attack on a FTP server just place ftp in the protocol section of the URL, followed by the target IP address.

For example;

root@find:~/Desktop# hydra -t 10 -V -f -l root -x 4:6:a ftp://192.168.67.132

  -t "run TASKS number of connects in parallel (per host, default: 16)"

  -V "verbose mode / show login+pass for each attempt / debug mode"

  -f "exit when a login/pass pair is found"

  -l "LOGIN or -L FILE  login with LOGIN name, or load several logins from FILE"

  -x "MIN:MAX:CHARSET password bruteforce generation"

Good blog post about this.

Another link that may help is Hydras page from tools.kali.org, which has a lot of good information including full syntax, beyond the examples above.

Hope this helps.


Is it possible to know the key if we have the original value and the hash using HmacSHA1?

It is not possible to recover the key ... assuming the key has sufficient entropy.

Here's what the attacker can do.  If the attacker has a guess at the key, the attacker can check whether his guess is correct.  This means that if the attacker can narrow down the list of possibilities for the key to a short enough list, the attacker can simply try all possibilities in that list and see which one is correct, and the attacker will eventually discover the correct value of the key.  This attack strategy is known as brute-force search, or exhaustive keysearch.  It turns out that this is essentially the only attack an attacker can do; with SHA1-HMAC, an attacker can't do any better than this attack strategy.

So, your job as defender is to make sure that the number of possibilities for the key is large enough that brute-force search will be unsuccessful.  Ideally, there would be at least 2128 possibilities for the key, all equally likely.  For instance, you might generate the key by reading 128 bits from /dev/urandom.  If that is how you select the key, then there will be no way for an attacker to recover the key.

On the other hand, if you do a lousy job as defender of picking the key, then it might be possible for an attacker to recover the key.  For instance, suppose you decide your key will be a random 4-digit number.  Well, then there are only 10,000 possibilities for the key, so an attacker can try them all and identify which one is correct.  The trial-and-error process will take only milliseconds -- so if that's how you picked your key, things would be totally insecure, and the attacker would be able to recover the key.  If you pick a random 10-digit number as your key, then there are 1010 possible values of the key, which is still not enough: an attacker could try all of those possible value in mere hours.  So, don't do that.  Or, if you use someone's telephone number or SSN as the key, then again it will be possible for an attacker to recover the key (simply by trying all possibilities).  So, don't do that, either.

In short: choose your key using 128 bits of crypto-strength randomness.  Then, it will not be possible for an attacker to recover the key.


This is indeed English slang and therefore this question relates more to etymology than security.

Wiktionary describes it as:

  (slang) A person.
  George was a bit of an odd bod.

  2005, Richard Templar, The Rules of Management (page 73) There were cameras covering car parks, offices, corridors and storage areas in the basement. Result. The security bods started watching as if their lives depended on it.

(Emphasis mine)


Posted images at company wifi network by accident. I used my personal IPhone

Assuming Grindr uses HTTPS (I'm not about to go confirm), you don't have to register your device with IT and your employer didn't force you to install anything on your phone before they let you use it on the network, then at most all they'll see is that a device made a DNS request for Grindr, connected to their server and transmitted some data (but not what specifically).

Again, depending on intrusiveness, they may not even be able to tell whose device it is. If they just said "here's the wifi password" and sent you on your way, then I wouldn't worry at all.

In my experience you likely aren't the only person in the company with it installed, so I wouldn't worry about being outed by that either. We've removed it from more than a few corporate phones.


What features do you look for in an Enterprise Log Management solution?

Here are a few different features you should consider, note that you might not need all of these, and one might not be better than the other - but they are points to consider:

Coverage:

Windows Event Log on servers, all current versions
Windows Event Log on clients, all versions in your org (you'd be surprised how many Win98s there still are...)
syslog on Linux/Unix servers according to your flavors
syslog on Linux/Unix workstations (if you have) according to common flavors in use
generic SNMP traps
Other OSs you might have...
Network equipment (if thats where you want to take it): Firewalls, routers, gateways, proxies, WAFs, IDS/IPS, etc
Web/App server logs: e.g. IIS, Apache, WebSphere, WebLogic, etc, whatever else you have
Databases
Mail servers
MQ servers if you have them and they are critical
AD/directory/IdM servers
security and control servers, e.g. content filtering gateway, HPOV, MS SMS, etc.
etc any other infrastructure you find critical
Application logs! As I said in my comment up top, this are of critical importance, yet are most often neglected. While there is no real common format (there are some structures but nothing data-specific), the SIEM product/solution should:
a. be able to receive and generically parse a variety of formats and files, e.g. CSV, XML, flatfiles, etc.
b. ideally would be able to define specific formats and recognize the data

Agent vs agentless (aka push vs. pull)

There are advantages to each, which is better really depends on your specific environment.
Best would be support of both models, and use each where appropriate
Even bester is support of a builtin API to log directly to it.

Aggregation and consolidation
Correlation - i.e. link different events from different sources together to form a single meaningful incident. Ideally should use a variety of techniques
Reporting and dashboards - should be BI-like, both for trend analysis and specific incident/user investigation
Automated analysis and active alerting, depending on configuration. Should be flexible enough to fit your needs and expectations. Analytical engines should be able to identify certain classes of misuse/fraud/attacks in (near-)real time.
Historical data, and reports/analysis/correlation over time
If its relevant, some products offer "Compliance" packages, to assist in meeting specific regulatory requirements.
high availability
Ample protection of log data, both its confidentiality and its integrity, using combination of encryption, access control, self-logging, etc.
Remote management (securely, of course)
Possibility to plug into SOC if/when you get there


Is "Why Should You Avoid AES In MySQL?" true?

The primary reason not to use AES_* functions in MySQL is because they are using ECB block mode of operation, which is insecure.

Read more at:

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

Edit:
Since MySQL 5.6.17 things have changed and MySQL supports CBC block mode, but it has to be enabled manually. Read http://mysqlserverteam.com/understand-and-satisfy-your-aes-encryption-needs-with-5-6-17/


Is it possible to encrypt your Java source code and still have it readable & writable in Eclipse?

This isn't particularly related to code, to be honest - I'll vote to move it to Programmers, although SuperUser may be equally appropriate. All of your concerns would apply equally to non-source-code files with some CMS taking the place of source control.

Use encryption within your local operating system (e.g. BitLocker) so that no-one can read the contents of your laptop disk without being logged in as you. Obviously make sure your laptop requires your password to be entered when it returns from sleep etc.
Use an encrypted channel (e.g. HTTPS) between your laptop and your source control server. That will depend on your source control system.
Make sure the server running your source control system is using appropriate OS-level encryption too


Tegra X1 bootrom exploit portability potential (K1 in nexus 9 specifically)

Are you sure that the K1 is vulnerable? I did a quick search and all that I found was that "NVIDIA Tegra X2, which was launched in 2016, and later Tegra systems on a chip (SOCs) such as Xavier, are not affected by this issue." from the official Nvidia security notice, but no explicit confirmations. Assuming it is, let's move on.

On fail0verflow's write-up of their Tegra RCM exploit ShofEL2 and how to use it on the Nintendo Switch, they said that the preferable method of putting the switch into RCM mode is by pressing Volume-Up, power, and the 'home button' all at once (the other methods being messing-up the bootloader/physically removing the flash and rebooting into RCM from software). They said that the home button wasn't the home button on the Joy-Con, but rather the 10th pin on the right Joy-Con connector (that pin and ground are where it would be connected if it were a button, anyway). According to Wikipedia (and fail0verflow in the blog post I linked earlier), the majority of Tegra devices run Android. As such, I would believe that this 10th pin is connected to the same CPU GPIO pin that the home pin on a Tegra-powered Android is connected to. So try that, turn your tablet off and press the power button while holding the home button at the bottom and volume-up. If it appears to still be off, plug it into your computer. When my I plug my Switch into my Linux system while it's in RCM mode, the lsusb command lists it as 'NVIDIA Corp.' (It is listed as 'Nintendo, Co. Ltd.' when the Switch is normally booted into the Switch operating system.) If you use Windows, try checking Device Manager. You can use that to verify that you got your tablet into RCM mode.

This applies to anything, not just Tegras: even if pieces of code share a vulnerability, the slightest differences can cause an exploit written for one to not work for the other (this is especially true for low-level stuff like a BootROM). On the other hand, in the readme file in fail0verflow's ShofEL2 repository, they said that the exploit 'probably works on the Ouya', which is an Android device with the Tegra 3 (and the Tegra K1 is probably more similiar to the X1 than the Tegra 3 is to the X1).

I don't know if you have a payload in mind; if not, you can probably use an existing kernel image built for the device. (Even if you don't in the end, it can be helpful to make sure that the exploit worked before investing your time in building your own kernel.) The following only applies if you do use an Android kernel image: If you use the exploit to boot the default kernel with the default cmdline, it will (probably) boot-up normally. To make sure the exploit worked try passing an invalid init= parameter or something else to cause it to panic. (I don't know if Android kernels are usually compiled with CONFIG_VT=y, and if not you won't see a panic message. If not, try running a simple executable that creates a file on an SD card, for example.)

Let me know what results you have, I'm also interested in porting this exploit. (I only own a Switch, but I've been contemplating purchasing a Tegra 3-powered Microsoft Surface RT and trying the exploit on that. The Surface RT uses UEFI Secure Boot to ensure that the end-user only uses Windows RT.)

I find it really funny that this vulnerability has supposedly been around for a really long time (at least since the launch of the X1) and no one noticed it until the Switch (and when they did, three separate groups discovered it around the same time).


Where is Bash Shellshock vulnerability in source code?

CVE-2014-6271

CVE-2014-6271 was the first vulnerability discovered. A patch can be found here.

From Wikipedia:

  Function definitions are exported by encoding them within the
  environment variable list as variables whose values begin with
  parentheses ("()") followed by a function definition. The new instance
  of Bash, upon starting, scans its environment variable list for values
  in this format and converts them back into internal functions.

  Bash performs this conversion by creating a fragment of code that
  defines the function and executing it, but it does not verify that the
  fragment is merely a function definition. Therefore anyone who can
  cause Bash to execute with a particular name/value pair in its
  environment, can also execute arbitrary commands by appending those
  commands to an exported function definition.

In the source code, we can see the importing of the function variables in variables.c:

/* Initialize the shell variables from the current environment.
   If PRIVMODE is nonzero, don't import functions from ENV or
   parse $SHELLOPTS. */
void
initialize_shell_variables (env, privmode)
     char **env;
     int privmode;
{
  [...]
  for (string_index = 0; string = env[string_index++]; )
    {

      [...]
      /* If exported function, define it now.  Don't import functions from
     the environment in privileged mode. */
      if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4))
      {
        [...]
        parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
        [...]
      }
}

We can see a for loop over all the environment variables given to the function, and then an if about whether we are in privileged mode, but that is disabled most times.
The "not verify that the fragment is merely a function definition" part is in the parse_and_execute line. The function description from builtins/evalstring.c:

/* Parse and execute the commands in STRING.  Returns whatever
   execute_command () returns.  This frees STRING.  FLAGS is a
   flags word; look in common.h for the possible values.  Actions
   are:
    (flags & SEVAL_NONINT) -> interactive = 0;
    (flags & SEVAL_INTERACT) -> interactive = 1;
    (flags & SEVAL_NOHIST) -> call bash_history_disable ()
    (flags & SEVAL_NOFREE) -> don't free STRING when finished
    (flags & SEVAL_RESETLINE) -> reset line_number to 1
*/
int
parse_and_execute (string, from_file, flags)
     char *string;
     const char *from_file;
     int flags;
{

So everything that's passed to the function gets executed as if it would be an ordinary bash command. The flags SEVAL_NONINT and SEVAL_NOHIST are self-explanatory (explanation of interactivity, NOHIST doesn't add the definition to your bash history) don't prevent passing other things than function definitions. The patch introduces flags SEVAL_FUNCDEF and SEVAL_ONECMD that can be passed in the flags field to parse_and_execute:

+ #define SEVAL_FUNCDEF 0x080       /* only allow function definitions */
+ #define SEVAL_ONECMD  0x100       /* only allow a single command */

The patch also adds functionality to parse_and_execute to comply with those new flags, and changes the call to parse_and_execute to pass those flags:

-     parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
+     /* Don't import function names that are invalid identifiers from the
+        environment. */
+     if (legal_identifier (name))
+       parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);

CVE-2014-7169

CVE-2014-7169 bases on a function parsing issue that has been pointed out by Tavis Ormandy. The fix of parse.y seems very simple, but its trickier than CVE-2014-6271:

/* Called from shell.c when Control-C is typed at top level.  Or
   by the error rule at top level. */
void
reset_parser ()
  [...]
  FREE (word_desc_to_read);
  word_desc_to_read = (WORD_DESC *)NULL;
+ eol_ungetc_lookahead = 0;
+
  current_token = '\n'; /* XXX */
  last_read_token = '\n';
  token_to_read = '\n';

The eol_ungetc_lookahead variable is explained at its definition:

/* This implements one-character lookahead/lookbehind across physical input
   lines, to avoid something being lost because it's pushed back with
   shell_ungetc when we're at the start of a line. */
static int eol_ungetc_lookahead = 0;

Its read inside the shell_getc function, and if its set, its (one-character) content is read instead.

The command rm echo; env -i X='() { function a .>\' bash -c 'echo date'; cat echo first creates a syntax error with the . character (you can also use other characters here, like a or =), and then uses the insufficient cleanup of the eol_ungetc_lookahead variable in the reset_parser function to inject the > character into the 'echo date' string that's also given to bash. Its equivalent to rm echo; bash -c '> echo date'; cat echo.

Further resources on the oss-sec mailing list.


It looks like they used the popular Metasploit framework to hack you. Everything you do on your computer between the time they hacked you and now is available to the attacker. I suggest you run an antivirus scan to remove the malware. If it turns up nothing, you should re-install your operating system. It's very unlikely that you need to buy an entire new computer. It takes a far more advanced hacker than the screenshot is showing to persist malware even after the system was re-installed.

Any account you logged into while your system was hacked should be considered compromised. Change the passwords for all of those accounts, and don't run random programs again. If you kept credit card or debit numbers on your computer, consider alerting your bank.


Can OpenSSL verify a public key - intermediate CA certificate chain with a Root CA certificate?

First, the syntax is wrong. It should be:

openssl verify -CAfile rootcert.pem publickey_imcert_chain.pem

CAfile is rootcert.pem...

Next that's definitely not the way openssl verify works. You must concatenate all intermediate signing certificates up to the root one in a bundle and use that bundle to verify the servercert.pem one:

cat imcert.pem rootcert.pem > verificator.bundle
openssl verify -CAfile verificator.bundle servercert.pem

You will find more references and examples in that SO question.


How to trace the actions performed by a virus?

I strongly recommend to run that virus in an artificial environment like a sandbox so you won't affect your personal computer! In this way you can track its activity through the sandbox specific CLI/GUI.

Sandbox Example: Cuckoo Sandbox, Sandboxie, etc.

The other way around:

Use an virtual environment to test the malware and to manually track its activity.


What specific padding weakness does OAEP address in RSA?

The operation at the core of RSA is a modular exponentiation: given input m, compute me modulo n. Although in general this is a one-way permutation of integers modulo n, it does not fulfill all the characteristics needed for generic asymmetric encryption:

If e is small and m is small, then me could be smaller than n, at which point the modular exponentiation is no longer modular, and can be reverted efficiently.
The operation is deterministic, which allows for exhaustive search on the message: the attacker encrypts possible messages until a match is found with the actual encrypted message.
The modular exponentiation is malleable: given the "encryption" of m1 and m2, a simple multiplication yields the encryption of m1m2. This is akin to homomorphic encryption, which can be a good property, or not, depending on the context.

For these reason, the integer m which is subject to RSA must not be the data to encrypt alone, but should be the result of a transform which ensures that m is "not small", contains some random bytes, and deters malleability.

The "v1.5" padding in PKCS#1 does the job reasonably well, subject to two (known) caveats:

A decryption engine can be turned into a padding oracle if the attacker can submit malicious messages to decrypt, and observe whether the decryption engine found a correct padding structure or not. This is Bleichenbacher's attack, which could work against SSL server, requiring about one million aborted handshakes to recover the SSL symmetric key. SSL servers have since been patched (if decryption fails to find a padding, the engine nevertheless continues with a random blob instead of the "pre-master secret"), but this highlights a potential problem with PKCS#1 v1.5.
This padding scheme was never "proven". Security proofs are a neat thing to have. In my opinion, this padding got something better, which is that it has been deployed in the field and widely used for almost 20 years; but many people prefer it when there are some mathematics which corroborate experience.

OAEP aims at making things better on these two points. It turned out that for padding oracles, things are not that clear; and the first proof was shown to be somewhat wrong by Shoup. The proof was "repaired" by Fujisaki, Okamoto, Pointcheval and Stern in the case of RSA (OAEP was designed as a generic padding scheme, but we now have a proof of security only when used with RSA).

To sum up, OAEP tries to improve over the previous padding for resistance against chosen ciphertext attacks (not chosen plaintext attack: since the public key is public, anybody can encrypt anything at will), but the v1.5 padding was already heuristically good at it, up to a million or so decryption, which is good enough for many purposes, and can be patched for others (as was done for SSL). OAEP does better if correctly implemented, which is not as easy as usually believed.


How do you keep track of numerous keys in the workplace?

You need a key cabinet.  You've probably seen them behind the counter at car dealers, car rental agencies, service stations with garages attached, etc. etc.  I've seen server rooms which had one as it was a good central location for various office keys.  Add some disposable key tags so you'll know which key goes with which lock for the duration of their stay.  If tagging both is a problem, you can also get some of those little colored dot stickers to use to mark which lock goes with which key.

You can usually leave the cabinet itself unlocked during the day, not lock after each access, if there are people in the office and it's reasonably controlled.

Another alternative is to bag incoming keys & locks with a label to hand back out when the device leaves - use your own (static, unchanging) locks to secure devices while they're in your care.  That way you're still keeping track of extra keys, but they're your extra keys, which can make it easier.

If you have two keys... keep them together and let the next guy worry about what to do with the spare :)


injecting javascript in webviews in Android

Heheh, feels weird to circle back on my own question almost 5 years since posting it ! I have gotten a chance to explore web view a little more since then. And this may serve someone, hopefully.

http://www.nuckingfoob.me/android-webview-csp-iframe-sandbox-bypass/index.html


firewall with cloud based malware analysis risks

All Firewall/ IPS vendors have a license option to use their "Intelligence Network".   It has been evolving slowly across the security vendors over past 5 years. The intelligence or cloud network is collection of their devices across the customer base.  These devices all report up to the vendor "cloud" or intelligence center.  Once they collect and score they are sent back out to the network of those people that have subcribed to the network for reputation updates.

That being said - you would not be effected at your Firewall / IPS layer if you are subscribing to the network. If the service go down, you loose update subscription.  The attack you are talking about could be shutdown by the intelligence service, since they control the pivot point in the connection of all the devices down stream, including DDOS.


Can someone explain the weird treatment of the OpenSSL AES-256-GCM authentication tag in PHP 7.1?

According to wikipedia:

  The bit-length of the tag, denoted t, is a security parameter. In general, t may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, t may be 64 or 32, but the use of these two tag lengths constrains the length of the input data and the lifetime of the key.

After testing it appears that since openssl_decrypt doesn't allow you to specify an expected tag size it will accept any tag size so long as the tag is valid. Unfortunately it doesn't limit it to 128-96 bits, and if you have even one byte it'll decrypt without errors, meaning that GCM with PHP is mostly broken, as the tag is easily brute-forcable. You can fix this by verifying the tag length before passing it to openssl_decrypt.

I'm not certain whether this is actually a bug with openssl_decrypt or it was intended that tag length would be verified outside the function, but either way the documentation is certainly lacking here.

It appears that Ruby has the exact same issue.


How should a web page respond to a CSRF attack?

In case you are using a secret token solution to counter CSRF attacks. There can be many response strategy in case you do not receive the secret token in your request where you expected it ( I will not go into when you should include/exclude the tokens). You need to keep a balance between usability and security

Some of possible response to user can be

Invalidate the session and take the user to the generic session expiry page. THis page can be common page for idle timeouot, use of back/refresh button etc. THis should be considered for web sites like transanctional, handling very sensitive data etc.
Do not invaldte the session, ask user to renter the password
Redirect user to a confirmation page before processing the request

In all cases you should log this as a security event.


What is the industry standard practice for saving a potentially (likely) malicious PDF for analysis?

Don't download it on a regular machine, as various services may try to access it for indexing or for previewing, which can be exploitable. But regardless, how advanced do you expect the malicious PDF to be? Who is your adversary? The answer to that will determine whether or not the answer is just to copy it with your AV enabled, or if you need to do it on a dedicated airgapped test machine.

Corporate espionage is often comparable to nation-states in terms of the risks. If you are a large company or in a high-risk business, consider getting a dedicated security team that can deal with this. If in doubt, use an airgapped system for analysis. Qubes OS uses virtualization for isolation, creating a new virtual machine for each application when necessary. Although it relies on Xen and a Xen 0day could easily break out of individual VMs, it can be quite secure when used on an airgapped machine.

PDF parsers are infamously insecure, so expect that it will not be difficult for an attacker of even moderate skill level to be able to achieve arbitrary code execution when the PDF is opened.


What are the security implications of allowing guest checkout using an email bound to known account?

There is no concern if you are not disclosing anything to anonymous users. When the email address on a guest order matches an existing account, you should proceed as if that account didn't exist. Prompting for a login after getting that information can indicate that the account exists.

Always guide users to the ideal workflow. The use of an established account will make auditing easier for both you and the customer. The availability of order status and history are frequently useful for reasons not directly related to your security. If the customer is expecting order history, then a gentle reminder to login is actually helpful.

When in doubt, ask. I would give the customer the option to login or checkout as guest as the first option after proceeding to checkout. This option should be given before asking for identifying information such as name, address, or payment details. You could encourage users to login by populating billing/shipping information from their account, if you were so inclined.

Mitigate brute force attacks. Regardless of whether you implement a guest option, your process for recovering registered accounts should not indicate whether that user/email is registered. This is somewhat tangential to guest checkout, but it is related since users may checkout as guests because they forgot their credentials. Personally, I would rather reset my password and use saved info than dig out my credit card.

E.g., ask for the email address associated with the account, then display the same message regardless of whether an account exists, e.g.,: "We are searching our database for an account associated with the email@address.com email address. If we find an account, we will send instructions for resetting the password to that address. This may take a few minutes."

The email can explain/link your password reset process on a match, or it can advise them to choose between creating an account or checkout as guest in the absence of a match. As long as the existence of the account is only disclosed in an email to the account owner, there is no appreciable risk.


Enabling wifi or bluetooth before user login in Linux

At a bare minimum, you expose the account the service runs as. If the service is subject to attack, then that becomes a vulnerability.

This is no different from exposing any other service, except that it is exposing a communications channel. The important question is, "what else on the box is using that communication channel?" You need to chase down the cascading services.