Microsoft account security alert - Is this legit?

I admit that it looks phishy but this, however, is not a scam : https://answers.microsoft.com/en-us/outlook_com/forum/osecurity-oinfosafe/is-this-adress-a-valid-ms-one-or-a-fraud/de185bc8-e2aa-47ba-a526-28d80ad577b1

The fact that you used a GMail address to sign up for a Microsoft service is not abnormal at all (you can also have a Google account and use an @hotmail.com or @outlook.com address for that). It's just the e-mail address where they can contact you on (as they did now)

I would highly recommend

resetting your password asap
setting up an Authenticator app for multi-factor authentication


What happens when a SSL certificate issued by CA for Y years but the domain get expired before that and purchased by someone else?

Yes, the scenario you are describing is kind of a loophole in the CA system. It is the obligation of the client (the certificate owner) to inform the CA that the ownership of the domain has ended. The CA (usually) does not do any active checks after the issuance has happened.

There are steps taken, to mitigate this problem, tough:

The Baseline requirements of the CA/Browser Forum do not allow certificates valid for more then 825 days starting next year, so the time where you could do attacks with your certificate will be shorter
Certificate Transparency, which will be required from all certificates next year, too, will allow the new domain owner to easily check if your certificate is still valid.


I've found my answer, referring to Signing Your Applications on Android developer, the apk needed to be signed.
However, I had to do it manually on Kali using the commands:

For generating the keystore:
keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

For singing the App:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my_application.apk alias_name


Are there any reasons for using SSL over IPSec?

There are different layers of secure transport to consider here:

VPNs

SSL VPN (including tunnels)
IPSec VPN

SSL/TLS for individual services

IPSec vs SSL VPNs

Both SSL and IPSec VPNs are good options, both with considerable security pedigree, although they may suit different applications.

IPsec VPNs operate at layer 3 (network), and in a typical deployment give full access to the local network (although access can be locked down via firewalls and some VPN servers support ACLs). This solution is therefore better suited to situations where you want remote clients to behave as if they were locally attached to the network, and is particularly good for site-to-site VPNs. IPSec VPNs also tend to require specific software supplied by the vendor, which is harder to maintain on end-user devices, and restricts usage of the VPN to managed devices.

SSL VPNs are often cited as being the preferred choice for remote access. They operate on layers 5 and 6, and in a typical deployment grant access to specific services based on the user's role, the most convenient of which are browser-based applications. It is usually easier to configure an SSL VPN with more granular control over access permissions, which can provide a more secure environment for remote access in some cases. Furthermore, SSL/TLS is inherently supported by modern devices, and can usually be deployed without the need for specialist client-side software, or with lightweight browser-based clients otherwise. These lightweight clients can often also run local checks to ensure that connecting machines meet certain requirements before they are granted access - a feature that would be much harder to achieve with IPSec.

In both cases one can be configured to achieve similar things as the other - SSL VPNs can be used to simply create a tunnel with full network access, and IPSec VPNs can be locked-down to specific services - however it is widely agreed that they are better suited to the above scenarios.

However, for exactly these reasons, many organisations will use a combination of both; often an IPSec VPN for site-to-site connections and SSL for remote access.

There are a number of references on the subject of SSL vs IPSec (some of these are directly from vendors):

https://supportforums.cisco.com/document/113896/quick-overview-ipsec-and-ssl-vpn-technologies
http://netsecurity.about.com/cs/generalsecurity/a/aa111703.htm
http://www.sonicwall.com/downloads/EB_Why_Switch_from_IPSec_to_SSL_VPN.pdf
http://searchsecurity.techtarget.com/feature/Tunnel-vision-Choosing-a-VPN-SSL-VPN-vs-IPSec-VPN
http://www.networkworld.com/article/2287584/lan-wan/ipsec-vs--ssl-vpns.html

End-to-End Encryption

In some of the above cases, such as IPSec VPNs and SSL VPN tunnels, you may not be getting end-to-end encryption with the actual service you're using. This is where using an additional layer of SSL/TLS comes in handy.

Say you're remote and trying to connect to an internally hosted web application via an IPSec VPN. If you use the HTTP protocol via your browser, your traffic is encrypted whilst it is running through the VPN tunnel itself, but it is then decrypted when it hits the remote VPN endpoint, and travels over the internal network in cleartext. This might be acceptable in some use cases, but in the interest of defence in depth, we ideally want to know that our data cannot be intercepted anywhere between you and the actual service itself. By connecting to this application over HTTPS, you effectively have two layers of security: one between you and the VPN endpoint, and another travelling through that (between you and the web server itself).

Of course, this is not limited to HTTPS - you should equally employ other secure protocols like SSH, FTPS, SMTP with STARTTLS etc etc.


Multiple Bank Accounts on one payment gateway or merchant account

I think you're interested in being a PayFac:

Provide payment transaction routing
Settle to sub-merchants

And use tokenization to avoid holding card details.

I think PayFac is a Vantiv-specific term, so you may want to look at the bullet items on that page and try to match them to the processor you're using, to determine if they have an equivalent.


I share your global feeling about U2F being a good job even if it is an half-done job. :) Note: I am working as a security architect inside a small company (FIDO Alliance member) with its own U2F certified products.

Regarding expiring TLS ChannelID support, it is supposed -eventually- to evolve into Token Binding support (updated specifications, same goal).
https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/
Yes, it is not easy to implement TlS Channel ID on the server side (BoringSSL library can help) and yes it is only supported by Chrome on the client side and yes, it can be downgraded... BUT the good thing is that if you are thinking about using U2F on your own server/service, it can still be done and you can enforce it. Better than nothing while it is true that on many global services (gmail, facebook...), TLS Channel ID protection is simply deactivated.

Regarding the key pinning debate and why the server authentication part is relying on good/bad old SSL server certificate, the original decision is probably a mixed result of technical difficulties and "political" positioning. U2F (and UAF) already attacks established Certificate Authorities on the client side... Note : these are anonymous client key pairs but associated attestation/production certificates can be signed by FIDO Alliance private keys (becoming its own Certificate Authority...).

Dealing with mutual authentication would require larger memory too... I don't care, but it can be a problem for some solutions providers.

Whatever the initial real reason, it is not done and as far as I know, this kind of feature is not planned for future U2F releases... and not planned either for WebAuthN (kind of U2F/UAF successor).

But it doesn't mean U2F can't be adapted to support enhanced mutual authentication feature... I am working on it with few other fools: Welcome to our madness :)


How does the client pick the correct certificate from its certificate store?

The sever sends its certificate during the TLS handshake
 and the client verifies its trust path.

In the first step the client matches the common name (CN) field with the server's hostname (it does not compare the certificates).

Then the client verifies the trust path, i.e. whether the certificate presented by the server is signed by an entity whose certificate is in the trusted root certificates store (again: it does not match the certificate directly)

if you use a self-signed certificate and add it to the store, then the verification is successful when server's certificate is in the store itself;
if you use a (self-signed) CA, then the verification is successful, when signing CA's certificate is in the client's trusted store.

  Does it loop through all the certificates from its store and get the one matching with the SQL Server's certificate?

Remember the client is not trying to match the two certificates (sent by server and stored on the client), but to verify the certificate used to sign the sent certificate.

As for the process itself, you can think of it this way, but whether it checks the trust path by looping through all entries or uses an index to speed up the process, is an implementation detail that does not really matter to the user.

  Is there any way to configure the client to use XXXX certificate for the SQL Server 1 and YYYY certificate for the SQL Server 2?

The client will verify the trust of the certificate sent by the server during the handshake phase. So effectively they will be different for SQL Server 1 and SQL Server 2 and it will work the way you described without any additional configuration.

As a sidenote, you shouldn't be really managing by adding a self-signed certificate for each server separately, but create a CA and sign sever certificates using it. Then you distribute only one CA's certificate to all clients.


Security risks of scanning an unknown QR code

You never must trust in user input, independly if this is a string, a bar code or a qr code.
All of them, can exploit your application. Eg. SQL-Injection.
Take a look in this PDF, its very useful for your question :)
http://qrcodethursday.files.wordpress.com/2011/03/qr_code_security.pdf

Bonus: I don't know if this is a joke or really true, but make sense: http://cicero.files.wordpress.com/2010/04/500x_for_traffic_cameras.jpg


distinguish between bots and legitimate clients

It's going to vary for every single attack.   With DoS attacks, you can looks for attributes that are different than "real" requests, say values that are out of range, or the lack or specific format of a particular piece of data like a user-agent or referer in a HTTP request.

Generally speaking for DDoS attacks, if the traffic gets to the server, you've lost, and it doesn't matter.   DDoS attacks are purely designed to choke resources and the most common bottleneck is the network bandwidth.   You can potentially identify characteristics of a DDoS attack, but it almost always needs to be identified and managed upstream so the traffic never reaches your servers.


Explain OWASP Data Validation best practice example

This example doesn't prevent against changing the value intentionally because the explained functionality says that the user is allowed to set the payeeLstId parameter. However, the example provided does prevent against multiple attacks because the parameter is first cast to an int before being used to query for the account. By tampering I'm assuming OWASP means that the value can't be used to exploit the vulnerabilities listed (buffer overflows, XML injection, etc) in the Why this is bad section not setting the value to reference another account.


Hydra on ssh does not work even with correct pass

By default THC-Hydra does not have SSH support and unless you install ALL of the following libraries it will behave exactly as you describe.

libssl-dev libssh-dev libidn11-dev libpcre3-dev libgtk2.0-dev libmysqlclient-dev libpq-dev libsvn-dev firebird2.1-dev libncp-dev libncurses5-dev

