Does DNSSEC provide signed statements that a certain domain does NOT yet support DNSSEC? If not, why not?

This means that websites have little incentive to start supporting DNSSEC, as a MITM can spoof a DNS record simply by not including a signature.

This is incorrect. If a MITM attacker sends a result without a signature to a client that supports DNSSEC, the resolve will fail. This is because there is a signed DS record for that domain returned by the TLD's nameservers. The MITM attacker cannot also strip that record, as (s)he will then need to provide a response will a valid signed NSEC/NSEC3 record proving that the requested DS record doesn't exist. This is impossible without obtaining the TLD's (or root's) private key.

It seems that an easy solution to this would be to provide signed statements that a website does not currently support DNSSEC, similar to the way signed negative responses work for subdomains.
Is this a part of DNSSEC, and if not, why not? What other solutions are there to this problem / is it a problem?

There is no specific record responsible for domains that don't support DNSSEC. Instead, the server will prove that the DS record (which indicates the domain uses DNSSEC) doesn't exist.

One of the reasons was that for backward compatibility reasons

The EDNS specification is fully backwards compatible. As DNSSEC uses EDNS, it is also fully backwards compatible. Clients that don't support DNSSEC simply won't request (and the server won't respond with) DNSSEC signatures. These clients will not receive the benefits of DNSSEC, but will be able to query DNSSEC signed zones with no problems. The use of DS records on the root nameservers and the TLD nameservers allows for TLDs and domains to not be signed without any issues (However, such TLDs/domains will obviously not receive the benefits of DNSSEC).


Is Vimium (Chrome extension) really safe?

It's not malicious. That doesn't mean that it's 100% safe (almost no piece of software is), but if there are any security holes, then they will be bugs, and not something the author has intended to do. It has 67 contributors on github and I'm sure a lot more people have wen't through the code without making any contributions (especially knowing the fact that it's mostly used by programmers who are used to VIM editor).

There are some 130+ reviews in the chrome webstore too.


is it secure to use sha256 to hash 64 cryptographically random byte data with 12 byte salt?

You're confusing cryptographic hashes with password hashes. A cryptographic hash takes an input and gives a random looking output. A password hash takes a password and a salt and very slowly gives a random looking output.

What you are worried about here is preimage attacks. You want to ensure that, knowing a hash y, the attacker cannot find a value x such that h(x) = y. 80 bits of complexity is still generally considered "good" (though not "great", and possibly vulnerable to a well funded attacker such as a nation-state). What this means is that you want a hash where the best preimage attack has a complexity of over 80 bits.

Analysis

Let's start with MD5 since it's something of a poster child for outdated crypto. The best known preimage attack on MD5 is 116.9 bits, well above 80. But you want to protect 1 trillion secrets, which lets the attacker do some optimizations.

Let's assume the attacker is able to use a hash table (and many terabytes of RAM) to check if a hash matches any of the 1 trillion in O(1). With 1 trillion secrets this reduces the complexity to break a single secret by log2(1012) ≈ 40 bits, which brings MD5 down to around 76 bits. Still not terrible, but worrying if you're facing a nation-state or want to keep these secret for many years.

But you're doing the right thing and using SHA256. The best preimage attack I could find on SHA256 was for reduced steps, and still had complexity over 250 bits, so you're looking at over 210 bits of complexity there. In this case an attacker will be running into some issues with physics.


How secure is SSL/TLS, explained in laymans terms?

What kind of security level does TLS provide, as of 2019?

Quite a good security level, under the assumption that the configuration is according to best practice. I'll try to explain what I mean using lay terms. This means I will stray a little bit from technical accuracy to make it more understandable for people who may not have a lot of experience in security.

TLS is not like Coca-Cola, it's like Steak!

When you go to the grocery store, and you go buy a can of Coca-Cola, you expect it to taste exactly like all the other cans of Coca-Cola you have ever drunk before. TLS is not like that! TLS is more like Steak. You had some good ones, you had some bad ones, and all of them taste different, depending on the meat and on how well it was cooked.

What that metaphor should show is that a question like "Is TLS secure?" is akin to asking "Does steak taste good?". The definite answer is maybe! You can have TLS that is considered very secure, and you can have TLS that offers no security whatsoever. Just like how you can have steak that tastes so amazing you will talk about it for a while, and how you can have steak that tastes like somebody put a shoe sole on a grill.

  When do I know if TLS is secure?

The meat of TLS

TLS is based on ciphers, just like steak is based on meat. A cipher is a fancy term for throwing a bunch of cryptographic stuff together, but the details don't matter for a lay explanation. The first ciphers we made were bad. We didn't know how to made good ciphers, but we eventually learned from our mistakes. Modern ciphers are considered "more secure" than old ciphers, because more knowledge went into the new ones than into the old one's. (Just like how the first steak a chef cooks will not be as good as the 1000th steak).

TLS is considered secure, if it only allows good, modern ciphers. Old, bad ciphers can cause problems!

  What does it take to attack TLS?

It depends on the ciphers being used. In the absolute worst possible case, this means that TLS is configured with a NULL cipher, meaning that no encryption or authentication is done at all. This shouldn't be accepted by clients anymore today, but if you run a very old and outdated system, it might.

In a more realistic "worst-case", it could be that TLS is configured in a way to use weak ciphers. While these ciphers are not trivial to crack, a sufficiently advanced attacker (think NSA, etc.) can certainly do it. If really weak ciphers are chosen, then even less sophisticated hardware may be necessary.

  Should I, as a normal consumer, worry about TLS?

Most likely not! Modern phones and operating systems are configured in a way that they only allow good ciphers. The chance of an attacker being able to crack one of those to sniff your traffic is very, very, very small. It is currently not known if any of the Alphabet Boys (e.g. NSA, etc.) are able to crack any of those ciphers.

On the other hand, if you use Android 2.3 or Windows XP, then it is time to upgrade to something more recent. Aside from the numerous other reasons for switching away from a long obsolete system, these operating systems don't support any modern ciphers. To fit with our analogy, they're like a store that only sells horrible old "meat".

The only time you should worry is when you see errors related to TLS. It is most likely an error on the side of the server you are trying to connect to, but it might also mean someone is trying to spy on you.


What's involved in taking over someone else's domain name?

Domain hijacks don't happen via web application hacks, but are usually via vulnerabilities in the domain registrar's system, or by managing to intercept/take over the email accounts the domains are registered to - so the attacker can reset the passwords and intercept the transfer emails, agreeing to the transfer.

Normally it'll happen by managing to convince the domain registrar that the attacker is the owner of the domain, using personal information about the domain owner to access their account on the registrar and then either switch the DNS servers to an attacker's DNS servers from where they can redirect how they like, or by transferring the domain to the attacker.

Or of course there's simply waiting for the domain to expire and grabbing it before it's renewed.

ICANN produced a report in 2005 about this issue, covering the risks and actions you can take.


Is it possible to inject something into this even if it's in an if statement?

Yes. With multiline queries, a simple '; drop table usertable;-- works. With single line queries, ' (select abc from def),0)-- can work, though with some more nesting you can run pretty much anything.

How can you escape out of this query?

Simply escaping everything won't work, as this may change the meaning of some of the characters. You have to be careful.
Stuff like mysqli_real_escape_string() are also vulnerable. Use prepared statements.

Is there a possibility to echo the whole statement so you could get more intel in the php used, meaning that the whole result query is being echo'ed due to the injected code?

Sure, store the string first and then echo it. But that may be worse, it's best if the attacker can't see anything. It's preferable to log the queries.

If this has a potential SQL injection situation. Are there any people dumb enough to code this way?

It's not so much dumbness as cluelessness/carelessness, but yes. MySQL injection is one of the most common web vulnerabilities out there.


What risk rating models are used for calculating risk scores of web vulnerabilities?

The Factor Analysis of Information Risk (FAIR), or any Value-at Risk (VaR) model, whether based on MC (Monte Carlo Method), Bayesian statistics, or other sound variable-crunching, model-bound, formulaic risk analysis -- any of these will culminate is a more-efficient risk calculation.

If you are a member of ISC2 (e.g., CISSP), you can check out CyVaR by PivotPoint Analytics (used to be CyberPoint Intl but now a division of) -- http://go.pivotpointra.com/lp-isc2-member-benefit

CyVaR, similar to RiskLens, is a way of engaging information risk in a VaR model. There is also a ton of information in the following three books (increasing in efficiency):

Measuring and Managing Information Risk
Cyber-Risk Informatics: Engineering Evaluation with Data Science
How to Measure Anything in Cybersecurity Risk

Book one would be the most-actionable of the three today, but that may change soon. In the book, you will commonly see vulnerabilities treated as a single variable called Vulnerability, which is a variable among several that bubble up to FAIR's version of likelihood, what the FAIR standard refers to as Loss Event Frequency.

What you need to know about Loss Event Frequency (LEF) is that LEF dictates not only "how" likely, but "how often in frequency". A generic likelihood variable would leave a questioner hanging if an event is "likely" to happen today, this week, this month, this year, this decade, or some other unspecified date. It doesn't say how many exact events will occur. LEF changes all of this -- it gives the decision makers the power to understand how often and how many times (e.g., per year) a loss event will occur.

