Online anonymity for a journalist in a dangerous country

(PS: This post is just a general discussion. I am in no ways enticing anyone to commit any crime!)

In order to be anonymous you really have to consider other things too, other than just using some tools while browsing the internet. Tor or VPN might help you to anonymize your identity online but have you considered being anonymous in your real(Offline) life.

Have you considered the fact that social engineering can also de-anonymize you or reveal your identity!
You just mentioned in your question that you are a journalist in some country and it would end bad for you. I don't know if it is true, but if it was true then you just revealed something about your identity here! I am pretty sure that this website has logged your public IP too.(It's different issue if you are using some proxy or not.) What if someone here on StackExchange had some suspicion about your this particular post and starts an investigation. He/she starts a discussion with you and finally get in contact with you. At last maybe it turns out that this user was one of the guys who were tracking you. (Perhaps one of that guys might have upvoted your question or my answer. :P )

Another example could be that suppose you use gmail for sending and receiving emails. Suppose in very begining you accessed your email account without using any proxy. So Gmail knows your actual public IP. The scenario would be something like below:

Scenario 1:

You(Public IP)   ---->   Gmail server

After some days you read that VPN or Tor will make you anonymous. So you started using Tor or VPN to access your email account. Now the scenario will be something like this:

You(Public IP)   ---->   VPN/Tor  ------->  Gmail server

Consider that you sent a threatening email to some VVIP. You think as you are using VPN/Tor you are anonymous. This VVIP has some decent friends in all three letter organizations(MI6, CIA, RAW etc...). Now they all are after you. They ask every email service providers to find who is the owner of this email address. The email service provider will have logs containing all the IP addresses you used to access your email. Then they find your original IP that you used in scenario 1. The very next hour you have some guys in black suits at your door.

I just gave an example of an email service providers. Consider the same for online shopping sites.

Suppose you shopped on Amazon to buy something using the same email address that you used to send the threatening email. You used Tor/VPN etc. to connect to the Amazon. It is very common that many users will give their home/company address for the delivery. Now maybe the 3 letter organization guys might ask Amazon to search the user profile for the person who has the email address that was used to send the threatening email. Amazon looks up its database and finds that you live at XYZ street!
Again you shall see your friends in black suits. :P

I know that the above scenarios sounds bit like a hollywood style, but just think about it, they can happen. It really depends how worth your are.(Sorry I don't mean anything to you personally) I mean to say how worth are you to the guys who want to find you. If you are really a worth and if the guys after you are powerful & intelligent, then beware. There could be thousands of ways to find you. If not you they will find some one close to you your parents, girlfriend or even your dog/cat.  On other hand you have to be very cautious about what you do and how you do and not make any mistake.

I am not trying to scare you from being anonymous. Also I am  NOT trying to entice you to do something that is against the law. If you feel that I have said something against your personality in my answer then I can assure you that it was unintentional.


I clicked on a grabify link and I don't know if it installed a virus

Links don't install viruses. The website you land on does. However, the site you end up landing on might be just the last site in a chain. It is possible that you passed through multiple sites to get to the last one and each one might have tried to do, well, anything.
Whether or not a virus was installed depends on your browser and any weaknesses it might have.


Does it matter which Certificate Authority I source my SSL Certificate from?

I guess it really depends on the nature of your users.

99.9% of users will simply see that the browser doesn't give them any errors when they visit your site (assuming you bought the cert from a company that has their CA cert in your browser's cert store).

This does however point to a bigger problem with the PKI infrastructure as currently deployed:

Any known CA can create a certificate for any other site, and browsers will accept that certificate, even if the legitimate owner of the site already has a certificate from another CA.

While this is good in some ways, in that a site operator can change CA vendors if he chooses to, it also means that a compromised CA can be used to generate certs for arbitrary sites. This issue was raised when CNNIC's CA cert was added to Mozilla (and others) CA lists.

There seems to be an innate distrust of China (possibly related to "the great firewall"), but in truth, this does mean that any user in China, when trying to use an encrypted connection to a "subversive" site, should be checking that the certificate presented was NOT signed by the CNNIC CA cert.

There is a handy Firefox extension (Certificate Patrol) that monitors the certificates presented by various sites, and warns you if the certificate changes for any reason.


Yes that statement is true, google maps traffic data are crowdsourced. Your phone send data to google about your location and your speed. And then they compare it with the data from the other devices. You can read more about this in their official blog here.

Even if you turn off your gps they can track you. Most of the modern phones can use data from cellular towers and they can pin-point your location. This is called a-gps if I remember correctly and they can say where are you using a method called trilateration.

If you have privacy concerns, then I suggest you check google maps settings somewhere there is an option called "Location Reporting" you can disable it.

If you are truly paranoid then, congratulations! You will have to change:

your life style
possible country (because of laws)
your phone operating system (or even the whole thing because who knows what is inside in these blobs, if you want an alternative see this).

PS:
Remember "If You're Not Paying, You're The Product"
in some cases might not be correct, but these cases are not that many.


Can I trust Google Scripts on sites like Labnol?

I am the author of Gmail script that you referenced in the question. The script is now available as a Google-approved add-on on the Chrome Store.

It requires access to the entire Gmail because, unfortunately, that's how permissions works inside Google Scripts. You either have full access or no access.

In the Gmail Scheduler script, it needs permissions to read your Gmail drafts for scheduling as well for sending email through your Gmail account. When a script sends email from your account, a copy of the email is always stored in the Gmail Sent items so it is a good place to check if the script is sending emails to any other address.


What are some Linux commands for genrating and verifying digital signatures?

You're probably not going to be happy about this answer, but - as pointed out in the comments to your question - it's a bad idea of reinventing the wheel when there are already libraries and commands available for that purpose e.g. OpenSSL, GnuPG, etc.

The risks in rolling out your own crypto implementation are multiple:

Leaking plaintext
Code prone to any kind of attack e.g. buffer overflows
Bad performances caused by non-optimized code
Diminished security (as calculations rely on multiple Linux commands written by third parties)

If you really want to do this you should code in a low-level language like C and not use Linux commands, but still, it's a bad idea because of the points above. Writing code that works is difficult; writing crypto code that's strong and bug-free is extremely hard, and should be left to experts.


SSL fingerprint inconsistency: what does it mean?

This probably depends on dns resolution + caching that might happen also at the notary servers. If you resolve www.facebook.com you usually get one IP address. But this IP changes over time and may lead you to somewhere different.

I just did a quick check and indeed the www.facebook.com IP address I was given changed, and also the certificate information was different.

Over the course of a few minutes, I received 3 different IP addresses for www.facebook.com: 69.171.229.16, 69.171.234.80, 69.171.228.40

Getting the SSL certificate for each of those IPs produced different certificates. However the certificates weren't consistent even for the same IP address it seems. Over those few minutes I received at least two certificates:

-----BEGIN CERTIFICATE-----
MIIDzDCCAzWgAwIBAgIQPAjP7r6f68QrsT7gPWIL3zANBgkqhkiG9w0BAQUFADCB
ujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy
aVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2Vy
dmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMg
SW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0x
MTExMTcwMDAwMDBaFw0xMjA3MTMyMzU5NTlaMGoxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlQYWxvIEFsdG8xFzAVBgNVBAoTDkZh
Y2Vib29rLCBJbmMuMRkwFwYDVQQDExB3d3cuZmFjZWJvb2suY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQC4e9C0eD3zy0YR829bH7fd3PGGDp/3Rd7UR65Q
+jcsRoLZaer9k9tPEOd5ZmWR1MTzwVEmZ94fhoWf219K2Nx/v7fQaWYh5U0DETUo
bkDfR4zBAe+oMuFDIGrhEkUEdlWUOcpvScrtzRjRLyikTc4twjRlpB5RdnGGFopw
CRTNMwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG
+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL1NWUkludGwtY3JsLnZlcmlzaWdu
LmNvbS9TVlJJbnRsLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
CwYDVR0PBAQDAgWgMCkGA1UdEQQiMCCCEHd3dy5mYWNlYm9vay5jb22CDGZhY2Vi
b29rLmNvbTA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LnZlcmlzaWduLmNvbTANBgkqhkiG9w0BAQUFAAOBgQANiGfuAUQqkUZiD2cozCmb
7+e6vK5yzc/3o/zAd+QBydo7dkPo/t8nIHUfGxcAKUICjAzH/j3FDykK3bupFvBW
D4GoU6qVvNFgH8ucYWMNbxsknN/s3lcFryIGZYFcsYuPEB/rbBEEseKTilUSR7vt
pUEsLwSGdWwTNtKgy/COcQ==
-----END CERTIFICATE-----

and

-----BEGIN CERTIFICATE-----
MIIDnzCCAwigAwIBAgIQCSGX4cDpzQPaNSQ2VhCGgTANBgkqhkiG9w0BAQUFADCB
ujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy
aVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2Vy
dmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMg
SW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0x
MTA3MTQwMDAwMDBaFw0xMjA3MTMyMzU5NTlaMGoxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlQYWxvIEFsdG8xFzAVBgNVBAoTDkZh
Y2Vib29rLCBJbmMuMRkwFwYDVQQDExB3d3cuZmFjZWJvb2suY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQC4e9C0eD3zy0YR829bH7fd3PGGDp/3Rd7UR65Q
+jcsRoLZaer9k9tPEOd5ZmWR1MTzwVEmZ94fhoWf219K2Nx/v7fQaWYh5U0DETUo
bkDfR4zBAe+oMuFDIGrhEkUEdlWUOcpvScrtzRjRLyikTc4twjRlpB5RdnGGFopw
CRTNMwIDAQABo4H0MIHxMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0
cDovL29jc3AudmVyaXNpZ24uY29tMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg
hkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9TVlJJbnRsLWNybC52ZXJp
c2lnbi5jb20vU1ZSSW50bC5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAsGA1UdDwQEAwIFoDANBgkqhkiG9w0BAQUFAAOBgQAwUGokl1919Kf6YPDK
uoF+k7CFm+j2YtZqw4ilP9166qkM8IDWyYa87MB084WXSyfS1VnT5FSwzjP37+Qx
gjRaROuWGxfY25KebCQpoBW2PJp3S1JmqHHyxjk4mzr+tzWK0Qn+tlBUy9igtkIh
VybjO+AxBZve1qyJIsVraz8wrw==
-----END CERTIFICATE-----