More specifically if you install all the libraries at once you won't see the failure of one of them in the middle followed by the last few succeeding. Problem I run into frequently when installing it on different systems.

If you install each one of these libraries one by one you can catch which one didn't install correctly, correct it, and then Hydra will start working again.

Finally also ensure that you use the following syntax with the port number at the end after the IP address IP:Port

hydra -l testuser007 -P top500.txt ssh://184.100.123.123:22


Cancelling a request stops new authentication cookie getting to browser, invalidating all further requests

The normal way to do this is to have one constant session ID in a cookie. It's a long random number that gets set when the user logs in, and is stored and verified on the server. That's how sessions are handled in most frameworks and languages.

Unless you are doing something special, there is no need to change the session ID on every request. Doing so causes you a lot of problems, like the one you describe. Also, what happends if the user has your page open in multiple tabs at the same time? And so on, and so on.

So unless you have some very specific need to change the token, why would you? It is not a very effective protection against session hijacking (i.e. the cookie being stolen), since an attacker can do a lot while the victim is viewing the page. It is not worth the trouble and the extra complexity it brings.


Running arp command on public wifi network

You have nothing to worry about. The arp -a command you ran would simply list the ARP cache tables on your local machine's interface(s) as explained on Microsoft's documentation site.

In order for your machine to communicate with other hosts on the same, internal network, MAC addresses are needed. Each interface should have an IP and MAC address. An ARP table is used to convert a machine's IP to its MAC address.

ARP Spoofing would require a bit more work to do, and by just running arp -a you are not sending anything onto the network that would put you into trouble.


Will setting a password for a linux login increase security?

