How issuer's certificate is found to verify a given certificate?

How verifying party can get the issuer's certificate which was used to sign some derived certificate.

The browser has a database of trusted certificates, who are known to verify identity before signing. If the derived certificate is signed by one of those, then it checks out.

However, there are some CAs known as 2nd level. In this case a certificate chain is used.

The server provides the certificate that needs to be verified.
The server provides the issuer certificate.
Following the chain, we reach the top-level certificate which is already in the browser's database of trusted certificates

Naturally, the top-level certificate issuer will be very careful about authorizing 2nd-level CAs. There is quite some process, but the important thing is that new CAs can be signed by existing ones for compatibility with older devices.

  The only idea I have is that it is embedded into derived certificate as other information.

Yes, the certificate to verify does indicate the fingerprint or similar identification of it's CA certificate. This way the browser knows which CA cert to use.

In the case of chain certification, the whole certificate is included. (#2 above) (not just the fingerprint) That certificate has the fingerprint of a top-level CA (#3 above) that is (hopefully) already in the browser's keystore.

  In this case certificate size would grow with each level of certificate trust tree.

If there are 2-3 certificates in the certification chain then yes it does take more space, (which could be considered 'certificate size') but that's hardly a problem.

As for the ever-growing browser certificate store, there is actually only a limited number of CAs, even accounting for the ones that are not top-level, so this is not a practical problem either.

  How client applications such as browser or MS Word know which certification authorities are trusted root authorities? Are they just hard-coded into every application? How big is the list of root certification authorities and who manages it? What if some application developers forget to include one of authorities (or just a new one is registered) - their certificates won't be considered trusted will they? So is it possible that some site is trusted in Chrome, but non-trusted using Firefox (it can be derived from here).

Some 2nd-level CAs could be trusted in one browser, and not in another. So the CA who issues your certificate often provides intermediate CA certs so that the apps will always be able to trace back to a top-level CA in their store.

Who manages this database? I don't know. I've heard of Google deciding to stop trusting a particular CA after they had a breach of their private key.

The CA must keep their private key secret, or else it can be used to sign any and all domains. CAs are trusted because it is known that

They have good security measures to protect their private key.
They verify ownership before issuing a certificate.
They have some means to issue certificate revocation (good topic for separate question)

  What if attacker manages to include his self-issued certificate into some trusted storage: it might be victim's computer trusted root certificates list, or her enterprise domain trusted certificates. I know it's unlikely scenario, but would it work?

If an attacker can access a victim's computer (presumably the victim has bigger problems at that point) and inserts a trusted certificate, then that attacker has means to successfully MiTM the https connections. Eavesdropping, or altering the connections at will, if he can get a device in between the victim and the server. (i.e. WiFi interception, or physical network connection)

  Similar scenario to #3: patch client's application such as MS Word (or share patched version on the web for everyone to download freely) so that it considers attacker's certificate to be root certification authority. Would that work?

Yes, but presumably if you can patch the client application then the victim has lots more to worry about.


Is it possible to utilize an outbound proxy to upgrade to TLS

Due to the security built into TLS this can not be done by changing the existing TLS handshake in the proxy. Instead a TLS connection between the target server and the proxy and another TLS connection between the proxy and the client must be created. The latter connection cannot get the original certificate from the server, but the proxy must create a new one signed by its own CA. All certificate validations will be done by the proxy, so you need to trust the outbound proxy to do this properly. You also need to configure your application to trust the CA used by the proxy to create the new certificates.

Since TLS is terminated and recreated at the proxy there is no longer an end-to-end encryption. This means, that client certificates will not work in this setup transparently, i.e. you would need to move the sending of the correct client certificate to the proxy. Only few proxies support this.

If you can live with these limitations and if you only care about HTTPS traffic there is a lot of software which can do this. If you have one of the better firewalls or secure gateways the functionality is probably already there in the form of SSL inception capabilities. Apart from that you might use the free squid web proxy or test tools like mitmproxy. But note that especially the test tools not always validate the certificates properly. Also some solutions cannot deal properly with sites using Server Name Indication which makes these products unusable with lots of today's sites.

If your aim is not to deal with HTTPS traffic but with other protocols (i.e. IMAP, SMTP, SIP ... or custom protocols) the choice is much smaller and you might need to develop your own protocol specific version of such a proxy.


All normal (GSM,CDMA,UMTS,LTE) mobile network communications are encrypted, except when it is not. For example, very old 2G GSM networks may only offer A5/0 or A5/1 "encryption", which is in effect none or broken.

Many other protocols are also already broken. See: Cellular encryption algorithms currently in use globally.

Some attacks are done by downgrading the communication from a safe/encrypted protocol to a broken one.


How MiTM attack got performed on self-signed certificate while private keys is generated by ourselves?

TL;DR: Using self-signed certificates does not mean MITM is possible and using a certificate issued by a public CA does not mean MITM is impossible. But, it is more likely that MITM is possible if self-signed certificates are used because the clients dealing with self-signed certificates often deal with these in the wrong way.

Using a self-signed certificate does not allow MITM in general and using a certificate issued by a public CA does not protect against MITM in general. Apart from keeping the private key private the important protection against MITM attacks is not what kind of certificate is used on the server but how this certificate is checked on the client, i.e. if the server gets properly authenticated using a certificate or not.

The established way to authenticate a server using a certificate signed by a public CA is to check the subject of the certificate, trust chain, expiration etc - see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for details. But if a client is not doing this checks or not doing these checks properly an attacker in the path might instead provide its own certificate and the client will not notice. In the past such kind of errors happened due to ignorance or due to bugs, for example not checking certificates at all, not validating the subject, not checking basic constraints etc.

With self-signed certificates proper authentication of the server is doable too: if the client knows the certificate to expect (or its public key, or a hash of it...) up front the client can check that the delivered certificate matches the expected one. This kind of verification is actually properly done in many use cases. But in many other cases it is done wrong: it is not uncommon that clients simply have all certificate checks disabled completely if they expect a self-signed certificate instead of expecting a specific self-signed certificate. With such broken clients MITM is easy since the attacker could just use an arbitrary certificate and the client will accept it.


Should I wipe my device when leaving the company?

The short answer is no, but...

The problem here is that you don't own the machine and your company may have a policy that forbids you to do such a thing.

Here's what I would do:

Talk to my CTO about my concerns and explain my plan of action
Ask them if there is any reason they would prefer to keep the data intact
Come up with 2 or 3 Other proposals that they might find agreeable (i.e. "how about you guys keep the laptop as is for a week or two to get anything you want from it or to go through your decommission policy, then we do a wipe on the drive so it addresses my concerns as well").
See if an amicable agreement can be made.

Ultimately the problem is a legal one, I'm no lawyer, but if you wipe the drive and they explicitly tell you not to, you might be liable in some way. I would avoid it if at all possible.

I would always want to wipe my drives, even work ones. But my strategy is to work with them in finding a way we are both happy with the result. Doing things unilaterally will at best put a sour note on your relationship with that company and possibly affect you in unintended ways in the future (think job references), and at worst might lead to grievances from the company, something you never want to be a part of.

I would advise strongly you talk to your managers and your technical department, have a sit down and plead your case and your reasoning. I'm sure you both can come to some sort of understanding, that way no one leaves feeling betrayed.


To-dos when taking over an existing webserver

Center for Internet Security (CIS) has extensive guides on how to secure Apache and MySQL. It include everything from file permissions, partition layout, log files best practices etc. For the OS hardening, you would find specific hardening advice for the specific OS as well. It doesn't mean like CIS is the end of the world but what it means is you will find a comprehensive list of security best practices that is not only high level but go on into as much detail as specific commands to run.

The good thing about CIS benchmarks is that once you implement the security settings, you can use many configuration bench-marking tools to audit the security settings against CIS configuration benchmarks. Nessus professional has such a service that I use regularly to audit my own servers.

CIS Apache Benchmark CIS
MySQL Benchmark CIS
Rehat Enterprise Benchmark (if you are using a base OS different than
Redhat, there are others as well.


The SIM card contains a private key or more commonly a symmetric key called the "Ki", and the card is designed to never divulge this key to the outside world. The SIM card itself has physical security measures to make reading the key from the card very difficult without destroying the original card and/or the data stored in the card. For a long time, this makes it difficult or impractical to clone a SIM card.

The secret key isn't stored in SIM card circuitry. SIM card circuitry is basically just a very small integrated computer; it contains a CPU, RAM, ROM, and a writeable storage and have an operating system which can run Java Card application. The encryption key itself is stored in a solid state storage within the card. The card itself is a form of tamper proof housing to protect the small computer from physical access. To read this solid state storage directly, you'll probably need to use an electron microscope and grind the card very precisely without triggering the physical security features of the card.

In recent times, there has been some successful attacks to SIM cards. These attacks are typically in the form of either side-channel attacks or attacks on the vulnerabilities of the operating systems in the card rather than physical attacks.

Further readings:

how SIM uses secret key to authenticate a device
SIM Card Forensics


Do iframes maintain the security of the nested website?

If a site can be loaded into an iframe, then it is vulnerable to clickjacking attacks.

You cannot however use javascript in your site to alter the content and perform actions into the iframe (this applies to different domains), because of the same origin policy mechanism. This applies both ways, a script loaded into the iframe cannot run in the context of the parent frame.

However, there may be drawbacks for loading another site into an iframe. For example, your site is attacked and a persistent XSS is found. The attacker could then replace the dropbox iframe with a fake one he controls and gather user credentials/ data. Because the user cannot easily check the url of the loaded iframe, phising can be more easily done in an iframe.

The other version is also possible . The site you embed in the iframe is hacked and instead of it's normal content it displays a webpage that resembles a login in your page. Using this method, credentials from your site can be collected.

Furthermore, the embedded site can check if it is loaded in an iframe and jump out of it (change window.location) and perform further attacks from there.

As a conclusion, the overall security depends both on the security of your site
and of the one you embed.


Why did firefox remove Javascript injection on address bar?

It basically has to do with social engineering - you'd be surprised how many lay people you can convince to copy and paste *anything* in their URL bar.

You can still do it through the developer console and/or some add-ons, so it's not that it is completely disabled - it just takes a few more steps now to actually do it, and the rationale is that gullible people would just give up if they need to follow a specific set of steps. Thus - more of a security through complexity than a real security measure, but it should in theory prevent many of the URL-bar 'attacks'.

You can read the whole discussion about that issue at Mozilla's Bugzilla.


For bluetooth low energy (BLE), this site mostly explains the problem:
https://blog.bluetooth.com/bluetooth-technology-protecting-your-privacy

  To safeguard user privacy, manufacturers can make use of a Bluetooth Smart feature known as “LE Privacy.” This feature causes the MAC address within the advertising packets to be replaced with a random value that changes at timing intervals determined by the manufacturer. Any malicious device(s), placed at intervals along your travel route, would not be able to determine that the series of different, randomly generated MAC addresses received from your device actually relates to the same physical device. It actually looks like a series of different devices, thus, it will not be possible to track you using the advertised MAC address.

At stack overflow this might be interesting:
https://stackoverflow.com/questions/23471364/private-vs-public-addresses-in-bluetooth-low-energy-on-android

To my knowledge all current iPhones implements this. And also many Android (new than 8.0) devices.

And yes, this is only 24 bit of randomness. This can be assumed to be enough. Since your device changed it MAC regularly, a sniffer has a change of 1 / 16.777.216 to guess what is you next MAC.  This (24 bit) is not enough for encryption, but this is not the problem to solve here.

For more information you can also look into the bluetooth core spec section 5.4.5:
https://www.bluetooth.com/specifications/bluetooth-core-specification

Also note that a bonded device is capable to resolving the random MAC to the permanent (public) MAC.


Why am I getting url requests for pages I never had on my site?

There's nothing malicious about this. It could simply be that someone is hitting your machines because they have an out-of-date IP address for a completely different host, maybe because it was hard-coded into a hosts file by someone or a DNS somewhere down the line isn't functioning correctly.


Can ROM checksum checker reliably defend against non-physical tampering/hacking of a voting machine?

There are a lot of assumptions in your description, and not all of them are valid.

Assuming physical security is a problem.  Election officials have access to the machines, and presumably have the keys to the locked innards.  Hidden physical tampering is always possible.  Someone could hide a Raspberry Pi inside the cabinet that replaces the main machine, and it could respond in all the right ways.  Even the election officials would not know the difference.

Assuming that there's safety in numbers is a huge problem.  I can't find the source right now, but a while back I read a paper on Schneier's blog that an attacker doesn't have to corrupt an entire swing state, but only a few swing precincts within one or two swing districts within the state.  Predicting which precincts to corrupt is entirely possible.  Theoretically, the outcome of the entire presidential election could be altered by tampering with only a few dozen voting machines across the country.

Assuming there is "an" application to be checked is a problem.  The machine has an operating system, a user interface, a ballot reader, a tally recorder, etc.  The checksum would have to represent the entirety of the machine and all of its peripherals, not just a single program.

You're describing what is similar to the UEFI Secure Boot process.  Microsoft, Intel, and others have had problems trying to get this to actually be an effective way to secure a machine (a Blackhat presentation showed ways around it.)  Without a specific working implementation and years of analysis and attack, it's impossible to pronounce "X is secure"; even with a working implementation, I know of nobody that would stake their professional security reputation on such a pronouncement for voting machines.


Is it possible to protect the emails and calendar in an Exchange server against own Exchange administrators?

You cannot truly protect mail from the Exchange admin if they have Exchange Domain Org/Enterprise access.  If their intent is malicious, they can bypass delivery methods, and impersonate users, bypassing transport encryption.

PGP would work for receipt only and in the case the sender is also honoring the PGP methods needed.  An admin could email the person back as the user and say "my PGP is screwed up, can you send that unenecrypted" and 9 out of 10 times, the sender would comply.

Any cloud method is going to fall into this category as well.  In order to effectively administer most systems like they, the admin will have keys to the kingdom.  You can have auditing in place that would at least monitor administrative abilities so you could see other people accessing mailboxes or impersonating users and then you can require access to these functions.  Exchange 2013's DLP (data loss prevention) has gone a long way since 2010.

https://technet.microsoft.com/en-us/library/jj150527(v=exchg.150).aspx

I would start there so IF someone was trying to be malicious, you could track it.  But again.... if they wanted to, they can turn this off and be on their way before the other admins find out.  You either have to have strict contracts in place that give you massive legal repercussions against the hosting provider, OR choose a provider that is complying with compliance requirements.  They have to have auditing and process control in place that would make it MUCH harder for admins to carry out malicious duties.

TLDR;

There's no perfect method to prevent a full admin from being malicious for most mail applications.


Is it possible to intercept HTTPS payload with a trusted CA but send it the wrong server?

There are several scenarios that make it possible to intercept that connection:

Your validation code is not actually validating correctly in which case another CA might sign certificates that are deemed valid by your code.
Your CA's private key gets leaked, lost or otherwise compromised (for example because it gets factorized) in which case anyone in possession of the key can sign themselves a certificate that is deemed valid by your code.
same thing (compromised key) for your actual certificate.
Your CA might not be under your control completely (i.e. not your own CA) in which case any certificate signed by that CA (for example, any TLS certificate for any domain, if your CA is a provider of domain TLS certificates (like, for example, let's encrypt)) is deemed valid by your code.

To mitigate the last possibility, you could use a self signed certificate authority that you explicitly trust in your client application, but this comes with the usual caveats of that, i.e. understanding what you're doing and keeping the CA itself safe.

  But how can you do that unless you have both the server's cert and the CA? Where does the private key of the server's cert factor in?

This question does suggest that you are not actually understanding how a PKI or TLS works and thus that hosting your own CA might come with an increased security risk.

The general idea is that the CA is not on the same machine that the certificate is deployed on - please do read up on PKI, TLS, certificate pinning and trust chains before you proceed employing your own CA.


Trust and signing: full public key or thumbprint?

A hash of the public key is enough, provided it's long enough(I'd recommend 160 bits), and the hash function is resistant against second pre-images.

I guess github wants full public keys because their SSH library expects that. There are also some situations where it's useful to have the full key available. For example you can offline encrypt a message to a certain public key, but not to a hash.

The decision hash vs. public key isn't a decision based on security, but on which one is more convenient for a particular use.


Although I dont use this particular metric I use something similar.

The only time I've seen differentiation from the table is using greater then (vs greater then or equal to). You are using the minimum values out of a range instead of a midpoint.

In the examples you have using 9 vs 8 for the high value should do it. Quantative values like this are really just estimates.


Which cloud providers can be used for the simulation of DDoS attacks?

I'd suggest that the point here is terminology.  Whilst an illegal attempt to DDoS a site is obviously out of ToS for most cloud providers, what about providing load testing facilities?  when it comes down to it load testing to failure is likely to be pretty similar to DDoS and is, I would expect, quite legitimate. The key difference is authorisation.  DDoS is an unauthorised attack and load testing is a legitimate activity that a company has authorised.

There are a number of cloud based load testing companies (I'll avoid listing them otherwise this could be a product recommendation) but also AWS can likely be used for load testing (e.g. bees with machine guns)


One of the primary things used for websites to determine which language to send the page back in is the Accept-Language header.  Modern browsers set this header for all requests based on your preferred language settings.  It is probable that even though you are using a VPN with an IP address in Japan, your browser is still sending the Accept-Language header with a preference for Serbian


Just go with the SELinux enabled, it doesn't break anything but adds plenty of security features.

By default, all network processes are sandboxed, it also can sandbox desktop apps as well.

Basically working with SELinux is easy, for example:

When you enable SELinux, filesystem has to be relabeled during boot, it is possible to relabel folders online as well, this is because files are not labeled when it's off
There are "booleans", they can boost your security a lot, you can disable "ptrace" for example or access to /proc and /sys for all non-root users
You can fix issues if any with custom applications by using "audit2allow" with the audit.log
you can use sandbox command to sandbox scripts
there are GUI tools in Fedora to manage SELinux policies

There are two things which are very beneficial:

sandboxed processes will not be able to read and write files if someone manages to inject code
it may prevent some kernel exploits from working especially if you harden it via "booleans". Kernel exploit would normally bypass SELinux.

There are also other security features in Linux like Capabilities, ACLs, cgroups.


Is WPA(2)/AES or some derivative really perfectly secure?

The quick answer is "no".  We know from long experience that nothing is "perfectly" secure.

AES has no significant flaws that we know about today, and has key sizes that are large enough to resist brute force attacks forever.  People have been studying it for a decade, looking for weaknesses, and have only come up with some weak keys, and reduced round attacks.  While we consider the chances unlikely, there is no guarantee that a fatal weakness doesn't exist.

Given the history of breaks so far, I don't think AES will prove to be the weak point of WPA2.

WPA2 is less mature than AES, and while the theories are good, and again nobody's published an exploit yet, we know that most security failures end up being flaws in protocol designs or implementations.

It's ironic that you use the phrase "or derivative" in your question.  Many protocol security flaws are created by implementations that offer backward compatibility.  "Set this flag to upgrade from Version 2 to Version 3" turns out to be exploitable by an attacker far more often than you might think.  WPA2 by itself may be fine, a mythical WPA3 might be fine, but an access point that offers both might hide a fatal flaw.


Yes, you can override parent .htaccess with a .htaccess file of your own. You can execute php/etc from within the .htaccess file itself. Take a look at my htshells project for some examples: https://github.com/wireghoul/htshells/


Why do so many browsers show sites with revoked certificates?

Checking for revocation is easy. But deciding what to do upon failure is not.

On the site you linked Steve Gibson writes:

  Much of the certificate revocation system is
  badly broken and doesn't actually work!!

Yup.

And further down he writes:

  Good and complete solutions DO exist.

And I don't think that's so. Unfortunately he doesn't go into more detail.

As far as I understand it comes down to the decision of what to do if the revocation check does not yield an answer but just times out.

Do you then err on the side of caution and deny access to the site ("hard fail")?
Or do you err on the side of "well networks are flakey sometimes" and allow access, perhaps after a click-through-message ("soft fail")?

If there actually is an attack against you with a revoked cert, then the attacker will probably control the network anyway and just block communication to the revocation checking server. This is a conceptual shortcoming in revocation checking.

Some ways around the issue with different approaches are:

OCSP must staple extension
short lived certificates

Further reading

https://www.imperialviolet.org/2011/03/18/revocation.html
https://www.imperialviolet.org/2014/04/19/revchecking.html
https://wiki.mozilla.org/CA:RevocationPlan
Update 2015-12-30Wed Excellent post by Hanno Böck about the revocation checking problems. See section Remaing Problems: 2015-11-18, Changes in the TLS certificate ecosystem, Part 2


Is it possible to reverse a sha256 hashed value if we know part of the input value?

Can we Calculate/Figure out/Find out? = NO
Can we efficiently Bruteforce? = YES
--- ANSWER BELOW IS FOR BRUTEFORCE ---
By the design of Cryptographic Hash Functions, they are 'one way'. i.e. can not be reversed.
But just in case you stumble upon this scenario (super rare in real-world and common in CTFs).
You can use Hashcat(tool) to Bruteforce with masking to bruteforce just initial characters.
E.g.
Hash (sha256) = c0489750c13b64906237515b5b944e0d9fe9380dfc2f60cc29ca2c88514c0a38
Plain Text = XXXXh_Example
(X - Unknown)
Constraint = printable ASCII and Numbers
Hashcat mask = ?a?a?a?a
Hashcat mode = 1400 (SHA2-256)
command =
hashcat -m 1400 c0489750c13b64906237515b5b944e0d9fe9380dfc2f60cc29ca2c88514c0a38 -a 3 ?a?a?a?ah_Example

so this will reduce the time significantly while brute force. Try the above example
you might see something like :
x64mayhem$ hashcat -m 1400 C0489750C13B64906237515B5B944E0D9FE9380DFC2F60CC29CA2C88514C0A38 -a 3 ?a?a?a?ah_Example
hashcat (v5.1.0) starting...

...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce MX150, 500/2002 MB allocatable, 3MCU

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers:
* Zero-Byte
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
...
<snip>
...

Approaching final keyspace - workload adjusted.

c0489750c13b64906237515b5b944e0d9fe9380dfc2f60cc29ca2c88514c0a38:hAa5h_Example

Session..........: hashcat
Status...........: Cracked
Hash.Type........: SHA2-256
Hash.Target......: c0489750c13b64906237515b5b944e0d9fe9380dfc2f60cc29c...4c0a38
Time.Started.....: Mon Aug  3 09:02:41 2020 (4 secs)
Time.Estimated...: Mon Aug  3 09:02:45 2020 (0 secs)
Guess.Mask.......: ?a?a?a?ah_Example [13]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 15592.6 kH/s (0.11ms) @ Accel:128 Loops:32 Thr:256 Vec:1
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 48369440/81450625 (59.38%)
Rejected.........: 0/48369440 (0.00%)
Restore.Point....: 0/95 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:509120-509152 Iteration:0-32
Candidates.#1....: hAaeh_Example -> RWj h_Example
Hardware.Mon.#1..: Temp: 51c Util: 61% Core:1721MHz Mem:3003MHz Bus:4

Started: Mon Aug  3 09:02:38 2020
Stopped: Mon Aug  3 09:02:45 2020

*on GPU


Thunderbolt to HDMI connector freezes macbook, potential security risks? Time for a clean install?

Ultra paranoid to me means you destroy your computer, put on a tinfoil hat and dig a bunker, so I'm going to interpret that as "sensible precautions"

The security risk of any physical port is that there is an exploitable vulnerability that would allow an attacker to compromise the hardware, firmware of OS. An attacker could embed an exploit into a device like display adapter to compromise vulnerable systems when it is plugged in.

The article is about Thunderclap, which is a vulnerability in how MacOS treats thunderbolt devices, and impacts thunderbolt 2 as well as thunderbolt 3. Your older Mac should have thunderbolt 2 so would be vulnerable until Apple develops a fix.

Unplugging the device while you are typing in your password isn't going to protect you if it is malicious because a compromise would involve installing memory resident software on your system to do whatever the attacker intends, once the device delivers its payload and infects your system the damage is done. However, the chances of the display adapter being malicious is extremely low - there aren't any known instances of that exploit being used in the wild. I don't think nuking the site from orbit is warranted, it's almost certainly it was just a glitch - even Macs get them occasionally.


This actually decreases anonymity. If the final IP address you exit from is fixed, for example a VPN, then you lose a large amount of privacy and anonymity functionality that Tor provides via its rotating exit relays. The fixed exit IP would result in a persistent exit point. Additionally, you would be exposing your networking stack to TCP fingerprinting, rather than exposing that of the exit relay. VPNs are vulnerable to this kind of fingerprinting because they send networking packets assembled by your operating system to the destination server unchanged, revealing identifying information.
If you wish to avoid membership attribution (revealing the mere fact that you are using Tor), a VPN does not help. Tor sends traffic in bursts of 514 bytes called cells. Anyone who sees a VPN connection that is sending encrypted data in 514 byte bursts can infer that Tor is being used. If you want to hide the fact that you are using Tor, you could use pluggable transports which obfuscate the traffic between you and a bridge relay, making detection and blocking harder.
Tor is designed to be most effective when used on its own. It provides rotating exits to reduce inter-website fingerprinting. It provides persistent guards to mitigate sybil attacks. It allows the use of bridges to bypass censorship. Even ignoring the fact the VPNs in general are bad at resisting traffic analysis attacks, chaining it with any other networks can interfere with these security features.


(Crosspost of https://crypto.stackexchange.com/questions/33728/uploading-pkcs12-to-yubikey-piv-slot which is offtopic there.) It is theoretically possible to change the public exponent while keeping n as long as the new e is coprime to p-1 and q-1, and for F4 you have a good chance of this. But this is much more work than generating a new keypair, plus it does require regenerating the cert(s).

I'll guess you generated your RSA keypair with ssh-keygen from OpenSSH; that's the only common tool I know that chooses e=37, and it also defaults to filename id_rsa. The easy answer is to instead generate the keypair with OpenSSL which defaults e=65537 aka F4 (at commandline). Further, req can combine keypair generation with CSR creation, and unless you need to keep the CSR file can also skip the CSR and produce a selfsigned certificate directly by adding -x509:

openssl req -newkey RSA:bits -x509 -days 3650 -keyout privatekey -out server.crt
# proceed with PKCS12 conversion etc.

If you are planning to use this for SSH, note that OpenSSH can perfectly well use an RSA key with e=65537; it simply doesn't generate one.


Can malicious software be installed inside Linux swap partition?

It is difficult to think of a way to write to the swap partition as Linux doesn't allow you to write to them. The only scenario I can come up with where this may be possible is when the system is coming out of sleep or hibernation and memory has been paged out to the swap file. Prior to restarting Linux, the bootloader or some other boot-time code makes malicious modifications to the swap partion.

Certainly encrypting your swap partition, as suggested in a comment by @ott, would make this more difficult. It may not be impossible as the OS must be able to decrypt the swap partition, but it will likely be much more complex.

The above notwithstanding, I've never heard of such an attack. I suspect the reason is that by the time you are in a position to modify the bootloader, you've pretty much pwned the computer and have no reason to mess around with subtle attacks like this one.


Why do I need to setup VPN on my router to protect a DVR from outside access?

As SmokeDispenser already explained, most consumer-grade and enterprise routers and firewalls have such default settings (UPNP disabled, no port on the Internet interface forwarded to a LAN IP address, etc) that will not allow devices connected on the LAN side to be accessed from the Internet side.

So, which options do you have when you need to access a device on the LAN from the Internet side? As you already know...

You could make static NAT configurations in the router or firewall in order to forward all needed ports on the Internet interface towards ports needed in the LAN device you need to connect to
You could configure a VPN on the router or firewall that connects to the Internet so that when you connect to the VPN you can access the resources connected in the LAN side.

Option 1 is more straightforward and can be easily accomplished even with the most simple home routers. But it also has several disadvantages:

You have to know in advance which ports are required by the application you are trying to use when connecting to the LAN device and then forward all of them. For instance, working with DVRs I have found a few models that need port TCP/80 (HTTP) and TCP/554 (RTSP) forwarded to be able to login and watch the composite of cameras connected to the DVR.
All forwarded ports will be accesible from Internet and therefore exposed to port scaners, vulnerability scanners, exploitation attempts etc. That means all forwarded ports will be part of the attack surface an attacker could use. In worst cases, I have seen scenarios where all ports in the Internet interface have been forwarded to a given device in the LAN, exposing to Internet not only the minimum required ports to work but also the management interfaces and unexpected services.
There are limitations if you need to access the same port on two different LAN devices. Lets say your LAN hosts two devices A and B needing port TCP/80. If your forward port TCP/80 on the Internet side to device A then you can not get TCP/80 on the Internet side forwarded to device B and you will need a different port, lets say TCP/81, forwarded to TCP/80 of device B. This can sometimes complicate the setup.
By using NAT, any security for the traffic will have to be provided by the application. If this is not the case, any intermediate element between client and the server would be able to eavesdrop on the traffic. Let´s say the DVR has only HTTP login interface but not HTTPS. Login credential will be carried unencrypted through the Internet and event the video streams will be carried unencrytped if the application does not care itself about the encryption.

Option 2 is usually harder as it requires understanding of most advanced networking concepts, some cryptography background and even may require specific hardware. That´s why its usually not as common as NAT in home or small business environments. But it has several advantages from the security point of view:

If the VPN is set up in the router or firewall connecting to internet there is no need to forward ports and any application on the LAN side will be accesible as soon as you connect to the VPN, even using the same port on different LAN devices (which was problematic to accomplish with NAT) If the VPN is set up in a DMZ or LAN device, you only need to forward the ports needed to establish the VPN. For instance, OpenVPN would only need UDP/1194 and IPsec would only need UDP/500 and UDP/4500. This way, forwarding only one or two ports you can establish the VPN and then access any application on the LAN side. This would usually need much more ports to be forwarded if using NAT. So you can see that attack surface is smaller when using VPN
The software running the VPN is usually designed with security in mind, so even if exposed to its own vulnerabilities, in average the number of vulnerabilities in this software will be lower than in general purpose software such as a web or e-mail server.
Since VPNs leverage cryptography, traffic between the VPN client on the internet and the router/firewall will be encrypted even if the application traffic is not encrypted by the application itself (i.e.HTTP). You can not obtain this additional protection at all using NAT.
VPN do require authentication in order to connect to it. This allows tracking connections of legitimate users and also prevents unauthorized users from even reaching the any port on the LAN side. Again, this can not be accomplished by using NAT: if you forward port TCP/80 anyone can connect to it, what allows credential bruteforcing attempts, exploitation attempts, etc.

Taking into account this comparison of NAT vs VPN, I would always recommend using VPN whenever LAN resources need to be accessed from the Internet only by authorized users.


LSB replacement and its effect on grayscale histogram

In LSB-Steganography you store your bitstream in the least significant bit, thus in the first bit of every pixel. doing so you change rgb-values that should ideally not be recognized by human eyes. The more data you put in it the easier it is to be recognized like your histograms shows.


Download webcrawler output from Dirbuster

A quick pipe into cut into xargs wget or any other simple scripting should do the trick. Google is very capable of helping with the sort of problems.


adaptive vs. non-adaptive adversaries; Is there a precise, unique and general definition?

The term is conceptual and is not a standard term in the field. The conceptual nature of the term means there is not going to be the type of definition that I think you are going for.

It broadly means what your first quote says. An adaptive adversary can adapt to the environment and responses from the environment as part of the attack. A non-adaptive adversary cannot.

Someone (or a bot) with a pre-written script to exploit a vulnerability is non-adaptive. They have one thing they can do. An expert with experience, creativity, and a suite of tools can devise new approaches while they attack in order to achieve their goal.


How to respond to a SSH brute force attack on a single VPS?

Yes, this is a perfectly reasonable and common approach. However, you've reinvented fail2ban. You probably want to switch to using that instead so you don't have to debug issues with your script and can make use of the existing filters for ssh, apache, and other common services.

Unfortunately, there is not terribly much you can do with these IPs. You can try to report the activity to the abuse contact listed for their IP block, but it's not really worth your time unless they do something more serious.

You should also do the standard ssh hardening, like disabling password-based and root logins unless you absolutely need them.


I suspect that an android device is trying all SSIDs it was ever connected during wifi scan. 1) It alone gives enough information to identify the device 2) If a network with no encryption is saved, a MitM attack can be performed.

This would be typical of most mobile devices if you store the connection in a way where it will automatically connect again at a future time.

  Is there a way to handle it?

Yes. You can do so by doing whatever combination of the below you like. This will at least limit your exposure.

Don't store you wireless networks so you can connect automatically in the future.
Delete wireless networks when you are done.
Disable wireless on your device when you don't want to be connected.

  E.g. trying only networks that are in the range (listen for beacons).

In comments elsewhere, you seem to find "passive scanning only" as an appealing solution. This will significantly increase times for a device to connect to a wireless network (from your reported 3+ seconds to something more like 6-20+ seconds) and have the potential to create what appear to users as "outages" of similar periods every time the device scans to check for better networks to which they can roam.

Put simply, it won't happen. Why? Because it is asking for developers to add a feature that (a) decreases usability by increasing time taken to find/connect to networks and (b) impacts modern devices more significantly than legacy devices. Or put another way, how many users do you think would be pushing developers to "significantly increase the times it takes to connect to a wireless network"?

Automatically trying to connect to any configured SSID as if were hidden was a change made to simplify the user experience and make it easier for the masses. As in many such feature decisions, this does come at a cost for potential security/privacy issues. You will find little support in developer circles for going back on this decision and increase the number of [confusing] choices people [with little technical knowledge] need to make when connecting to a wireless network.

A better and more likely suggestion that you could make is an option (global or per profile) to "allow connections to hidden networks" that would be enabled by default and provide the existing behavior. Knowledgeable users could then choose to disable it if they wanted, and the active scanning for networks taking place could do so without including an SSID. No negative impact from disabling active scanning necessary.

Still a tough sell since there are many features users [in larger numbers] want for their devices and developers tend to follow the demand, but more viable than the prior suggestion.

  It will make impossible to connect to hidden SSIDs, but who uses it?

Many organizations do and some home users. Personally I find very few cases where it is used for a valid reason, but my opinion doesn't stop people from using hidden SSIDs.


Is this an uncommon PNG ending or image steganography?

That block seems to contain PDF syntax.

Here you can find information about the PDF format. The page provides this sample file where you might recognize the syntax for the cross-reference table (xref) and the trailer section:

%PDF-1.7
1 0 obj
  << /Type /Catalog
     /Pages 2 0 R
  >>
endobj

2 0 obj
  << /Type /Pages
     /Kids [3 0 R]
     /Count 1
  >>
endobj

3 0 obj
  << /Type /Page
     /Parent 2 0 R
     /MediaBox [0 0 600 400]
     /Resources << >>
  >>
endobj

xref
0 4
00000000000 65535 f
00000000010 00000 n
00000000069 00000 n
00000000141 00000 n
trailer
  << /Root 1 0 R
     /Size 4
  >>
startxref
249
%%EOF


Why isn't there a FROST-like cold boot exploit for iOS?

The attack simply does not work on iphones. Main reason being iOS performs key wipe on the RAM, so it is not possible to retrieve any key via cold boot attack. You may find this link useful. Note also that this attack was based quite some time ago on Android 4.0

http://www.slideshare.net/DaiYang/main-29642969


If website A and B are linked internally, you could just transport the session information, so the session key can be used to automatically login to website B - doing this without website A and B communicating internally somehow would very very difficult to secure.

Basically you need a method of A telling B which client session codes are valid, without relying on the client transmitting this information.

Of course it is possible to do it this way using PKI, but I imagine that's a little overcomplicated for you situation. In any case, this solution would basically be implemented as follows:

Client connects an logs into website A
Website A creates session cookie and signs it with website B's public key
Website A redirects client to website B along with signed cookie
Client goes to website B, presents signed session cookie
Website B reads session cookie, verifies it with website B private key
Client is now logged into website B

Bear in mind this whole process could still suffer from a number of attacks if any of these connections are not secured via SSL/TLS.


Is it correct to use form field(hidden) for storing Session Token

To be protected against CSRF while also hardening against XSS, store your session IDs in cookies (with httpOnly flag) and use separate session-bound form tokens that you validate upon POST. By combining these methods, you prevent an attacker that has found XSS from stealing session IDs, while you still protect against CSRF in a meaningful way. Using the session ID as form token enables an attacker to steal the session ID through XSS.


Asymmetric key encryption that can have a public decryption key, but encryption key cannot be computed from that

First of all, as @WhiteWinterWolf points out, this is a digital signature scheme. Digital signing is specifically for the purpose of making sure that the message is from you, not somebody else, and hasn't been modified since it was signed. Without going into the math, here's how it works:

You have a message that you want the world to know came from you
You have a public/private key pair that supports signing (RSA, DSA, etc.)
You take a cryptographic hash (usually something like SHA-256) of the message
 - Like asymmetric encryption, signing schemes work best on small bits of data
You create a digital signature of the hash digest (the output of the hash function)
 - This requires your private key
You distribute the message, the signature, and the algorithms (hash and signing) used
Alice has your public key, and wants to confirm that the message is authentic
Alice re-hashes the message, with the same scheme
Alice then uses your public key to turn the signature back into the hash digest
Alice checks if the digest of the message and the digest from the signature match
 - This is called verifying a signature

Cryptographic signatures are used all over. They're used in X.509 certificates (like SSL/TLS uses) to verify that the certificate was issued by a trusted authority, and hasn't been tampered with. They're used in secure email, to make sure that the recipient knows the sender of the mail wasn't spoofed. They're used with signed files, usually executable binaries, so that the author of the file is known. That's just a few of the common uses.

Now, with that said, let's be clear about something:

Encryption, in general, does NOT provide authentication (proof of the identity of the source of the message) or integrity (confirmation that the message has not been tampered with); only confidentiality (also called privacy or secrecy). If you encrypt a message, but don't sign it (or provide some other form of verification), an attacker can take the encrypted message and manipulate it, changing the meaning even though the attacker doesn't know what the original text was. The recipient of the message can then decrypt the message, and may have no idea it was tampered with.

For some stuff, this isn't very meaningful; an attacker tweaking English text that they don't know the content of will produce meaningless gibberish. For other things, though, it can matter a lot. Do not rely on encryption to verify where a message comes from! (Caveat: if using an "authenticated encryption" scheme, that includes integrity checks and, if nobody else has the key, also provides authentication. You shouldn't assume that encryption provides these things, though; most of the time it doesn't.)


What is the website checking about my browser to protect the website from a DDoS?

Most Denial-Of-Service (DOS) attacks rely on some asymmetry between the resources involved on attacker side and on target side. In other words, to be successful, a DOS needs an action to require very few resources client-side (so the each clients can send a lot of requests) while involving larger resources server-side (so the server(s) will be unable to handle the load).

Due to this, DDOS attacks (the "Distributed" version of DOS attacks) are obviously not engaged by real humans clicking on links in a browser tab, but by bots sending massive amount of parallel requests to the target. The consequence of this is that the DDOS "client" is not a real browser, but a tool which may more-or-less simulate one.

Cloudflare DDOS protection system is quickly described on their website as follow: "an interstitial page is presented to your site’s visitors for 5 seconds while the checks are completed".

Two things trigger my attention here:

The checks: the most obvious way to sort real website users from automatic DDOS bots is to check whether the HTTP client is a real browser or not. This can go through testing the client's behavior against a panel of tests (see the post "bot detection via browser fingerprinting" for instance) and compare the result with the one expected from a genuine instance of the browser the client claims to be (for instance if the client claims to be a Firefox version 52 running on a Windows 10 machine, does it present the same characteristics?).
5 seconds: Executing JavaScript tests and redirecting the visitor could be a very fast and almost transparent operation, so I believe that this "5 seconds" timeout is not there by accident but is meant to revert the computational asymmetry back in favor of the server.

The most light version of such principle would simply be to ask the client to wait (sleep) 5 seconds before resubmitting the same request (with a unique identifier stored in a cookie, as described on Cloudflare page). This would force the DDOS client to somehow handle a queue of pending redirections, and would finally make the overall DDOS process less effective.
A more brutal alternative would be to request the browser to solve some mathematical challenge which would require a few seconds to be solved on an average home system. In such a case, attackers would have no other choice than spend computational power to solve these challenges if they would like to proceed, but doing so will completely void the asymmetry since all the attacker's resource will be busy in solving challenges instead of sending requests, finally "DOSing" the attacker's system instead of the target's one.


Privacy policy about links to other sites

You might be interested in these:

Internet user arrested for linking to other websites (Free Software Foundation ask to take action)
Facebook to check outbound links for viruses, malware (yahoo news), Twitter also has a similar service
I think that links to other "dangerous" sites might impact google's SafeBrowsing result, but I'm not sure about it


Is posting Windows dumpfiles online a privacy or security threat?

Please consider: Microsoft collects such files via Windows Error Reporting and companies can get access to those files collected by Microsoft by signing an NDA. Microsoft takes actions to only make the crash dumps available to companies who can prove that it's their driver that causes the crash. It requires a digital certificate to do so.

You would post that information for everyone publically, so I'm glad you care. Personally I'd not post such a file on the Internet.

It requires only a few commands to get the most important information out of it, if you have an Internet connection. The output of

.symfix c:\symbols
.reload /f
!analyze -v

and removing the line that contains ANALYSIS_SESSION_HOST should suffice for someone to either solve the problem or give more instructions on what is needed. It may take a few moments longer for asking and answering, but using above steps gives you human readable text that you can check for sensitive data.

The most important data is such a line:

BugCheck 117, {fffffa80188fb4e0, fffff88004248e9c, 0, 0}

If you still consider posting it, here's what it may contain: An OS crash (bluescreen) will generate a kernel dump. Such a dump contains

crash information (exception information),
processor information,
the executables that are running,
crash time and uptime of your PC,
the drivers you loaded and
potentially all contents of physical RAM (everything what is in memory at the time of the crash).

This may give hackers an attack vector: given they find your IP address and they know the version of a vulnerable driver you have in use, they might start attacking.

However, it heavily depends on the settings with which the crash dump was captured. By default it will be "Small memory dump (256 kb)" (on Windows 7 at least), so it does not contain all information from RAM but only a very small subset which is related to the crash. This may still include drivers and version numbers. Usually the small crash dump is sufficient to solve problems.

If you have a full kernel crash dump, you can convert it into a small one using WinDbg and the .dump command, so you'll finally have the original full dump and a small dump.

Example information contained in a small kernel dump:

Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.23418.amd64fre.win7sp1_ldr.160408-2045

Debug session time: Sun Jul  3 15:37:39.242 2016 (UTC + 1:00)
System Uptime: 0 days 6:59:28.965

0: kd> lmDvmAtihdW76
start             end                 module name
fffff880`04f5f000 fffff880`04f7b000   AtihdW76   (deferred)
    Image path: AtihdW76.sys
    Image name: AtihdW76.sys
    Browse all global symbols  functions  data
    Timestamp:        Wed Feb 24 19:28:17 2016 (56CDF641)
    CheckSum:         000201BA
    ImageSize:        0001C000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

So I can find out that in July I was using the ATI graphics card with a driver AtihdW76.sys from February. That might already suffice for an attack, if I leave other traces, e.g. your IP.

Note that this information is not included in the textual output of !analyze -v, so it seems not relevant for the analysis:

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

VIDEO_TDR_TIMEOUT_DETECTED (117)
The display driver failed to respond in timely fashion.
(This code can never be used for a real bugcheck.)
Arguments:
Arg1: fffffa80188fb4e0, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
Arg2: fffff88004248e9c, The pointer into responsible device driver module (e.g owner tag).
Arg3: 0000000000000000, The secondary driver specific bucketing key.
Arg4: 0000000000000000, Optional internal context dependent data.

Debugging Details:
------------------

DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING:  7601.23418.amd64fre.win7sp1_ldr.160408-2045
DUMP_TYPE:  2
BUGCHECK_P1: fffffa80188fb4e0
BUGCHECK_P2: fffff88004248e9c
BUGCHECK_P3: 0
BUGCHECK_P4: 0

FAULTING_IP:
atikmpag+ce9c
fffff880`04248e9c ??              ???

DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_TDR_TIMEOUT
TAG_NOT_DEFINED_202b:  *** Unknown TAG in analysis list 202b

CPU_COUNT: 4
CPU_MHZ: c25
CPU_VENDOR:  GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 2a
CPU_STEPPING: 7
BUGCHECK_STR:  0x117
PROCESS_NAME:  System
CURRENT_IRQL:  0
ANALYSIS_SESSION_HOST:  REMOVETHIS
ANALYSIS_SESSION_TIME:  12-09-2016 19:03:01.0993
ANALYSIS_VERSION: 10.0.14321.1024 amd64fre

STACK_TEXT:
fffff880`05bad2c0 fffff880`044b27e7 : fffffa80`188fb4e0 00000000`00000024 fffffa80`182fc800 fffff880`044b2488 : watchdog!WdDbgReportRecreate+0xa3
fffff880`05bad7e0 fffff880`044b2c1e : 00000000`00001000 fffff8a0`3dd1c8e0 00000000`00000008 00000000`00004000 : dxgkrnl!TdrUpdateDbgReport+0xcb
fffff880`05bad830 fffff880`044b3ed2 : fffffa80`188fb4e0 fffffa80`188fb4e0 fffffa80`182fc800 fffffa80`0dd73410 : dxgkrnl!TdrCollectDbgInfoStage1+0x2e6
fffff880`05bad8d0 fffff880`0455bfbf : fffffa80`188fb4e0 00000000`00000000 fffffa80`182fc800 fffffa80`0dd73410 : dxgkrnl!TdrIsRecoveryRequired+0x17a
fffff880`05bad900 fffff880`04585d09 : 00000000`ffffffff 00000000`00189d69 00000000`00000000 00000000`00000002 : dxgmms1!VidSchiReportHwHang+0x40b
fffff880`05bad9e0 fffff880`0458444f : 00000000`00000102 00000000`00000000 00000000`00189d69 00000000`00000000 : dxgmms1!VidSchiCheckHwProgress+0x71
fffff880`05bada10 fffff880`045572e6 : ffffffff`ff676980 fffffa80`0dd73410 00000000`00000000 00000000`00000000 : dxgmms1!VidSchiWaitForSchedulerEvents+0x1fb
fffff880`05badab0 fffff880`0458400e : 00000000`00000000 fffffa80`182fc800 00000000`00000080 fffffa80`0dd73410 : dxgmms1!VidSchiScheduleCommandToRun+0x1da
fffff880`05badbc0 fffff800`03713bc6 : 00000000`02c4d1a9 fffffa80`0ddb5060 fffffa80`0ca00720 fffffa80`0ddb5060 : dxgmms1!VidSchiWorkerThread+0xba
fffff880`05badc00 fffff800`0346d6a6 : fffff800`035fae80 fffffa80`0ddb5060 fffff800`03608cc0 fffffa80`0da82d90 : nt!PspSystemThreadStartup+0x5a
fffff880`05badc40 00000000`00000000 : fffff880`05bae000 fffff880`05ba8000 fffff880`05bac2b0 00000000`00000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND:  kb
THREAD_SHA1_HASH_MOD_FUNC:  711770ee3782c8990d4679145cf9108ec8a862f4
THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  cc3ee750d9914b4f5449ea07474e889f95552a7e
THREAD_SHA1_HASH_MOD:  36a574ce8074060aba5fc87a076613c500071d03

FOLLOWUP_IP:
atikmpag+ce9c
fffff880`04248e9c ??              ???

SYMBOL_NAME:  atikmpag+ce9c
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: atikmpag
IMAGE_NAME:  atikmpag.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  56effafd
FAILURE_BUCKET_ID:  X64_0x117_IMAGE_atikmpag.sys
BUCKET_ID:  X64_0x117_IMAGE_atikmpag.sys
PRIMARY_PROBLEM_CLASS:  X64_0x117_IMAGE_atikmpag.sys
TARGET_TIME:  2016-07-03T14:37:39.000Z
OSBUILD:  7601
OSSERVICEPACK:  1000
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK:  272
PRODUCT_TYPE:  1
OSPLATFORM_TYPE:  x64
OSNAME:  Windows 7
OSEDITION:  Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID:  0
OSBUILD_TIMESTAMP:  2016-04-09 07:46:22
BUILDDATESTAMP_STR:  160408-2045
BUILDLAB_STR:  win7sp1_ldr
BUILDOSVER_STR:  6.1.7601.23418.amd64fre.win7sp1_ldr.160408-2045
ANALYSIS_SESSION_ELAPSED_TIME: 493
ANALYSIS_SOURCE:  KM
FAILURE_ID_HASH_STRING:  km:x64_0x117_image_atikmpag.sys
FAILURE_ID_HASH:  {fa4b6286-8c4a-e9c2-c89f-5612619e000e}
Followup:     MachineOwner
---------


options are case sensitive, -t means format of timestamp and I guess you want to use -T that set the format of output. Depends on what kind of data you would like to dump, e.g., http host, tshark -r file.pcap -T fields -e http.host should be what you are looking for.


Write zeros in memory through a buffer overflow

If I understood correctly the problem has to do with packing your input. You can use any scripting language to pack your input. For example in python you can do (assuming x64-bit arch):

cat <(python -c 'from pwn import p64; print your_padding_here + p64(0x555555554bce)') - | ./your_program

or if for any reason you prefer only built-in modules:

cat <(python -c 'print your_padding_here + __import__("struct").pack("I", 0x555555554bce)') - | ./your_program

Also you can accomplish the same thing by writing the buffer to a file and then pass the file as input.


Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, ...)

Quite frequently this appraoch is judged insecure stating that one file could have several names at the same time (links, bind-mounting etc).

It is most certainly true that one file could have multiple security contexts, one for each name. However, whether or not this is insecure depends on how you view it:

This feature of AppArmor does not require that remote filesystems support AppArmor, so for example it can be implemented for NFS paths.
Usually, Unix DAC remains enabled, so even interesting applications such as the contents of /usr/bin should not be writeable. In theory!
There may be additional controls to prevent end users from mounting or symlinking.

However, all of that aside, the goal of MAC-type projects is to confine processes as well as users, so that a process run as user only runs with the necessary permissions it needs. Few applications, except perhaps ln, need the ability to create symbolic links and those that do do not require them on all directories and paths. So it should be possible to implement the desired containment for most processes.

Whilst not suffering from the potential issue in pathnames, inode-based security does have its problems:

The information attached to file security is stored in xattrs (extended attributes) which means special considerations for network file systems.
Some applications change inode values which can cause issues working with security contexts - specifically your file is likely to revert to the default security context if you edit it and vim operates this way.

I think the difference is quite subtle and it is not a case of one is more secure than the other, as that each has its advantages and drawbacks. Properly understood, both enable secure policies to be implemented.


Should I avoid authenticating the user unnecessarily to a server?

Application complexity

Let us assume that client uses a secure channel like TLS to communicate with server. Then, sending authentication info like tokens does not expose any sensitive data.

If you make the client decide when to send authentication info, it increases complexity of your application. Each time you change protected or unprotected routes on the server, or each time you add new protected or unprotected resources, you have to update the client. There will always be some probability that you don't send authentication info when server requires it.

Header types

You are talking about authentication headers. If you mean cookies, then it is fine. But if you mean that you have your own header type, then this can be a problem. Browsers send cookies related to particular domain / path automatically. You can be sure that the cookies set by your application will not be sent to some external domain.
Whereas if you use your own header type, there is some chance that you send your authentication headers also to external domains. The owner of the external domain can use it to attack your application. That's why I discourage you from using custom headers for authentication and use cookies instead.


Does the TLS 1.0 support on CloudFront create a vulnerability when only TLS 1.2 is enabled on the Origin side?

I've disabled TLS 1.0 and 1.1 on our API and the Origin side of CloudFront.

I spoke with AWS support and it seems that there is no way to disable TLS 1.0 and 1.1 on the Viewer to CloudFront side. Support notified me that there is an open feature request but no timeline for its implementation.

This means that a Viewer will be able to establish a TLS 1.0/1.1 connection with CloudFront and then CloudFront will establish the 1.2 connection to our ELB and web servers.

The API connections from the Viewer requires TLS 1.2. We will need to add a check in the UI to notify the user if an API connection cannot be established.

While not as clean of a solution as I had hoped for it seems to have mitigated our immediate risk.


Security margin of a winzip, Winrar password of 64 characters against GPU cracking

Modern versions of WinZIP and WinRAR employ fairly slow key derivation in order to combat password guessing attacks. In particular, WinRAR uses scheme where number of effective SHA-1 iterations depends on length of the password (longer passwords yield more iterations), and WinZIP uses PBKDF2-based function, IIRC.

"Fairly slow" is not a precise metric. For WinZIP actual speed will depend on ZIP file format; older formats used weak encryption and weak key derivation; later formats are much better in that respect. If you need some numbers, you can assume one modern GPU can deliver about one million passwords per second. For WinRAR that figure is much lower and will likely be below 50'000 passwords/sec per GPU.

Using those figures you can actually estimate what length of a random password is sufficient for your purposes (e.g. how long it should resist attacks).

I'd also like to note that 64-char random password is an overkill. 20 characters will already give you more than 128 bits of strength which is more than sufficient (encryption in WinRAR is AES-128 anyway). If you want 256 bits of strength then 40 characters is sufficient.


What is the exact meaning of this gpg output regarding trust?

The official GnuPG documentation regarding this output is rather awkward.

The OpenPGP trust model

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model

By default, GnuPG uses the OpenPGP trust model. In this, you can put trust on a key, which allows it to validate other keys.

Trusted Keys

Keys can be trusted. Trust allows keys to validate other keys. Although trust is a kind of signature on other keys, it does not get distributed when uploading keys to key servers.

There are different trust levels:

  - No ownertrust assigned / not yet calculated
  e Trust calculation has failed; probably due to an expired key
  q Not enough information for calculation
  n Never trust this key
  m Marginally trusted
  f Fully trusted
  u Ultimately trusted

(taken from the GnuPG manual, chapter key management)

Mostly important are the last three categories: your own keys are ultimately trusted; fully trusted keys' signatures are regarded equally worth your own ones; while marginal trusted keys require more signature paths to make a key valid.

Valid Keys

In the default OpenPGP trust model, a key is fully valid if:

  it is signed by enough valid keys, meaning

  you have signed it personally,
  it has been signed by one fully trusted key, or
  it has been signed by three marginally trusted keys; and

  the path of signed keys leading from K back to your own key is five steps or shorter.

(taken from the GnuPG manual, chapter 'Validating other keys on your public keyring')

Other keys are marginally valid; showing there is a trust path, yet it is not strong enough. I highlighted the word "valid" in the quote above: only fully valid keys' trust is taken in account for calculating validity! In GnuPG, the default trust model can be configured.

The manual page linked directly above also contains some examples for trust calculation, but watch out for the non-default trust model applied for simplicity!

GnuPG's Trust DB Information

This information gets printed whenever the trust database gets updated, for example after receiving them from a key server.

gpg: depth: 0  valid:   1  signed:  16  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:  16  signed: 115  trust: 1-, 1q, 1n, 1m, 12f, 0u
gpg: depth: 2  valid: 105  signed: 189  trust: 81-, 11q, 0n, 4m, 9f, 0u
gpg: depth: 3  valid:  29  signed: 120  trust: 19-, 9q, 0n, 0m, 1f, 0u

This output describes your web of trust. The letters represent the trust levels listed above. On level 0, you will find your own (ultimately trusted) keys. There should not be any other kind of trust on this level. This key is valid (of course).

The further output represents my interpretation which is not based on reading the (missing) documentation nor the source code: You signed 16 keys, making all of them fully valid on level 1. For 12 of them you issued full trust, one of them only marginal. Those again lead to another 105 valid keys you trust on level 2. Some of them are trusted again, leading to another 29 valid keys in level 3.

Comparing this output to what the keyservers tell, you should probably update your keyring. ;)

More trusted keys in deeper levels could create the levels 0-5 if you do not change the maximum path length of five proposed by OpenPGP's trust model.

Werner Koch, the main author of GnuPG, once stated on the GnuPG mailing list:

  You would need to look at the source.  However, if you known the WoT well,  you should be able to figure out what this is. [...]  You should consider this a debugging output.


Determine a Web Application's version of AngularJS

You can get the version number from the JS file itself.

Header of the current angular.js:

/**
 * @license AngularJS v1.0.6
 * (c) 2010-2012 Google, Inc. http://angularjs.org
 * License: MIT
 */

You can search for this file using the console of your browser as well.


How to verify if a phone number is an online SMS account as opposed to a genuine SIM card

Most VoIP system tries to behave like a real phone, so unless you have access to the internals of a telco, you can never be sure what kind of device is behind a number.

One alternative is to make the user call a special number (premium, toll-free, etc.) that requires contracts to be setup to call, then you can control exactly which telcos you'd setup the contracts with.

Similarly, you can establish ties with major telcos so they can tell you if the number belongs to a subscriber.

Another unsupported ways is finding SMS gateway addresses of popular carriers and asking the user to select the carrier to receive the text. Only numbers that are actually with the carrier can receive the text.

Also, if you can write an app to be installed on the user's phone, you can access their SIM info.


Is there any way to set up secure email for Network Solutions domains?

It sounds to me like you bought a domain for your website and want to have your email @yourdomain.com type of deal. You don't have to use "their mail services". You can use Google Apps or any number of third party providers. You will then just update your DNS settings at Network Solutions with instructions provided by the provider.

As for your PHP solution, that would be writing an email server from scratch. Unless you have your own server, you would not be able to have PHP listen on the expected mail ports, but if you do have root on your server, you can just set up your own mail server and update your DNS accordingly.

The main point here is unless you have some odd package, Network Solutions shouldn't restrict your from connecting a third party email service to your domain. If this answer doesn't fit your scenario, please clarify your needs.


Can my employer see my Google Search Data on my personal IOS device when I’m at home but accidentally logged into company Google Account?

It doesn't matter what Internet connection you use or what device you use, the fact that you are using the company's account means that they could review all your activity on that account.


Security implications of using public subnets in AWS VPC for hosting web and job servers

Public subnet means  that the instances can be directly accessible from the internet with their public IP address (or EIP). There are a lot of bots constantly crawling IP addresses. If they get a response from a server, they know that it could be potentially be breached or bruteforced.

I understand the cost consideration and I would make use of NACL (first) + Security group.(first and second). NACL is setup on the subnet level, protecting all the instances within that subnet. Security group is on the instance level, meaning it can be forgotten and leave the instance to the mercy of "hackers".


Key derivation inside secure container of HSM

Some HSM are configurable enough to allow adding functionality within the HSM. However, this will not be doable through PKCS#11, which is an API meant for invocation of cryptographic algorithm on externally provided data. What PKCS#11 offers and is closest to your problem is C_UnwrapKey() that can take as input an encrypted key (key is encrypted with another key) and decrypts it. However, chances are that the custom key derivation function that you must implement does not match any of the key unwrapping formats that your HSM knows of (if only because you derive your key with encryption, not decryption).

As for extended the HSM functionalities, it happens outside of the scope of PKCS#11, so if this is supported at all by your HSM, it will be done with methods specific to that HSM. I have some experience with Thales HSM (formerly known as "nCipher"): some of them allow custom code to be pushed into the HSM, provided that you activated (i.e. paid for) the relevant option, called CodeSafe. When I was doing that (now some years ago), development was done in C, with a much reduced subset of the standard library; the HSM CPU was not fast at all (think megahertz, not gigahertz); but there was a substantial amount of RAM (dozens of megabytes), and, most importantly, the cryptographic accelerators could be used for crypto operations.


Is it more secure to apply updates as soon as they get released?

The general rule of thumb is to apply the updates in a test or parallel environment, run tests, then approve for general release.

In some cases, people will apply patches to live environments but on lower priority servers and be willing to suffer outages on the less critical systems.

BUT, because of the criticality of a lot of patches, it is also advised to design a policy of applying all patches to all servers as soon as possible and have a procedure by which you can quickly recover from an issue. You trade patch-based 'availability' issues for security-based issues and you need to determine which trade-off is the best fit for your environment.


Is it safe to reveal table column names in ajax?

I would agree with Xiong that obfuscation of table column names makes your code more complicated, and harder to understand. If you do this with every table, you might confuse other developers (or yourself, looking at the code a year later).

(I assume that your database is not directly reachable from the internet, but only through your own backend. If it is, you should review your architecture.)

  Also, perhaps there are other issues with using ajax calls like this that  I'm not thinking of? I.e. a user maybe could edit the page JavaScript and call my ColdFusion code in ways it wasn't originally intended?

Be always prepared that your API might not only be called from your own web page, but also from a curious developer, trying it out for fun, after having looked at the JavaScript code or HTTP traffic:

You should always validate user data before persisting it. Otherwise you might end up fixing data causing exceptions somewhere in your backend (e.g. trying to parse a string as date, but having just a garbage string value).
If your API route causes database rows to be added, it should probably only be available to authenticated users.


Is it dangerous to allow clients to run JavaScript on a Server

If any of the pages you've archived on your server contain malicious code targeting webkit vulnerabilities (remember, wkhtmltopdf runs on webkit), it's theoretically possible this will result in a security breach on your server upon running the page through wkhtmltopdf.

The implication here being that malicious code that would normally target your users' client machines is now de facto attacking your server, you'll have to decide for yourself how you rate this risk.


Blockchain + shared unused bandwidth as the proxy front = ddos mitigated?

I can't speak about the security of private blockchains, because, frankly, I do not believe in private blockchain solutions. I can, however, speak about my experience with public blockchains and why I believe in the security they can provide.

Utilizing a public blockchain, like the one we leverage at our company- in this case I am referring to the Ethereum mainnet- does not necessarily solve the DDoS problem or prevent heavy request load from bogging down the network. Rather, it makes launching DDoS, or even DoS attacks, extremely costly to the attacker because in order to write to the blockchain, one must pay gas, which is essentially a POST request fee.

It is also very difficult to launch a DDoS attack due to the decentralized nature of the network. The nodes are scattered around allowing requests to the network to be handled by hundreds or thousands of points rather than one, central point of failure. As it may be possible to take down a collection of network nodes, the other nodes in the network will still able to handle requests, though perhaps maybe be responding at a slower rate.

With regards to pentesting a web-app that utilizes smart contracts or a blockchain back-end, the server hosting the web-app front-end resources (or using something like s3 to host static pages) will still need to utilize traditional systems, and will therefore not be protected by a blockchain at all, requiring the company to rely on traditional DDoS protections. The blockchain back-end, however, will still be accessible via some gateway for whatever duration the web-app remains offline. The exception to this would be if the web-app was able to host its files and resources using additional distributed technologies (e.g. IPFS). Thus, making the web-app truly decentralized and more resistant to attacks.

Please don't misunderstand me, it is very possible to DDoS a public blockchain, though it is difficult and extremely costly. There have been a few cases of this happening in the history of Ethereum, yet these attacks have not prevented the consensus algorithm from working correctly, nor has it prevented access to the network resources (e.g. accessing smart contract functionality, stored data). What these attacks have done is significantly increase the time it takes for transactions to be validated, thus encouraging Ethereum users to add higher gas fees to their transactions in hopes of getting their transactions mined in a more timely fashion.


While Thomas Pornin is correctly pointing out that the only way to trust a host under attack is using fully homomorphic encryption in practice you can try to work around this requirement.

A potential attacker has full control of CPU, memory and disk. So it is not possible to do any calculations on valuable data in a VM that might not be under your control. On the other hand it is often not necessary. If you want to use your VM as a database or storage / backup service the VM never needs access to unencrypted information. You could store files or entries in a database, store hashes of the encrypted files or file names and e.g. sort for file size or retrieve a certain file where the client supplies the file name as a hash value.

Such a scheme limits what you can do with your data but given a good encryption it is impossible for an attacker to steal your data. In the worst case they can modify it, so you need encrypted signatures to prevent tampering of the data.

A popular example is boxcryptor, which uses an encrypted container to store files securely at different cloud providers. Another is duplicity, which allows encrypted backups using rsync and GnuPG.

Encrypting the storage of the VM itself by, e.g. truecrypt or Bitlocker does not increase the security level significantly. It might thwart an attack if the VM is powered off but as soon as you run it the OS needs the key to access the encrypted volume and at that moment a potential attacker can get hold of the key as well.


help developer choose correct path to go down for security certifications

Most security folks are rather cynical about certifications. We get sold a LOT of certs, and we also validate that many of cert holding folks of the world aren't paying very close attention. (CCNA, you know default creds are bad!)

My advice:

Only get certs your employer pays for
If compliance is a concern, go that route first
Try not to go vendor specific unless you are absolutely married to that vendor
Realize that you'll have to do a lot of real training at home or on the side. Lots of folks with certs miss silly stuff like bad crypto and sql injection.

Besides that, you just want to ask yourself what's good for my career/what's best to do with my time?

Personally, from my perspective as a pen tester, the list looks a little bonkers.

"Cyber security" is a buzzword. I wouldn't pick a training course with that name.
Do you want to be a PCI auditor? Do you like doing PCI auditing? Is there a management role in it for you? If you don't like auditing I wouldn't train myself to do it.
Same goes for business cont.

From a pen tester role I like these certs:

OSCP
OSCE

But I understand that's not exactly what your organization needs or is asking you to do.


Can a program containing virus, used to flash USB firmware infect it despite formatting?

Yes.
Unfortunately, without more specific information on the infection, it's hard to know how likely it is, and it probably isn't likely* that it flashed the firmware in such a way as to infect it, but you can't be 100% sure.
* This is not to say of malware that uses the Autorun feature which hop off of a USB flash drive by using autorun.inf. It's actually not unlikely that malware on the machine may hop onto the flash drive that way.


JSON Web Tokens - How to securely store the key?

The reality is if other processes can access your process memory or features of your
virtual machine, the game is probably over as you're already compromised. If a process
has access at this level, it can probably gain other information, such as the initial
credentials used to authenticate before obtaining the token or just modifying
results to make token verification return true despite the actual verification result
etc. Don't focus too much on extreme possibilities. Most compromises occur through
far simpler exploits or configuration errors, such as storing the private key on the
file system which is world readable and accessible to your web server etc.

The best way to manage keys and secrets will depend a little on your platform. Some
platforms provide key management frameworks and perhaps using one of those would be
appropriate.

Don't focus too much on the fact this is a secret key. In reality, it is no more
critical than other credentials you need to manage. For example, how do you manage
the credentials which allow access to your databases? If that solution is good enough
for your databases, then it is probably good enough for your secret key. If it isn't,
then I'd be asking whether it is actually good enough for your database. The reality
is, if someone is going to compromise the system, then it is likely they are doing so
to gain access to whatever data/service the interface is providing. In most cases,
this underlying service or database also needs credentials and credential management
and these are the real keys to the kingdom.

I think it is best to use a consistent approach to manage all the credentials your
application needs and not to treat the secret key for token creation/verification as
extra special. Don't over think the solution simply because it involves words like
'key' or 'secret'. All credentials are sensitive data which need to be managed in a
secure manner. A large proportion of the mistakes that are made are due to
over engineered complex solutions that become difficult to maintain and easy to get
wrong. Consider solutions which use existing, known and tested facilities/frameworks,
such as keytool, key chain managers etc. Failing that, use something which can be
easily understood and maintained. Something as simple as a database may be
sufficient. Avoid solutions which involve storing the information as constants or
global variables as this can become difficult to maintain because changing the key
now means a code change and now you have to test, do change management and promote to
production, etc.

As to how you generate the keys, well that will depend on your environment and the
types/levels of risks you need to manage. As a rule of thumb, I'm always very wary of
anything that relies on 'random'. Generating true random values is extremely
difficult and often doesn't do anything to improve security. In fact, assumptions of
randomness which have later proved to not be random can reveal patterns, which in
turn means the possibility of being able to predict future values, which is almost
always a bad thing when you're talking about keys. In this scenario, I don't think
randomness is going to gain you much from a security perspective unless you're in an
environment where it is critical that sys admins don't know the key. Likewise,
regular changing of the key is unlikely to provide much other than inconvenience for
your users. Whenever you change the key, all currently issued tokens will become
invalid. You might want to consider having a policy to change the key when staff
leave or change roles and you could even consider a policy to change the key whenever
the software is updated, etc.
However, religiously changing the key every week or so
is unlikely to provide anything with respect to security.

Note that the above does not hold true for all keys. There are situations where a
private key needs to be managed with extreme care - for example, the private key for
root CA. Not all keys are equal. Your management approach needs to match the
requirements and risks you need to protect against. In the case of JWT, you are
dealing with a largely closed ecosystem - the key is used to generate/sign and verify
tokens. The objective is about detection of tampering, not protection of secrecy. The
risk is that if someone gets the key, they can create forged tokens and gain
unauthorised access to your service. What this ultimately means depends on the
service. The extent to which someone will try to do this also depends on the
underlying service and its perceived value. The lengths you go to to secure the key
should reflect the threat.


How do I prevent users from modifying resources they do not own?

This is called Access Control.

You need to check that a user has access to a record before performing an operation on it.

The simplest method would be to use a different database or schema per tenant. Or...

As you use Java, you could use Spring Security. It now integrates with Spring Data JPA, allowing you to pass in the userid/username into your SQL queries easily.

Or use Row Security right in the database. Oracle if you have $10M to spare, or this will be available for PostgreSQL in October. You can mimic it with updateable security_barrier CHECK OPTION views as of PG 9.4. For this you'd have to have the web server tell the db server the name of the current user.

You probably want to add an owner_id column to your "child" tables. Use an on update cascade foreign key to the parent table.


Using the password, among other values, as key data in two-factor authentication

The important part of this seems to be the next line in the RFC:

  In this scenario, the composite shared secret K is constructed during
  the provisioning process from a random seed value combined with one
  or more additional authentication factors.

The key data should never be just the data known at that point, but should be derived from it using a strong process, which should ensure that the individual components of a composite key are sufficiently mixed to make reconstruction impossible.

This doesn't necessarily contradict the DeFigueiredo statement - if you used a PIN of 1234, and your tokens were 1234-token1 and 1234-token2, clearly the tokens leak the PIN. If they were MTIzNC10b2tlbjE= and MTIzNC10b2tlbjI=, they still leak it, just slightly less obviously - these are just the base-64 representations of the above tokens. If they were 32e38e71a26e560092e395a02fb85132 and bd7c0c61696eb5716fc866c21246e846, it takes a lot more effort to work out what is going on - in this case, hex representation of the MD2 hash of the above strings. That's not a strong generation process, but it shows the basic principle.

Therefore, if you have a strong generation process, you can put almost anything you want into it, and not leak what went in.


OAuth 2.0: what's stopping a client from lying to the Resource owner about scopes

TL;DR: You rely on Authorization Service for issuing a token with correct scope(s). In "paranoid mode", the Resource Owner can introspect the token for granted scopes and allow or deny access on that basis.
There are two entities involved in this process: Authorization Service (AS) and Resource Owner (RO). AS issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization.  RO grants access to a protected resource based on the access token presented by the client. Even if the AS and RO might be physically under "one roof" (same server, same app, same process, ...), they have different responsibilities.
Management of scopes and making sure the client doesn't get a token with a "wider" scope than allowed is the responsibility of AS. Resource Owner should not be involved in validating the scope granted by AS. From oAuth spec:

The authorization and token endpoints allow the client to specify the
scope of the access request using the "scope" request parameter.  In
turn, the authorization server uses the "scope" response parameter to
inform the client of the scope of the access token issued.
The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions.  If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.

On paper, this is the answer to your question. You rely on AS to do its job.
In a less than perfect world with bad actors, Things Happentm
If the client asks for access with a wide scope and the AS policy allows granting that scope, the client has to be authorized for this grant to succeed. The step of doing so involves authentication of said client. How this happens depends on the chosen oAuth flow (grant type) and the implementation specifics of AS, RO and the client.
The various grant types and associated implementation nuances of oAuth 2.0 resulted in a wide attack surface. A number of Best Current Practices (BCPs) have been issued over the years to highlight some of these issues. oAuth 2.1 (currently in draft) is attempting to rectify this by removing all grant types other than authorization and removing a number of other loopholes.
If the AS sticks with authorization grant type as the only allowed grant and the AS is properly implemented, a user will have to explicitly provide their consent to granting access with requested scopes. Still, it is certainly possible for a client to misrepresent this in UX terms, especially in situations where AS doesn't strongly enforce the presentation of consent and AS/client boundary. Moreover, an attacker could redirect the client to their own AS and play from there. Finally if the access token gets issued with a wide scope despite AS policy prohibiting this, what can the Resource Owner do?
The RO has limited recourse. It can introspect the access token and find out the scope(s) associated with the token. This step requires AS to support the introspection service and the caller (RO in this case) must be authorized. This is in addition to the access token being introspected:

the endpoint MUST also require some form of authorization to access
this endpoint, such as client authentication as described in OAuth 2.0
[RFC6749] or a separate OAuth 2.0 access token such as the bearer
token described in OAuth 2.0 Bearer Token Usage [RFC6750].  The
methods of managing and validating these authentication credentials
are out of scope of this specification.

If you can jump through all of these hoops, then you're almost there. All you have left to do is create a policy-like construct in your RO that will somehow know when a particular client wielding an access token is exceeding their "ask" (requested scopes) based on the introspected (actual) token scopes. Note: you can't know the requested scopes so it'll have to be a blind-ish "deny if scopes = ... when client is blah" type of policy.


one of my colleagues told me that it's a security risk because password will show as plain text

Show where? If you connect to your proxy using HTTP, then the password will either be sent as base64 encoded (negligible improvement over plain text) or as an NTLM hash (small improvement). If this is what your proxy requires, then you have not created the problem - all the proxy users will be affected by this. If your proxy uses HTTPS, then the password is not visible on the network.

It will still be visible in the VM image if you didn't configure the instance to use encrypted storage.

Is it a problem if the account details don't stay secret inside your organization?

In a lot of environments, the web proxy is simply a way to multiplex many clients access to the internet. Sometimes there may be some filtering on the proxy. Rarely is there any per-user policy constraints - and if there are any being applied here, then the account you are using should only have access to the Redhat / Fedora / Centos repositories.

On the other hand if you are not using a dedicated account, then you could be publishing a password which might give access to all sorts of other things.


What harm could malicious PHP code cause?

It all comes down to the credentials that that PHP code is running with on the server.

If the apache2 process running that PHP code is running as www-root, the damage that this script can do goes to the extent of what www-root can access, which would typically mean all of the /var/www/ folder.

To fully understand this question, one needs to understand how linux works, if the web server is running under linux, to fully understand the extent of the possible damage.

If it's running under Windows, it would be the same thing, only the damage would be to the extent of what the owner of the process is able to use the machine's resources for.

Things that typically PHP viruses do are:

Use your server to send spam
Use your server to brute force other servers
Use your server's resources to join their own rig and mine crypto-currencies

Those are just a few. They can pretty much use your server to run any software.


There are not many security certifications for developers. The simple reason is that there would have to be certs for every language and trend. And considering that trends swing wildly from year to year, there is not enough time to develop a robust security certification that will not be laughed at while the trend is still relevant.

Dev communities opt for calling secure libraries, on-the-job training around secure coding, and testing.

There are general secure coding certs, but they are so general that few people take them seriously.

This is a situation that is not going to change while the innovation cycle in software development is so tight.

IT/Networking pros have a much more stable environment to work in, so the certifications have a chance to grow and mature. Firewalls are firewalls, the only change from situation to situation is the syntax. Phishing is phishing and the hallmarks, how to identify, how to block, and how to educate users has not changed in years.

Could the IT end of things have a much tighter innovation cycle? Yes. But we have been working for so many years to get the basics right, that there is little need for attackers or defenders to innovate. So, the common body of knowledge remains stable, making it possible to certify against that common body of knowledge.


I would avoid using the Windows VM until you've investigated further - a fresh install of Windows may be warranted. As for macOS receiving a Windows Virus it's unlikely unless you use a tool like Wine. I would run an anti-virus scan on both your macOS install as well as the Windows VM. It's important that you communicate with the IT Staff and get the issue resolved they are hired there to help you - work with them to resolve the issue and networking can be restored.


How can mini-computers (like Raspberry Pi) be applied to IT security?

There was a presentation at BlackHat yesterday where they used a Arduino to open hotel rooms that are using a certain kind of lock: http://www.h-online.com/security/news/item/Arduino-used-as-master-key-for-hotel-rooms-1652281.html

As devices get smaller and more powerful, that are getting better suited to be used as pentesting drop boxes. Examples are:
MiniPwner, http://www.minipwner.com/index.php/what-is-the-minipwner or
PwnPlug, http://pwnieexpress.com/products/elite-plug
PwnPi, A pen test drop box distro for the raspberry pi, http://sourceforge.net/projects/pwnpi/