While I won't likely convince you in this single answer, the Vulnerability variable is difficult to control through mitigation (the Open FAIR standard refers to these as vulnerability controls) which would affect the underlying Difficulty variable. If a Threat Community's (TCom) Threat Capability (TCap) variable overcomes the Difficulty variable, then any TCom with a sufficiently-advanced TCap will cause Vulnerability to rise above 90 percent (often to 100 percent) and thus a loss event will almost certainly occur on this side of the LEF equation.

Let me put this in context for you. Let's say that the Dukes (aka CozyBear aka APT 29) decide that a web-app entry point will grant them a web shell against a target US-based financial services company. A few officers of the Dukes (i.e., handlers) have led a few confidential assets in Eastern Europe to believe that they are participating in an online carding forum. One of the assets has some webappsec experience and is handed a fully-cracked webappsec scanner, Acunetix, at the latest version. The asset runs it against a list of financial services websites provided to the actor by the handlers, who used a previous confidential asset team to conduct the reconnaissance necessary to build a list they are proud of.

After about three weeks, the asset is confident that many webappsec vulnerabilities could be used to upload a webshell, but some of them are SQL injection and have non-standard RDBMS backends, such as PGSQL and DB2. Perhaps one of these also has a web-app firewall (WAF) in place. The Eastern European asset does not have the TCap to bypass the WAF or to load a web shell through these vectors. However, after reporting through the forum (our secondary TCom) up the chain and back around to the Dukes (the primary TCom), the Dukes have the necessary talent to bypass the WAF (e.g., custom tamper scripts they built against the target's WAF using a modified version of sqlmap) as well as the understanding of how to build a web shell against PGSQL and DB2 backends. Thus, the TCap of the Dukes TCom is high enough to bypass all of the Difficulty.

In this case, the target web servers happen to also be connected to at least one Microsoft Domain through BeyondTrust PowerBroker or winbind, and the Dukes utilize the getent(1) utility to dump the users as well as laterally move into the network through SMBRelay and JASBUG. Let's say that the Domain has a trust relationship back to the Microsoft Forest that eventually gives the Dukes Forest Administrator access, and thus read-write to all domains including ones hosting services such as SAP ERP and SAP S/4 HANA, in addition to Oracle Hyperion, HMIS, Essbase, and JDE. These services also host databases that contain the employee, partner, contractor, and customer records -- in addition to financial records, company-wide financial services, and intellectual property. At this point, the Dukes install persistence layers that allow them to act as system administrators with an average longevity of 5 years (typically 3-9 years). At this point, the VaR is the entire company's top line growth -- all of its sales; all of its revenue-generating business.

Do you rate such as scenario as critical? Do you use bold or red in your compromise-assessment report? According to FAIR, the VaR should be shown in monetary amounts, such as US Dollars.


Should OIDC introspection endpoint be used to validate the JWT access token?

It depends on your threat model and the implementation of the Authorization Server. The principal reason to check with Authorization Server is to know if the access token has or has not been revoked. From oAuth token revocation spec (RFC 7009):

  OAuth 2.0 allows deployment flexibility with respect to the style of
  access tokens.  The access tokens may be self-contained so that a
  resource server needs no further interaction with an authorization
  server issuing these tokens to perform an authorization decision of
  the client requesting access to a protected resource.  A system design
  may, however, instead use access tokens that are handles referring to
  authorization data stored at the authorization server. This
  consequently requires a resource server to issue a request to the
  respective authorization server to retrieve the content of the access
  token every time a client presents an access token.

  While these are not the only options, they illustrate the implications
  for revocation.  In the latter case, the authorization server is able
  to revoke an access token previously issued to a client when the
  resource server relays a received access token.  In the former case,
  some (currently non-standardized) backend interaction between the
  authorization server and the resource server may be used when
  immediate access token revocation is desired. Another design
  alternative is to issue short-lived access tokens, which can be
  refreshed at any time using the corresponding refresh tokens.  This
  allows the authorization server to impose a limit on the time revoked
  when access tokens are in use.

  Which approach of token revocation is chosen will depend on the
  overall system design and on the application service provider's risk
  analysis.  The cost of revocation in terms of required state and
  communication overhead is ultimately the result of the desired
  security properties.

Translation: if you're worried about token revocation, you should contact Authorization Server. The Introspection endpoint is the standard way of doing so.


When using PGP/GPG, is it safe to use the same public/private key pair on multiple computers for the same person?

The private key is owned by a human, not by a machine -- indeed, the normal case is that you (as a user) have one key pair, and use the private key on all machines where you need to.

Having a key pair per machine would not work well; this would mean that when people send you an encrypted email, they will use one of your public keys, and you will be able to read the email only on the specific machine which contains the corresponding private key. This is hardly convenient.

We can say that as long as you want to read the same emails on several machines, then these machines must contain private keys which are functionally equivalent. Making these private keys distinct from each other is then a useless complication; just accept that you really want to have your private keys in several machines. Of course, the security of your key against theft will then be bounded by the security level of the weakest of these machines. You have to balance the convenience of being able to use many machines to read your emails, with the increased risks.

To move the private key safely (independently of the wisdom, or lack thereof, of having the same private key in many machines), you should protect your "keyring" with symmetric encryption and a passphrase of high entropy. Encryption of the keyring with a passphrase is the normal setting, so your job is "just" to use a strong passphrase. Since the format allows for reasonably strong password hashing (with iterations and salts), you can get away with a passphrase of entropy 60 bits or so. With such a strong passphrase, the keyring is "inherently" strong, and the travelling key is no longer an issue.


This can be done (see other answers) but the better question is-- even if you spent $1000 on all-new networking equipment, routers, wifi pineapples and whatnot, and you successfully captured the burglar's phone's hardware MAC address, the better questions are:

How does this prove that the actual owner of the phone was in your house (and the phone itself wasn't stolen, along with six others in his possession),
Does your rural PD actually have any digital forensics experts on staff, and
Even if they did, would they actually do anything with this evidence?

I've seen cases where burglars left visible fingerprints and other more low-tech evidence at the scene, which went ignored by investigators. Your solution, while clever, would probably not be sufficient evidence to convict anybody. Your money would be better spent on infrared CCTV. Juries are much more easily convinced by video evidence than long explanations about hexadecimal numbers.


What are the most effective ways to stay anonymous in the internet?

Go to a cafeteria where free Wi-Fi is available. Take your laptop and run  Tails Linux from a USB stick: your Internet connections will go through the Tor network which is the best implementation of onion routing, and offers very effective cryptographic tools to secure your online exchanges; and whatever you do  no traces will be saved in your USB stick -unless if you choose that explicitly by modifying the default settings.


How to listen on all encrypted (SSL/TLS) traffic of a (Windows) system under your control?

There's no way to guarantee the ability to listen to all TLS traffic from a given host. As you mention, the malware might not even use the system security store. It also might have a hard-coded certificate (or at least public key) that it is expecting, in which case it will notice any attempt at a man-in-the-middle attack unless you can steal the server's private key (or crack the public key).

You do have a few options, though. Since you're really only interested in cracking traffic from one particular program, this gets somewhat more plausible.

Attempt to reverse engineer the binary and see if there's a hardcoded certificate or key in it. If so, you can attempt to replace this key with the one your MitM uses. However, this will change the binary's fingerprint, so if it attempts to validate its own integrity you'll need to eliminate or patch that check, too.
Find out what crypto library the malware is using, and replace it with a "backdoored" version that logs all traffic to plain text. If it's just using the Windows libraries, you'll need to obtain or create such a backdoored one but it should be possible to force the process to use it (although, again, if it's checking the fingerprint or signature on those binaries then this won't work until you patch that out). If it's using a third-party library such as OpenSSL, you can replace that easily, though again look out for authenticity checks. If it's using statically-linked code, this approach is much trickier but might still be possible by dynamically patching the process image at runtime to replace the TLS code's entry point with a backdoored function (though this will require significant reverse engineering).
Attempt to reverse engineer the malware enough to just patch out the use of TLS, and tell it to send the traffic in plain text instead. The server obviously won't accept this, but you can use an invisible proxy that encrypts the outbound traffic (and decrypts responses) and logs the plain text both ways. Again, beware integrity checks, and also the server might expect a client certificate that you'll need to pull out of the binary.
Attempt to reverse engineer the program enough to tell what it would do from static analysis. This won't tell you what the server would say, but should in theory let you write your own client that the server will trust if that part interests you too. However, any half-competent malware author will include protections and obfuscations to make reverse engineering the binary very hard (this applies to all previous approaches requiring reverse engineering too, of course).


Information Security Policy and Information Security Plan

Your Information Security Policy is different from your Information Security Plan:

Your Information Security Plan should include all required actions for organization-wide implementation of your Information Security Policy. Although the two are closely tied, they are also separate documents.

A solid Information Security Plan will typically include several phases, depending on your existing infrastructure, network / systems topology and configuration. You may need several distinct technical phases to implement the required security controls without major service disruption. This is entirely subjective, and is up to you, the Security Engineer, to envision.

Note that if compliance with NIST 800-53 is required for your organization, the key word is required: Your organization will be expected to show proof of Due Diligence and implementation of all required items, and as many "suggested" or "recommended" items as technically possible/feasible.

Good luck!


What is the procedure to implement security zones in a production network without impacting negatively in the communications?

I've got nothing more than common sense to offer.

Tap the network, collect network flows and verify the network flows.
Introduce rules to permit those network flows.

When we did this, we discovered that network flows are a long tail distribution. Work from both ends:

Work with stakeholders to determine business needs, and document those as firewall permit rules.  This requires a lot of soft skill negotiation in tandem with other activities.
Study the high traffic flows, validate that they are aligned with business needs, and permit them explicitly
Study the low frequency network flows and see if they align with business needs; if not, block them
Get access to a blacklist with known bad actors; alarm or block these (this is a good step to use to feed to stakeholders

In each case, when you think you've identified a bad flow, run it as an alarm until you can get stakeholders to agree that it is not aligned with business needs.

Depending on how close you are to your management, I'd measure each of these steps and advertise the results.  Measure the bandwidth through your permit rules and your deny rules and let management know that you've preserved teh value of X MB (and at the current price of bandwidth, that's $)  And you've denied Y MB of traffic (at the current price, that's $.  I'd probably also include that I'm studying ZMB of traffic.  Ultimately your work is blocking attack, preserving network for legitimate uses, and significantly advancing the state of the company's continuity of operations, disaster recover and devolution plans.


Should you recompile your software with these flags enabled?  In general, no.

Most software used by the average person is not seriously threatened by Spectre.  It's a very difficult attack to pull off, and requires that the attacker already be able to run arbitrary code on your computer.  Additionally, Phoronix's benchmarking shows there can be a substantial performance hit (sometimes as high as 40%), and that hit often shows up in things like video games that are performance-sensitive but don't handle secret information.  If you're feeling paranoid, you might consider recompiling your kernel, web browser, and password manager with these flags, but other than that, the security gain isn't worth the drawbacks.

If, on the other hand, you're running a shared-hosting service, or are running a moderately valuable site (eg. e-commerce) on a shared-hosting service, you should consider recompiling your software with Spectre mitigations enabled.  In this situation, arbitrary code from unknown users is running on your computer all the time.  Additionally, you may be handling information that's valuable enough to justify the time needed to pull off a Spectre attack.

The difference between "thunk", "thunk-external", and "thunk-inline" is basically a performance-versus-size tradeoff: "thunk" creates one thunk section per input file, "thunk-inline" creates one per indirect branch or function return, and "thunk-external" uses one thunk section for an entire program.  Thunk-inline is usually the fastest, but if it causes code to grow large enough to overflow the available cache space, it can cause significant slowdowns.


As a rule, traceability is good. In some jurisdictions, you are supposed to keep logs for some minimum amount of time. So I would say: keep an entry for the banned user. Abusive behaviour may have legal consequences (depending on the kind of abuse, another user may wish to trigger legal retaliation, or law enforcement agencies might declare themselves interested on their own account). If you are not able to show logs and other traces, then you could be suspected of being an accomplice, which is rarely a good thing.

In any case, you most probably have other, technical reasons for keeping the banned user entry around. If your Web site is some kind of forum (a typical reason for banning being abusive behaviour when writing) then your forum database contains some messages which refer to the user as author. By deleting the user entry, you would make these references dangling links, which can only confuse your forum management software. Deleting the banned user would then entail deleting all traces of his activities on your site, i.e. pretending that the user never existed at all in the first place. This is probably hard to do, if at all possible.

Also, a user who gets banned is also a user who got bad reputation. You can delete forum posts and records, but you cannot delete reputation. If the user entry is destroyed, another user may register and happen to use the same name, thus unwillingly inheriting the dubious fame.


Generate a .p12 certificate which contains only root certificate

openssl pkcs12 -export -nokeys -in certificate.cer -out pkcs12.pfx


Is posting data to a https address secure?

The SSL "bridge" is established first, otherwise all the post data will be sent in cleartext, I am assuming you don't want this.

The whole point of https is to establish a secure connection in a insecure environment, hence we need root authorities that we trust.  This is established via trusted certs, public/private keys etc... all done in the background.  In other words you do not need the post data to establish the secure connection:)

Hope that helps.


Penetration Testing vs Secure Source Code Review

How exercise of independent third party secure source code review is
  different from penetration testing?

The secure code review is a white-box methodology where the code reviewer will be using automated tools and/or manual approach to identify security issues in the the given source code whereas, penetration testing is mostly a black-box methodology where the organisation will only provide only the IP address or name/URL of the application under test. In the penetration test the security analyst usually starts with information gathering and will then identify the vulnerabilities in the system. Later, the analyst will attack the system under test and will try to penetrate deeper and deeper so as to identify more security issues and to evaluate the impact of the identified vulnerabilities.

  What are limitations of independent third party secure source code
  review and penetration testing and do they cover each other where they
  are limited?

It purely depends on the type of engagement with your vendor. Mostly, they don't cover each other. I personally recommend both penetration test and secure code review on the application. Secure code review is more of a static approach. Although, modern secure code review tools offers dynamic capabilities such as taint analysis where the data in motion is also analysed but again my personal experience says that secure code review can never accomplish the results of penetration test and vice versa.

  What areas independent third party secure source code review covers
  which penetration testing doesn't and vice versa?

As already stated, both of the approach can be used to achieve better results. I hope I can explain it better using an example. For an instance, server-side secure code review will include the password management checks. In the scenario where a weak hashing algorithm such as MD5 is used to hash the user's password. This security issue will be identified in secure code review where the issue may not be identified in a penetration test if the server/code access is not attained.


How does the Windows "Secure Desktop" mode work?

Short answer

There are three, separate issues claiming the name of "Secure Desktop":

Windows builtin functions like GINA and the Credential Provider Model.
Separation of privileged vs unprivileged applications running as the same user (nominally prevent privilege escalation), which may or may not be related to:
SwitchDesktop(), which is what KeePass is using and may or may not (I'm not sure) be resistant to DLL Injection.

Detailed answer

As a quick primer to how Windows GUIs are built, basically everything runs through a function called CreateWindow() (I mean everything, every button, every menu, everything) and is given a hWnd or Window Handle. Modifying these Windows is done via another function, SendMessage().

Here's the catch. As a user mode application, making the right API calls I can fairly easily send messages to other Windows. It's fairly trivial to make buttons disappear from other people's forms. It is a little harder to perform DLL injection and hook the message loop that receives messages (the OS sends Windows messages when things happen to them) but not that much harder. If I can hook those events, I could automatically submit your "yes/no" form. Or, I could change the label from ReallyDodgyVirus.exe to explorer.exe and you'd be none the wiser.

Insert: A really good article on the various techniques of getting your code into the address space of a running process.

Now, what are KeePass doing?

A very brief perusal of the source shows they are using CreateDesktop(), SwitchDesktop() and CloseDesktop() to create a second desktop connected to the physical viewing device you're on. In English, they're asking the kernel to create for them an isolated desktop whose hWnd objects are outside of the findable range of any other application's SendMessage().

I should point out that SwitchDesktop suspends the updating of the UI of the default desktop. I'm not sure if the message loops are also frozen - I suspect not since the desktop is created as a new thread.

In this instance, KeePass is drawing the UI, so the execution is not, as I understand it, as NT AUTHORITY/SYSTEM. Instead, the new desktop is created in isolation from basically the rest of the current desktop, which protects it. I'll be happy to be corrected on that. However, see the MSDN for SwitchDesktop:

  The SwitchDesktop function fails if the desktop belongs to an invisible window station. SwitchDesktop also fails when called from a process that is associated with a secured desktop such as the WinLogon and ScreenSaver desktops. Processes that are associated with a secured desktop include custom UserInit processes. Such calls typically fail with an "access denied" error.

I believe this means that these dialogs (screensavers, Windows Logon) are built more deeply into Windows such that they always execute as NT AUTHORITY\SYSTEM and the UserInit process creates the sub processes on valid authentication at the required privilege level.

The reason I bring this up is because I believe there are two issues: different desktops and privilege separation. From Mark Russinovich's discussion of the topic of Secure Desktop:

  The Windows Integrity Mechanism and UIPI were designed to create a protective barrier around
  elevated applications. One of its original goals was to prevent software developers from taking
  shortcuts and leveraging already-elevated applications to accomplish administrative tasks. An
  application running with standard user rights cannot send synthetic mouse or keyboard inputs
  into an elevated application to make it do its bidding or inject code into an elevated application
  to perform administrative operations.

As SteveS says, UAC runs a separate desktop process as NT AUTHORITY/SYSTEM. If you can catch UAC in action (consent.exe) via process explorer, it looks like this:

Escalating privileges as a process I don't have the specifics of, but here is what I think I understand: I believe the process of privilege escalation in the Windows API causes a process running as NT AUTHORITY/SYSTEM (therefore able to execute the new process under whatever privileges it wants to, in this case an Administrator). When an application asks for higher privileges, that question is asked to you on a new desktop locally, to which none of your applications can get either the Desktop Handle or any of the GUI element handles. When you consent, consent.exe creates the process as the privileged user. Thus, the process running as NT AUTHORITY\SYSTEM is a consequence of the need to create a new privileged process, not as a method of creating a secure desktop. The fact the desktop is different to the default is what adds security in both cases.

I believe what Mark means above is that, in addition to these secure desktops, two things are happening:

Your default administrator desktop is in fact running unprivileged, contrary to Windows XP and earlier and
Unprivileged and privileged applications now exist on separate desktops (disclaimer: could just be ACLs on the objects in memory, I'm not sure), ensuring that unprivileged code can't access privileged objects.

The Windows Logon UI is different again in Vista/7.

Clearly, none of these methods will defend you against kernel mode rootkits, but they do prevent privilege escalation and UI integrity compromise by isolating privileged applications, or in the case of KeePass, the sensitive dialog.

Edit

Having looked harder at the KeePass code, I saw this handy piece of C#:

Bitmap bmpBack = UIUtil.CreateScreenshot();
if(bmpBack != null) UIUtil.DimImage(bmpBack);
/* ... */

SecureThreadParams stp = new SecureThreadParams();
stp.BackgroundBitmap = bmpBack;
stp.ThreadDesktop = pNewDesktop;

From this you can see that in fact in order to mimic consent.exe, KeePass takes a screenshot of the background, dims it and creates its new desktop with the background of the old desktop. I therefore suspect the old desktop continues running even while it isn't being rendered. This I think confirms that no magic NT AUTHORITY\SYSTEM action is happening both with KeePass and consent.exe (I suspect consent.exe is doing the same thing UI-wise, it just happens to be launched in the context of NT AUTHORITY\SYSTEM).

Edit 2

When I say DLL Injection, I'm specifically thinking of DLL injection to corrupt the UI. DLL Injection remains possible on KeePass as a process, I'm just not sure whether it could be used to influence that secure UI. It could, however, be used to access the memory of the process and its threads, thereby grabbing the entered password pre-encryption. Hard, but I think possible. I'd appreciate someone advising on this if they know.


Cant access most websites using a fake AP created by aircrack-ng suite

After some comments, you are on the road... now you must locate exactly your problem. To launch sslstrip I can recommend you this nomenclature:

sslstrip -f -p -k -l 10000

-l to listen on port. so 10000 is default, you can avoid this or change port.
-k this kills possible previous sslstrip sessions in progress, recommended.
-f this change the favicon to a lock similar to used in https pages. It rocks if the victim uses old internet explorer versions, useless on chrome and firefox.
-p log only ssls POSTs

Of course if you launch this, you must activate the rule: iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000 as we said in previous comments.

I think you are doing good the commands... but sslstrip is a technique on which it depends not only on your side. If the "victim" use good built links like https://whatever.com you have nothing to do. He/she is going to ask directly always for an encrypted page.

So many people say "HSTS is the solution to sslstrip". And this is NOT TRUE. I did sslstrip a lot of times testing access to pages with HSTS and it works... they key as I said is the victim must do the http (without "s") initial request.

Another decisive factor is that not everypage can be sslstripped if you use common browsers on last versions since some years ago... I mean, if you use modern Chrome, Firefox or Internet Explorer for example... these browsers have an internal list of known ssl sites. That sites (like twitter or facebook for example) will never be sslstripped because the browser knows that ALWAYS must look for them using https even if the user did the "bad way request" putting facebook.com without specifying the https:// before. I guess these sites pay to the browser's companies to be in that list.

There are more advanced techniques to do sslstrip even to pages in that lists... like Delorean attack, or using sslstrip+ also called sslstrip2 which requires dns and proxy etc... but are more complicated.

I suggest to you try against not very known ssl pages because in that way there are less possibilities to crash in your tests against a site which is in that browser internal lists.

Good luck!


Crack Linux password if you have plaintext and hash?

The hashing algorithm used is not part of the secret. The hashing algorithm should always be assumed to be known. You can read up to this here.

In fact, the string you find in /etc/passwd or /etc/shadow tells you which hash has been used right in the first number:

$1 → md5
$2 → blowfish
$2 → eksblowfish
$5 → sha256
$6 → sha512


Would it be possible to use cookie to store SSL Client Certificate?

A cookie has only one function: to be sent back to the server. It is stored on the client, but the client does not understand its contents; and the client does not use it except by sending it back.

Which basically explains that the "answer" you quote is not a real answer: it tries to side-step the problem by stating that side-stepping the problem would be cool. The whole point of cookies is to be client-side storage under control of the server; the whole point of client-side certificates and private keys is to be client-side storage that is NOT under control of the server.

In fact, client-side certificates have no real value when there is only the client and the server. Certificates make sense when a third entity enters the dance: the Certification Authority. A certificate uses asymmetric cryptography so that the client may prove its identity to the server without allowing the server to impersonate the client; this contrasts with show-the-password authentication methods in which the server necessarily learns the user's password in the process. That property of certificates is of any use only if the server was not the one who issued (signed) the certificate in the first place; otherwise, a dishonest server may emit fake user certificates at will.

So the lack of client-side certificates in the Web as we know it right now is not really a "usability problem"; it rather pertains to the idea that certificates don't have extra value for the way Web sites handle authentication (namely, each site handles its own authentication needs). Delegated authentication (like OAuth) may change this model, which would then indirectly prompt for more deployment of client-side certificates, with better user interfaces.


Should a closed source website keep a secret key in its source?

My recommended practice is not to put keys in source code. The best option for your particular situation depends on some of the details.

Generally, the preference is to keep the key in a separate file that is not stored in the source code repository. You can even have a secrets directory if you like and store the keys there. Generally you issue the keys to appropriate users -- those who need to make final builds or builds that can test the functionality that requires the key.

If you have individuals who work with your source code who are not fully trusted with the keys (for example, if outsourced programmers add to your code) you can rig the code to operate in a fallback mode if it doesn't have the secrets. This may or may not be appropriate to your situation.

I should point out that there really is no good way to keep the key secret if you distribute the object code. This method really should only be used in programs that are not just closed source but closed distribution. If you have to do some obfuscation, not just the key but the obfuscator should be in the secrets directory and its distribution restricted.


Is there a backdoor in the hardware of our smartphones?

I don't know for you but I always felt like Android especially is not safe. Is somebody - the government or other - able to listen to my microphone, or access my hard drive remotely?

Why do you think Android might be especially vulnerable? I expect the NSA has the tools to snoop in on practically anything connected to the Internet.

  I'm wondering if secured apps like Textsecure and Redphone really help or are just an illusion. Indeed it is pointless to secure the transport if the source and the destination are corrupted with a security hole at the hardware level.

Indeed, but it sounds pretty expensive to built a security hole at the hardware level when a software one will work admirably.

  Can the monitoring of our network really tell us if we are spied ? The data sent to government agencies could be excluded by the author of the network monitoring app.

Most likely, such data would not reach the network monitoring app at all. After all, all a network monitoring app does is use a public API to sniff the data; it doesn't have a direct link to the fabric of the universe, right? The way to check would be with a passive cell signal receiver ... and you'd have to transfer the encryption keys used by the phone to it in real time; massively complicated stuff. But it'd be relatively easy to spot "extraneous" packets included in that capture but excluded by a network monitoring app.

  Also, at the software level, can we really assume that Android is safer since it is - supposed to be - open-source ?

Not unless you obtain a copy of the source, the whole source, and nothing but the source, and compile and flash it from a toolchain known not be compromised. And even then only if you trust that vulnerabilities in "open-source" software are rapidly found. Historically, this hasn't been the case. Consider how long the heartbleed vulnerability was around before it was found, and the underlying bug wasn't even hard to spot.

  Well lot of questions, but I'm trying to find a middle ground between concern and paranoia.

The simple thing to do here is just don't do anything that might raise flags for the NSA. They really don't care about your communication with your girlfriend(s).


What is the effect of the arguments in the following: conhost.exe 0xffffffff -ForceV1

The argument is the console application ID/session ID to which conhost should "connect" to. The value is mediated by csrss.


Login from a desktop application to a web application

I had this problematic a few weeks ago.
I simply resolved it by making a webservice accessible via Https.

The user login from a local client application via a login/password form which is sent by https.
The server get the data and send a Token to the client.

The Token is stored into the application for login purpose and expires after 2 weeks. When the Token expire my client has to login again.

My request are https based, so it takes care of the handshakes,encryption,etc.

A large amount of WebAPIs use this method to make secure transactions.

If you notice a large amount of login fail tentatives on server side, block any upcoming tentative from the client for a given amount of time, which will increase after futur failed attempts.


How to convert IBM Domino SSL keys (private key) to the OpenSSL format?

If you are referring to the .kyr format, you can use a tool thats part of websphere called iKeyman (ftp://ftp.software.ibm.com/software/lotus/tools/Domino/gsk5-ikeyman.zip).

A quick overview of what you need to do can be found here: http://labs.groupwave.be/index.php/2009/08/31/exporting-kyr-certificate-for-apache/


What are the security issues of exposing default server home page in public internet?

Exposure of these details allow attackers to conduct enumeration, which is the process to extract and obtain information of targets in order to launch future attacks.  For example, knowing the PHP version that is running on a particular server allows an attacker to find what vulnerabilities are on that particular version that could be exploited, providing that these have not been patched. This is just a simplistic example of enumeration.

There are website resources out there that discuss this in further detail, the techniques used to enumerate various information, and so on.


How to make sqlmap exploit an SQLi vulnerability

Since you mentioned that you found a boolean based blind SQli, you will require a sqlmap input such as the one below:

#sqlmap -u "http://host/path?param=123" --technique=B --level=5 --risk=3 --random-agent --dbms=MSSQL

--technique switch will force only Blind SQLi Attacks
--random-agent will ensure you use a legit user agent, most of the vulnerabilties fail to get exploited if you don't provide this since
the site may lock you out seeing an unknown agent
Increase the level
Also, your query doesnt have any other parameter so skip providing
the parameter part and suffix and prefixes


Can you get virus from previewing email attachments in Gmail?

You are actually opening the file in the browser. If the browser has a vulnerability that the file exploits, it is possible (though unlikely at this point) that you can get infected.


What can be done with the last 4 digits of one's SSN

Far too many places use the last 4 of a SSN for customer support representative (CSR) validation. It's supposedly one of those "pieces of information" only you would know, but, sadly, is more often better known that we'd like to think. It can then be used as part of a social engineering attack to gain access to, or control of, an account. Here's an account of how something similar was used to gain control of a reporter's Apple account and wipe all his devices.

As Honan explained, Amazon allowed users to add a credit card number to an account simply by calling Amazon and providing a name, e-mail address, and billing address. After hackers used this method of adding a credit card number to Honan's account, they hung up—and then called Amazon back to claim they'd lost access to the account. At this point, they provided the fake credit card number, convincing Amazon to let them add a new e-mail address to the account. The next step was going to the Amazon website and requesting that a password reset e-mail be sent to that e-mail address. From there, the hackers could view the last four digits of Honan's credit cards on Amazon's website.
With those four digits (and Honan's username and billing address), hackers convinced Apple to send a temporary password that let them take over his iCloud account and wreak all sorts of havoc. "The very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification," Honan wrote.

I can't tell you how often I've had a CSR just take the last 4 of my social as proof that it's me.


Rating social engineering threats in a penetration test report

I'm not sure that I would rate it at all. Rating requires that you can define the limits and boundaries of the risk. The potential for every social engineering attack is extremely high.

If you successfully performed a social engineering attack, then I would simply list the event and the extent of the effect you had.


How can one secure a password/key in source code

Short answer: you can't.

You can't never protect a password that you are distributing. You might hide it between some strings and use other operations to "cover" the password but, in the end you will have to put it all together to make your function to operate. And here is where the cracker is going to take it.

There is no easy way to solve this problem and usually it means that you have not chosen the best security scheme or, if you feel it is enough, maybe it means that you just don't need this kind of security.

And if you really, really, really need to do in that way you will have to go with "security by obscurity" after all, the longer it takes to be cracked, the better. You better have some detection system for when this happens.

As an example, consider the gaming industry all these years with their copy protections and so on, if there would have been a way to achieve security within the code itself that would mean the end of "piracy".


"acceptable client certificate CA names" OpenSSL

This is the list of certificate authorities which are accepted by the server as issuer for the client certificate. The client can use this list to select the appropriate client certificate. See RFC 5246 (TLS 1.2) section 7.4.4:

  certificate_authorities
  A list of the distinguished names [X501] of acceptable certificate_authorities ... may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space.


security issues related to setting cookie using an  tag

TL;DR: If the cookie you use can be used to authorize any action on site B, then that site becomes vulnerable to a CSRF attack.

As @Sjoerd has already pointed out in his comment, you need to set the SameSite attribute of the cookie to None, otherwise the cookie won't be sent to site B when the image is retrieved.

This could very well be a vulnerability, depending on the effect the cookie has on site B. The SameSite attribute was invented to prevent a Cross Site Request Forgery (CSRF) attack. By setting SameSite=None on the cookie, you are disabling that CSRF protection of site B.


An easy way to check if they are somehow getting access to the OTPs (and therefore to your accounts) is to log into your account and theck the activity log. Most reputable services (GMail, Amazon, etc) should have some way to view a list of date/time/location of recent successful logins.

If any of those were not you, then you have a problem.

Are you sure they are triggering your account's OTPs (which would sound like they are trying to get in to your account and / or may have already gotten past the password page)? Rather than signing up your phone number on new accounts (which could be the beginning of harassment / extortion)? OTP SMS messages don't typically tell you which account / username triggered them, but are you getting any OTPs for sites on which you don't have an account?

It's hard to say for certain that your sensitive information isn't at risk (apart from whatever was accessed via your Outlook before you changed the password), but this smells more like a social engineering attack of some sort rather than a technical attack.

My condolences that you've been caught up in this.


What is this hotspot doing to my traffic?

I think you are very close; but checking out superclick.com, seems like its being done for network monitoring and management purposes.

http://www.superclick.com/mama-analytics


How to do client side hashing of password using BCrypt?

I know HTTPS can solve the problem, but I am still instructed to encode the password before sending it over network as per our organizational guidelines.

This really defines your situation.

Basically, you have a simple solution that you should use anyway (use HTTPS), if only because without HTTPS an active attacker could hijack the connection after the authentication step, regardless of any "encoding" and hashing you use for the password (an attacker who is in position to do a Man-in-the-Middle attack will succeed regardless of how much you ritually dance with hash functions and encryption). Then, you also have a guideline that is both idiotic, and administratively unavoidable. Your problem is then: how can you do things properly, and still comply with the "guideline" ?

Note that the guideline makes little sense at several levels. Not only does the lack of SSL makes the protocol vulnerable to hijack; but also any kind of "encoding" does nothing good against passive attackers either. The reason is that if the protocol is "the client shows the 'encoded' password" then a passive eavesdropper will simply look at that "encoded password" and send it himself -- thus, that kind of encoding does not actually improve security in any way. It just makes some people feel more secure because they understand cryptography as some kind of barbecue sauce ("the more we sprinkle everywhere the better it gets").

What I suggest is that you do the following:

First, try to sell the idea that "HTTPS" incarnates the 'encoding'. In other words, by sending the password inside a SSL tunnel, you are already complying with the guideline, since the password is duly encoded (and, really, encrypted), along with the rest of the data.
If the stupidity infestation is more serious and some auditor (let's call him Bob) still throws a fit about your lack of "encoding" then try applying some reversible encoding on the client side. E.g. before sending the password, apply Base64. This means that if the password is "bobsucks", what will be sent (within the SSL, of course) will be "Ym9ic3Vja3M=", and Bob will be happier, because the latter string is obviously a lot more secure.

The important point here is that since the requirement does not make sense, the solution won't make much sense either.


How high is the entropy of this salt-generating code? (No code-reading actually necessary)

Entropy is a measure of the number of possible outcomes for the whole system. If you start with three random bytes, then there are 16777216 possible inputs. Regardless of what you do from these inputs, you will only get 16777216 possible outputs; no amount of hashing & cutting & praying will change anything to that -- except possibly by reducing the number of possible outputs. With your hashing and then truncation to 3 final bytes, there is no guarantee that all 16777216 values for these three bytes will be possible. In fact, you should get about 10 millions of them, no more.

A salt is only as good as it is unique. It does not need to be secret or unpredictable, but you should strive for never using the same salt value twice, or at least to keep the reuse to the bare minimum. If your salts must fit in three bytes, and your source of randomness is three bytes, then the best you can do is to simply use these three random bytes as salt. Hashing them is just a needless complication, which has no security benefit, and actually reduces the space of possible salt values, thus implying a higher reuse rate.

You could generate salts with a non-random process, if you can keep a state. Namely, maintain a counter, which is incremented for every generated salt. Counter management can be troublesome (especially in multi-frontend systems), which is why using randomness is often preferred. But that randomness is just a tool to achieve uniqueness. It is not a problem if salts are not random or follow a predictable sequence. The problem is when you reuse a salt value.


When storing private identifying information in a web application, what is "industry standard" best practices?

If you are not using credit cards, or similar information, you (thankfully) do not need to consider PCI-DSS compliance.

For general 'industry standards' based security for web hosting, look to OWASP:

https://www.owasp.org/


How does "Somewhere you are" authentication add further security?

“Somewhere you are” is NOT an authentication factor, despite what you might have read elsewhere. It is an authorization factor.
Indeed, it does not answer the question "are you who you claim to be?", but instead it answers "should you be there? / are you authorized to be here?". (The answer to the question "who are you?" being an identification, yet another category.)
To further clarify (as asked in comments): Owning a badge, a key or knowing a password (a.k.a. a token) can answer the question "are you who you claim to be?" because the token should unique and should be in its owner possession. Whereas multiple different persons can easily be in front of the door trying to enter.
If in your very specific case, only authenticated persons can be in front of the door, this only means that the authentication has been performed elsewhere beforehand and that you trust this specific location to be a good conveyor of the authentication information. It also implies that you trust this first authentication method. Whether this trust is misplaced or not depends on your threat model.
As a side note: biometrics should only be considered an identification factor (or a most a very weak authentication factor), because you cannot revoke a biometric feature, while you can revoke a stolen authentication factor, by changing the lock or updating the whitelist. End of side note.
This means in practice that you should check the "somewhere you are" factor (IP address, geo-localization, time-locatization (date expiration), etc.) independently of authentication, and preferably after a proper authentication to be able to log the activity and be able to do accountability.
So yes, you can use the “somewhere you are” factor on top of the classical 3 types of authentication factors, but not as another authentication factor, but as an authorization parameter. Whether it's useful depends on the use-cases, and other answers to this question address this point or give examples.


There is no theoretical problem with using test certificates for tests, as long as you apply some proper external protection (e.g. the tests use a test server which is not accessible, firewall-wise, from the outside). Experience shows, however, that test features tend to leak to production. If a developer must remember that he should switch certificate configurations when going to production, then chances are that, at some point, he will forget, and a test certificate with a not-really-private key will be deployed in production.

Hence, it would be best if you include some sort of failsafe. For instance, in its initialization code, the App could test whether the certificate to use is the dummy or not, and if this is the dummy, change a visible feature of the app (e.g. put a red border around the screen, or something like that).


Any reasons to why not use randomize_va_space?

When debugging some C code, especially tracking down after-free-accesses bugs, address space randomization is quite inconvenient, because it makes bugs non deterministic. By turning it off, you can much more easily reproduce the issues. That's a good reason to turn it off on development machines (as opposed to production systems).

As for the slowing down, there is a theoretical effect due to the spreading of "interesting addresses" over a larger space. Since the MMU on x86 hardware uses forward tables to represent the address space (a mapping from virtual space to physical space, contrary to the reverse tables used in recent PowerPC processors), it can be predicted that address space randomization will induce slight additional pressure on the caches (more cache memory will be used to read parts of the MMU tables). However, as for all performance-related issues, I strongly suggest that such a slowdown should be duly measured and confirmed before taking harsh measures. In other words, turning address space randomization off is worth a try if you are desperate for performance on a given system, but it should not matter much on average.


Security implications of putting virtual hosts source code in /var/www/[domain]

As a general rule, things should not be made accessible in ways that were not intended or for reasons that were not intended. The best reason to follow this pattern is because you don't know how it might be abused. Just because you can't think of a vulnerability doesn't mean somebody else can't.

But in this case, I have seen this pattern used against a site owner.

As an example, virtual-hosting operations typically run website content under user isolated users. That is, foo.com runs as the user foo, while bar.com runs as the user bar, and neither can access the other's files.

But a secondary route for accessing site content, such as 1.2.3.4/~foo/ might run foo.com content using some alternate context -- perhaps www-data, for example. And in that case, foo.com/filemanager.php could be accessed as 1.2.3.4/~foo/filemanager.php, which gives the visitor access through the site using a different set of permissions than the site owner thought.

There are other potential vulnerabilities as well that I can thing of -- things having to do with configuration differences, path differences, access-control, and other such details. All of this is somewhat installation-dependent, but the potential is there.


In short I think its unlikely - it would be a very niche solution.

There are numerous services which support syncing of messages from a mobile to online clients - but these work by storing your messages to a database - you could use a dedicated mobile left somewhere secure with a mobile signal to receive the messages.

There are also various online services which allow you to receive SMS's to a dedicated number via their website.

  login protection with google authenticator or similar.

You want two factor for your two factor? :P

I think you are misunderstanding a couple of things. First is the purpose of 2FA. Second is the security (or lack thereof) of SMS. Two factor via SMS is not very secure - it is very easy to view an SMS while in transit (especially if you are within range of the same tower as the legitimate user). Its also not that difficult to clone a mobile SIM. You also need to realise you are inherently trusting a service provider as it is (your cell provider).

So either of the above options simply add an additional party to an already fairly insecure system.

The purpose of Two factor is a separate channel that an attacker needs to compromise. Obtaining a username/password combination and intercepting an SMS require two very different resource and skill sets. Unless you are a high value target expecting dedicated resourceful attacks (in which case frankly you shouldn't be using SMS in the first place), you have to ask what is the probability of my credentials for a service being breached AND the same attacker identifying me as using an SMS relay service / lifting the two factor code from it before it expires. Unless you have used the same credentials for both services i'd argue extremely slim.


How to compare passwords with duplicate password

This is bad.

They're either storing the password:
* in unsalted form (which is bad),
* in reversibly encrypted form, from which they can reproduce the plaintext (this is worse),
* in unencrypted form (this is the worst).

The prefered way to store passwords is in salted form. This is explicitly made to prevent identical plaintexts winding up as identical ciphertexts. So they can't be using salts.


Is it safe to provide others with a VPN server at home?

You can do it mostly safely with combination of technologies. You will be able to mitigate most of the issues except the illegal activities one.  Their outbound traffic will be originating from your home IP address and therefore any illegal actions will point back to you.
For the rest of the issues:

Protecting your home network. You will want to put them on separate VLAN/subnet which has no access to your home network. You can easily do that with many routers, especially if you have OpenWRT, DDWRT installed on your router. Usually how this works is, you connect the PI to one specific port on your router(or you can make guest WLAN if your router supports it) and then in the software you specify that this port is separate LAN which has no connection to the rest of the ports/WIFI, only to the internet. If the router supports guest/multi WLAN you can create one and connect the PI to that WLAN and it will be separated from the rest of the network. If you simply connect the RaspberryPI to your network they will have access to all your internal LAN devices and computers.
Bandwidth limiting. You might want to limit the bandwidth they can use, so that they wont slowdown/saturate your network. This can also be done on your home router but again it depends on the OS/firmware you have there.
Setup a firewall on the RaspberryPI or your router which will allow them to only use services you think are safe, for example 80(HTTP) 443(HTTPS). Blocking outgoing connections to port 25 for example will prevent them to send spam directly. It is safe to block everything and only open ports they specifically ask for. This will prevent them do ports scans, bruteforceing services and etc.
You will need to setup some port forwarding so that the Raspberry can be accessed from outside your home lan.
Do more deep check on these friends. Trying to help is a noble endeavor but in this day and age the amount of scam/spam/fishing/malware is troublesome and has become profitable business. Even if they don't have bad intentions, their devices might be infected with virus/rat/malware which can spread to your network if you don't take the necessary precautions.

Unfortunately this is not a short topic and I'm not gonna be able to cover all the aspects in detail. You'll have to do some reading and research by yourself. Good luck :)


Yes, with some caveats. As a prior answer described, Kerberos authentication also shares a session key between the client and server principals, which they can use for further communication. Another prior answer claimed that “Kerberos is not an encryption protocol,” but this is not true: the protocol includes messages specifically for sending arbitrary data protected by the session key negotiated during authentication (KRB_SAFE and KRB_PRIV). The most common way to take advantage of this is via GSSAPI (which is the most common way to use Kerberos at all, rather than via a Kerberos-specific API like that of MIT Kerberos or Heimdal). After creating a GSSAPI security context, the peers can use the routines gss_wrap() and gss_unwrap() to seal data for transmission, either with just integrity checking, or integrity and confidentiality (encryption). Probably the most common example of this actually being used is via SASL, when the client requests installation of a “security layer” after authentication with the GSSAPI/Kerberos mechanism.

Keep in mind, though, that unlike Diffie-Hellman you don’t have forward secrecy here. In the simplest case the KDC generates the session key, so it was always known to a party other than the communicating peers. The key may actually be a “subkey” generated by one of the peers, which is better, but still it’s generated by one side only, making it vulnerable to one-sided Trojan or Byzantine attacks, whereas Diffie-Hellman limits either side’s ability to control the final shared key. And in either case the session key is ultimately secured on the wire by the long-term key of the server, which is typically in a keytab file on the server as well as in the KDC, and prior recorded communications will be compromised if that is later revealed.


Is there any way to protect main activity of the Android application from being launched by the other applications?

No. After all, the launcher is an application. If you ban applications from starting your activity, you ban the launcher from starting your activity.


How can I securely check if a username exists?

This source says that it is almost impossible to avoid user enumeration in this situation and delaying an attacker is the best you can do:

  If you are a developer you might be wondering how you can protect your site against this kind of attack. Well, although it's virtually impossible to make an account signup facility immune to username enumeration, it is however possible to avoid automated username enumeration attacks against it by implementing a CAPTCHA mechanism.

However, I might have missed something - I'm also curious if anybody else has a better solution.


how are flaws in google chrome usually patched and disclosed

Usually the vendor is informed by the person who has found the vulnerability. The vendor is given some time to fix the issue before the vulnerability is disclosed publicly. This is called responsible disclosure. This way, there is already a fix available when the vulnerability gets publicly known.


Using short hostname in X509 certificates

is it secure?

a bit less than FQDN. The problem with short names is name ambiguity. FQDN is unique in public, but not necessary to be in private networks. The problem with short names is name ambiguity and nothing else. It is acceptable to use short names in small private networks, however it is impossible to maintain them in large networks. There is nothing wrong if you use unique short name in private networks. However, there might be an issue when multiple factory-provisioned devices are configured to share the same short name.

  what is the type of attack that someone could take advantage of this config.

an attacker still have to spoof name resolution mechanism (DNS for FQDN and NetBIOS for short names) to redirect client to rogue host with the same name.


SERVER-IIS multiple extension code execution attempt

What you see is an attempt to exploit a Microsoft IIS vulnerability (a pretty old one, in fact). I found this blog entry with documentation and more details about it:

https://soroush.secproject.com/blog/2009/12/microsoft-iis-semi-colon-vulnerability/

The code name for this vulnerability is CVE-2009-4444.

This event doesn't identify whether the attacker succeeded or not, it just shows that they attempted to exploit it.


Applications of probability/statistics in IT security?

Intrusion Detection Systems indeed are a natural fit for statistics.

An interesting example I've come across:

At host based IDSes, track and statistically analyze the system calls of an application. An interesting approach is to group the system calls in pairs, triples etc. and then observe their behavior when the application encounters an attack.

Have a look at this:

P. Astithas, V. Pappas, B. Maglaris, "Detecting Intrusions by Monitoring System Processes", in Proceedings of the 8th HPOVUA Plenary Workshop on Network and Systems Management, Berlin, Germany, June 2001. (it's a postscript file)

You may also find interesting analysis work done with high speed networks where specialized network processors capture enormous amounts of traffic. Theoretically such analysis can reveal ongoing DDoS attacks and be used to deploy dynamic filtering.

I would also suggest to take a look for interesting ideas at the proceedings of RAID, the International Symposium on Recent Advances in Intrusion Detection. From what I have seen much of it is available online with free access


Whether or not this is standard is going to depend on your specific industry.

Not knowing anything about yours or the nature of your projects, I can say this is a standard practice for data under legal hold, where a company is anticipating litigation and don't want to be accused of destroying evidence. Or the company wants to be able to demonstrate prior art in the event of patent litigation.


How to give a web application a key in order to decrypt data in a database

Initially I thought that I could just enter the keys manually on application startup and keep them stored in memory, but the problem with that is then I would need to manually intervene to start up each instance of the application.

Whilst memory only is in practice notably more secure than on disk if they have enough access to the underlying machine running the application they can just take a core dump and lift the keys out of there.

  So now my questions are, am I overthinking this, and is there a better, industry standard way of providing keys to a web application for the purpose of encrypting/decrypting data in a database?

The best approach I have seen is to have them stored on the application server in a config file which is not readable by the user which runs the application. They are passed in either as arguments or by IPC when the application is started.

This means privilege escalation on the application server is required to obtain the keys. If the DB server is compromised the keys aren't there.


The answer is: it depends.

If you need to see all the crap hitting you from the Internet, IDS should be outside the firewall. Although it is not recommended because you literally get flooded with useless data and gives the machine lots of load. If not, just put it in.

IPS should be inside the firewall because it consumes more time per packet to inspect than the firewall.


3G, 4G How does my provider know i am using facebook?

Without going into deep detail about how Internet Protocol routing and the Domain Name System work, it's actually quite easy for your ISP (and in this case, your provider is your ISP) to know what domains you visit.

To answer your question, the provider maintains a list of all the IP addresses registered to Facebook. When your phone requests Internet data via its cellular connection, it addresses the request to a specific IP address. That request gets routed through the Internet gateway at your provider. The gateway (or other hardware between it and the tower) can record this usage, and check the source and destination addresses. If the destination address (for a request) or source address (for a response or push notification) is from an IP address registered to Facebook, your provider simply doesn't count that usage against your plan's data limit.

They can't necessarily read the traffic - even using Deep Packet Inspection (DPI) they won't be able to read encrypted traffic - but they can see how big it is, where it comes from, and where it goes. Be aware that mobile operators often do use DPI, though; it lets them detect people doing things like using tethered data without (or in excess of) their tethering limit. Also, while the traffic between your phone and the tower is encrypted (with not-very-good crypto on older-generation protocols, though I don't think 4g is broken yet), the operator obviously needs to be able to decrypt that layer of traffic so they can route the data. The data could be encrypted at a higher level as well, using things like SSL/TLS, but anything above the Internet Protocol level will reveal the sender and recipient of each packet.

Any ISP can do this monitoring of your connections for anything that accesses the Internet through them, by the way. This kind of "metadata" is one of the things the NSA and similar agencies around the world is so intent on slurping up. China's "Great Firewall" places filters on IP addresses that it doesn't want you to reach, though I think it also uses DPI to block specific content on otherwise-permitted sites. This kind of thing is one of the reasons anonymizing proxy servers and anonymous networks (such as TOR) exist; your ISP can tell you are connecting to a proxy / TOR entry node, but can't tell where your request goes after that unless they control the node. By bouncing the request a few times to random machines, it's possible to be pretty sure that anybody trying to track the path of the request has lost it. The actual final destination is encrypted within the data sent to the proxy, so it's never visible to a network attacker.


Why does Chrome tell me this certificate is valid when it can't be verified?

Looks like a reported bug.  Someone blogged about it.


Will changing the Wifi router fix a hijacked Wifi problem?

If we are assuming that there actually is a malware risk, then all your assumptions are correct. It is possible that malware could exploit your browser, infect your machine, pivot to your router, DNS, and slowly take over every device in your network.

1) If the router is hacked, you do not have the same controls as you might have on a computer, so replacing it with another fresh router would solve that problem

2) "Factory settings" typically means that even the boot partition is reset, so depending on what a reset means, this should protect your device.

3) It is possible that malware could figure out your tv cable box, find an exploit and infect it, even if connected to the router by a cable (doesn't matter how it is connected)

But you know all this.

What I think you are really asking is if we think all this is necessary. The chances that malware that was designed to display ads would also be so advanced as to do all that is very low. Malware that is that advanced would not announce itself by displaying ads.

I would not go through all this activity unless I had some confirmation that there was infection.


Yubikeys & SSH - which option is best for lockdown?

Yubikey can either be cloud-based with Yubi providing the "yes/no" answer or you can run it locally. Run locally and benefit from the OTP.


There was a study done, to which unfortunately I do not have a link, using which they found out that even when user's data did not contain personally identifiable information, they could track individuals from other attributes so long as they had rough idea of their location. Now this may or may not be as much applicable to dense areas as to sparse areas, but if someone promises anonymity, it can be a concern.

With the approach that you are suggesting, how do you guarantee that they will get to the same code both times, and not make a slightest mistake to arrive at a different code? Remember, they have no way to verify it.

Since your question is open ended, there're a few different kinds of approaches that you can take:

1) When you are distributing them the questionnaires, can you just give both upfront? For example, have them fill out one immediately, and then have the other in a sealed envelope that they open up two months later and then fill up? If that's possible, of course, you can have same ID on both surveys. There is of course the possibility of them losing the survey, but I think you will have to assume in your sample that some folks who are surveyed the first time will not be providing surveys the second time. It is probably a little less likely that they will lose surveys vs a code that you had provided.

2) Perhaps you can have them use an online CRC32 or MD5 hash function using their last four digits of their phone, two digits of their address, etc. or some simple combination like that. They will still not be giving too much personally identifiable information, and they can verify that the site they're getting the hash from is not related to you, if they have concerns. This is not as user friendly, but definitely more friendly than they calculating their own hash, using the scheme you specified in your question. (for example, see here: http://www.fileformat.info/tool/hash.htm -- you can also search for "calculate hash online" or something similar. I am sure there will be some phone apps too.)

As for the code approach that you have, keep in mind that any time you use any variable that's in a database somewhere, the users will be trackable. For example, my doctor's office has my social security, my date of birth, my name -- no matter how you ask me to put it on the survey, someone can easily run an automated tool to find out what the codes will be calculated for each of those records and find the survey. Of course, it boils down to how important is it to be anonymous and what you're promising and the impact if someone were to trace the survey to an individual.

FYI. The hash approach in #2 is also vulnerable to the same approach, although a little more effort is required depending on the hash used.

Sorry, that's the best I can think of as of now, hopefully, it will help you go towards a solution. IMO, if you can go with #1 approach above (give both surveys upfront), that's the best way to approach it and ensure high level of anonymity.


Is saving a list of passwords in Acrobat XI with 256bit AES encryption as secure as something like KeePass?

...is this just as safe as password manager's technology? Is there any reason not to do this?

I've done a little bit of security analysis on the keepass password manager, so I think telling you some of the things they have done to increase security will help you understand why this is a bad idea.

Even after decryption, memory is still protected (in Windows using DPAPI). This means that while your password DB is "decrypted" when you enter your password, all the passwords are still encrypted using DPAPI. This prevents memory scraping attacks where other processes read through their uninitialized memory to try to find interesting information.
When you copy a password from keepass in order to paste it into your browser window, for example, keepass gives you only a certain amount of time before it wipes the clipboard. This makes it harder for other applications to find passwords in the clipboard.
When you enter your master password into keepass, once it has decrypted the DB, it wipes the password from memory to ensure it doesn't leak. We don't really know if PDF viewers do the same.
Password managers do not store decrypted versions of your DB in temporary files, etc. We don't know if PDF viewers do that.

You can sync a password DB from password managers using Dropbox or another file syncing program. So, there really is no benefit to doing things the way you suggest.


What is the procedure to follow against a security breach?

Serverfault has a great canonical answer on "what should we do now to clean up this mess", so I'll take a stab at "what should we do to prevent this happening ever again".

Your organisation needs to establish an "employee leaving" process and stick to it.
Your organisation will need to work out if they should treat all terminations the same, or differently between "hostile" and "non-hostile" terminations, or differently between regular employees and those with access to sensitive information.
IT needs to document the procedures for closing every account an employee might have, including accounts IT doesn't control.
IT needs to keep an employee account register that lets them instantly identify what accounts any given employee has. (This can be a lot of work.)
IT needs to have a list of all generic accounts and who knows the passwords to them. They also need to remove as many generic accounts as possible, ideally all of them.
When the decision is made to "hostile" terminate, HR need to meet with IT in advance and plan so the accounts are all disabled while the employee is learning that they have been terminated.
At the same time as the accounts are closed, their computer hardware and ID badges need to be secured.

IT, HR and senior management all need to commit to the above.

In addition, it also sounds from your question that your backup procedures are not good — fix that. (Don't forget to secure your backups. In particular, try not to have any people with permission to delete both the originals and the backups.)


Are there any security advantages to the "TrueCrypt-Paradigm"?

Yes, there is a very real advantage. Take this hypothetical, but very likely scenario. You are storing something Very Bad(tm) that you absolutely do not want the police to find. Your opsec is pretty good, but you make a single mistake online, and the cops are on their way. It's 4 AM in the morning, and they burst in with a fresh warrant for a no-knock raid. You stand by helpless as they take every single device in your house, all of your dozen flash drives and SD cards, your hard drives, laptops, etc.

Days later, they confront you again, asking you if any of your flash drives are encrypted with something called "TrueCrypt". They know you are tech savvy enough to use it, but they also know you are tech savvy enough to wipe your flash drives. They have no idea whether or not you encrypted it, or you simply wiped it. They can't force the key out of you, they can't lock you up for refusing to give them the key, and most importantly, they can't spend a long time trying to crack all of your dozen either-wiped-or-encrypted devices because spending too much time on a single case gets investigators in a lot of trouble.

Because you used TrueCrypt, the devices which you simply wiped blend in perfectly with the devices you have encrypted. You're let free after the cops are reprimanded by an angry judge who regrets signing the warrant in the first place.

This example is especially potent in countries with mandatory key disclosure laws, where if they have evidence that you are hiding encryption, they can lock you up. If you can claim that you simply wiped your hard drive and it's all random data (which is especially plausible if you have a spare CD with DBAN burnt on it lying around), then no matter how much they want you, they'll have a very hard time getting you locked up. But even in countries without such laws, it's still an extremely good idea to prevent your adversary from knowing where to focus their efforts, or even knowing that they have found what they are looking for.

Note that this "TrueCrypt-Paradigm" is much more effective on entire disks. It is significantly less effective when used as individual volumes, because it's not that easy to explain away a large, random file sitting on your hard drive, especially if TrueCrypt is installed on that system. Not as easy as it is to explain away a hard drive with random data, where even if TrueCrypt is installed on some computer in your house, it still isn't even close to enough evidence to point to that specific hard drive being encrypted rather than just wiped.


Disk Encryption vs File Encryption for Embedded Linux?

Choice of encryption model is going to depend on the device's threat model and available resources.  Both Full Disk Encryption and File-based encryption are designed to protect data at rest.  Full disk encryption is going to offer you more protection in the event of a stolen HDD, provided the device is powered off.  FDE, however, will not protect you in the event the device is powered on.  File-based encryption will offer more protection against attacks when the device is powered on, as it allows you to unlock different files using different keys independently.

Regarding the specific devices you mentioned, the choice is all going to depend on the threat model that the developer used.


Is there external service which can detect ransomware?

Many mail providers scan by default for mails containing malicious code or links. Also browsers use blacklists like Google Safebrowsing to protect the user. And many enterprise firewalls try to protect their users as do local antivirus products. But, none of this is fully reliable so you should still use backups as an additional protection. Apart from that these backups also protect against hardware malfunctions (dead hard disk) or accidental data loss (i.e. delete the wrong file) so you should have such backups anyway.


Is it html escape enough for mitigating all xss, if html is going to be generated only in client side?

Not necessarily, and it wouldn't be recommended. Admittedly it is likely to prevent DOM-based XSS in the majority of cases (in an HTML output context anyway), but not all as detailed on OWASP...

Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HTML encoding may not work to mitigate against XSS.
--- SNIP ---
If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element.

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet#Encoding_Misconceptions
This page also includes examples.
Furthermore, HTML encoding only applies when the output context is HTML.
Generally, I would still say that the best practice of validating and sanitising all user controllable input on a case-by-case basis is still the best solution. Generally, data would need to be both JavaScript and HTML encoded in this case. See the recommendation on the same OWASP page above.


Have a look at this answer here for more detail. But here's the salient bits for your question:

The problem with 2-factor as implemented by  Symantec VIP and Okta Verify has less to do with the fact that it's implemented in software, and more to do with the fact that the code can be intercepted.

In this sense, Symantec VIP, Okta Verify, and RSA SecurID are all in the same boat as Google Authenticator; none of them will protect you from phishing because the same technique the attacker uses to get your password can also be used to get your 2nd factor code; usually by getting you to type it into a fake login page.

But U2F is different.

With U2F, you don't type in a one-time-password to show you have your token. Instead, the browser communicates directly with the hardware token, and part of the process is that the browser tells the hardware token the hostname of the site that is requesting identification, and 2FA identities are tied to the individual host. And the browser (unlike the user) cannot be fooled regarding which host is requesting authentication because the browser checks the TLS certificate.

This means that an attacker's website can't get the correct 2nd factor code, and it means that even if a clever social engineering attacker managed to trick a user into giving up their password, the user can't give up their 2nd factor code.

The 2nd factor token can ONLY be used if the browser is communicating with the correct site, and only if the browser is physically connected to the U2F token. This pretty much eliminates any attack that doesn't involve the physical theft of the victim's hardware.

U2F could be implemented (and has been) in software, so you're depending on software on your computer rather than a physical device. This is still better than OTP-based 2FA such as Symantec VIP for phishing resistance, but in this case physical theft is no longer a requirement for exploitation. Instead, if your token is implemented in software, then any intrusion on your computer (virus, etc.) could make a copy of your authentication device and use it on their computer without your knowledge. So it's not quite as good as a physical device, but it's a lot less expensive.


I started to learn about MITM attacks, and I can't figure out few things

Passive sniffing is not a MiTM attack. Depending on the network setup, sniffing may be able to view all communication, but it can't change any of it. A MiTM is when an attacker controls one of the nodes directly in the connection path between the client and the server. As shown in this diagram from Wikimedia, you think that you are talking to the server, either directly or through a series of trusted nodes, but you are really talking through an evil intermediary.

There are many ways to get a computer to use the incorrect route through the attacker's machine. Spoofing various network settings (eg: ARP spoofing or evil twin attack) is one common strategy. Another might be to infiltrate a network provider's machine.

How the attacker achieves the MiTM status is highly-situational. It's not like you can go to MiTM.com to attack any computer in the world. You need a foothold that you obtain by leveraging a vulnerability or other security weakness (eg: evil twin relies on insecure access points).

As to why ARP caches are subject to poisoning, it's a combination of the need to be dynamic and performant in a large network and weak security design. That said, ARP poisoning isn't trivial to execute. OS's come with defenses, but sometimes they can be bypassed.


Judging from the question and the comments, I'll paraphrase your question as:

I'd like to encrypt a file, but part of my file has a predictable format.  Will this make it easier to crack the encryption?  Should I leave the structured parts out and encrypt only the minimum?

First off: that's not a silly question.  Intuitively, you would think that knowing about the structure of the message would help you decrypt it, and this is true—to a certain point.
Luckily, this issue has long been anticipated by cryptography.  'Modern' encryption algorithms have a high branching factor: a small tweak in the input, a single changed bit, will create an unrecognisably different output.  Because of this, knowing the structure of part of your file will not help me much, because any variation in content will lead to a very different result.
High branching factors are essential to strong encryption.  Here is a brief example(1) of this in action:
> echo HELO1 | openssl aes-128-cbc -k meep -S 0
∙╞X╟ε╜i§B÷FÄ│Γat

> echo HELO2 | openssl aes-128-cbc -k meep -S 0
╩ ëhnw²╜╗ç1L▀≡☼·

(1) Syntax: openssl <algorithm> -k <passphrase> -S <salt>
Note that HELO1 and HELO2 have a similar structure—they differ by only two bits—but produce a very different output.  This makes it so that, if I start guessing for your encryption key, I will have no idea of how 'close' I am.  Basically, unless I get an exact hit and guess your passphrase, I'm going to have a hard time decerning anything from your file.
Unless, of course, you give me information by leaving your headers exposed.  Not only do I now know the file type, I also have access to the Huffman tree, which was built from, and hence contains information about, the message it encoded.  I may be able to make an educated guess about the contents without ever trying to decrypt it.

Analogy: HTTP(S)
HTTP is a structured protocol as well: each request starts with a 'method' (GET, POST, PUT...) and ends with HTTP/1.X with X some number.  Even more: each line that follows has a predictable structure, as well as some lines which could be accurately guessed (Host:).  That sounds like a lot of information for me to use.
Yet HTTPS encrypts the entire conversation, because not doing so would give me a lot more information.  Heck, with all the headers, I might not even need to decrypt the payload: I can blackmail you with just the header data.


How can I protect a client's mirror of the server's database?

Are these (local and central) databases holding authorization or authentication data (or both)? Your question refers to it using both ways.

But, whichever it is, if the database is local and the user (or, equivalently, a process running as that user) has to be able to read it (e.g. to check that they have valid authentication/authorization) and that read has to be (by definition!) before the user is authenticated and authorized, then you are out of luck -- the user will need to have read access so they will be able to read the data.

You may be able to prevent modification of the data (or at least detect and reject such modification e.g. via a cryptographic signature/public key encryption using a private key held on the server whose public key pair is held on the client machine) but the user could still subvert the authentication/authorization within the client application's "offline" mode by modifying/injecting into the locally running code.

In addition to any such "roadblocks" you'll also need to make sure that when the client reconnects, the server prevents any unauthorised changes which were made while in offline mode from propagating to the server.