Facebook might have some priority-list of which IP address the DNS issues and then the SSL endpoint you hit (via their load balancers) when you access any one of the facebook IP addresses. Their infrastructure setup might 'prefer' some endpoints over others (maybe they have stronger hardware on one endpoint over another), which is why you'd mostly see one fingerprint, but occasionally another.

UPDATE:

To answer your additional questions more specifically:

  Does this improve security?

I think it does, but primarily if you consider availability rather than confidentiality or integrity when you say 'security'. If one certificate expires/needs to be revoked/needs replacing for any other reason, you still have another one fully-operational, live and ready.

  Keeping track of which server has which certificate looks tedious, is
  this method really worthwhile? It's not even scalable since
  certificates are different within a single regional cluster

It might be a bit tedious, but I'm sure it's only a fraction of the tedious tasks facebook have to deal with in the grand scheme of things. Is it worth it? I think so, and I'd say facebook do it for a reason (As I mentioned above, primarily availability reasons). I would imagine it's not running on a server, but some beefy dedicated SSL accelerator/endpoint cluster of some sort. Those will handle SSL traffic and then reverse-proxy communication to some front-end web servers (which wouldn't need to worry about certificates).

  How about just keeping spare certificates in case of a leak? Keeping
  them versus deploying them all seems better from a security point of
  view: if one leaked, why not the others?

Yes, keeping some spare certificates offline is a very good idea, and without knowing I would bet Facebook do that too. Having multiple online certificates is not mutually exclusive to having a few offline too. You are assuming that they deploy all of them, which might not be the case. Also making the logical connection that if one leaked so would the others requires more facts. If they have good security in place to keep things segregated, then one compromise doesn't immediately link to another. They could, for example, use different HSMs from different vendors on different server OS, protected by a separate set of firewalls and managed by a completely independent teams.


Is there such a thing as MySQL connection flooding?

MySQL includes an anonymous user account that allows anyone to connect into the MySQL server without having a user account. This is meant only for testing, and should be removed before the database server is put into a production environment.

If configured correctly, the MySQL server shouldn't even be reachable by IP's other than the web front-ends (aside: if it's a small site, why do you need so many servers?).

This is more likely to be a configuration/code issue than a security issue. In any case, my advice would be to try to gather and document as much information (

What makes you think the connections are from the web front ends?
Which databases is the user accessing?
What queries are running?
Which IP are the connections coming from?

) as you can about what's going on with the system, and continue trying to wake your admin.


Differences between the Root user and users with AdministratorAccess in AWS

Does this mean the users in the AdministratorAccess group can do
  everything that the Root user can do?

Yes, barring the fact that IAM users with admin rights cannot delete root, while root obviously can delete any IAM users.

The root user generally should not be used for anything but creating an IAM user with admin rights. This should be then used for everything else.


How do you find out if a phone is secretly sending private data to a remote server?

An easy way? Pehaps, but it depends on your own experience with Android penetration testing or relatable systems; Linux. And what level of perinoa you're willing to advance to.

If you're command line savvy then install no-root BusyBox and run netstat -plant with auto sync off on the target device to list the ports and addresses and process IDs that it is listening and connected to. The process IDs can be further investigated by listing their symbolic links with ls -hal /proc/<PID_number>/exe ... However this will not detect all forms of malware, some are better hidden with rootkits or reverse SSH sessions that only activate if the device is in a certain state; nastier still are the ones that fork or take the ID of a legit process. For general security the app Tustable by Bluebox is fairly easy to use for scanning for known exploits on a target device but this and other scanners can really only tell you about known exploits and Bluebox will not even tell you if you're currently being exploited.

For Rooted Android (attacking/sniffing) I like InterceterNG and DSploit for intercepting traffic between another device and it's WiFi access point. However for this to work on cell phones and force all traffic through the WiFi the target should first be put into 'Airplane Mode' and then have it's WiFi turned on. Then fire up interceptor on the attacking Android device and sniff away. WireSkark helps with pcap files but if you just need IPs and packets with time stamp IntercepterNG is great on the go; it'll even try to help strip https.

For on the target device sniffing you could try RRCpacketsniffer and Android IMSI Catcher or Logging Test App all of which have their own nice user interfaces and features to explore. These are good for root but there is also NoRoot Data Firewall which may help with logging dropped packets when nothing should be hitting the network. Also if you have access to the device it is possible to setup a reverse modum USB tether via the Android USB debugging Bridge ADB and have all traffic routed to your PC that the device is plugged into; no root required but nearly the same amount of work to setup.

For Rooted mitigation of security risks on Android targets I like Xprivacy Installer because instead of blocking access to data it can feed junk to advertizing/spyware apps; causes less errors than blocking access on legit apps too. The Xposed framework also has other fun plugins for security on device that can be setup before you think you'll be a target. But is inadvisable if you think the device is already compromised because Xposed gives a lot of control of the system to the system.

If you want full insight into what data is being sent over your target device's radio then RIL the Radio Interface Layer is what you'll want to become more fimilure with here's part one of an artical that'll get you up to speed on the technical. And if you need to capture packets sent over non-WiFi networks (be first aware of legalities of frequency ranges in your area) then SDR a Software Defined Radio maybe what you need as SDR devices can act as a full base station (cell phone tower) and preform full man in the middle attacks on these frequency ranges. It is even possible to use a second Android with a USB attached SDR and some chroot magic to act as a mobile BTS. Put both (target device and SDR antina) into a box that doesn't allow other cell phones to accidentally connect (Faraday Cage) and you'll avoid breaking laws while trying to capture packets of the target. Testing if it's sending packets while on Airplane Mode is also a good sign you've a rouge process

I've tried to list these in the order of easy to harder and only link to information that is a bit harder to find when diving into Android's networking capabilities. Unfortunately the very base of Android's networking has propiotery drivers so for now there will always be a bit of mystery as to what goes on and what vulnerabilities are available. Additionally if the device has been compromised a sufficiently advanced attacker could clone the device's ID (ESN/IMEI/SIM numbers) such that even when the target has switched off or doesn't have network access the cloned device receives the calls and text instead; when the target device is on it's more of a coin-flip's chance on which'll get rung first...

Edit/Updates bellow

On the defencive train of thought:

After doing a bit more testing on my Android devices of apps to restrict network access (fancy GUI'es for iptables) the best one so far is
afwall the source is on github and the interface is easy enough to use with little to no knowlage of iptables. Better still is that the backed up rules can be used as a good study guide for how to effectively use iptables chains and logging features. Though this does not help if the device has already been compermized (nothing can be trusted if it has) from the more devious forms of mobile rootkits.

On the breaking things for your self train of thought;

I've also been preforming some tests using one Android device as a target and another as exploiter a sonopsis of installation and re-configuration can be found at the linked stackoverflow topic. Sufice it to say that where you to have a sufficently edcated attacker infect your device nearly anything within it's network range and anything it becomes pluged into (ie a PC for charging) could then become the next target. While the network bit is old news you may have cause to worry about USB based attacks being used to infect the PC running ADB while preforming your investigations... no knowlage of this link's trustabilaty, but, they do have a BadAndroid .zip for download as well as some documentation on how BadUSB is not a product but a feature that many devices can use to tell the system what you've just plugged in.

I've not seen it in the wield just yet but the potential to have your phone infect your PC is there and the potential to have your phone infect another's phone is also present. Tests so far shows that Metasploit is sluggish but very useable for scripted actions and having logs pushed back to the exploiting device. Some apps even work fine when ports are forwarded correctly for remote file browsing of the target's file system on the Android doing the explotation; got'a love them custom mount points option in fstab. Android devices do well at attacking printers, routers and modums but not so well without backup at attacking resonably secure Linux servers or home PCs, MS-boxes though are very much at the mursy of exploits left un-patched.

When preforming your tests be carefull and consider the PC preforming the tests to be suspect. Consider setting up KVM or firejail ie something to sandbox the USB and ADB and tripwire to monitor both the jailed system and host OS on the PC. Even then you may want to have the host PC on a seperate network and monitored remotly via another device preforming packet capture and or man in the midle attacks. If you plug in your phone and the PC starts trying to make an outgoing SSH connection then you've just won a really advanced set of Malware to study; really any kind of network activity from a PC when a phone is connected should be a very bad sign unless you've setup modum tethering over USB.

News updates

  The story as I heard it was that an odd pop-up told it's user to plugin their phone to their computer and (surprise surprise) their computer isn't working so well for them anymore and their phone is still acting funny and not keeping a charge. Seeking a new phone from the store this mobile user was completely baffled and their attending service agent was at a loss for words... hopefully they where told to not plug in their new phone too their old computer when it asks to sync to it.

What was once a known but underutilized attack vector is now in the wild and being used by markers of cross platform malware. Not FUD'ing y'all just keeping readers updated to the possible threats to security when performing evidence gathering over USB.


How do Cloud Encryption Gateways and CASB work?

CASBs are on premises or cloud based security policy enforcement points which are placed between consumers of cloud services and cloud service providers.

CASB reside between cloud services and their users and intercepts the sensitive data and replace it with tokens or encrypted values before it is passed to the cloud for processing and storage. CASB can reside on premise as a gateway. For better understanding, see diagrammatic representation.


Disadvantages of disabling RC4 in SSL/TLS

Disabling RC4 completely would be great in an ideal world, but unfortunately we don't live in an ideal world. If you do disable it, certain mobile and embedded devices may not be able to communicate with you. Keep in mind that IE on Windows XP can only use RC4 because the underlying cryptographic API (CAPI) on the system doesn't have AES.

As for the risk, the RC4 bias attacks are generally considered to be relatively infeasible due to the requirements - somewhere in the order of a few billion requests. While this is clearly not good, it's also very hard to do anything practical with.

I would currently, as of May 2015, recommend the following:

Enable TLS 1.2 with AES-GCM, ChaCha20-Poly1305, AES-CBC, and RC4 cipher suites.
Enable TLS 1.1 with AES-CBC and RC4 cipher suites.
Enable TLS 1.0 with RC4 cipher suites (avoid CBC block ciphers in TLS 1.0 due to BEAST)
Disable SSLv3 and earlier.
Configure your cipher suite order preferences to have the AES-GCM and ChaCha20-Poly1305 suites at the top.
Prefer cipher suites with DHE / ECDHE key exchange over RSA / DSA key exchange to promote ephemeral key exchange.

Note that this is subject to change - you should check for up-to-date information in future.

In such a configuration, all but the very oldest browsers (i.e. anything post-90s) should work just fine, and modern browsers will use the strongest possible protocol and ciphers.


Curious about best start for autoresponding Certificate Authority (CA)

Well you can make web API which will sign the requests (Java, C#), and run it over SSL (HTTPS).

The secure build running web based API for signing requests, with multi-layer security filtering (firewall) and access control (physical, network, application and human factor involved), in isolated network / cabinet with physical locks.

Definitely the app should run in something like C# or Java - not PHP. Static language is far more secure, C# or Java is very good choice for the big application server, while filtering and other can be even written in C++ or use the ModSecurity.

Also you need good cryptography on each security layer - not only SSL, but also SSL based access to database, certificate authentication in database like SQL Server or Oracle, database encryption. Also session token randomization (cryptographically secure RNG), password recovery security and so on must be protected with random/crypted token.

Finally the backup of the certs and the private key preferably on different non-accessible location with replication or handling via secure copy with ssh.

As it seems properly and easy way that would work with IIS on Windows Server in C# Visual Studio, which guarantees proper isolation and resilience / filtering, as well you can use SQL Server and it's crypto API. There is also very good framework for web based API with serialization and session.


Why not simply backup the TrueCrypt container file?

Backing up the TrueCrypt container means that you'll end with a timeline of your encrypted volume, and all of those versions share the same key. Having different versions of the container with the same key gives the adversary two advantages:

Information leakage: The adversary will know which sectors of the volume changed.
and, as a consequence, a compromise of the plausible deniability in case you have a hidden volume inside that volume.

In the real world, however, the case is quite different. If you don't have a hidden volume or you don't care about the adversary knowing about your hidden volume, then having some backups of the volume isn't really an issue. The cryptographic concerns (cryptanalysis) are, so far, only theoretical.


Using browser AJAX to initiate credit card transaction with processor?

Never trust the client browser.

There are four main attack vectors I can see based on this model.

1) Leaked credentials

First, as @JuliePelletier commented, in order for this to work, all the information necessary to make a "charge this card" call to Authorize.Net has to be available to the customer's webbrowser.  This includes whatever secure credentials you have to identify you to the processor.  With those in hand, anyone can make the same AJAX post to Authorize.Net to charge any card or, worse, refund from your account to any card.

2) Altered order data

Second, as @Jay commented, this scheme requires all the information about the order to pass through the user's browser before getting to your processor.  It's trivial for the user to put a breakpoint in the javascript between the return of "get order data" and the call to "send payment data" and alter the variables that are about to be sent. (All modern browsers support this with their built-in developer tools.)  This lets the user order $5000 worth of stuff, then successfully charge their card for $0.01.  Unless you explicitly checked the amount approved, you'd just see that the payment was successful and be out $4999.99.  Even if you added an approved amount check, you'd still have to void off the transaction (which might incur extra fees), cancel the order in your system, and somehow communicate that to the user.

Also, even with a tamper-check, the algorithm for doing that is going to be part of the official Authorize.Net documentation.  Unless it involves a secret key which you do not make available to the Javascript (see point 1), it would be very possible to just recalculate the check after making changes.  And if the tamper-check is supposed to also validate that the card data is unchanged, there's no way to do that without making it available to the Javascript.

3) Spoofed response

Related to the approved amount check from point 2, your AJAX call is going to be expecting some kind of "Approved" response from Authorize.Net before updating the order in your system to indicate that it was paid.  Nothing prevents the user from skipping the call to the processor and faking that response altogether.  Then you think you've been paid, but now you have no record of it - not even a failed attempt.

4) Hijacked calls