Right now, there are zero passwords that will work if an attacker randomly guesses it. If you set a password, there is at least one that works if an attacker randomly guesses it. This is infinity percent more likely to happen (still very, very unlikely, but it is a nonzero chance compared to the literally zero chance it'll happen with no password), so your system is less secure with password login enabled for that user.

There are cases where passwords are useful: for instance, if you log in via an SSH key, but want to be able to run sudo, it's best to have a password protecting sudo, because that means that someone who somehow obtains your SSH private key can't log in to the server and run sudo. Likewise, you might in theory set it up so you need a key and password to log in, and not store the password anywhere but in your head, though it's more common to just encrypt the private key with a passphrase and enter that passphrase every time you want to use the key, which achieves essentially the same goal.

But what these have in common is that there are situations where you need to use the password. Adding another authentication system that you never use cannot improve security, because the only way an authentication system provides security is by requiring you to authenticate with it. If you never use it (because you threw away the password after making it), then an attacker doesn't have to either, so they can apply the same attack they'd use if the system wasn't enabled. If an attacker does use it, it's because it's an easier attack than the one they'd use if it was disabled, so it's decreased security.


What is the best way for securing data transportation between sites

I'd first try SSL/TLS - https.  That's easy, there's lots of great info on it, you can use websockets to keep the connection open to improve your speed (much of the SSL/TLS slowdowns are in the handshaking at the beginning of each connection).

If that doesn't work for you, look at Quic - https://www.chromium.org/quic - Google's 'https' over udp protocol - designed to be both fast and secure.

Whatever you do, try to avoid inventing your own protocol and/or encryption - it is much harder than you might think to avoid all security holes.


Is the javascript browser tool at printfriendly.com secure for my browser

Read this report carefully and don't worry about it. This isn't on what URL does with iexplore.exe (IE) but what IE does with typed URL. Every website will bring you similar report (e.g. report for google.com).

I recommend you to check that URL with services that analyze URLs, like VirusTotal.


In regards to your first question:

The protocols you use will matter when leaving the VPN and going to the servers that you are trying to contact, so anyone sniffing traffic to those servers will be able to see what's being sent.

In regards to your second question:

If another person using EC2/Digital Ocean were able to sniff your traffic through that provider's network, it would be a MAJOR security flaw on the part of the provider, and I sincerely doubt that it would happen (unless you piss off the government and they get a warrant to force the provider to do it, but if you do that, they could also probably force the provider to identify you).

The main comment I have, though, is that you might not want to set up a VPN yourself, for multiple reasons:

You're leaving a paper trail of who owns the VPN server with the cloud provider, who (as I mentioned) will be perfectly happy to identify you to the government.  If you don't care about the government knowing what you're doing, you should be fine.
The companies that provide VPN services will be able to host more than one VPN client on a single box, which provides:

More protection (as an attacker will not be able to distinguish traffic that is yours from traffic that belongs to other clients)
Lower costs, as they only require one instance for multiple VPN clients

They're probably more optimized for what they're doing than something you set up will be, and they'll hopefully be less likely to make mistakes like allowing weak encryptions to be used.


How can I best manage root passwords for many servers?

Here are a few options, each with their own aspects of security and insecurity:

Use a tool like KeePass or LastPass (both are pretty good)
Use SSH keys exclusively (remove the root password completely and disable password auth)
Use a non-reversible password pattern, e.g.: SHA1(hostip+secret+some_iterator)

Of those options, I like the SSH keys one the most if you're in an environment where that makes sense. Because honestly, why have root passwords if you don't need to?

My Next favorite is keepass and lastpass. Random passwords are better than not-random passwords

The password-pattern option is categorically less secure than the other options, but certainly better than using passwords with a readily-discernable pattern.


Is it possible having only public key from SSH keypair to see if private key is password protected?

No.  It has nothing to do with the key generation.  One can encrypt a key, later remove the password, change the password, and/or change the algorithm.  The reverse is also true one can start with an unencrypted key and later encrypt it.  The encryption is done client side after the keypair generation is complete.

It really is no different than encrypting any other type of data.  I would point out if encrypting a key leaked that information to the public key that would be a bad design.


What difference does the attacker’s proximity to target / access point make to KRACK susceptibility?

There are too many variable factors to create a reliable formula.

  If we assume that only standards compliant antennae are used for the attack

The antennae is not the main issue. By default the signal strength (TX strength) on a lot of NICs is set to ~20dBm. This is a legal requirement, each country has a different cap on signal strength.

You can find out more here: https://w.wol.ph/2015/08/28/maximum-wifi-transmission-power-country/

It is trivial however to crank your TX strength up, in fact it is usually an important step in getting a successful WiFi Evil Twin/MiTM. I very much doubt anyone actually trying to use this attack will be sticking to standards compliance.

They might not be setting up in your local coffee shop with a 20ft Yagi antenna, but you can bet they will be cranking up their TX strength to at least 30dBm, which will be enough to over come many short range strength issues if the target is physically closer to the original AP.


How should I safely display my phone number on my website?

Well, the first thing is not to worry about it so much, because your threat model is unlikely.

Voice spammers don't get phone numbers by sending bots out to crawl the web, because they have much better sources of numbers.

And targeted attacks, where someone wants to prank call you specifically, can't be prevented because you can't tell who is an attacker and who is a customer.

If you still want to obscure your text, then here you can use similar techniques to those used to obscure email addresses:

Do the formatting weird so bots don't recognise it as a phone number.
Use an image of the number instead of the text. (But please don't do this, because it'll break accessibility.)
Shrug your shoulders and put good anti-spam in place.


Where should I start looking if an internet provider has notified me of malware?

It'll be one of your ios devices. I'd review the list of applications in the paloalto research report on xcode ghost and see if any of them line up with applications you have installed on one of your ios devices, and uninstall the infected app.


How can I recover encrypted files after system reinstallation

Do you have a copy of the key?

http://windows.microsoft.com/en-US/windows7/Recover-encrypted-files-or-folders

Connect the drive that contains the encrypted file.
Connect the drive that contains the backed-up certificate and key.
Start certmgr.msc
Import the certificate

You should now have access to the files.

http://technet.microsoft.com/en-us/library/bb457020.aspx


Burpsuite 1.5 initiating TLS Connection on their IP to Port 443. What is it?

One thing you could look at is setting an upstream proxy in burp (either another instance of burp or a similar tool) and see if the traffic is then sent via that proxy.  It may hit a problem with SSL certificate validity on the other hand might work.  Assuming that it works, it would let you see within the SSL stream (although there could be further encryption of course).

To block the communication you could add an entry to your hosts file for the DNS name that it's contacting and redirect it to 127.0.0.1 as one option.  You could also block it on your hosts firewall or if you're running it via a chained proxy as I mentioned above, you could likely block the traffic there too (depending on which tool you use.)

Another thing I'd recommend is asking in the the PortSwigger Forums, they're usually reasonably responsive, so you could well get an answer there.


Whats the point in having software's like Veracrypt, which end of the day needs password to decrypt?

Encrypted archives are fine if you want to send encrypted data to somebody else, or perhaps to encrypt a backup.

Disk encryption software like TrueCrypt target different use cases:

You can encrypt your system drive. You get prompted for your password on boot. If somebody steals your computer/hard disk they can't read your data without guessing the password.
Mounting encrypted partitions and containers. Once you mount a container all the files in it are accessible to every program transparently, instead of needing a specialized tool.

Since you can use any filesystem supported by you OS on top of a TrueCrypt container (file, partition or whole disk). These filesystems support efficient random read- and write access. Compressed archives are meant to be created and unpacked as one long operation, they're not suitable for mounting.

If I remember correctly, rar uses ECB mode for encryption. This is very bad for uncompressed data, but compression should eliminate should remove most of the plaintext structure/repetition, so it's slightly less bad in the common case of compressed files in a rar archive.


How to make a secure key distribution scheme/protocol?

First, you cannot securely move data over an untrusted network between two untrusted endpoints. To securely distribute anything, whether it's keys or 100 GB Blu-Ray images, you're going to need one of two things set up on each endpoint to establish initial mutual trust between the two:

A shared secret (i.e. a password or a shared key)
One half of an asymmetric keypair (i.e. a trusted certificate)

Second, you say you're using a VPN. The whole point of a VPN is to transform an untrusted network into a trusted network between two now-trusted endpoints. If your hosts automatically authenticate and join the VPN, they already have either a shared secret or a trusted certificate.

Assuming your VPN is encrypted, your data will already be encrypted in transit between your network and the EC2 network. If your EC2 hosts can join the VPN on startup, they already have enough information to identify themselves as one of your hosts. If they can't, you can establish trust when the hosts are manually connected to the VPN by an administrator.

Once the endpoints are authenticated to join your trusted network, your EC2 hosts can exchange certificates, establishing a trusted link all the way through. This is (sorta) how Kerberos works.

Note that this won't protect your data against:

A malicious insider - say, one of your own system or network admins
Programs that retain key material on the EC2 hosts longer than they need it

Third, at an absolute minimum, for your own protection, your company will want to be able to audit all access to key materials in a way that's secured against an attacker with root access. You may also need to audit all access to encrypted materials in the database. Think hard about what it would take to implement that.

Fourth, protecting your keys at rest (against an attacker who wants to gain root on your KMS or any of your EC2 hosts) is an entirely different problem, and it's even harder to solve than protecting keys in transit between two mutually trusted hosts. I've been involved in implementing a "PCI-DSS network island" in the past, and it's a giant pain.

I strongly recommend that your company hire a security consultant with experience setting up distributed key management systems. The problem here isn't only the known risks - the things you know you need to defend yourself against - but what Rumsfeld famously called the "unknown unknowns" - risks you don't even know you have.

As a developer myself, I wouldn't trust my abilities to design and implement a full crypto-system without outside advice from an expert.


Yes, the server supports only RC4-SHA with TLS 1.0 and TLS 1.1. With TLS 1.2 it supports several more ciphers. Since all of these (GCM) ciphers where introduced with TLS 1.2 they are not available for TLS 1.0 and TLS 1.1 connections.

You can solve the problem in the following ways:

Have the client use TLS 1.2 so it can offer more ciphers. The protocol is available since Windows 7.
Enable support for RC4-SHA4 at the client. This cipher is often disabled for security reasons.
Enable more TLS 1.0 ciphers at the server side.


Does Internet Explorer handle Extended Validation properly

That one is simple: in a windows domain environment, domain administrators have the capability of doing ANYTHING they want with your machine. In a sense, your machine is more their machine than yours.

That includes, of course, manipulating the certificate store to add (or deny) any kind of trust relationship they want.

That is, to use the usual turn of phrase, a feature and not a bug.

Now, the real question is, of course, "how do I protect myself from rogue admin?" (or perhaps "who watch the watchers?"). That one is hard to answer (ask the NSA about it).

The simplest way is simply no to allow anyone you can't trust with the domain administrator password. In small shops, that could means that only the domain owner knows the domain administrator password. It is also typically controlled by contracts and internal rules stating who is allowed to do what, how and under what kind of supervision.

In any case, that's an issue that should not be approach through technological means, at least until you're 100% sure you need it because the ways to improve on the situation through technical limitation are cumbersome, expensive and far from being 100% efficient.


The only way to really guarantee that data cannot be recovered is
(a) use full-disk encryption, so all sensitive data is already encrypted before it hits the media, and then
(b) destroy the encryption key when you no longer want the data on that media.

spinning disks

Yes, a single zero-fill, on a spinning disk, is adequate.

Civilian data recovery companies cannot recover data off spinning disks after a single zero-fill.
There is no evidence that anyone else can, either.
In spite of the popular urban legends you might have heard.
a b c d e

solid-state media

A zero-fill is probably inadequate on solid-state media, but using random-data-fill or multiple passes or both, aren't any better.

Solid-state "disks" typically have extra space used for wear-leveling that cannot be read or written to with normal tools.
Sensitive data that ends up in this extra space is not guaranteed to be erased,
no matter what data patterns you write and no matter how many passes you make.

See Is it enough to only wipe a flash drive once? .


How to best use JavaScript to encrypt client side so the server never sees it?

When this question was asked in 2014, the Web Crypto API did not yet exist.  But, now that we have the Web Crypto API, you may want to consider using it instead of one of the libraries referenced in the other answers on this page, for doing in-browser crypto.  The Web Crypto API has a CSPRNG implementation, as well as implementations of most common symmetric encryption, asymmetric encryption, hashing, and HMAC functions, all of which you can call from javascript.
However, this still doesn't solve the age-old 'chicken-and-egg' problem when it comes to browser-crypto:  `If you can't trust the server with your secrets, then how can you trust the server to serve you secure code?'


Can a computer virus be stored somewhere else than on the hard drive?

Plenty of places:

BIOS / UEFI - BlackHat presentation (PDF)
System Management Mode (SMM) or the Intel Management Engine (IME) - Phrack article.
GPUs - Proof of concept rootkit on GitHub.
Network cards - Recon 2011 presentation (PDF)
A Quest To The Core (PDF) - a good presentation covering everything from BIOS to SMM to microcode.

Modern hardware has a wide range of persistent data stores, usually used for firmware. It's far too expensive to ship a complex device like a GPU or network card and put the firmware on a mask ROM where it can't be updated, then have a fault cause mass  recalls. As such you need two things: a writeable location for that firmware, and a way to put the new firmware in place. This means the operating system software must be able to write to where the firmware is stored in the hardware (usually EEPROMs).

A good example of this is the state of modern BIOS/UEFI update utilities. You can take a UEFI image and an executable running on your OS (e.g. Windows), click a button, and your UEFI updates. Simple! If you reverse engineer how these work (which I have done a few times) it's mostly a case of a kernel-mode driver being loaded which takes page data from the given UEFI image and talks directly to the UEFI chip using the out instruction, sending the correct commands to unlock the flash and start the update process.

There are some protections, of course. Most BIOS / UEFI images won't load unless they're signed by the vendor. Of course, an advanced enough attacker might just steal the signing key from the vendor, but that's going into conspiracy theories and godlike threat actors, which just aren't realistic to fight in almost any scenario. Management engines like IME are meant to have certain protections which prevent their memory sections from being accessed even by ring0 code, but research has shown that there are many mistakes out there, and lots of weaknesses.

So, everything is screwed, right? Well, yes and no. It's possible to put rootkits in hardware, but it's also incredibly difficult. Each individual computer has such a variance in hardware and firmware versions that it's impossible to build a generic rootkit for most things. You can't just get a generic Asus BIOS and flash it to any board; you'll kill it. You'd need to create a rootkit for each separate board type, sometimes down to the correct revision range. It's also an area of security that involves a huge amount of cross-domain knowledge, way down deep to the hardware and low-level operational aspects of modern computing platforms, alongside strong security and cryptographic knowledge, so not many people are capable.

Are you likely to be targeted? No.

Are you likely to get infected with a BIOS/UEFI/SMM/GPU/NIC-resident rootkit? No.

The complexities and variances involved are just too great for the average user to ever realistically have to worry about it. Even from an economic perspective, these things take an inordinate amount of skill and effort and money to build, so burning them on consumer malware is idiotic. These kinds of threats are so targeted that they only ever really belong in the nation-state threat model.


ISP provides RJ45 instead of RJ11/coaxial/modem, how to separate the network?

The medium they use for the connection has nothing to do with security. You could equally put all your computers on the public internet by connecting it to a DSL/coax modem (not a router).

In this case it looks like due to the fact that every computer has an Ethernet card the ISP decided not to provide a router, and as a result people are putting their machines directly onto the Internet. Nothing prevents you from putting your own router/firewall in the middle if you need the extra security.

As far as reaching other computers by IP, this is exactly how the internet is designed to work. You may have had the impression that it isn't the case due to an awful hack called NAT which hides multiple computers behind one single IP - the router has the public IP and everyone else behind it uses a local, private IP, and to receive incoming connections you had to tell the router to forward particular ports to the local IP. In this case since people aren't using routers no NAT is happening and every device has a publicly routable address.


How to Securely Implement a "Remember Me" Feature?

My answer is incomplete and has a nontrivial flaw, in some situations - please see @Scott's answer instead.

There are two parts to my answer:

First, assuming your threat model does not worry about exposure of client side cookies, you can generate and store a nonce on the server side, hash that with the username and other info (e.g. client ip, computername, timestamp, similar stuff), and send that in the cookie. The nonce should be stored in the database, together with expiry date, and both checked when the cookie comes back.
This should be a "rememberance" cookie only, NOT a session cookie - i.e. when you get that cookie without a session, reissue a new, regular session cookie. Also note that like the session cookie, this should be delivered only over https, and using the secure and httpOnly attributes, and of course have the cookie scoped properly etc.

Second, for users that were remembered, you should (probably, depending on sensitivity) invoke a reauthentication process for certain sensitive operations. That is, sometimes they would need to put their password in again anyway, but seldom, and only for sensitive operations. This is to prevent attacks such as CSRF and shared desktop exposure.


How to detect a silent .pdf exploit without opening the file?

To examine a malicious PDF you can use:

PDF Stream Dumper

After installing PDF Stream Dumper, load the suspicious PDF file and start looking around. You can see different colors on the right side, where the red color shows headers with JavaScript tags.

The tool includes a number of signatures of known PDF exploits. To scan the file, select Exploits Scan from the menu by pressing.

peepdf

  peepdf is a Python tool to explore PDF files in order to find out if the file can be harmful or not. The aim of this tool is to provide all the necessary components that a security researcher could need in a PDF analysis without using 3 or 4 tools to make all the tasks. With peepdf it's possible to see all the objects in the document showing the suspicious elements, supports all the most used filters and encodings, it can parse different versions of a file, object streams and encrypted files. With the installation of PyV8 and Pylibemu it provides Javascript and shellcode analysis wrappers too. Apart of this it's able to create new PDF files and to modify/obfuscate existent ones.


Spam Mail - have someone broke in to my shared hosting account?

To answer your initial concern. Its very unlikely you were hacked. If you were, I would recommend using stronger passwords and getting into a regiment of changing it once every 60 days. But again I find it very unlikely that your hosting account was compromised.

In regards to the issue:

Beside switching Hosting providers. The only thing you could do is provide mail header information which comes with each email sent and shows originating information as well as the route. That information can help your provider track it down in their system. Sometimes the issues come from one bad able on your shared IP address that is abusing the mail server which then other mail servers will begin to block any emails coming from that originating IP.

From my experience in running a webhosting Infrastructure, some allow you to switch IP's which can sometimes fix the issue if the whole mailserver has not been blacklisted. this might, require you to be moved To a new server (which is not a terrible thing its all batch script).

Best to just see what your provider can do. But from what I am hearing this sounds more like a case of a bad apple on the server or more of spammer ruining the mail server and overall product experience.


Entering sensitive information into non-SSL site that uses secure iFrame

I'm wondering what are the security risks of this type of setup for the users.

It's almost as bad as serving everything over plain HTTP.

You get protection against purely passive listening attacks, but really anyone in the position to do that kind of man-in-the-middle attack is very likely also to be able to do an active attack, changing the content that gets sent back to the browser. That could include changing the iframe src in the unprotected parent page, or injecting some attack script.

In practice the HTTPS-iframe gets you protection from a casual attacker sniffing general traffic, but for any man-in-the-middle targeting the site specifically it is trivial to make the measure ineffective.

It's up to the provider whether they think this barely-more-than-plain-HTTP assurance is suitable for the kind of information that will be entered into the frame - except if that information contains credit card data, in which case they have an obligation to abide by the PCI-DSS rules requiring HTTPS. (Assessors are expected to verify that HTTPS indicators are visible in the browser chrome.)

  seeing the browser's address bar unable to provide identity/encryption information is disconcerting.

Yes - independently of the question of actual security, this is poor perceived-security and may put some users off.

  Without viewing the source of the page, how do I know where the iframe content is from?

Quite. Viewing source/DOM isn't something you can expect an average user to do.

Additionally, even if you verify the iframe is being served using HTTPS, there is nothing stopping the unsecured parent page from interfering with it with 'clickjacking' attacks, for example a keylogging overlay form.

  Is relying on the godaddy seal sufficient?

Seals offer no security, as they are trivially spoof-able. They are nothing but a marketing exercise; CAs should be ashamed of this deliberately misleading behaviour.


How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?

It is the magic of public-key cryptography. Mathematics are involved.

The asymmetric key exchange scheme which is easiest to understand is asymmetric encryption with RSA. Here is an oversimplified description:

Let n be a big integer (say 300 digits); n is chosen such that it is a product of two prime numbers of similar sizes (let's call them p and q). We will then compute things "modulo n": this means that whenever we add or multiply together two integers, we divide the result by n and we keep the remainder (which is between 0 and n-1, necessarily).

Given x, computing x3 modulo n is easy: you multiply x with x and then again with x, and then you divide by n and keep the remainder. Everybody can do that. On the other hand, given x3 modulo n, recovering x seems overly difficult (the best known methods being far too expensive for existing technology) -- unless you know p and q, in which case it becomes easy again. But computing p and q from n seems hard, too (it is the problem known as integer factorization).

So here is what the server and client do:

The server has a n and knows the corresponding p and q (it generated them). The server sends n to the client.
The client chooses a random x and computes x3 modulo n.
The client sends x3 modulo n to the server.
The server uses its knowledge of p and q to recover x.

At that point, both client and server know x. But an eavesdropper saw only n and x3 modulo n; he cannot recompute p, q and/or x from that information. So x is a shared secret between the client and the server. After that this is pretty straightforward symmetric encryption, using x as key.

The certificate is a vessel for the server public key (n). It is used to thwart active attackers who would want to impersonate the server: such an attacker intercepts the communication and sends its value n instead of the server's n. The certificate is signed by a certification authority, so that the client may know that a given n is really the genuine n from the server he wants to talk with. Digital signatures also use asymmetric cryptography, although in a distinct way (for instance, there is also a variant of RSA for digital signatures).


TL;DR Yes, but it's unlikely. Just to be sure, either unplug the PC or ensure it can't connect to anything.
Several operating systems - notably Windows 10 - have the possibility of setting "automatic wakeup", using appropriate drivers and related, complicated hardware management.
As a result, IF (and that's a big if!) a malware program has gained sufficient access to have the operating system do its bidding, it has a way to simply ask the system itself to do this on its behalf.
On some systems (that the malware must be able to recognize and plan for), this holds for "true powerdown" also: additional circuitry will turn the computer on at a preselected time of the onboard Real Time Clock. In a less software-accessible manner this is available on some desktop BIOSes ("Power up automatically: [ ] Never; [ ] After power loss; [ ] Every day at a given time: :" or similar, in the BIOS setup).
Then, the system will automatically power up after some time, for example at a time when you're likely to be asleep.
So:

there is RTC powerup hardware support, or more (integrated management systems, common on enterprise computers)

the malware must already have taken control of the system, since RTC functions usually require administrator/root level access.

RTC powerup HW support not present, or not used:

if the malware has taken control of the system, it can have replaced the shutdown procedure with a mere going into sleep, and set up things to exit sleep mode at a later time.

But did either of these options happen? Probably not. Most malware rely on being run unwittingly and being able to operate without being detected for some time. The "power off simulation" is only useful in very specific scenarios (and the hardware option is only available on comparatively few systems), and I don't think it would be worthwhile for a malware writer to worry themselves with them. They usually go with the third and easiest option:

some of the usual automatic power-up or logon sequences (autoexec, boot scripts, scheduled tasks, run services and so on) is subverted so that additional code, namely, the malware, is silently run.

For a "targeted" malware, designed with some specific victim in mind and tailored to the specific target's capabilities, rather than the subset available on the average infected machine, all the qualifications above wouldn't come into play.


Is there a common standard for digitally signing via smart cards?

Minidrivers abstract the actual smart cards so that applications can all talk to them using a common interface. Your app doesn't even need to know nor care about which smartcard it's talking to, or whether it's really a smartcard or a big networked HSM, assuming it accesses the card through the standard interface and not talk directly to the card. Here's a good example from Microsoft themselves, as you can see the RsaCryptoServiceProvider can be used the same way no matter which card is behind it, because the minidriver provides a Cryptographic Service Provider that abstracts the card.

The right minidriver should automatically be installed via Windows Update, assuming the manufacturer submitted their minidriver there. I'm not sure which manufacturers bothered to do this in practice though. But yes, in theory nothing prevents you from bundling a lot of minidrivers with you app and installing them in advance.

CCID is a standard to talk to USB smart card readers, its sole job is to relay APDUs (commands) between the computer and the smart card reader. Basically the minidriver translates from high-level crypto functions into low-level APDUs (which are card-specific) and then passes them on to the reader via CCID.


Choice of programming language for cryptography depends on a lot of parameters, including (but not limited to) the following:

If the goal is to support research (e.g. to try variations) then the language should be one that is most mastered by whomever will do the research. For instance, people who want to "investigate crypto" and feel most comfortable with Python will use Python.
If the goal is to serve as a pedagogical tool, e.g. for a reference implementation of a new algorithm, then a widespread language with clear semantics should be preferred. Cryptographers have long used C for that job, but, arguably, Java or C# would be better choices since they have much fewer "dark corners".
If the goal is efficiency, then the target architecture is of paramount importance; for instance, many embedded platforms support only (a subset of) C, and any implementation will have to be more or less directly implemented in C (automatic translation from other languages is possible but requires work). If you have the choice, then compiled languages (e.g. C) and languages with efficient JIT compilers (e.g. Java, C#) are appropriate.
If the goal is maximum efficiency, and you want to run in the least possible number of clock cycles, then some assembly will be needed. This hardly matters in practice, outside of microbenchmarks (in most practical applications, memory and network bandwidth are the bottleneck, not cryptography), but it is a fun exercise.
Most cryptographic algorithms process secret elements (e.g. keys) and may be vulnerable to side-channel attacks. Preventing such attacks requires intimate knowledge of all the arcane management of cache memory, jump prediction and other subtle details. Implementations which are robust against such attacks are awfully difficult to build, but the problem becomes easier (not easy, just easier) with a lower-level language. Hence, assembly or C (with C, you still have to understand what is going on at the assembly level). Arguably, if you know enough to implement a side-channel-free cryptographic implementation, then you already know that...
If you are weary of life, use C++.

Personally, I have implemented cryptographic algorithms for various goals, including research, pedagogy and efficient production-level code (currently deployed in the field) in C, Java, C#, Forth, a dozen of assembly dialects, and a few other languages. None of these languages was "better" than the others in an absolute way; it is all a matter of context.


In addition to clear-text configuration settings, the EncFS configuration file also contains the volume key, but that key is encrypted with the master key, which is derived from your password.

In other words, it is not possible to decrypt anything without the password.


What's the actual danger of public key spoofing?

It's an attack, FOR SURE And that's why : all the crypto-systems have JUST ONE common problem, regardless of their other differences, : a key distribution problem. Yjat's why it's essential to buy a holographically-protected licensed CD with Windows and so forth : it contains a correct and true public key. If a malicious third party will ship you a software with public key changed - it will easily wiretap your traffic and - maybe - even make a MitM with a correct key, so the software vendor will likely see no difference.


You are absolutely correct there is no real way to know with certainty that the provider is not monitoring you. This could either be purposefully or due to an unnoticed compromise. A VPN service logging your traffic would not be able to necessarily break the encryption used for a web page. They can man in the middle your traffic, but unless they can exploit a weakness in the protocol or encryption, they are unable to see the encrypted data. They would know you went to the site, but not be able to see your password or any other details.


File SHA256 checksum failed, but OK on reboot

@ThatGuy Lets start by re-downloading the http and ftp links again now we can upload them to VirusTotal.com while you are uploading the files we should come up with the MD5 hashs of the files, after you have found the MD5s you should Google them to see if anything comes back with the same MD5 you need to Google them with quotes and without. If everything comes back all okay then you have nothing to worry about.

Note that Googling the SHA256 may not return anything which happens alot when you search for them.

Hope that helps.


The bootloader won't be encrypted, because you first need to load the LVM service.

A probably possible way to install malicious script is to corrupt the code that will prompt you the password, but can't access to your password directly

However, you can still encrypt /boot using LUKS, and use LVM over LUKS
Have a look at this link from ArchLinux, yet doable on Kali.

Furthermore, you can use GRUB from a USB key, that will load the encryption module and boot from the encrypted /boot

That's a bit overkill, but I hope it answers your question !


How do polymorphic/metamorphic/self-encrypting/self-changing file infectors know if they have infected a file or not?

Eric Filiol's paper Metamorphism, Formal Grammars and Undecidable Code Mutation pretty much shows that it can be made impossible for a virus to know if a metamorphosed copy of itself has infected a file.  Sic transit gloria anti-virus.


Which encryption schemes have been designed without involvement from the NSA

How do you know that ole' Bruce Schneier was not covertly paid by the NSA to inject weaknesses in his designs ?

If you take the paranoid stance that NSA is powerful, aims at making encryption systems weak, and may resort to tinkering and bribery to that effect, then claiming that any specific system author is immune and obviously clean from such interference, is pure wishful thinking. For that matter, it would make more sense to believe that the AES itself, i.e. Rijndael, is "unmodified by NSA", for the basic reason that the Rijndael authors are not American, and thus less susceptible to NSA leverage than Bruce Schneier.

Note that I do not claim that Bruce was bought off; Heavens forbid that I accuse without any proof someone whose appearance is so uncannily similar to that of Chuck Norris. But I mean that you are not thinking your own question through. If your enemy can manipulate algorithms to include weaknesses "in plain sight", that hundreds of trained cryptographers miss, then you cannot trust any algorithm, regardless of its purported authors.

Now if you really want raucous gossip, rumour was, at the time of the AES competition, that the NSA candidate was MARS. Cryptographers did not like it, not because of its purported ascendancy (Don Coppersmith is a highly respected cryptographer) but because it was internally too complex, somewhat "inelegant", compared to nice regular structures like Rijndael or Serpent, where proper Science could be made much more easily.


You appear to be asking about keys exported from GnuPG, although you don't actually say so, and it isn't clear if you mean public keys (only) or secret (aka private) keys.
Nor if you mean the GnuPG suite (which includes both gpg and gpgsm) or the gpg program only.
First, to clarify, the extension on a filename doesn't really matter; what is important is the format of the data in the file(s). People often (usually?) choose the extension to reflect the format, and some programs (like the GUI Kleopatra in gpg4win) encourage this, but GnuPG itself can process a file depending on its actual format without regard to the extension (or lack thereof).

gpg processes OpenPGP messages using OpenPGP keys, and for all files (except clearsigned) it supports binary or 'ASCII armored' variants. There is one OpenPGP-defined format for each of public and private keys, and those are the (only) export formats gpg supports, in both variants. People generally use .asc for armored files, because the actual content type can be determined by looking at the first (or last) line; .gpg is sometimes used for binary files, but sometimes people use other extensions to indicate the type of content as well as format, such as .enc for encrypted, .sig for signed or signature, .key or maybe .pub or .sec for keys, etc.
Public keys are protected against tampering by at least one signature, and don't need to be confidential; private keys have one signature, and are encrypted with password-based encryption using reasonable algorithms by default (unless you have deliberately configured them badly) so their confidentiality is protected if you use a good password (including passphrase) and not otherwise.

gpgsm processes S/MIME (effectively CMS) messages using S/MIME keys and certificates, and similarly supports binary and PEM files; although not identical, PEM is very similar to PGP's ASCII armor and gpgsm adapts option --armor to actually mean PEM. gpgsm supports exporting public keys as X.509 certificates, and private keys in PKCS1, PKCS8, or PKCS12 formats, all in binary and PEM variants. However Kleopatra supports only X.509 and PKCS12. Similarly people, and Kleopatra, use .pem for PEM and varying extensions like .p7s .p7m .der .p12 for binary.
X.509 public keys (certs) are protected from tampering by CA signature and don't need confidentiality, like PGP public keys. PKCS1 and PKCS8 private keys from gpgsm are not encrypted, which is very bad, and not protected from tampering either, but as noted Kleopatra doesn't support these. PKCS12 private keys are protected by a password-based MAC and also include the X.509 cert which is protected as above and partially verifies the private key. The private key is encrypted by password-based encryption with 3DES which is decent but at risk if and when quantum analysis succeeds, and dependent on the password in the same fashion as gpg/OpenPGP; following common practice, the cert is encrypted with a weak algorithm (RC2-40) which is unnecessary and silly.

The main differences are that a PGP key can only be used with PGP programs and not S/MIME, while the S/MIME format keys can only be used with S/MIME and similar programs but not PGP, so which is better depends on who you want or need to communicate with. The text formats (armor and PEM) are necessary if you want or need to process the key as text, for example with cut-and-paste; otherwise it doesn't matter to (most? all?) programs, although the text formats are easier for a person to identify, especially if the filename was badly chosen or altered accidentally.


I believe you're mixing up a few different threats and attack vectors here.

Threat: MITM sniffing or setting tokens

Location: Public wifi

How to mitigate: Use HTTPS so the connection is secured over TLS/SSL. Also the cookie Secure Flag is recommended, and an HSTS policy with preload.

Threat: XSS

Location: Over the internet

What it is: An attacker injecting JavaScript code into the page, either by enticing their victim to visit a URL for a "reflected XSS" attack, or by storing script within the system's database that is not correctly encoded on output for a "stored XSS" attack. When the attack payload is executed, it comes from the victim's browser and IP.

How to mitigate: Correctly encode output values, implement a Content Security Policy, set X-XSS-Protection and X-Content-Type-Options HTTP headers, set the HttpOnly flag on cookies.

OWASP Secure Headers Project

Threat: CSRF

Location: Over the internet

What it is: At attacker enticing their victim to visit the attacker's site or a site compromised by the attacker that then makes a malicious request to a good site that the victim is also logged into. When the attack payload is executed, it comes from the victim's browser and IP.

How to mitigate: Generate a random token per session which is passed outside of the cookie mechanism (aka Synchronizer Token Pattern).

Your points

  I was wondering what prevents an attacker from generating his/her own
  token

Nothing - however if you have associated the token with the user session, Bob's login cannot use Alice's CSRF token and vice versa. Therefore any attacker will not be able to use their own token in a CSRF attack. A good storage location is the server-side session mechanism many web frameworks provide.

  Then I began requiring the clients IP to also be stored and checked
  during validation. But this would not be secure if our attacker and
  victim were on the same network such as a public WiFi hotspot.

A CSRF attack comes from the victim browser. Therefore, the IP address will be the same as the rest of the victim's session. Reading your paragraph again I now realise you may not have been referencing a Man-In-The-Middle situation as I described above, however I've left it in for completeness.

  My attempt at a solution: To place a cookie on every user's browser
  and to hash their token with the cookie's value so that I can be sure
  that it is not an XSS attack.

XSS is a different type of attack. If you have an XSS vulnerability then most CSRF protection mechanisms are either useless or severely compromised.

The mechanism you describe appears to be the Encrypted Token Pattern which is also a valid way to mitigate CSRF.


Is a PKI for the IoT really a good idea?

Let's look at your fridge. Why is it connected to the Internet? It could send maintenance data to the manufacturer, connect to stores to order food for you, or tell you its contents ("fridge, how many eggs do I have?").

If you classify this data as having no impact if adversely affected, then yes, a massive infrastructure like PKI would have little value (the risk is low).

But, it's not that low. Imagine a hacker accessing your fridge to raise the temperature and spoiling the entire contents? What about a hacker accessing the fridge and ordering tons of food on your account? What if the type of food you store indicates certain sensitive information about you (only kosher foods or only halal meats, suddenly no more alcohol (pregnant?), or a 1-off big order of cranberry juice that gets steadily consumed (urinary tract infection?)). What about stats on how often the door is opened (are the owners away?) Assessing the information this way indicates quite a different risk level.

PKI (properly implemented) can protect the control data (who can order, who can access, who can change settings) and can protect the information at rest and the information in transit.

Imagine a WhatsApp or Signal-like encryption process where only the manufacturer's certificates or your phone app can access the control functions, or even certain data. That's where PKI can be useful.


How do you assess if your computer has a hardware rootkit?

There's no practical way to provide complete assurance that a machine isn't compromised.  There are a few things you could look for, but none are definitive.

Based on details in the NSA ANT catalog, you could compare the board in question to a reference photograph of a known-clean motherboard and look for evidence of the implants they offered a few years ago.  The NSA designed small boards that are designed to fit behind an Ethernet jack tower; they have implants hidden inside USB and monitor cables, etc. But finding one would be a total shot in the dark.

And even if you look, it's just as likely that a machine has had its firmware or silicon compromised somewhere, and those implants would be entirely invisible.

You could monitor your network for unexpected traffic, but know that some of these implants use RF energy to exfiltrate their data.  And not all of them use WiFi, 3G, or Bluetooth protocols, either.  Some are even based on malicious USB drives that rely on an agent (witting or unwitting) to physically carry them off of the premises.

Instead of focusing on a particular threat, you'll do more for your overall security by watching your network carefully.  Run NIDS and DLP tools.  Monitor for suspicious traffic volumes, times, ports, etc.  Consider an SSL intercepting proxy.  Also keep abreast of security alerts.  Not only will these types of activities help defend against malicious implants, but they could detect the activity of ransomware, worms, viruses, malware, or hackers, too.


Is Chrome completely secure against Reflected XSS?

No, because the XSS filter only looks whether it sees XSS code in the input back in the HTML outputted by your server.

For example, if Chrome sees your web page is accessed with an URL that contains the following:

?q=

and if the HTML returned by the server contains this:

You have searched for

it knows that this code is most likely the result of it being included in the request, and neutralizes it.

However, if the code is not found in the request, for example if the application accepts input that is encoded in some way, the filter may not be able to figure out that the code is the result of some XSS code embedded in the request.

As seen in the commit log for WebKit, until it was forked recently  the rendering engine in Chrome, they are trying to address the most common bypasses, where the XSS-code in the URL and the resulting XSS-code in the HTML look slightly different.

If none of these rules for special cases apply, the XSS will be left through. For example, if they aren't decoding Base64-encoded data in the URL, if the web application were to accept input encoded with Base64, it may be possible to XSS a web application.

An example:

?q=PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+

(PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+ is  encoded in Base-64), if not filtered, would result in response HTML like this:

You have searched for

Additionally, it won't stop XSS occurring with data that is not embedded in the HTML unencoded, but is treated in an unsafe way by JavaScript.

For example, consider a page which contains the following JavaScript:

eval(location.hash.substring(1))

This will execute any code trailing the # in the URL, but it is not filtered out by Chrome.

↪ You can see this example in action here

↪ Another example, which uses Base64


Using a decoy traffic while using the internet

You can not distract your ISP basically, there is no a human checking the traffic so he can be distracted. In general, ISP logs dns, ips, https and so on in the same way bro/snort/aiengine does. However there is some traffic generators that can make hard for an ISP to determine what you do, because basically you enter in 1000 sites every time. Have a look at https://github.com/ecapuano/web-traffic-generator for example, this may help you.


Is this the correct way to use AWS Cognito?

The cognito-express calls Cognito to get public JSON Web Key (jwks.json) from your user pool which it then uses to validate your JWT. The address is derived from your pool-id and region you provide to the library.
As far as I can tell this appears to be a bug in cognito-express. The number they pass in maxAge option is supposed to be in milliseconds but the library they use (node-jsonwebtoken) says a numeric value gives the expiration in seconds. Might want to raise an issue at their github site to clear this up.
You should have received a refresh token along with access token when first logging in. You should pass this refresh token to Cognito to receive a new access-token as mentioned in the documentation. You'll have to do this yourself as cognito-express doesn't handle this part. Basically you'll need to keep track of the expiration in your app and make a call to Cognito at or slightly before expiration.


What are the steps to take in order to securely transmit credit card information via a standard web form?

I cannot emphasise enough that this is highly "involved".

You would need to be compliant with PCI DSS, since you'll be handling card data. PCI DSS is the definition of involved. I'm also unsure as to where you stand with someone actually copying this data into a PoS, but I can imagine it would be extremely difficult to generate a complaint process that includes this step.
Data will need to be secured in-transit, so that means configuring an SSL/TLS server to only support strong, non-vulnerable ciphers, protocols and other configuration settings. You will need to purchase an SSL/TLS certificate and keep this in-date. Furthermore, you'll need to consider any transport encryption beyond the web server... for example, you definitely cannot email this data to your copy-typer.
Data will need to be secured at rest (and it will need to be at rest at some point if its not being immediately passed to a separate payment processor). This means that all card details will need to be encrypted using a strong scheme, most likely involving both symmetric and asymmetric forms. Keys will need to be securely managed to prevent the data from being accessed.
A secure Card Data Environment (CDE) needs to be established - a highly secure network that is segregated from other business areas. Access to this would need to be tightly controlled.
Both the web application (form) and the network infrastructure need to be regularly tested/reviewed for security vulnerabilities, which then have to be managed and resolved.

This really only scrapes the surface. Try the PCI DSS requirements for a full understanding of the steps involved in securely handling card data.

It would be significantly easier and cheaper, especially for a small operation, to utilise a 3rd party service that have already undergone these processes. For extreme ease-of-use, an out-of-the-box service like PayPal could be used. If you're interested in using your own form, consider a service like Stripe that can handle the back-end and security. These services are already PCI compliant.


Is a substring of base64 encoded random_bytes less secure then just using random_bytes

If you have 15 random bytes and encode these as base64 you get 20 bytes since base64 encodes 3 bytes into 4 characters. If you then take only the first 15 bytes from the encode 20 bytes you thus use only 3/4 of the original 15 bytes, i.e. 11.25 bytes - or 90 bits. These 90 bits are definitely less  than the original 120 bits (15*8).  How this effects the security depends on your specific (unknown) use case.


When I decode it, I get random 8 chars regardless of password length.

With the given base64 of length 24 you get 16 bytes. These 16 bytes are 8 unicode characters only when interpreted as utf-16. When interpreted as utf-32 it would be 4 characters and when interpreted as utf-8 it would be a variable number of (possible invalid) characters.

But nothing in the base64 or in any context you provide indicates that it actually has to be interpreted as utf-16, i.e. this is probably only an (unfounded) assumption you make. It is more likely that these are just 128 bits without any specific structure, i.e. no unicode characters at all.

  So, is there an algorithm known that a) has 8 char fixed output b) output consists of random unicode chars?

Again, the question is more if there is an algorithm which creates 128 seemingly random bits. Sure, it's a random generator. And another famous algorithm which has a 128 bit output is actually the MD5 hash.


Man in the middle attack still possible against ssl?

Sslstrip is not an attack against SSL. It has never been. It is an attack against HTTP (not HTTPS): it looks for points where some HTTP (hence unprotected) Web site tries to switch to HTTPS, and prevents this from happening. Thus there is no SSL to begin with.

To counter sslstrip (which still works, by definition), Web sites must:

make SSL usage explicit: the human user MUST see the https:// URL in his browser's URL bar, with the padlock icon and so on;
educate users into expecting such explicit SSL usage, and bailing out in case the expected SSL does not happen.

There are no known MitM attacks against properly used SSL. "Proper usage" includes, in particular, a user who does not click through warnings about invalid server certificates. It always comes down to the user.


How should I compile program for fuzz testing?

No one suggested a definitive answer, so I ran a tiny experiment.  Based up on this experiment, here is my recommendation so far:
Recommendation. When fuzzing, you might consider setting the environment variables LIBC_FATAL_STDERR_=1 MALLOC_CHECK_=3.  This setting had no measurable performance impact in my experiment, and based upon my results, this setting might slightly increase the number of bugs you detect.
None of the other settings made any detectable difference in my experiment.
Optional. If you want, you can compile with -fstack-protector or -fstack-protector-all, with -O2 -D_FORTIFY_SOURCE=2, and/or with mudflap; and you can run with the environment variable G_SLICE=debug-blocks.  None of them had any measurable performance impact in my experiment.  However, none of them had any impact on the set of bugs found.  So while there was no cost in my experiment, there was also no benefit.
Experimental methodology and details. In each run, I fuzzed ffmpeg with zzuf, using one seed file, for 5000 iterations.  There was one run per setting of compiler flags/environment variables.  I ensured that fuzzing would generate exactly the same set of variant-files in each run, so the only difference was the compiler flags/environment variables.  To measure the performance impact, I measured the CPU+system time to complete fuzzing.  To measure the impact on ability to detect bugs, I recorded which variant-files triggered a detectable crash.
I measured performance, but none of the options had any detectable effect on performance (the differences were < 1% in all cases, and probably due to random noise).
For bug detection power, I MALLOC_CHECK_=3 gave a slight advantage, but none of the other flags or settings made any difference in bug detection power:

MALLOC_CHECK_=3 did have an influence on which variant-files caused a crash.  With no flags, 22 of the 5000 iterations caused a crash.  Another 2 iterations caused a warning message (*** glibc detected *** ...) that, if you knew to look for it, could be used to detect a bug, so if you were smart enough to grep your fuzzing logs for that message, 24 of the 5000 iterations would provide signs of a bug -- whereas if you don't know to grep the logs for that particular warning message, then only 22 of the 5000 iterations provided indications of a bug.  In contrast, when I enabled MALLOC_CHECK_=3, 25 of the 5000 iterations caused a crash, and there was no need to grep the logs.  Thus, MALLOC_CHECK_=3 both is slightly more effective at uncovering signs of a bug, and also reduces the need to postprocess your fuzzing logs specially.
Interestingly, there was one variant-file that crashed the program with no settings but did not crash the program with MALLOC_CHECK_=3, confirming @this.josh's hypothesis that additional checking in some cases might cause us to miss some bugs -- but at the same time, there were 2 variant-files that didn't crash the program with no settings, but that did crash the program with MALLOC_CHECK_=3.  Thus, the benefits of MALLOC_CHECK_=3 outweighed its costs.

Apart from MALLOC_CHECK_, none of the other settings had any influence whatsoever on which variant-files triggered a detectable crash.  The set of variant-files that caused the baseline program (no special flags) to crash was exactly as the set of variant-files that caused the program to crash when compiled with special flags.  Therefore, at least in this experiment, those other settings didn't cost us anything (in performance) -- but also didn't gain us anything (in bug detection power).

My experiment is far from authoritative.  To do this right, one should really try it out with many different programs (not just one), and multiple different seed files (not just one).  So I'd caution you against drawing too many conclusions from this one small experiment.  But I thought the results were interesting nonetheless.


Methods for determining if a file is encypted?

You could run ent to see how much entropy a file has, a file with high entropy is likely either compressed or encrypted (or both). A problem is that JPEG, XLSX and ZIP are compressed, so actually compressed files are very common.

If you suspect that X is an encrypted version of file Z then you could check if they have similar sizes, plus small delta for encryption headers.


Virtual Environments vs SELinux/AppArmor : Which is better for running unreliable applications?

Docker attempts some tricks to contain processes, but the creators themselves acknowledge they aren't effective containers of applications out of the box. Since you are concerned about security, but aren't interested in a heavyweight VM environment, I would recommend running SELinux and Docker together. SELinux can automatically apply an MCS label to each Docker container launched which helps protect you against container breakout. This makes it really easy to get the strength of SELinux and the ease of use of Docker.

To further expand on this, Docker doesn't effectively contain applications launched within it. Docker communicates directly to the kernel as there is no hypervisor between it and the host system. This means an attacker inside a container capable of using local privilege exploit attacks which are fairly common and generally easy to pull off.

SELinux would be much more capable of containing the application, since you could effectively prevent it from communicating from any system component it didn't absolutely need to. It can be difficult to build profiles, but this is far and away a better option to contain an application.


Arduino buffer overflow and arbitrary code execution

The answer to this question will be heavily dependent on several factors including the toolchain used, and the target architecture. For simplicity's sake I'll limit this answer to the Arduino Uno and the ATMega328 AVR microcontroller.

tl;dr: Yes, it is possible, but only if you include WriteFlashByte(), or WriteFlashPage() in your source, and if the attacker has access to your source, or physical access to your device.

Buffer Overflow Exploits

Buffer overflow exploits are fairly straightforward. The general idea is to write a shellcode payload to a known location on the stack, and overwrite the return address to point at that shellcode. This works because the x86 architecture allows execution from ram. This is not the only exploit of this type, but it is very common.

Why the architecture is important

The AVR8 architecture (the one used by the ATMega micro on the Arduino) is what is known as a Harvard Architecture. The important part to note here is that in the Harvard Architecture the "instruction memory", or "program memory" is completely independent from "data memory". In the AVR8 architecture the program memory is implemented in Flash, the data memory is implemented in SRAM, and instructions can only be fetched and executed from Flash memory. What this means is that the buffer overflow exploit outlined above won't work. You can override the return address, but the address you change will be read from Flash, and not from SRAM. Now, you might think that this would make a buffer overflow exploit impossible, but it does not.

AVR8 buffer overflow exploits

Since the only way to execute code on an ATMega328 is to execute from Flash memory, we will have to put our shellcode into Flash memory. Here, you will find an appnote with the requisite information about reading/writing to flash memory. So, now we know that it is actually possible to write a payload to program memory during runtime, but there is an issue. The only way we can write data to flash is by using either WriteFlashByte(), or WriteFlashPage(), and the only way to use those functions is for them to already be in the Flash memory for that device. However, not only does the device need to be programmed with one of these functions, you must also know the address where that function resides in memory. There are two ways of discovering this information:

Compile the source using the exact same flags, then use avr-objdump to determine if these functions are present, and what address they reside at.
Read the contents of the Flash memory present on the micro, then use avr-objdump  to determine if these functions are present, and what address they reside at. Note that if the lock bits are set, you may not be able to read the contents of the Flash memory.

If you do not have access to the source, or you can't read the flash memory to dump it, a buffer overflow exploit of this type would be nigh on impossible.


Telemedicine on Google+ Hangouts or Skype. Is it encrypted?

Here's the answer to the technical part of the question. As for the legal bit, well... here's the technical bit:

All three services are encrypted, but there's some concern about the scope of that encryption:

Client-only encryption:

   Me              Provider            You
+-------+        +----------+       +-------+
| Plain |========|  Plain   |=======| Plain |
+-------+        +----------+       +-------+

End-To-End Encryption:

   Me              Provider            You
+-------+        +----------+       +-------+
| Plain |===========================| Plain |
+-------+        +----------+       +-------+

If your worry is eavesdropping by between you and your provider, then client-only encryption is fine. If you want to make sure that there is no evesdropping or modification anywhere along the path between between me and you, then only end-to-end encryption is sufficient.

Voice and data are often encrypted end-to-end simply as a matter of performance: it's a lot of data to move around, so the traffic goes directly between the two callers ("Peer to Peer"), which means it's also encrypted from one caller to the other.

Text data (chats) are typically routed through the provider's servers. This allows them to store chat history and deliver messages to offline users when they come back online. These are typically not encrypted end-to-end.

As for as who does what, all three systems are proprietary, so you don't know. We know with certainty that Skype's text messages are not encrypted end-to-end because Microsoft actually visits URLs you send over Skype, we know Google+ text messages are not end-to-end encrypted because your chat history shows up in your Gmail box. And it appears that Apple has access to your facetime text messages as well.

As for the security of voice and video; as mentioned before, peer-to-peer communication is typical, which would prevent snooping. But it is at least possible for all these providers to route traffic through their own servers as intermediaries, perhaps on a call-by-call basis.

But perhaps most importantly: All three of these services are more secure than a telephone. The security of telephone calls is approximately zero. Most phones make no attempt at encryption; listening to the phone call is as simple as attaching a speaker to the wire.


Money stolen via Android malware Port 4000 remote anything exploit

Stuff like this happens everyday.  It's not a surprise that any of the companies don't want to investigate.  It's too small of a scale and not in their best interest to do so.  Now as for your questions...

Network Devices: Home/consumer network devices are typical not kept as secure or firmware updates released as often for.  The best thing to do would be to check the manufacturer's website of your router/AP/switch to see if you're running the latest firmware.  A hard/factory reset of the device would be prudent.  While it's unlikely that the malware on the phone was able to infect your router in any way, it's not impossible.  Also, if your home router allows you to implement policies, consider blocking unnecessary outbound traffic.  This can deter malware applications from reaching their host if they are not using a default http/https port.
Other computers/phones: You should start by changing Administrator passwords on each device and running full AV scans.  If you use any cloud-based file sharing services (i.e.- Google Drive, Dropbox, etc.) you'll want to scan those as well.  Certainly try and target the services you used on  your infected phone first.  Any accounts that were tied to your phone should have their credentials changed, including username, if possible.  If you're not already doing so, make sure you're running a software firewall on each of your machines.
Gmail: I'm assuming that you have a Gmail account and that several of your services are tied to this account.  Consider using the Google Authenticator service that Google provides.  It requires a 6 digit PIN whenever you try and use your Google account for ANYTHING that isn't already approved.  Your email account generally is the apex for many other accounts.  Set a password on it that is different from all other accounts (which you should always do anyways) and implement the maximum security your provider allows.
Additional Security Moving Forward: For credit cards and bank accounts, setup email/text notifications to notify you when charges are made or when new devices are used to access your accounts.  Most banks offer this.  Also, be very careful about the applications you install on your phone.  It's possible the the infection came from an application that was installed by you to begin with.


Suppose antivirus provider turned malicious: What do we do?

I would say security "in-depth always". What you have read is what is public in a way. Wearing my tin-foil hat, it's a good idea to assume advanced and state sponsored groups have attacks on other security software too (you might have read how an Israeli group hacked Kaspersky and saw how a Russian group also hacked them and stole data a few years ago). The Israeli hackers had in a way better network monitoring than Kaspersky itself. So the aim is to make it as difficult as possible for the bad guys and the so-called good guys too.

Good practices?

Isolate / segment networks.
Disable USB/thunderbolt ports.
Airgap critical networks/PCs.
Keep software updated (this is unfortunately a two-edged sword, but one side is sharper than the other)
Use 2FA
Train people to avoid phishing / malware campaings
Check your internal networks for certs expiration :D
Use a network monitoring tool to spot strange traffic.
Do not allow things like RDP be public on the internet (quite a few hacks in the last years happened because of this).

and many, many more.


Client-Side is never secure. You have to implement a way for the server to differentiate between authorized and unauthorized users.

For this, you need some server-side logic, which goes more into the realms of programming than information security.


Could Mental Cryptography(?) be useful to ordinary users?

The two defences you list are meant to protect against two different attacks.

  Unique password for every login

This is meant to protect against a leak of someone else's password database.  Even if the attacker works out your password, it's useless as it only allows access to the single website the leak happened on (which you've probably changed by the time the attacker gets the password).

  Never use trivial password (ex: user name plus one digit)

This protects against any password database leak.  If a password database leaks (and the password is properly hashed) then this makes it harder (and maybe impossible, depending on the entropy of your password) for the attacker to actually reverse the hash and get your password.

This might lead you to believe that a strong password is the most important defence of these two.  However, you cannot guarantee that a website hashes the password correctly.  For example, in the massive Adobe breach recently, the passwords were not salted.  This meant that attackers could reverse a great many hashes very fast.

So you see, your password could leak in plain text, or in a reversible form of encryption; making it easy for the attacker to know your password even if it's strong. In this case, your only defence is making sure you have a unique password for each site.

In the end, it's your choice, but neither defence is to be considered secure on its own.  My recommendation is to use a password manager, to gain strong and unique passwords for each site.


How does "Let's Encrypt" provide authenticity?

If you follow the links from the first Wikipedia link you provided, you'll find the spec for the ACME protocol that Let's Encrypt will use. And what it says is:

  Because there are many different ways to validate possession of
  different types of identifiers, the server will choose from an
  extensible set of challenges that are appropriate for the identifier
  being claimed. For example, if the client requests a domain name, the
  server might challenge the client to provision a record in the DNS
  under that name, or to provision a file on a web server reference by
  an A or AAAA record under that name.


Your connection will not be private - Wi-Fi CA certificate warning message on Android

Without a valid certificate in place, there is effectively no way to verify that the owner of that network is who they say they are.

Secondly, these certificates are used to encrypt the client device with the destination so you could be vulnerable to a MITM attack here.

The organisation does need to pay for a registrant authority to distribute a certificate - in my experience a lot of very small organisaitons who host public WiFi see this as a needless cost.

Your usability of the network won't be affected but I would not connect to an unverified, public WiFi as it's trivial to intercept any data flowing between you and the AP: it's the digital equivilent of not locking a public bathroom door.


When you move to your own VPS you are the one administering the server so you will have to take care of your own security.

Now this security administration could be difficult or easy depending on how many services or users you allow in, if you are the one using the VPS and you just install a few services for tests purposes and not for production issue you might relax a little, following I will add some basic security considerations you will have to take care:

Install a server you really know how to manage (or one you want to learn how to manage). If you don't have the time to learn and you want to keep it secure go for one you already know.
Keep your server up to date with security updates.
Keep track of the services you are running: ftp, DB, ssh, http server... For each of one you should keep track of the users and the passwords.
Stop or remove any service you don't use (the less services, the less problems).
From time to time have a look to the user list on your services or to the latest connections to your system if you find anything suspicious try to find the problem and change passwords.
Do backups outside the server (this is a life saver).

Long story short, a VPS security is a DIY.


Of the two, the prior method is more secure and should be used. As imjoevasquez said, its used to curtail signups and make sure email address is legitimate.
The other thing you could do is send a randomly generated code to the email, and ask to enter that to let the user create the account.


Crack password protected zip file with pkcrack

PKCrack does a known-plaintext attack (KPA). So you need to know the plaintext of a file in the zip archive before you can decrypt other files in the same zip file. But there are no other files in your archive, so you cannot do the attack.

One might ask "What is the point of doing a KPA, if you already need to know the answer?" Well, imagine you have a zip archive with the files "passwords.txt" and "usernames.txt". You could have obtained the plaintext of "usernames.txt" through other means (like asking the sysadmin) because it's not secret. By comparing the known contents of the usernames file with the encrypted version, you can (using pkcrack) recover the keystream. Then, you can use that keystream to decrypt the other file ("passwords.txt"). Note that you never learn the password, but you can decrypt the other file(s) in the archive.

In your case, "passwords.txt" is "allfiles.exe" (the file you don't know the contents of, but you want to decrypt it). To try to simulate the attack, you added "words.txt" to the zip archive, but you can't encrypt "words.txt" with the same keystream as "allfiles.exe" because you don't know the password (so you can't generate that keystream). So the attack is impossible this way.


Do WordPress vulnerabilities matter in intranet?

This question is two-fold really. First, what are the vulnerabilities of a wordpress site within your intranet, and the second are what are the risks of certain employees to that intranet. So i'll tackle this in two parts for clarity.

Intranet and Wordpress

A lot of companies set up internal sites for various reasons, but proper configuration should be done anyway, since WP itself has a lot of vulnerabilities. One of the more prominent security issues is the ease that its login credentials can be brute-forced.

Just because the site is on a company network, doesn't necessarily mean that it can't be reached / used by people on the network. If any machine that has access to the intranet becomes compromised, it can be used to access this WP site. A technique known as pivoting, allows an attacker to compromise one machine and then use that to leverage other machines on the same network quickly. So the WP site should still conform to security standards, eg. proper authentication, strong credentials, etc. Depending on what data is going to be stored behind this page, extra measures should be taken, will it be a blog? will it be a portal for employees to see their payslips? etc.

Employees

Within any company there will be various forms of risk. Whether this be internal, like disgruntled employees, or external actors, like competitors, criminals, etc. The goal is not to reduce them as much as possible.

Internal employees have a certain level of inherent trust, as in they may have key-cards to open doors, access to certain sensitive information, websites, etc. And this can and often does lead to acts of fraud or collusion occurring, where the employee might feel as though they deserve more, they should've got that raise, they work hard, etc. etc.

Internal actors still need to authenticate with the system to gain access to its internal assets, however it can be just as much a risk if someone wants to cause damage if they get admin credentials for that site, allowing it to be used as a platform for various other attacks.

External actors will have to get into the network first, which can be done in various ways, but a poorly configured WP site would be an excellent target to compromise, and possible use to pivot, maybe the admin credentials for the site are the same for someones laptop?

In any case, an internal site should be configured to at least a certain standard to avoid cases where it can be exploited. I hope this answers your question - if not I'll be happy to add more to it if you have further questions.

EDIT: I came across this article that highlights the points made in the "Intranet and Wordpress" section of the answer. Specifically about identifying sites on local networks and bruteforcing logins. it can be found here.


Is it possible to trick a keylogger, when entering a password?

Its impossible to tell without knowing which exact keylogger.

Depending on how the keylogger gets the keys, it can be tricked. For example, if the keylogger works on such a low level that it gets the keys before the operating system, then  you can likely hide from it by using a virtual on-screen keyboard or other methods that don't have you touch the actual keyboard.

OTOH, if the keylogger uses a high-level OS API to get the keys, then chances are you won't be able to trick it, since whatever the OS treats as a keystroke will be seen as a keystroke by the keylogger as well.

Some programs let you specify passwords using standard input. So what might work is storing the password in a file (off-system, of course), and then piping the password into the program you want to use via shell pipes. This will almost certainly  bypass keyloggers. The downside is that its limited to programs which accept input on the standard input stream, so most GUI programs are out.

Another method that should work everywhere with a clipboard is to store the sensitive info / password in a file, open it in a text editor, copy its contents into the clipboard and paste it where you need it. The keylogger will just see the copy and paste commands (if it doesn't know how to read the clipboard contents, that is). But note tha keeping sensitive info in a system clipboard is hardly secure.


Should I consider my Azure tenant ID as a secret?

The Azure Tenant ID is a key piece of information used for configuration, management, and identification of your Azure cloud architecture. As such it should be treated in the same way as other internal architecture information/documentation would be. The exact steps you take will vary depending upon your particular organizations policies.
However, having said that, as per this site https://www.whatismytenantid.com/ if someone has the domain name then they can also get your tenant ID.
This StackOverFlow thread also contains multiple ways (ex. curl) to access the tenant ID depending on other pieces of information in your possession: https://stackoverflow.com/questions/26384034/how-to-get-the-azure-account-tenant-id
At the end of the day it makes sense to make it harder for an attacker to discover information about your Cloud environment, while realizing that the information is discoverable and protecting yourself accordingly.
Dirk-jan Mollema's presentation https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20presentations/DEFCON-27-Dirk-jan-Mollema-Im-in-your-cloud-pwning-your-azure-environment.pdf at Defcon 27 has examples where the tenant ID is part of the information used to exploit weaknesses in Azure.


TOR Nodes silently bundled into mass produced usb devices?

Would it be possible to deploy: Yes

USB can be configured as a HID device and yield the potential of root access to a computer it is plugged into.

Would it be possible with out a power user noticing: Maybe?

If it is just a node and not an exit node the bandwidth would be low enough that most users wouldn't notice any degradation in speed ... and thus wouldn't know to look for it.

If a power user was looking for it, it would be hard to hide from things like "tcpdump" ... even if you could some how prevent them from seeing the extra traffic on there computer if they sniffed the physical connection between there computer and the router ... they would still see it.

I guess it depends on your power user

See Also:

Am I at risk if I let someone charge their Android phone from my MacBook through a micro USB cable?


Getting a log of computers that have remotely accessed a Windows server

Once someone has access to your server it's not your server anymore. Meaning that logs could be tampered with as well as binaries.

There is a security log in Windows which allows you (if configured correctly) to:

Account logon events
Account management
Directory service access
Logon events
Object access
Policy change
Privilege use
Process tracking
System events

There is just a catch here. Any administrator will be able (as mentioned before) to tamper with the logs. If you are unsure it is best to place a sniffer between your server and the network. That way you can monitor all incoming and outgoing connections and determine if the IPs accessing the machine are indeed legitimate.