Finally, none of this provides any protection against a malicious browser plugin hijacking the user's data.  You can't prevent one from scraping the card data as the user enters it and just sending it off to a server in Russia (or wherever), but you have no protection against one which intercepts the AJAX POST, redirects the whole thing to that server (including your credentials and the card data), and then either passes it on to Authorize.Net itself or simulates a failure so that the user tries again.

It's via a different attack vector, but this article discusses a recent breach which had a similar effect.  In that case, the server was serving a maliciously altered script which caused the card data to first be POSTed to the server, and then sent off to the processor.

  From the consumer's point of view the data entered into the iFrame vanishes and the customer is left with an empty iFrame to complete again. It is expected the customer would assume something went wrong with the web page and re-enter and submit their payment details which, on the second attempt, are submitted direct to the Payment Service Provider.

Your site would have similar behavior - the malicious script would POST elsewhere, return what appeared to be an Authorize.Net "please try again" error, and then remove itself.  The unsuspecting user would then resubmit, and it would go through, with no indication to you or them that anything untoward happened.

The secure method

The secure way to address all these issues (except for part of 4) is to instead have the user POST their card data to your server.  Then, your server sends the request off to Authorize.Net and handles the response.  This addresses all the points as follows:

By sending the request to your processor from the backend, your credentials are never exposed to the user.  This also includes any secret data needed for the tamper-check in 2.
By pulling the data direct from your database to send, you can be sure that it's exactly what you want to be sending, with no chance for the client to modify it.
Because you're calling Authorize.Net in a way the end user can't see or intercept, you don't have to worry about fake responses being returned.
POSTing to your own server still doesn't prevent malicious plugins from scraping the user's data as they enter it, and there's really nothing at all you can do about that.  Additionally, you still don't have any good way to prevent said malicious plugin from altering your page to POST to some random other server on the internet.  But you can verify the IP address posting the data to your server is the same as created the order in the first place, and you can use anti-forgery/anti-XSS tokens to prevent other servers from trying to POST to you.

All that said YOU ARE NOW UNDER HIGHER PCI SCOPE, because you're sending card data to your server.  Here's the summary, but you're basically moving yourself from A-EP (Direct POST) to D-Merchant.  Even if you just immediately pass the card data along and never store it, you're still in that scope - it just means that you'll have an easier time passing your certification.

An alternative

The other secure way which keeps you out of scope is to outsource the entire payment screen to another site (such as Paypal).  This will actually reduce your PCI level, since you have even less interaction with the card data, and it outsources dealing with all these security issues as well.


Full Disk Encryption with GPT disk support

I don't think you're completely right on the TC/GPT issue. According to their documentation for V4.3:

  Support for devices with a GPT partition table (GUID partitions).  (Windows Vista/2003/XP)

The problem is that Windows 8 have to have GPT partitioning, so you'll have to run TC in legacy 32 bit mode. So it should work fine if you don't have UEFI BIOS or are using the legacy boot mode.

However, if you're ready to pay for it, then Jetico's BestCrypt Volume Encryption may be the best choice, although there are certainly many others out there as well. (I didn't look.)

http://www.jetico.com/products/personal-privacy/bestcrypt-volume-encryption

You also have Symantec Drive Encryption formerly 'PGP Disk encryption'.

http://www.symantec.com/drive-encryption/pricing


Buffer overflow exploit still seg faults

I faced the same problem. This happens when you are:

Not doing your calculation right so as to determine how many strings to put in buffer.
You are overwriting the instruction itself.

You might want to try checking if there were addresses you were already skipping before this string (it worked for me).

Or you can also try passing a string which has many %x and few alphabets and then you will see after n number of %x you can see the ASCII value of the alphabets you passed will be printed. Now this n can be used as %nu (not the n here from before) and this way also you could attack the buffer and it's called Format String attack. Maybe this would work.


Well, as the previous posters already explained, a real encryption validating the recipient is very hard to implement.

What you can do with easier methods - like symmetric encryption on application level - is to create a layer of abstraction:
When an attacker gains access to only the datastore (like when there was a vunerability in the datastore's permission/ACL system or a possibility for query injection - those are common flaws), the data will stay safe. The application will be necessary to gain plain text.

I guess (no facts, though) that social networks and communities are unlikely to do more - or even do anything.

The only real answer for your topic question is: It depends. (like always)

If you're creating a forum about sweet cats, PN encryption is probably not an issue you should primarily deal with.


If it's being altered coming from the client, then we'd also need a mechanism for client certificates to have trust.  To avoid alterations on the connection coming from the server, SSL would already cover this and more.  Really, I fail to see what this would offer over the capabilities of SSL unless you are simply looking for a lighter weight way to protect links without having to use a full SSL connection.

This also seems like it would be very open to replay attacks unless some kind of IV was provided since if the server ever displayed a URL to an attacker, that URL could then be copied, with signature, to any future user.  This would be particularly devastating on a site that allowed links to be made by users, though perhaps those links could be left untrusted and unsigned.


Yes.  If you do a normal format, the old data can be recovered.  A normal format only deletes/overwrites a tiny bit of filesystem metadata, but does not overwrite all of the data itself.  The data is still there.  This is especially true on SSDs, due to wear levelling and other features of SSDs.

The following research paper studies erasure of data on SSDs:

Michael Wei, Laura M. Grupp, Frederick E. Spada, and Steven Swanson.  Reliably Erasing Data From Flash-Based Solid State Drives.  USENIX Conference on File and Storage Technologies, 2011.

One takeaway lesson is that securely erasing data on a SSD is a bit tricky.  One reason is that overwriting data on a SSD doesn't work the way you'd think it does, due to wear-leveling and other features.  When you ask the SSD to "overwrite" an existing sector, it doesn't actually overwrite or delete the existing data immediately.  Instead, it writes the new data somewhere else and just change a pointer to point to the new version (leaving the old version laying around).  The old version may eventually get erased, or it may not.  As a result, even data you think you have erased, may still be present and accessible on the SSD.

Also, SSDs are a bit tricky to sanitize (erase completely), because the methods that used to work for magnetic HDDs don't necessarily work reliably on SSDs (due to the aforementioned wear levelling and other issues).  Consequently, utilities that are advertised as providing "secure drive erase" functionality may not be fully secure, if applied to a SSD.  For instance, the FAST paper found that, in most cases, performing a full overwrite of all of the data on the SSD twice was enough to sanitize the disk drive, but there were a few exceptional cases where some of the data still remained present.  There may be other reasons not to want to perform repeated overwrites of the full drive: it is very slow, and it may reduce the subsequent lifetime of the drive.

The FAST paper also found that degaussing (a standard method used for sanitizing magnetic hard drives) is not effective at all at sanitizing SSDs.

Moreover, the FAST paper found that standard utilities for sanitizing individual files were highly unreliable on SSDs: often a large fraction of the data remained present somewhere on the drive.  Therefore, you should assume there is no reliable way to securely erase individual files on a SSD; you need to sanitize the whole drive, as an entire unit.

The most reliable way to securely erase an entire SSD is to use the ATA Secure Erase command.  However, this is not foolproof.  The FAST paper found that most SSDs implement this correctly, but not all.  In particular, 8 of the 12 SSDs they studied supported ATA Secure Erase, and 4 did not.  Of the 8 that did support it, 3 had a buggy implementation.  1 buggy implementation was really bad: it reported success, but actually left the data laying around.  This is atrociously bad, because there is no way that software could detect the failure to erase.  2 buggy implementations failed and left old data laying around (under certain conditions), but at least they reported failure, so if the software that sends the ATA Secure Erase command checks the result code, at least the failure could be detected.

The other possible approach is to use full disk encryption: make sure the entire filesystem on the drive is encrypted from the start (e.g., Bitlocker, Truecrypt).  When you want to sanitize the drive, forget all the crypto keys and securely erase them, and then erase the drive as best as possible.  This may be a workable solution, though personally I would probably want to combine it with ATA Secure Erase, too, for best security.

See also the following questions on this site:

Is it enough to only wipe a flash drive once?
SSD (Flash Memory) security when data is encrypted in place
How can files be deleted in a HIPAA-compliant way?
Have anyone tried to extract the encryption key from a SSD?


How does CSRF correlate with Same Origin Policy

Let us start by defining the term "origin". The origin of a page is decided by three unique factors: hostname, protocol and port number. For example, http://test.com and https://test.com have different origins as the protocol is different. Similarly http://one.test.com and http://two.test.com have different origins as the hostnames are different. The origin property is also different for two services running on the same host with different port numbers e.g. http://test.com:8081 and http://test.com:8082 are considered to be different origins.

Same Origin Policy (SOP) is a browser-level security control which dictates how a document or script served by one origin can interact with a resource from some other origin. Basically, it prevents scripts running under one origin to read data from another origin.

Cross-domain requests and form submissions are still permitted but reading data from another origin is not permitted. This means that if you are performing a CSRF attack on a vulnerable site which results in some server side state change (e.g. user creation, document deletion etc), the attack will be successful but you would not be able to read the response.

In short SOP only prevents reading data which was served from a different origin. It does not cover cross-domain form submissions which are used to carry out a CSRF attack.

As far as performing cross-domain communication using AJAX is concerned, there are a few other security controls which dictate the communication. Refer to Cross Origin Resource Sharing. CORS allows different origins to communicate and share data in a controlled way and a CORS misconfiguration may also result in security vulnerabilities.

Note that SOP does not prevent resources hosted on different domains to be embedded in a page by using script tags, CSS and image tags. While this might not allow a direct reading of the contents, side effects of the loading and rendering can be used to determine (parts of) the content. Note also that Websockets are not covered by SOP at all and thus cross-site reading is possible.

P.S. Taken from my blog.


For legal question please use Law.

But from a technical point: it does not matter if a redirect happens and where it points to. The visitor first hits the .com domain and whoever has control over this domain decides what happens next. And control over this domain means that the owner can make the DNS resolve the .com domain to an IP address controlled by the owner.

If the government or somebody else gets hold of the domain name it can make the DNS point it to an IP address controlled by the new owner and the intended redirect by the old owner will thus not happen.


Suspicious established network connection

If the systems are running Windows 10, it's that feature that allows you to download updates from your peers.

Port 7680 is the listener for the peer service that Windows 10 uses to transmit the update files. If the other employee has their host name set to their last name, that's what will appear on the connection. Windows will locate all of the hosts that are broadcasting themselves, and connect to their host name.

In the event you aren't running Windows 10, it's more suspicious.


Performance of biometric authentication on cell phones as of 2014?

Though this is not measured science with hard figures, it is known that the "security performance" of the iPhone fingerprint reader sucks.

Now the question might be the wrong one. A scanner is a scanner; it takes a "picture" of the finger (the iPhone scanner is supposed to use some longer-wave emission which very slightly penetrate into the skin, but that's still a kind of picture). What makes a "good" fingerprint scanner is its resolution, and also whether it will also measure temperature, blood pressure and other such data elements which can be strong indicators of an abnormal situation (fake finger; real finger no longer attached to a living body; finger owner is under heavy stress;...). As a rule, phone readers will offer decent resolution but nothing more.

Yet the most visible "performance" indicators of a fingerprint-reader system are the false negative/positive ratios:

How many good fingers are unduly rejected
How many bad fingers are incorrectly accepted

Beyond the scanner resolution, nothing in the scanner impacts these values. This is all a question of processing of the picture, and that's not done in the reader itself.


How to detect if I am vulnerable to "Superfish," and how to remove it?

You can check to see if you're machine is vulnerable by browsing to this site: https://badssl.com/dashboard/

Everyone keeps saying that you need to completely reinstall a clean version of Windows.  I would first try to remove Superfish first.  To remove the executable you should be able to use the normal Windows Add/Remove programs method.  I believe the executable is called Visual Discovery.

To remove the certificate follow these steps from StackOverflow:

  FYI, this Superfish software is now a major news headline:
  http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/

  It is preloaded by Lenovo (there may be other vendors). You have to
  uninstall it, but that will not remove the certificate. To remove the
  certificate, you must do the following:

  Run mmc.exe
  Go to File -> Add/Remove Snap-in
  Pick Certificates, click Add
  Pick Computer Account, click Next
  Pick Local Computer, click Finish
  Click OK
  Look under Trusted Root Certification Authorities -> Certificates.
  Find the one issued to Superfish and delete it.

  If you are really paranoid, the best solution would be to reformat
  your laptop and install Windows with Microsoft media, not the factory
  recovery stuff.

While the above removes it from the Microsoft Trusted Store, this link indicates that the root certificate might be injected into browser trusted stores.  Check that your browser also does not trust the Superfish Inc certificate.  Chrome and IE both use the operating system's trusted root store.  If you're using FireFox you need to manually remove it.

Remove Trusted CA from FireFox Trusted Store

Click the menu button, then choose Preferences
Click the Advanced in the upper tab menu
Then click Certificates in the lower tab menu.
Click View Certificates
Under the Authorities tab check for the Superfish Inc certificate
If it's found, then click on the certificate and then click Delete or Distrust
Finally click the Ok button to confirm that you're removing it.


How to ensure reasonable anonymity when submitting information to a platform?

Run the site that takes the employee messages both as a plain website and as a TOR hidden service. Provide an explanation on how to connect to the site via TOR if someone wishes to do so.

This way, the people who fear repercussions can connect from their personal device at home via the TOR Browser, which will make their reports as good as untraceable. Note that this applies only to the network origin of the message; depending on what's said in the message, it might lead to the original poster.

All the others who don't fear repercussions can still connect and use the site normally.

(You could also leave out the hidden service step and just use the TOR browser to connect to the site, but if the site provided a hidden service, that would  drive the point home that the company is serious about user privacy).


Being able to convert an archive from one format to another without decompressing it is very rare. Different formats use different file structures and algorithms that are incompatible and you'll be forced to decompress the source format at some point.

When conversion by decompression is done, many of the vulnerabilities could be exploitable. The attack surface might even get bigger than before since several programs are used when doing decompression, compression, and again decompression.

If you are receiving the files from untrusted sources you could specify that only a certain archive formats are allowed. Choosing which one to support is not easy since none of the formats are "safer" than the others. You could argue that the ones with more CVEs is less secure, but that also means that a lot of issues in them have already been fixed. Is zip safer because it has less CVEs? Not necessarily, the vulnerabilities might not have been disclosed to the public, or less research might have been done.

If you stick to the most common archive formats (7z, zip, gz) and keep your software up to date, you should be fine.


The author of the code wrote it so the max values for the field were 28 most likely, 29 breaks it. As @gameOver said you can define a variable to be any length you want.

Here is a really silly python example of a buffer overflow, it is just dumb but it shows how an arbitrary limit is defined then breaks when it is exceeded.

#!/usr/bin/env python

import sys
if len(sys.argv) != 2:
    print("ERROR: Must supply 1 argument.")
    quit()
else:
    userInput=sys.argv[1]

fixedBuff=[None]*10
j=0
for i in userInput:
    print("Appending: " + str(i))
    fixedBuff[j]=i
    j=j+1

If you run that and increase your argument it breaks eventually. Very simplistic but it helps to show how a buffer overflow works.


Security of wireless connection vs. wired connection on wireless router

The answer of this question depends on your usage of the router.

First I want to mention that it depends how you implemented your wifi connection. If you are using WEP it's like you are using no encryption. Sadly there are so many problems with this standard that you should not use it at all. If you switch to WPA2-AES with a PSK you got better security at all but that's also not unhackable. If you want to increase your routers security I would recommend to disable the WPS function. In many hacks this was the entry point of some hackers but in newer versions security got better at this point. Anyway I would still recommend to deactivate it.

If you are connecting your PC with a cable with the router and disable the WIFI I would really say this is the best solution for your LAN. So you closed one entry point. It's like closing one door.

If you want to leave your WIFI enabled I would say Yes it makes a difference but just if someone got your WPA Key, so he will be possible to decrypt your packets. But if that happens, your PC will not be safe at all. No matter if u are using a cable or a wifi connection.

Hints:

Try using a long PSK (WPA Key) for your Router
Disable WPS. It's anyway just for comfort
Alter your PSK every year or if you think you are compromised
Don't save your Key in any Keyservers
Alter your standard admin user and password at the router
Disable UPNP services
Disable web access throught WAN
Update your router!
Disable SSID broadcasting
Use MAC filtering
Disable TKIP

Hopefully this information helps you. If you got more questions or want to get more details about it feel free to ask!


How to preform black-box (no source) vulnerability testing/fuzzing?

Fuzzing refers to random input testing. Contrast this to a scenario where you subject a program to a set of known inputs, which you might otherwise call unit testing. The basic idea is that you programmatically generate a large number of inputs to a program in hopes of finding some combination of inputs that causes incorrect behavior- either to detect bugs or to look for the basis of constructing an attack. There aren't really any general purpose fuzzing tools because fuzzing tends to be application specific and the inputs can't be completely random.

For example, suppose you've got a program that reads an XML file, performs some computation on that file, and then produces another file as output. To fuzz that program you could randomly generate XML files and submit it to the program. You can't necessarily know what output your program should produce (or else you wouldn't have needed the program), but you might say:

The program should always terminate within 10 seconds
The program should not crash
The program should always produce an output file, even if we can't verify the output file is correct
You might be able to verify some attributes of the output- for example if the XML input file has 27 top level tags then your output file should have 27 lines.

So you randomly generate a million XML files run your program a million times, and every time one of those conditions is not met you record what inputs caused the apparent problem. Then a developer can use those inputs to hopefully find whatever condition caused them.

Note that we're using random XML files, not totally random files. A totally random input file would be a random sequence of characters. There are a huge number of totally random files that do not constitute valid XML and won't test your program in any productive way. A totally random fuzzer would likely never generate a valid XML file to actually test the program logic. This is the basic reason why there is no general fuzzing program- random inputs need to be meaningful rather than totally and truly random in most cases.

Generating totally random invalid inputs can be meaningful, especially if you want to ensure that your program doesn't crash on mal-formed inputs. But this is essentially testing input validation and not program logic. You can use fuzzing to test both things.


Why does everyone require certain password characters now?

Identity thieves have long used a simple trick: as soon as you've cracked an account for one person, that password becomes the first thing you try for all of their other accounts.

Most of the time, this actually works. Most people use the same password for everything. Most of the rest have a few passwords, but no real system for deciding which passwords get used for what data, so "important" and "unimportant" data sometimes gets locked behind the same password. Because of this, the passwords on your site may be protecting "important" data, even if you think that the data on your site is "unimportant." To use the SE example: what about you? Maybe you store nothing "important" on SE, but do you lock other "important" data behind the same password? If you do, you're vulnerable, and even if you don't, many people do.

We cannot make users implement perfect security practices, but we can make them implement one good practice: strong passwords, every time. Or at the very least, we can choose to educate people who do not know enough, and to refrain from enabling people who do not care enough. That is the point of strong passwords, even on sites like this.


XSS in script tags application/json - possible?

No but maybe.
You cannot directly execute JavaScript inside an application/json script tag, because the browser will not treat anything inside the tag as JavaScript.  It is (unfortunately for you) that simple.  Unless you can close the script tag and open a new one, there is no direct XSS here.
However injecting JSON data into a page like that is useless by itself.  It only happens because the page will read the data from JSON and use it elsewhere.  If by chance you can figure out when and where that gets used and find some improper data usage, then you may find a vulnerability yet.  For reference here is an example of some vulnerable code with a simple alert demo.


Not enough information to tell - given this, it could simply be rejecting empty passwords, and taking any input in the password field, hashing it, then checking it against the DB safely.

Consider the following pseudocode (this is not intended to be good practice, just clear to read - do not use in production!):

if (isempty($password)) {
  reloadPage();
} else {
  $query = "SELECT * FROM users where username = :username";
  if ($user = dbquery($query, $username)){
    if (checkpassword($password, $user.password)){
      login();
    } else {
      reloadPage("Invalid Username/Password");
    }
  } else {
    reloadPage("Invalid Username/Password");
  }
}

This would give the described behaviour, without (assuming that the dbquery function makes a clear distinction between query data and user supplied parameters) allowing SQLi.

In a slight aside, using DROP TABLE in a penetration test is unlikely to go down well with the client. You should use safer methods to verify the potential flaw: get the current DB user, for example.


How would one design security in internet/network-facing industrial devices running for decades where malfunction could cost lifes?

Your 'first step' is actually the trap the industry fell into. By believing that there is a way to put these systems online without a thorough understanding of the security domain, and without providing a way to upgrade the security components without compromising the integrity of the rest of the systems, they trapped themselves with process dependencies on ancient, insecure protocols.  By that, I mean they offered the promise of cheap remote-controlled maintenance, so they eliminated the need for expensive experts to travel to remote sites.  They reduced head-count; which left themselves utterly dependent on the remote control systems.  They can't shut them off now even in the face of a cyber-security emergency, because they depend on that control to keep them running.

The first step is to segregate the internet facing components from the rest of the systems.  Leaving the system controller online and hoping its integrated sign-on page from 2003 will keep it safe is a failure.

Because SCADA networks are so vulnerable, the entire ICN needs to be firewalled from every other system; including other internal systems and networks.  View yourself as the SCADA operator and assume that everyone else in your organization, including your sysadmins and network admins, is attempting to hack into your SCADA network - then defend that.

It may be that you have no adequate defense, or that the risk of compromise is too great in terms of safety.  An air-gap is the last, best defense; even then, it's not perfect.  Stuxnet was an example of an ICN attack that leapt the air gap using a 0-day exploit on a USB drive.


Tools to extract code comments from sites?

Well, it's not really a tool, but it'll get you started. This RegEx matches many kinds of comments (# comments, HTML comments, JavaScript comments, and VBScript comments).

(<!--(.*?)-->)|(/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/)|(//.*)|(^'.*$)|(^#.*$)

And here's a demo

Note: Be sure to set the g and m flags

Update: I thought it'd be a good idea to mention some ways to use it.

You can use that RegEx with sed on httrack results. Another possibility is to pack this in a bash script where you pass the URL and catch it with $1 then wget/curl it and finally sed the page after prepending $1 to mark the file with the URL to the page.


Is there any standard that encrypts domain name of the certificate?

I think you are confusing this with encrypting the domain name send in the TLS handshake by the client, which has nothing to do with encrypting parts of the certificate. In fact, with TLS 1.3 certificates are encrypted anyway inside the handshake.

What is left instead is that the client even with TLS 1.3 sends the expected target domain name inside the ClientHello (SNI - server domain indication). Up-front knowledge of this name is necessary for the server to pick the correct certificate in case when multiple certificates are configured on the same IP address.

There is already a draft to encrypt the SNI too and there are also implementations of this draft. Note that in order to work it must be supported by both client and server, i.e. there is no way to protect connections from the client side with this unless the server also supports this. See Encrypt it or lose it: how encrypted SNI works for more details.


To answer the NAS portion of the question: the typical CryptoLocker behaviour is to crawl all connected drives (local and network mapped drives), which would include a connected NAS.

Protect the NAS by:

Not keeping it mounted
Backups that you can restore even if the entire NAS gets compromised


how to deal with with authentication tokens in the client browser and in my database?

I would not allow persistent admin logins with cookies because the administrator could browse a site with malicious javascript and get his cookies stolen.  I would force a password check at each new admin login. The cookie could obviously maintain the session once he has authenticated but the method outlined above looks to be insecure.


Where to perform authorisation in a web app?

Based on the way you have worded the question I'm assuming you mean in a .net MVC app.

Personally I view MVC as a presentation pattern. I tend to may my models pretty much DTOs. My controller is only responsible for passing data from the user into my service layer, and mapping the response to the DTO.

The service layer would contain all the authentication logic, and thus would be shared across many different controllers

My controllers are also responsible for translating internal security exceptions to appropriate http status codes.

Really controllers should be pretty empty of logic for exactly the reason you describe.


Because WebAuthn is backwards compatible with U2F.
Yes.
Yes.

To your U2F key, a website using WebAuthn just looks like a website using U2F. There are certain WebAuthn features that can't be used with your U2F key (such as storing a userHandle), but for the most part the standards are very similar.


For security purposes, can I use vpn with ufw to allow traffic only from the vpn on ubuntu?

Inbound Traffic

It seems like the threat you are concerned about is "hacking", which I will interpret in this case as "exploitation of locally running network services by malicious actors".

If this is your threat model, and we disregard out other privacy/security implications and potential benefits of using a VPN, I suspect the VPN has little to offer in this case.

First off, if your public address is known to an adversary, and you do not have any public-facing network services or they are firewalled off, the above threat model is effectively mitigated. Full stop. Any unwarranted traffic inbound to your device should be silently dropped with no effect to you*. If you are behind a network firewall (possibly providing NAT), you have even less to worry about, since stray traffic will not reach your device unless you have specifically enabled port forwarding (or UPnP is enabled)**.

So, a VPN doesn't help much with inbound traffic if you already have a firewall that denies by default. Unless you have specifically requested/configured it, a commercial VPN service is not going to allow public traffic to be sent to your device. That said, if the VPN provider is compromised, malicious actors could use the VPN as a channel to reach your device even while on your private network. But again, with a firewall, such inbound attacks are likely null and void.

Outbound Traffic

In the case I am interpreting your question incorrectly, and you mean traffic to the VPN instead of from the VPN, there could be an advantage to only allowing outbound traffic across a VPN. A likely scenario is that you are using untrusted public WiFi, perhaps in an airport. While the modern internet over HTTPS is fairly secure against MitM attacks, there are still privacy ramifications of using a public network. Modern devices are also very noisy, and could unintentionally reveal information about you or your devices that could result in privacy issues or compromise. For example, look into the tool Responder, which targets Windows devices on the same network by responding to queries they automatically make, sometimes without prompt from the user. To prevent your computer from leaking more information to the network than necessary, you can indeed lock down all outbound traffic to a VPN adapter. Example below with iptables (although any firewall should suffice):

# Name of VPN network adapter
VPN_IF=tun0

VPN_SERVER=1.2.3.4
VPN_PORT=1194

# Allow inbound connections related to things you initiate on any interface
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow all out to VPN
iptables -A OUTPUT -o $VPN_IF -j ACCEPT
# Assuming UDP
iptables -A OUTPUT -p udp --dport $VPN_PORT -d $VPN_SERVER -j ACCEPT
# Allow DHCP
iptables -A OUTPUT -p udp --dport 67 -j ACCEPT
iptables -A INPUT -p udp --dport 68 -j ACCEPT
# Default drop the rest
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

That should do it. Note you may need to make changes specific to your scenario. If your VPN configuration uses a hostname for the VPN server instead of an IP address, you will need to allow DNS outbound too. You also may need to allow multiple IP addresses if the server resolves to more than one address.

* Ignoring the possibility of a bug in the kernel firewall code.

** A vulnerability in your edge router/firewall would remove any of this possible protection.


How to use sslstrip with Internet Connection Sharing?

Fundamentally, sslstrip acts as a transparent proxy for web traffic that changes https:// to http://.  The transparent proxy functionality is implemented using ARP spoofing, which means the network switch needs to be susceptible to ARP spoofing attempts.

So you'd install sslstrip on pc1, make sure pc1 is able to forward packets, start arpspoof (separate package than sslstrip - i think arpspoof is on SF), and run sslstrip.  You can see if arpspoof is running by running tcpdump on pc1 or checking the mac address table on the broadband router - the internet router should list the MAC address of pc1 and tcpdump should show all packets routing from pc2.

Aside from that, moxie's defcon prezo is published here.  There's also videos that show you how to make this work link


Understanding the scope of Intel hyperthreading errata KBL095

The ocaml bug tracker still has the original bug report: https://caml.inria.fr/mantis/view.php?id=7452

Using the same ocaml version (4.03) and using the steps to reproduce, namely: while ocamlfind opt -c -g -bin-annot -ccopt -g -ccopt -O2 -ccopt -Wextra -ccopt '-Wstrict-overflow=5' -thread -w +a-4-40..42-44-45-48-58 -w -27-32 -package extprot test.ml -o test.cmx; do echo "ok"; done it is stated that it can be reproduced within ~30m on an unpatched machine.

I could not find any internal Intel information concerning the errata. I assume it is kept secret due to the sensitive nature of the issue.

The debian ML post (https://lists.debian.org/debian-devel/2017/06/msg00308.html) has more detail on the issue itself and the types of processors affected. This might be relevant to your research.


Preventing tampering of ~/.ssh/authorized_keys

If a server is compromised, it is basically game over. You can restore from known good backups or reinstall, and you can do some post-mortem analyses to find out how they gained entry, but that sistem is hosed and should not be repaired but reinstalled.

So, nothing prevents attacker who've gained superuser privileges to modify authorized_keys. Normally, only the user to whom this file belongs (and root, of course) should be able to access it.


How to make users trust my website? I want to convince them that is all, 100%, fully open-source without any hidden additions

You can't, unless the code that runs is entirely client side and interpreted directly from source, in which case they can verify it trivially with standard file comparison tools.

The reason is that you would have to prove that the entire software stack of the system was trustworthy, and that the entire hardware stack was trustworthy, and that every point on the network between your system and the client system was trustworthy. Oh, and that the client system was trustworthy.

Even with a third party system, you could potentially serve different files to that and to users - see this article about detecting the use of Bash pipes for an example of this. You could silently redirect the third party service to a "good" version of your code, whilst sending users the "bad" version, unless they are attempting to download the files for inspection, when you send the "good" version.

You could fake the third party system entirely, and actually control it yourself, claiming that every set of files was identical. You could intercept the response from a third party, changing it so that it appeared to show that all your code was safe. You could do that through malicious code which runs on the client system upon first load, so they never get a true response from the third party system, or just turn off the third party verification so they don't even know about it.

You can't even verify with complete confidence that a compiled application was generated from a specific set of source code, in the general case. See this answer from 2010 for some details on why - it's the same for any other compiled code, so don't be afraid of the VB6 references.

Basically, you have to behave in such a way that they trust that you won't do anything bad, and be prepared that some users won't have that level of trust. There are some people who won't use any software they haven't compiled themselves, on systems they built themselves, using hand written compilers, and even they might fall foul of malicious instructions buried in chips. We went past the point where it is possible to fully verify computer behavior a long time ago (read up on Ken Thompson's evil compiler for an example), and the client-server model doesn't help with that.

On the other hand, most of the time it doesn't matter - people trust systems all the time without this level of reassurance.


Yes, if your threat model says that you should be worried about only web application attacks, putting WAF (modsecurity etc) is ideal when no network config changes are desired.


Why don't secure tunnels (such as VPN) mask themselves as an HTTPS stream? Wouldn't this make it impossible to block them?

Actually we do have these kind of protocols and they work pretty well. One example is called "shadowsocks". The spec can be found here: https://shadowsocks.org/en/spec/protocol.html. Its main goal is simply obfuscate TCP/UDP packets into random traffic by very simple encryption, so that the GFW cannot recognize any pattern but some random bytes. It's very flexible with many "ciphersuites" to choose from.

A variant of shadowsocks is called shadowsocks-rss, which allows more obfuscation mechanism, including disguises traffic as TLS. Shadowsocks and shadowsocks-rss are the very few protocols can be used efficiently in China to bypass GFW. Moreover, these protocols and their implementations are open source on Github.


Is it dangerous to connect to a public unsecure wifi network a few seconds before connecting to a vpn?

First, let's just take a moment to appreciate the tin foil hats. Everyone has them, we just put them to different uses. As a security architect, I cherish mine for both the safety it provides and the bountiful feast it helps me supply for my family. Thank you, tin foil hats.

Your question is legitimate. Your concern is legitimate. So that's a good start. Let's start digging into why the question and concern are legitimate and discuss simple things you can do to analyze what's occurring on your machine to ensure you're not broadcasting anything you don't want to be.

VPN as a method of privacy on an encrypted network is great for ensuring that no one can eaves drop on the conversation. The tunnel provides encrypted security when there isn't one natively on the network to begin with. Since you stated that you travel a lot, it makes sense that you would want this peace of mind especially when travelling around the globe. There are some sketchy places out there not to mention shady ISPs and routers providing access for malicious purposes (eg. Evil twin attacks).

Now, when your machine boots up, it will load your core services and essential applications and any other non essential applications you may have chosen. These could be slack or email or a number of other services that you have used on your machine. If any of these services leverage a network protocol that is not secure (ie. HTTPS or IMAP/POP/SMTP w/o TLS) then you may have an oops moment.

Since most services start the back and forth with authentication, that means that any of these applications running at start up are attempting to authenticate to a remote service. This may mean that you are transmitting a password and username in the clear even though you didn't want/intend do (and again is largely dependent on the type of protocol the application is running). Ideally, you would not transmit any of this data before your VPN session is fully established.

So there is the risk, what can you do about it?

Look at your start up application lists. If there is anything you don't need to launch right away, remove it from the start up lists and launch it when you feel safe in your network environment. If you have multiple apps you wish to start at once, you could try building a simple start up script that you can execute at your leisure.
Determine if your VPN client permits the blocking of network communication before a tunnel is created. This restricts your application clients from reaching out before your network tunnel is established. A good way to keep your start up applications managed by the OS too.

NOTE: This may have adverse effects if you want to present inside of another company, as an example. I know companies I have worked for explicitly prevent VPN tunnel connections from any guest networks, which would be a set back if you needed internet hosted materials.

Ensure that you are using VPN only and not running in split tunnel mode. Split Tunnel Mode will allow your applications to bypass your VPN Tunnel to communicate. This is definitely a feature of some clients that should be turned off.

And I just want to circle back to the paranoia. So long as your paranoia doesn't prevent you from functioning in your role, it's probably a good thing. Being aware of security and the risks you run into, especially when you're on the go, is a good thing. In fact, depending on your travel I would tell you that there are some countries where you should never bring a device that you care about and use. Stay aware, share the awareness, and keep yourself secure and in your own way you're helping to make the internet a safer place.


I'm not sure what the value in their searching for %00 is.  (I mean, I guess truncating filenames on really old versions on PHP?)

If the webserver is configured to send all requests to PHP, you can use alternate extensions (.html) and try to get code execution that way.  If they've carefully configured to only allow PHP execution for the file extensions they are filtering, I would consider whether any other scripting languages are installed.  (e.g., mod_python)

Regardless of RCE on the server, if they're allowing HTML content to be uploaded on the same origin that they host the site, you almost certainly have an XSS vector...


How can I set up DHCP so that domain devices get a certain block of IP addresses and other non-domain devices get a separate block?

DHCP on its own isn't capable of this. YaRi's answer doesn't do anything to separate the networks - if you plug a non domain system in to a domain assigned VLAN port you would be on the wrong network.

You could maintain a list of MAC addresses for your domain systems and base your ranges on this (if you aren't in the list, you aren't included in the domain IP range).

If you are serious about this what you really need is a device designed for network access control and supporting the 802.1x protocol. That is probably overkill.


Is it secure to use UUID as authentication?

No, you should not use UUIDs as authentication tokens.
UUIDs are designed to be unique, not to be random or unpredictable. See wikipedia for a list of methods used to generate UUIDs. Let's take, for example,

Version 1 (date-time and MAC address)
Version 1 concatenates the 48-bit MAC address of the "node" (that is, the computer generating the UUID), with a 60-bit timestamp, being the number of 100-nanosecond intervals since midnight 15 October 1582.

If I was an attacker trying to predict the next UUID your server will generate, well once I've seen one one of your UUIDs then I know your MAC address, then I sync my system clock close to yours and I have a high chance of predicting your UUIDs. Your UUIDs are giving you ... maybe the equivalent of a 3 digit PIN's worth of security.

Now, you're proposing to use this as a super secret value that only the server and the logged in user know...
I could make some specific suggestions to improve your scheme, but you could probably benefit from doing some broad ground-up reading about "web authentication" and "session management". Here's a good primer to get you started:
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet


Does a revocation certificate leak information about the private key?

No. It does not reveal any information, except the key id, which is revealed to anyone who has a copy of either a signature made by the key, a message encrypted to the key, or the public key.

PGP keys are commonly distributed as base64 encoded data, which is simply a way of encoding data, not specific to PGP, and is probably what you say when you say it looks a lot like private keys.

The internal data is not similar. The revocation certificate is a signature, made with the private key, and a specific content, which basically says that it's revoked. You can examine the content of it easily:

gpg --list-packets revocation.asc
# off=0 ctb=88 tag=2 hlen=2 plen=120
:signature packet: algo 17, keyid <keyid>
        version 4, created 1586130213, md5len 0, sigclass 0x20
        digest algo 8, begin of digest d5 a4
        hashed subpkt 33 len 21 (issuer fpr v4 <issuer>)
        hashed subpkt 2 len 4 (sig created 2020-04-05)
        hashed subpkt 29 len 1 (revocation reason 0x00 ())
        subpkt 16 len 8 (issuer key ID <keyid>)
        data: [256 bits]
        data: [254 bits]

As you can see, it has a signature type 0x20. If we go to RFC4880, which standardizes PGP, we can read the following about signature type 0x20:

  0x20:
  Key revocation signature

  The signature is calculated directly on the key being revoked.  A revoked key is not to be used.  Only revocation signatures by the key being revoked, or by an authorized revocation key, should be considered valid revocation signatures.


Are there joint password accounts? (Like bank accounts)

It's generally undesirable to have multiple people knowing the same password.

Instead, systems that requires multiple user to be able to access the same resources usually requires each user to create their own accounts, each with their own password that's only known to themselves, and the system would simply allow all the users to access the same resources. This means that a Joint Paypal account would have worked by allowing multiple user accounts to transact from the same wallet.

This means that it's unnecessary to get the approval of the other account holders to change password.


If you don't care about your calls being monitored, you could backup the stored data and reset the phone before the departure, reset it again and restore from the backup after coming back home (as R15 suggests).
However, you need to keep in mind that Chinese intelligence agencies occasionally enter hotel rooms and perform low-level copies of your laptop and phone (some kind of "forensic acquisition", like those made by conventional law enforcement agencies). Factory reset may not be enough and a skilled attacker may be able to recover the erased files. You can mitigate, but not completely remove, this risk
a) either by moving your sensitive files to a removable card (which you cannot bring to China), overwriting the memory with random notes, irrelevant pictures, and so on, encrypting the phone, and factory reset it,
b) or by simply buying a burner phone.
You should also be careful about charging your phone.

It's possible to replace your phone's charging equipment with a malicious doppelganger while you're gone, or even while you're asleep.
If you spend enough time in hotels, you may run even into hotel employees who actually enter your hotel while you're asleep. Even if you've bolted the doors and locked them.

Source
Note that this risk could be mitigated by buying a cheap burner (dumb)phone. "Dumbphone" batteries usually last for a rather long time, which means that you may be able to stay in China for, say, a week without having to charge your phone.


FOSS Enterprise Password Management Solution

A large enterprise can't use a password manager like KeepPass,  that would be a total nightmare.  A more scalable password management solution is LDAP and Kerberos.   Kerberos' highlights are that its very scalable and no matter how large you can disable access to a user across the entire system immediately,  because authentication is centralized.


How can I detect that steganography has been used?

There can be no universal algorithm to detect steganography.

You can implement a series of tests against every known specific steganographic system in existence.  But an attacker can use that as a test to develop a new form of steganography that bypasses all existing tests.

What you'll need to do is start researching all the various known forms of stenography in existence today, and provide tests that identify each one.  Least Significant Bit is just one of dozens of known techniques.

Alternately, you can look to tools that others have developed.  See outguess.org for a ten-year-old project that tried to do something like this.  One novel thing the authors of stegdetect did was to be able to provide a set of plain images, then include samples of those images known to contain steganography.  Using linear discriminant analysis, they are able to create a detection function based on the differences.


How was the concept of password entropy developed?

Entropy in physics and in information science is just the logarithm (typically natural log in physics; base-2 log in computer science) of the number of equally likely possibilities, because it's generally easier to deal and think about with the logarithm of these exceptionally large number of possibilities than the possibilities directly.

If I randomly generated 128-bit as my random AES-128 key (that I store somewhere), it's easy to see there are 2128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 possible keys I could have used (2 equally-likely choices for each bit; and probabilities multiply).  When talking about informational complexity, it's just simpler to talk about the key having 128-bits of entropy than saying about 340 x 1036 or 340 undecillion (short scale), especially if you want to compare it against say a 256-bit key with 2256=115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possibilities.

Now if I hand you a random user's password, technically it's not possible to uniquely assign an entropy to it.

You can only assign an entropy to a model of generating passwords.  So if you are asked to estimate an entropy for a password, your task is to assume the model that might have generated that password.

If I gave you a password like P[rmDrds,r you might assume I randomly chose 10 characters from a set of 95 printable ASCII characters and to brute-force you would have to go through 9510 ~ 265.7 possibilities and it would have an entropy of 65.7 bits.  However, it's just a very weak password OpenSesame where I shifted my hands on the keyboard over to the right one letter (which is probably one of say 2^6 ~ 64 common ways to alter typing an easy to remember low-entropy password).  If you could find OpenSesame on a list of say the 1,000 (1000 ~ 210) most common passwords then in fact the entropy of P[rmDrds,r is closer to 16-bits (possibilities of 210 x 26), when the password generation is pick one of 64 common ways to obscure a password and then choose a password off a list of 1000 common passwords.  Thus after about 64,000 attempts a sophisticated brute forcer who tried this avenue of attack could arrive at P[rmDrds,r, so it's more accurate to estimate it's entropy as about 16 bits than 65.7 bits, which is 265.7-16 ~ 249.7 ~ 914 trillion times times easier to brute-force than the 65.7 bit password.

Now, obviously some less-sophisticated brute force attacker might have ignored the possibility of shifting characters over on the keyboard one space to the left while going through common password lists. But to be safe you ignore dumb attackers and assume very sophisticated attacker has considered all of your methods of password generation (Kerckhoffs's principle says avoid security by obscurity; assume the enemy has considered your secret technique among many other methods).  So when someone says you need a high-entropy password, your goal isn't a password that appears to be highly random (and some simple password tester labels it as high-entropy).  You want a random password that was built off of lots of random choices being input into your password generation procedure.  You should not pick meaningful words to you and make up a password for it with obscure tricks like shifting letters around or leetspeak substitutions.  For a strong password, you should rely on 80+ bits of non-human randomness being input into your procedure.  You should note that one bit of entropy in a password generation procedure is equivalent to a two-option decision (e.g., something that could be determined by a coin flip).

And again, with very small likelihood you can randomly generate a password with a lot of random choices and it ends up a very weak password; e.g., it's technically possible that you randomly choose 12 characters and get password1234 or dddddddddddd.  In practice, that's a possibility though it's unlikely to happen (e.g., if you use a procedure that generates an 90-bit password, the chance that it generated a password that also could have been generated with a simpler procedure with only 34-bits is 234/290 = 1 in 256 which is roughly the odds of buying exactly two Mega Millions tickets in a row and winning the jackpot both times).


How can I prevent keys loaded into ssh-agent from being sent to a particular (insecure) server?

You have several misconceptions here.

First, the whole point of a public/private keypair is that you don't send the private key to the server. The only thing your key is used for is signing messages; the server doesn't get your private key at any point during the SSH protocol. Even if you use agent forwarding (which lets you login to other servers from the first one using your key), the server doesn't get your private key: it just passes things on to ssh-agent on your computer, which signs them and sends the signature back to the first server to send on down the line.

Second, "key exchange" in this context doesn't mean "pass around keys," it means "establish a shared secret." The way Diffie-Hellman works is that the client and the server work out a new key, which is completely unrelated to any keys they might have had before. Long-term keys (i.e. the keypairs that are stored in files) are just used to sign elements of the key exchange, so that you know you're talking to the server you think you're talking to.

Third, key exchange in SSH has nothing at all to do with client keys (id_rsa and similar). The server authenticates itself during key exchange using the host key, but client authentication doesn't happen during key exchange. All a client key is used for is to sign a particular string after the key exchange (and after you've sent the username you want to log in to), in order to prove you can sign things with a private key corresponding to an authorized public key for that user. Key exchange algorithms have nothing to do with client keys.

So, weak key exchange doesn't pose any problems at all for private key security. That security doesn't rely on strong key exchange. The only attack you could do is exploit agent forwarding, but that could only work if a) you enabled it in the first place and b) you're still connected (disconnecting = no more agent forwarding).

Fourth, I'm actually not aware of an issue with using SHA-1 for the exchange hash. SHA-1 is weak to collision attacks, which means it's easier than it should be to create two things that hash to the same value. But to successfully MITM the connection, you'd need a second preimage attack, which means creating a collision with something that you don't control. In a collision attack you control both halves of the collision, which is a problem if you're signing something and the attacker can control what you're signing, in which case the attacker could create a colliding pair, get you to sign one thing, and use that as a signature of the other thing. While it's generally better to move away from it, calling it insecure for cases that only need second-preimage resistance is a bit of a stretch.


I think this question was already discussed here and the answer was like that it is actually possible, as examples like Skein and Keccak show. They participated at SHA3-Competition in 2012, particularly the so called NIST hash function competition. Skimming the functionality of the winner of this competition, the currently representative of the SHA-3 algorithm, could help you to comprehend that there is at least one efficient example for an algorithm, which in a sense allows hash length manipulation.
Keccak
So for example the Hash function Keccak is, as Tom Leek told already, a so called Sponge-Hash and gives the opportunity to manipulate the length of the resulting Hash by default. Interesting for you to see are, all in all, the following two parameters Keccak is taking:
Parameter: L
If we just take exemplarily a quick look at its functionality we will see, that Keccak works with a state vector b which is initialized with 0 , containing 25 words  w and each of this words consist of w = 2 ^ L  Bits. Consequential to this, the state vector has a length of b = 25 * w .
Parameter: n
n represents the bit length of the desired hash value. In the version that was handed in for the competition, there was L = 6 , what implies that the length of the actual hash value will be between 224 and 512 Bits. But as you can see the resulting length of the hash is variable , depending on the input parameters we discussed so far. The accosted length of the hash, in the range between 224 and 512 Bits, is just customary as you could change the L parameter to manipulate the length.
Of course the Keccak, respectively since for now two years the officially SHA-3-Algorithm, does not end here and this was not a very sophisticated description. Actually furthermore there will be gradually XOR-Encryption, which is comparable to a classical block cipher. But for further details you could take a look at the wikipedia article here. I think going into details related to technically sophistrys would be more as needed to answer your question.
I just wanted to exemplary knock up the initialization of the needed parameters to show you that there are ways of manipulating the resulting hash length.


What can I do with private 128 bit AES Keys?

You can try to decrypt things using these keys :)

First of all I would try to decrypt the hard disk (TrueCrypt) using the keys.

Regarding OpenPGP you should know that the 2048-bit RSA key is only used to decrypt a symmetric key, which can be used to decrypt the message. It's a matter of performance. You you can try decrypting the message with one of the above keys.


BGP hijacking is real and there are enough and easy to find reports in the internet, like this one or this one or this one. But of course you need to be at the right place to do it. Simple from your DSL connected system is not possible but you need to be at the level of ISP's which actually participate in BGP routing. Though you can still play with the techniques in your own virtual playground.

Of course poisining routers is possible too but even there you need to have access, i.e. only the ISP or government agencies.


What programming language does this code use?

The content of that array, is low level machine code that will execute the shell /bin/sh, if executed on the correct architecture. An attacker may be able to feed it as data to a program which will execute it as code because of a bug.

It's commonly used to exploit buffer overflows.

One of the core principle of software programming is the concept of sub routines. So a programmer can call a function which has it's own set of variables and does some work. After it is completed, the program continues execution right after the call.

This concept, however, does not exist at the hardware layer. The processor just executes the next command, unless it is a jump to somewhere else.

So in order to be able to return from a call, some preparation has to be done at the time the call is made: The return address is saved on a stack, together with parameters for the function. All local variables that are created by the function are stored on the stack as well. At the end of the function, the local variables are deleted from the stack and the saved return address is used as the target of a jump.

In theory this works fine. In practice a bug in the program may allow an attacker to store some data to a local variable that is longer then the capacity of that variable. Since the local variables are stored before the return address in memory, the attacker may overwrite the return address, to point into his own data. The processor will happily execute it, assuming it is valid machine code.

If you are interested in the background have a look at Smashing The Stack For Fun And Profit. It's old and there are some counter measurements in place today, but it gives a very good introduction.


Insecure https connection to reputable companies' domains?

Yes, www.paypal.com is really using RC4 as their preferred cipher, even though this cipher is considered broken for a while. It does support some better ciphers like AES256-SHA but unless the browser explicitly denies support for RC4 (like recent Firefox versions and IE11 do by default) it will use RC4. See also the analysis of SSLLabs.

Interestingly paypal.com (w/o the www) is a different server and supports the more modern GCM ciphers and also enables them by default. It will use RC4 only with older clients not supporting TLS1.2. See also the SSLLabs analysis.

Apart from that none of these servers support any ciphers with forward secrecy, which means if somebody gets hold of the private key of the server (by accident or by law) they can decrypt all the traffic they captured in the last time.

As for www.skype.com: they do support forward secrecy and use it by default, but they don't support any of the modern TLS1.2 AEAD ciphers and thus chrome considers the cryptography obsolete. See Chrome showing cryptography as 'obsolete' and Google Chrome "Your connection to website is encrypted with obsolete cryptography" for more information.

Note that using RC4 as the preferred cipher as done by www.paypal.com is considerable different from offering RC4 as the last resort for clients which don't support better ciphers. RC4 is considered insecure and RFC7465 from 02/2015 goes so far as to explicitly prohibit its use with all versions of TLS:

  ... However, RC4 has long been known to have a variety of cryptographic weaknesses, e.g., see [PAU], [MAN], and [FLU].  Recent cryptanalysis results [ALF] exploit biases in the RC4 keystream to recover repeatedly encrypted plaintexts. ... As a result, RC4 can no longer be seen as providing at sufficient level of security for TLS sessions.

In the context of www.paypal.com the cipher might probably currently still be safe enough, since not enough data with known plaintext will be transferred with the same key. When used for long-lived TLS based VPN tunnels it might be more problematic. Also, attacks only get better and NSA is known to have top experts in cryptography and might even have better attacks than known to the public.


In Windows, what's the difference between enumerating logged on users vs sessions?

A logged on user may have multiple sessions on a network connection - akin to the idea of threads in an application possibly.

In addition, sessions will likely refresh a lot more often than login events. This is especially true of more modern authentication and authorisation methods such as OAuth.


How does security work in a cloud-to-cloud backup scenario?

How are they limited

Using OAuth, you ask for scopes, which are similar to permissions, this means they can only use the credentials for what they ask for, and cannot do things that are out of scope.

Some of the scopes do cover multiple things though, for example being able to copy an email means they can also read the email, which is not something that OAuth could defend against unless Gmail provided an encrypted access scope, but then if Gmail disappeared so would the decryption keys.

The benefits of using OAuth are:

You can revoke one app without revoking all of them
You can change your password without losing your apps
You can limit what apps do
Apps need to explicitly ask for scopes, so they can't escalate permissions

What do they ask for

Visually

Behind the scenes

Using data from the docs and a test login I found the following scopes are requested

email

View your email address
profile

View your basic profile info
https://mail.google.com/

Read, send, delete, and manage your email
https://www.googleapis.com/auth/drive

View and manage the files in your Google Drive
https://picasaweb.google.com/data/

This appears to be an old scope: Info
https://www.googleapis.com/auth/calendar

Manage your calendars
https://www.google.com/m8/feeds/

Manage your contacts
https://www.googleapis.com/auth/tasks

Manage your tasks

Conclusion

As you can see above, they ask for a lot of permissions, in theory, they could get away with the read-only variants of the above, but they may allow you to push data back to your account, which requires being able to write.