TLS downgrade attacks I'm currently looking at e-mail security and wondered whether server to server e-mail communication that enforces TLS, will prevent the risk of TLS downgrade attacks?

TLS Downgrade attacks consist of a MITM threat actor forcing the weaker TLS/SSL protocols because the server permits the weaker protocols. Server-to-Server is still possible but client-to-server is the most likely.

A good candidate for an attackers success:

In this scenario, the attacker in the simplest form, drops the packets of the victim requesting the higher protocols, thus the downgrade attack, then the client retries lower protocols. This downgrade gives the attacker a high probability of being able to acquire session cookies, modify traffic, steal credentials, intercept emails, etc.

Victim   - Supports SSL 2.0, 3.0: TLS v1.0, v1.1, v1.2, v1.3
         - Supports High, Medium, Weak, CBC, and Null Ciphers
Attacker - Has Successful MITM
Server   - Supports SSL 2.0, 3.0: TLS v1.0, v1.1, v1.2, v1.3
         - Supports High, Medium, Null Ciphers

A good candidate for an admin's success:

In this scenario, the attacker can attempt to try and modify the negotiations but the server is hard set, use high protocols and ciphers, or nothing. The attacker really has no chance to decrypt the communications. Or at least not yet... Computers in 5-10 years will be different and these protocols will become outdated. IETF already has a draft for decommission of TLS v1.1.

Victim   - Supports SSL 2.0, 3.0: TLS v1.0, v1.1, v1.2, v1.3
         - Supports High, Medium, Weak, CBC, and Null Ciphers
Attacker - Has Successful MITM
Server   - Supports TLS v1.1, v1.2, v1.3 or just TLS v1.2 & v1.3
         - Supports High Ciphers only


My computer was being remotely controlled by someone. Can find no viruses Walking back to my computer (Windows 10), I noticed that my browser's history tab had just opened without me touching it and I thought I saw my cursor moving around. I had no control over my mouse until I ctrl-alt-deleted.

When I came back I had multiple new tabs open to things like ps4 digital game cards bought under my account and confirmation emails saying I just had bought a few hundred dollars worth of them. I also had a confirmation email about an account created with my email on "gameflip.com". I've never even heard of this website but it looks like its a place where you can sell stuff. My credit card company sent me an email detecting fraudulent charges and I dealt with that so I think I'm good on that end. Also, changed my passwords and all that jazz.

The problem is that I can't figure out how they did this. I've scanned my computer with Windows Defender, Malwarebytes, and Malwarebytes Anti-Rootkit. I also ran Malwarebytes in safe mode as well but they all found absolutely nothing.

Someone suggested I go to grc.com and run a scan to see if I had any open ports, but they were all in stealth mode except 21 which was in closed status. I'm not super tech savvy so I'm not sure if that means anything but as far as I can tell, "closed" shouldn't really be bad right?

If someone had just figured out my credit card number and passwords then whatever, that's easily solved, but how do I stop them from just taking control of my computer again?

There are a large number of remote control utilities.

VNC is just one of them.

Virtual Network Computing is open source so anyone can copy the source and include it as the payload of a trojan that they arrange to have installed on your computer.

Anti Virus software is not necessarily going to see everything. Something that is new or something that is a one off that is created for one job will not have made into yiour anti-virus signature files as yet.

Also, anti-virus software is not going to see the VNC part of the software as a problem.

If someone tricks you into installing some software that included this then they would be able to access your computer at any time.

Closing unused ports is always a good idea, but a trojan will probably be using a commonly used port like port 80 which is used for web browsers and web servers or will search for a unused port that is open. A Trojan that is well written could also only respond on a particular port under certain set conditions to prevent their being found.

If an attacker has had enough time to take over your PC and has made a variety of purchases through your web browser using your credit card details and processed confirmation emails, then they have had enough access and timew to totally compromise your computer.

I would think that there is no effective method of cleaning this up short of Copying all data to a secure external drive, wiping the hard drive and any connected data storage, including cloud storage that may contain re infection software, and reinstalling everything from scratch.

Make sure that any access to the backup drive containing all of you data is done in such a manner that you do not risk re infection.

You will also need to update passwords on any accounts the attacker had access to and replace all of your credit cards.


What could be the reasons for two different OTP messages for the same merchant when we do online transactions through debit card? While I was doing a transaction (say adding money to one of the mobile wallets) through a SBI debit card, I could see two different OTP messages for different transactions. (Please refer to the image)

Say one time I am adding X amount, So I was getting OTP message from SBI but in the next transaction when I was adding Y amount, I was getting OTP message from BHIM SBI Pay.

What could be the reasons behind it?
Is it becuase of the payment gateway (Like PayU,CC Avenue) or somethineg else?
Has anyone else observed the OTP message coming in the name of BHIM SBI Pay / SBIPAY?

It's typical that a single server can't handle the workload of a big service, but there must be a cluster of servers. As Bharat Interface for Money BHIM is a service by the National Payments Corporation of India (NPCI) and the population of India is ~18% of the total world population, that's likely the case. What you witness here is just two SMS gateways with a slightly different configuration.

Although confusing, this isn't really a security problem, as the payment system is feeding you with the OTP information instead of asking anything from you. Spoofing SMS messages with fake Sender IDs is possible i.e. either of the names you see here can't ultimately be trusted. However, receiving incorrect OTP codes wouldn't be a security risk, as it wouldn't give anyone else access to your account.


How can you transmit data without revealing your location? Anyone can pick up wireless transmissions without revealing their location, but transmitting is much harder.

What types of wireless communication systems are there that a device can use to transmit information without revealing its location to other parties (e.g. the network operator) assuming that the other parties are using only standard equipment (not specialized equipment specifically designed to track users)?

Systems that routinely employ receivers capable of measuring arrival time (i.e. precisely enough for time of flight), or directionality,  such as beamforming WiFi, could allow a network operator or someone with several receivers to deduce the user's location, and so would not qualify.

Systems in which the device reports its location itself (e.g. to help select the best reciever) such that a device could spoof it or fail to report it (and still be able to use the network) would still qualify.

There is no way to transmit data wirelessly without being susceptible to trilateration (using the standard definition of "radio wireless").

That's why attempts to "transmit data without revealing your location" usually end up shifting to things like laser, infrared, or other visible light methods.  These things tend to work well in directional applications, which is why they're either static (like MAN) or military (for whom the benefits of secrecy justify the trouble of maintaining directional links with mobile and semi-mobile equipment).

(Which is, incidentally, the point I was going for with the motorcycles.  If you want non-detectable wireless transmissions, you have to use something other than a radio, and that was a spectacular example).

There's really only two ways to mitigate the the ability to ELINT radio transmissions:

Make them directional.  Requires special hardware, works better for some types of radio than others, not really worth it (if you're going there, use a laser).
Lower the power so that the opponent has to be physically closer to triangulate.  Of course, in turn, whoever you're transmitting to has to be closer than that.  And you don't seem to trust the network operator, so that won't work.

Now, you stipulate that

  parties are using only standard equipment (not specialized equipment
  specifically designed to track users)

That's kind of a difficult stipulation.  You can walk your wifi laptop into most businesses secure in the knowledge that their system isn't set up to locate you.  But getting a system to do it isn't difficult.  And heck, just like Pringles cans weaponized armies of hackers, you can put together your own FindMe pretty easily.  I think it's fair to say that anything you can transmit with "standard equipment" can be located by an opponent using off-the-shelf or homebrew devices.


John the Ripper - Can't get cracked MD5 hash to show I'm trying to crack some MD5 hashes given in OWASP's BWA on their DVWA site. I was able to use John the Ripper and the very first time it worked fine and it showed the reversed hashes using the code:

john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

However, whenever I try to do it again for the exact same file, it gives back the following:

Using default input encoding: UTF-8
Loaded 6 password hashes with no different salts (Raw-MD5 [MD5 128/128 XOP 4x2])
Remaining 1 password hash
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:01 DONE (2017-02-22 17:31) 0g/s 8746Kp/s 8746Kc/s 8746KC/s                   ..*7¡Vamos!
Session completed

As you can see in the docs http://www.openwall.com/john/doc/, John (and almost any good hash cracker) will store the cracked hashes in some sort of file/db.

This is for performance, this programs will check for already cracked hashes preventing them to spend cpu/gpu time.

In the case of John, is located at: $JOHN/john.pot ($JOHN path depends on the install)

You can view the previously cracked hashes in the terminal with the command: john --show passwd

This behavior is almost standard.


Which is better: MCTIP vs. CCNA These past months I have attained a bunch of security related certs:

-CISSP
-GCIH
-CPT
-CEH

When applying for IA/Security positions, will employers prefer to see these certs paired with MCTIP (knowing the system) or CCNA/CCNP (knowing the network)?

General mutterings in the chat room seem to indicate that certs are primarily for entry level positions. My personal opinion is that certs are for HR. HR will either require, give some preference, or completely ignore certs. The cert will only appear on the resume and maybe a good line or two on a cover letter. If a cert is required for a position you will either have it or not. Given the number of certs you currently have, unless you know you will need either MCTIP or CCNA for a position, focus on other accomplishments you can discuss in an interview.


Can a load balancer "BE" the computer in the DMZ? I'm wondering if a web load balancer can take over the duties of what would normally be considered the front end server in a DMZ?

In our current environment, we have the classic DMZ setup as illustrated below.

Internet --> Firewall --> DMZ front end server --> Firewall --> Lan Server data

We have a new application coming online that does not have a purpose built front end server from the vendor.  Although no data will live on this server, it will be located on the lan.  When asked about how to make the application secure, their response was to use a reverse proxy as the front end.

So my question is this- can I simply use our web load balancer to be the "server" in the dmz?  Does this pass the sniff test?  Does this work in an audit?

Here is an illustration.

Internet --> Firewall --> Load Balancer --> Lan Server

The load balancer by its nature operates as a firewall as port numbers need to be specified.  However, the inside interface of the firewall as well as all interfaces of the load balancer (single arm) and the interface of the lan server are all on the same lan network.  However, the load balancer does end and create new sessions.

Or do I need to employ a reverse proxy and a load balancer as illustrated below?

Internet --> Firewall --> Load Balancer --> NGINX rev proxy --> Lan Server

The NGINX reverse proxy would do nothing essentially except exist and forward packets.

What really makes a DMZ?  Is it two different subnets with firewalling that is most important or is it the termination and recreation of the session prior to reaching the lan?  Or is it something else?

Another project I've been needing to button up is an open SSH to a server in the lan.  It has no front end server, but we could potentially use the load balancer to serve this purpose, but only if it can legitimately pass an SOC audit.

Thanks for any meaningful discussion!

A DMZ is both of those things. It is the point where non-trustworthy known non-acceptable inbound requests are blocked (by an outer firewall), and non-trustworthy but potentially acceptable inbound requests are terminated and evaluated for potential re-initiation to the sensitive interior.

This evaluation process may lead to a compromise, so the subnet in which the application terminating the inbound request lives should itself be separate from the interior networks, potentially using another firewall for segregation. This request-terminating-application is also known as a reverse proxy.

So:

internet -> firewall -> reverse proxy -> firewall -> lan

For HTTP, the reverse proxy can be considered a layer 7 or application firewall. It should do protocol compliance and request sanitization and should support some defensive functions like blacklisting and malicious request signature functions.

For HTTPS, the reverse proxy terminates HTTPS, though traffic from the reverse proxy into the LAN may be re-encrypted.

The load balancing role can be placed in a DMZ, but the need should be evaluated. Load balancing is usually an application function that requires orchestration and coordination with application deployments, and is also logically downstream of the kinds of sanitization and safety-oriented functions that should occur in a DMZ.

So:

internet -> firewall -> reverse proxy -> firewall -> load balancer

In terms of trust boundaries, the internet is untrusted, the DMZ (where the reverse proxy runs, in between the two firewalls) is semi-trusted, and the lan, where the load balancer runs, is trusted.

Finally, nginx is versatile software that can support both reverse proxy/web application firewall and load balancing functions, and so often it will be the same nginx instance playing both roles- meaning load balancing is in the DMZ, though there also can still be a firewall between nginx and the application hosts.

So:

internet -> firewall -> nginx (waf and lb) -> firewall -> applications

That may or may not be fine, depending on the audit conditions.


Is it a security risk to be using Doctrine1 today, as the PHP Library has not been updated in 8 years? We have an application that is running Doctrine1 and it would be a VERY large undertaking to upgrade from Doctrine1 to the current Doctrine3 (essentially a complete rewrite).

From a security standpoint, what is the risk with using this library?

Any time you are using a library that has not and cannot be updated, you are increasing your exposure to risks of vulnerabilities in that library (and in other libraries embedded into that library). This talk by Kymberlee Price does a nice job of talking through some of the impact a third-party library or integration of any kind can have on your codebase's attack surface and risk profile.


How do you put your own CA into the trusted root CA store of users who are not members of your domain? Suppose I want to use EAP-TLS or EAP-MSCHAPv2 for 802.1x authentication for my wireless network users who are not part of my domain. Is there any way to make your CA trusted by the users other than to manually put it in the trusted store of every single device?

I would highly recommend against this. Adding your certificate to personal devices root stores is a bad security practice. It's a matter of trust. Should your corporate devices trust your authority? Yes. Should random peoples devices trust your authority? Not really. The worst that I've seen happen when I've connected to an 802.1x wifi network is it ask me if I want to continue with an unverifiable certificate.

In regards to your question though, you need to have a way of distributing the CA certificate before a user connects. For iOS you can create a provisioning profile that contains your CA cert. All you would need to do is have users go to the profile URL in safari and install it.

Android as far as I know is more complicated. Users would need to first download the CA cert, then go into their setting and manually add it.

Automatically allowing CA certificates to be installed is impossible. If it were allowed, attackers could force you to install their own CA certificate and hijack sites like Google or your bank.

Photo source: http://www.bu.edu/tech/services/infrastructure/networks/wireless/8021x/iphone/


SSL negotiating too low a protocol? I'm trying to diagnose a potential SSL/TLS problem between a Mac client and a Windows server.  I have generated my own root cert and signed a cert for the server, and installed the root cert on the Mac client.   When I try to connect to the server from the mac like this

echo quit | openssl s_client -connect newmail.example.com:443 -CAfile ~/Downloads/myroot.cer

I see these results

---
SSL handshake has read 1365 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: DE2800000D2050CAB6CEE9136CD377998559C46C7AD57A1062907EE417457DE0
    Session-ID-ctx:
    Master-Key: 24E2BE661880D703B7033E0F723323296C26ECEDA0BA79493AE134C7F03EEBD765692C9DF10933BE213FF4E0F89771AC
    Key-Arg   : None
    Start Time: 1458249776
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

Do these results mean that the HIGHEST level of protocol negotiated is TLSv1 ?  (Which I suspect is causing my app problem)?  Shouldn't this be TLS 1.2 ?

Protocol version is the result of a negotiation between client and server. Client sends, in the ClientHello, the maximum version that it supports; then the server responds with the version that will be used. Normally, the server will select the highest protocol version that it supports and is not higher than the client's advertised max version.

Here, with the openssl command-line tool as client, you got TLS 1.0. So either the client (here, OpenSSL) or the server knows only TLS 1.0 and not 1.2.

The /usr/bin/openssl tool shipped with OS X is pretty old; on an up-to-date OS X installation (El Capitan), it is OpenSSL-0.9.8zg -- this is an ancient OpenSSL with bug fixes, but no support for features added in the OpenSSL-1.* versions. In particular, no TLS 1.1 or 1.2. Which explains that, with OpenSSL, you only get 1.0.

(OS X does not upgrade OpenSSL to the newer versions because the OpenSSL developers broke backward compatibility in the API, so changing the library version may break third-party existing applications that use it.)

To further investigate your issue, I suggest the following:

Try a newer openssl client. You could use MacPorts (for instance) to reasonably easily install such opensource software.
You may want to test your server with one of the tools that are dedicated to such a purpose. If your server is reachable from the Internet, Qualys SSL Labs is the usual method. For servers on private networks, there are also command-line tools such as testssl.sh or TestSSLServer that can give you some information.
You should observe a SSL handshake attempt with a network monitoring application (e.g. Network Monitor on the Windows server, or Wireshark). This will reveal whether the client tries to initiate a handshake at all, what versions / cipher suites it sends, and what the server responds.

Such a trace may also reveal other things, such as failed attempts to download CRL as part as certificate validation on the client side.


How to disable Firewire in OpenBSD/Linux to prevent attacks through Firewire? Since Firewire lacks security, allowing a plugged-in device to access host memory, it's a good thing to fully disable it. If we're not using the BIOS to disable the Firewire port then how could we do it using "software methods"? The OS running on the PC is OpenBSD or Fedora or Ubuntu.

Edit: Is it sufficient to disable Firewire support in the operating system to prevent a Firewire attack device from accessing the memory? Which steps are required to prevent this kind of threat?

Software method:

Disable the Firewire driver / recompile kernel

Disabling the firewire driver prevents the use of any firewire device, as it disables the firewire hardware controller. In order for the attacks to work several requirements exist: The driver must be loaded so that the controller is initialised (bus-mastering etc), it must be configured to 'open-access' and not per-device, and dma must be enabled (ohci1394 had a disable dma option).

In Ubuntu firewire drivers are kernel modules. There is an easy way to blacklist them: Open /etc/modprobe.d/blacklist-firewire.conf, there you will find there a list of modules to be blacklisted.

blacklist ohci1394
blacklist sbp2
blacklist dv1394
blacklist raw1394
blacklist video1394
#blacklist firewire-ohci
#blacklist firewire-sbp2

Just remove the # in front of everything and save it. Then run sudo update-initramfs -k all -u

Other methods:

Disable the Firewire ports in BIOS
Seal the actual ports, as often done for USB ports in some environments.


Is sharing a Speccy report with others safe? I shared a Speccy report link (publish option) on Reddit Security's chatroom after I was asked to by an expert while he was trying to solve an issue for me. please let me know. thanks

In your scenario, there are (at least) 3 things to be mindful of or possibly concerned with:

Are you sharing any PII or other personally sensitive information? This could include unique technical identifiers such as MAC addresses and public IP addresses, or more personal information. Just glancing at the report, I'd say probably not, but that may differ by individual opinion. One thing to note is that the report contains a list of IP addresses you were connected to; this could reveal what sites and services you were using at the time.
Are you sharing any sensitive technical information? The data contains what applications are running, what patches you have, and what network services are listening. If you were running anything vulnerable or unpatched, this could be an issue.
Is the person friend or foe? Obtaining basic system information could be a legitimate request, but it could also be used maliciously by a social engineer to demonstrate their credibility and/or learn more about your machine. It gives them the ability to say, "oh no, your report says you have explorer.exe running; that's a virus! I better remote in right away to fix it!" or "looks like you have Microsoft Word installed; lucky you, just download this document and it has all the steps to fix your computer! Just make sure you enable macros first."

I don't think you need to worry too much about the information you already shared, but proceed with caution and don't let them connect in or run any software that you don't understand.


Is it a bad practice to send sensitive information(like a session id) in the aspx response? Lets say I have an aspx login page which validates user credentials, obtains a session id and then redirects to the home page in the following way.

login.aspx:

var sessionId = ValidateCredentials();

// below embeds specified javascript into response. the javascript sets the browser's sessionStorage.SESSION_ID and performs a redirect to home page
Page.ClientScript.RegisterStartupScript(
         this.GetType(),
         "key",
         “sessionStorage.SESSION_ID=@sessionId@;window.location='home.aspx'",
         true);

  My concern - this means we are temporarily placing the session id in
  the login.aspx html response, does this pose any security risks at
  browser side?

I think it shouldn't as it is no different than sending sensitive information in an xml/json response (which I believe is a norm in most of SPA web apps).

The reason this got me concerned is because the html responses are treated as sources by the browser and I don't know if it is possible for an attacker to get the source file contents or if there are some other reasons which makes this a bad practice.

Note: There are other ways user authentication can be managed (httponly cookies, asp.net session etc etc..), but for argument sake, lets say we have to store the sessionid in browser's sessionStorage and I can only come up with above to achieve this.

Thank you.

Is it a bad practice to send sensitive information(like a session id)
  in the aspx response?

No.From a security perspective sending sessions id in a response doesn't make it insecure.Also use POST method if you intend to send that session back in a request.

But

From a development point of view its better to send session as cookies rather.Most Languages have SESSION management inbuilt.Why not use that?

  browser and I don't know if it is possible for an attacker to get the
  source file contents

That's possible only if there is an XSS flaw.Session identifiers in a cookie might be immune to that if you use httponly. Another reason to use cookies.


What is the difference between Vulnerability Assessment and Ethical Hacking? What is the difference between Vulnerability Assessment and Ethical Hacking?

A vulnerability assessment is a passive analysis of the current security measures in place. This would involve simply looking at systems and seeing if they meet certain criteria.

Ethical Hacking is a form of offensive and active security where deliberate attempts are being made to exploit vulnerabilities in systems to highlight security issues.

Long story short, one is passive, one is active.


Is ransomware that threatens with publication and verifiably deletes upon payment possible? Inspired by the article The future of Ransomware and its description of possible ransomware with verifiable key delivery, I wonder if the idea can be taken further into ransomware that credibly threatens publication unless a payment is made, yet verifiably destroys the data if it receives payment.

Let us first make some (probably not entirely reasonable) assumptions:

The attacker can maintain control, despite attempts of the security community, of sufficient network resources to exfiltrate data from infected computers with internet connection at a rate of, say, 10 Gbit/s globally (i.e. the bandwidth from all victims combined), and resources to store all data downloaded over that connection.
The attacker possesses a decent heuristic for detecting blackmail-worthy files. The idea is just to avoid almost all of the downloaded data being worthless junk like Windows swap files. (Though it would probably be impossible to avoid the security community deliberately feeding junk designed to trigger the heuristic.)

Would it be possible for a sufficiently motivated attacker to develop ransomware using modern CPU "secure enclave" technologies and e.g. Ethereum that encrypts files and transmits them to the attacker, but in such a way that the attacker can only choose to either decrypt the files or to receive payment, but not both?

For example, is it possible for the attacker to verifiably create an enclave that he runs on his backend computers that either allows releasing funds transferred to an account securely created inside it or to decrypt the files, have that enclave attest itself to the ransomware, and to publish the code running in that enclave so that others can verify that functionality?

I don't think it's possible to prove that you DON'T know a piece of information.

This is relevant to your question because in order to guarantee that he won't publish your files after payment is received, the attacker would have to prove that he no longer has the decryption key for your data.

Since there was a moment in time where the attacker did have access to that key (when he encrypted the data on your hard drive), he'd have to credibly prove that he couldn't have made a copy of the key.

There's several moments where he could have done that: First, while exfiltrating your data to his backend, he could have used a covert channel to send a copy of the encryption key from your machine to somewhere else.

Second, he could embed a bit of code into the decryption routine that runs after you pay which would send the decryption key out to him either right then, or at some later time.

Third, he could install a man in the middle between you and his secure enclave, and intercept the traffic between your machine and his enclave. Since his "man in the middle" was actually friendly (to him), he could provide it with the encryption key used to encrypt the traffic between you and his endpoint, and you'd never know, because it wouldn't be part of the code you could audit.

Fourth, even if he gave you proof that the code running in his security enclave was the one he gave you to audit, you'd a) actually have to audit the code, to make sure it didn't somehow leak the key or your data, and b) as long as he sat at the other end of a network connection, how could you ever be sure that what he had on his side actually was a secure enclave with the security guarantees you needed, and not just something masquerading as one? You're probably thinking digital signatures, and I'm thinking "complex system, probably faulty".


PHP 5.3.9 Vulnerability Help This is one of the first vulnerabilities I've tried to exploit on my own to expand my knowledge of exploits.

This is a good summary of the vulnerability. I have been able to control EIP but I'm not sure how to execute code.

My test machine is Ubuntu 11.10 and has ASLR enabled along with NX for the stack, heap, and libraries. The string I control (as described in the article) is stored on the heap so I cannot place any code in there since its not executable. Other than EIP I also control the EDI register but that's all. This is a 32 bit system so brute force is sufficient to defeat ASLR (plus I don't have any other security mechanisms in place; not very realistic, but a good start).

EDIT:

Just found this PoC. Basically the author gets to the same place where I am and then relies on code on the PHP server to take it a step furthur to be able to read the Apache process memory. He states that code execution is "highly possible" but doesn't go into much detail beyond that.

This is a nasty vulnerability that is very similar to a Dangling Pointer. In short, it allows a remote attacker to read and/or write to an arbitrary memory address.   This is a lot more valuable than just a simple stack based buffer-overflow, especially in exploiting modern systems.  A solid remote code execution exploit for this vulnerability has not surfaced to the public.  However Vupen, a well known exploit dealer,  may have developed such an exploit.

Because this is also a memory disclosure vulnerability you don't have to use brute force to bypass ASLR.  An exploit has been written to read the ASLR'ed memory address of where your payload is in memory.

There is still the problem of controlling the EIP. I haven't seen an exploit that does this, but it looks like it maybe possible,  perhaps with a GOT overwrite or corrupting the stack frame.

After you the EIP/RIP you have a few options.  One option is to use Return Oriented Programming (ROP Chain) to execute arbitrary code.  ROP Chains consist of useful "gadgets",  or segments of assembler within the application that perform a useful task and these tasks are chained together.   A common ROP gadget is controlling the EIP/RIP with a jmp edx. Another useful ROP gadget would be a call to system(), keep in mind that because of ASLR a ret2libc call to system() will fail because you don't know this function's address, hence the need for ROP gadget(s).  These are some simple examples,  however ROP chains can also be very complex.  ROP Chains are useful because they consist of code that must be executable and isn't randomized.  There are tools to help you find ROP gadgets within a target application.  In an application like Apache,  there are bound to be many useful ROP gadgets.

Or another option is to leak memory to find a memory address that you can place a payload.  Then defeat the NX bit (which might need a ROP chain) to make your payload executable and point the EIP/RIP to your payload.

Boom.


Android phone's lockscreen PIN disappeared? I own a ZTE Axon 7 (model 2017G) that I purchased secondhand from a reputable vendor in Germany ca. 3 years ago. The phone has been working well, and I updated the OS to Android 8.0. manually earlier this year using an official image from ZTE.
A severe case of butterfingers affected me yesterday (and I guess today), and I dropped the phone a couple of times (the phone has never been in use with out this very good TPU case from this company called Spigen). The last of these drops (today) broke the display. No physical damage, but half the screen is "gone"--it looks like the display pictured here in this iFixit thread but with multicolored dots instead of lines.
I wasn't too worried about this (hopefully it's just a loose cable), but then I noticed I was only swiping up to get past the lockscreen. Now here's the thing: I've always used this phone with a 4-digit lockscreen PIN. I can confirm--that as recently as yesterday--my partner and I mentioned the PIN because my phone had died (battery ran too low), and they had to enter the PIN after restarting it; so this isn't my imagination going wild.
As far as I can tell, nothing else has been affected. All the data still seems to be there, and nothing seems to have been "hacked" (I even briefly texted my partner with the broken screen to let them know that the screen is broken).
I went and checked in the settings, and the lockscreen PIN isn't active there either as far as I can tell (so it doesn't seem to be some kind of a glitch). I restarted the phone, and it asked for the PIN as it does normally to authorize the SIM. So it appears the lockscreen PIN has been disabled entirely, but it wasn't me who disabled it.
How is this even possible? Can the phone being dropped at a weird angle disable the lockscreen PIN? (It sounds ridiculous just even typing that.) How can I check for signs of intrusion on the device (with the broken screen)?
Some "events"/facts that may be of relevance(?):

The one other question I have on this SE is about legitimate Google 2FA codes arriving from random numbers. This hadn't happened in a while, but it happened again on 29.06.2020 (this Monday).
I always put my phone next to the bed during the night, and I did so last night. The phone was in another room this morning, however. Neither my partner nor I remember moving it. It is plausible that I moved the phone (I have a mild tendency to sleep walk), but I doubt I would have been able to disable the PIN in my sleep.
The phone's storage is not encrypted.

Sorry to sound cynical, but if your phone moved in the night and you didn't have signs of a break in, and only you and your partner are in the building and know your pin.. if your lockscreen pin mysteriously got disabled, and you are getting unsolicited 2FA calls..
MOST PARANOID SCENARIO your partner probably moved the phone in the night, disabled the lockscreen pin, probably has location tracking and keylogging software installed to the phone. If this is the case, can you think of any reason why your partner might want to snoop on whatever you have on the phone? Have you been particularly aloof, or behaving in a way might make your partner think you were acting suspiciously?
ALTERNATIVE PARANOID SCENARIO your phone has been hacked by script kiddies who are managing to trigger 2FA calls and do sloppy stuff like removing your lockscreen pin. Or perhaps someone has managed to get the login details for your gmail account associated with the phone. You might be able to see a history of where you have been logged in from, when, and on what devices. You can change your password and logout of any unrecognised devices.
NON PARANOID SCENARIO The knock by complete chance somehow changed your lockscreen setting, you moved the phone yourself and forgot, nobody has hacked your phone, and your partner is innocent!


Password protected wall I'm currently building a website where you have an account and can do "dangerous" things with it. I want to password-protect these things, so the user has to type their password, if they want to continue.
I couldn't find any ressources on this, so I came up with this idea.
My method works this way:

User navigates to dangerous action
The server redirects the user to the password prompt website
The user types the password
The server checks if the typed in password matches the currently logged in user
If check was successfull, the server redirects the user to the action with a uniquely created token associated to the user as a GET parameter
The dangerous actions checks if the token matches to the user
If match, the server will continue as normal

My question: Is this secure?
I think this is secure because I will probably make the token like 511 chars long and bruteforcing it would be very unlikely and I couldn't find any other security holes in this.

Homebrewed security is dangerous
The thing you are describing already well developed with a multitude of publicly audited libraries and tools available for almost every web platform. A great place to start would be with oauth2. Even a service like auth0 might work, which would essentially be the "password server".
The danger of doing this yourself is that the concept of token-based authentication has a lot of subtle pitfalls that have already been analyzed, but you are likely to make (at least) one of several obvious mistakes.


Master thesis topic - mod_security I've been playing with mod_security for some time and I'd like somehow to use it in my master thesis. I don't know exactly how this work could be more interesting than describing what mod_security does, what kind of web attacks can be prevented using it, what are other functions of it (like analysing if the requests are really HTTP, analysing XML). I'd rather not focus on this particular tool, but create some system that would secure for example some specific kinds of websites.
What could make it more reaserch-like? Any hints please?

Maybe look into creating or applying advanced analytics to web application activity to profile users for the purpose of identifying potential bad activity.  Build on top of what ModSecurity outputs and test algorithms/models that make it easier for a security operations team to quickly understand what activity a particular user is doing and why it may be hostile (talking beyond reporting simple atomic events).

Do an amazon search for “machine learning security” or “data mining security” and find books, for example, like Statistical Techniques for Network Security: Modern Statistically-Based Intrusion Detection and Protection http://www.amazon.com/gp/product/159904708X/ref=wms_ohs_product and research which techniques described in those books may advance web application security.  There seems to be a near infinite way to mix and match algorithms - your research could result in new ways to combine existing algorithms to produce better results.

Reading Robert Hansen’s blog entry on web log forensics may spawn additional ideas:
http://ha.ckers.org/blog/20100613/web-server-log-forensics-app-wanted/


Keeping software signing keys secure I am creating an application that will automatically sign code with secure keys (.key). The app will run on Windows environment developed in .NET environment (C#). Signing is simple: source code + keys will generate signed artifacts. This is already in place. The challenge that I am facing is how to store the keys as secure as possible.

What I am considering is to encrypt the keys with tools like VeraCrypt. Whenever the app needs to sign code, encrypt the files, sign it and decrypt again. VeraCrypt for instance offers command line options for this. This then raises another issue: How to store the passphrase in the app safely.

Since I am not a security expert, could you provide me some comments on proposed solution? What other options would be appropriate and maybe better ones?

You've stumbled into a very hard problem; when storing cryptographic keys in software you really kinda have three options:

Store the password encrypted on disk and have the user enter a password to decrypt it at runtime. You then need to worry about secure memory management also, which is a real rabbit hole.
Avoid prompting the user for a password by doing some weird obfuscation trick where you derive a decryption key from hardware serial numbers and stuff.
Use the OS' key management APIs. If possible, also use the OS APIs to do all the crypto operations for you so that your app never actually has the private key in memory. Then you can trust that the OS is handling the key securely and you don't have to think about it.

Fortunately for you, Windows and .NET has very good key management APIs called CAPI: Crypto API.

I would start by Googling "windows storing cryptographic keys .net" and doing some reading. This article in particular seems like a good starting point:

msdn.microsoft.com : Key Storage and Retrieval

If you are writing a webservice that will run in a datacentre that you control, then you could consider using a Hardware Security Module. Also, hosting providers like Amazon and Azure provide APIs for this rather than needing your own physical HSM. That said, these devices start at $5,000 USD and they are overkill for most applications.


Can a corporate proxy downgrade an SSL handshake? At work, I'm behind an NTLM Proxy. When the SSL Poodle flaw came out, I hardened the configuration of my private server, and found out that even if the client and server shared common ciphers, some configurations led to unsuccessful handshakes. I suspected the proxy to modify the list of supported ciphers and this problem came out again today when a website that I regularly visit stopped working saying that the connection was downgraded to a version of TLS lower than the minimum required by the server, an operation that my web browser wouldn't do.

So I'm wondering, why would a corporate proxy behave like this if it wasn't in an attempt to weaken and spy a connection? I checked the certificates, it doesn't attempt to do MITM attack by issuing fake certificates. Then, what is the point? If I still manage to get an SSL connection, should I consider it secure?

Edit: Seeing the comments, I double checked. The certificates chain and fingerprints are the same as at home. I further checked with my own server where I know what is the real fingerprint (in the unreal case where my home is compromised too :) ) and it is also OK.

I suspected the proxy to modify the list of supported ciphers and this problem came out again today when a website that I regularly visit stopped working saying that the connection was downgraded to a version of TLS lower than the minimum required by the server, an operation that my web browser wouldn't do.

It is not possible to just modify the ciphers within the handshake and leave the rest the same. Since the handshake is protected by a cryptographic checksum this would cause a handshake error because the checksum inside the Finished message (last part of handshake) does not match any longer. For more details see https://security.stackexchange.com/a/20847/37315.

Changes in ciphers can only be done with real man-in-the-middle attack (or SSL interception, which is the same but sounds more friendly), where the man in the middle must change the servers certificate too. This is often done in companies to make scanning of SSL traffic for malware possible. Change of cipher is only a side effect of this, since you have independent SSL connections from the middlebox to the client and another to the server when doing SSL interception.

  I checked the certificates, it doesn't attempt to do MITM attack by issuing fake certificates.

The contents of the servers leaf certificate like subject, lifetime etc often gets replicated when doing SSL interception. But if you check fingerprint, certificate chain and trust anchor (root-CA) you will detect the difference.


Are algorithmically-generated personal passwords a security risk? We all know why password reuse is bad: eventually some site at which you have an account that did not properly hash+salt user passwords will get hacked, and your password will be published in a big dump. Then some hackers will take that user/pass combination and try it on every site they think that can get something useful from.
I know that password managers are the recommended solution to having a unique totally random password for every site.  But they are not completely without their own difficulties, and especially trying to persuade non-technical people to use them may be difficult.  Instead, as a minimal alternative to shared passwords, one might have a simple algorithm to generate unique passwords from a shared random component. A minimal example might be <sitename>_<good random password>. So my passwords might be
stackoverflow_rm6Z0$f237db^DGYU3r
google_rm6Z0$f237db^DGYU3r

etc, where the second part is shared.  Now, any idiot actually trying to hack me specifically could probably guess my algorithm even knowing only one password, and trivially if they got ahold of two, so if I were for some reason a high-profile target this would be a bad plan. But if anyone wanted to hack me, I'm probably in trouble no matter what I do.  Assuming I'm not a high profile target, it seems to me a simple algorithm like this would protect me from the majority of password-reuse dangers, because no human will ever see my password specifically.
So really I'm asking, is this reasoning flawed? Is this kind of algorithmically-generated password actually any safer than exact password reuse?  Or are password dumps used differently than I have in mind? The accepted answer to this question suggests that varied passwords are only useful if it is hashed, but to me it seems that a hacker having the cleartext password doesn't help them.
I agree this is fundamentally security-by-obscurity, but maybe security-by-anonymity would be a better title.  My password would be one of a million in a big dump, with essentially zero chance that any human would ever actually see mine.
the question (edited to be more explicit):
Assume that:

An average person (not a high profile target for hackers) uses an algorithm to generate unique site passwords.
The algorithm is extremely simple, so that a human could guess the algorithm given even a single password
One or more of those passwords have been obtained by hackers

Is this person any less likely to be hacked on other sites than a person who uses the same password on every site?  If not, is it because

There is a reasonable chance that a human will actually look at this password?
Attackers already look for some kinds of algorithmically-generated passwords?
Some other reason?

Note:
Many have pointed out that using a password manager is a better idea. In particular ThoriumBR and others point out that this scheme is unsustainable, because once I need to change one of the passwords, I now have to change my algorithm.
These are very good points, but not what I am hoping to learn from this question.

The main issue with a "password generation algorithm" is that the passwords are fixed. You cannot change a single leaked password without changing the algorithm, thus changing every password.
To avoid that, you had to record somewhere the sites using the first version, the ones using the second one (because the password generated by the first leaked), the sites using another one because the algorithm generated a password unacceptable by some site, and so on.
And some sites require you to change your password from time to time. So you would have to take that into account, and record more and more information just to keep in pace with the state of the passwords. And for that, you would need a secure data storage, with encryption, a backup process, something easy to use and easy to be integrated on your online routine.
Losing any of those records would lock you out, and create an Availability Compromise. Leaking it in plaintext would create a Confidentiality Compromise. Corrupting (or forgetting) any of it would create an Integrity Compromise. You need some software specially created for secure storage.
Something like... a password manager.


Build a secure channel without SSL/TLS I'm looking at possible options to build a secure channel between multiple embedded devices with limited cryptography capabilities and an HTTP server (It could be some sort of web service).
1. Context
The devices only supports HTTP, some Symmetric-Key Algorithm and some Hashes Function via a development framework on the devices. Unfortunately SSL/TLS is not supported and thus is not an option here.
At boot time the devices contact the HTTP server in order to retrieve their specific configuration. I do have complete control over the devices before they are sent in the wild.
Some of the threats identified are:

Download of a malicious configuration file.
Download of the wrong configuration file (from another device).
Multiple Download of the same configuration file.
Eavesdropping of the configuration file by an unauthorized third
party.
Fraudulent access to the HTTP server (not necessarily relevant here).

The process of retrieving the configuration file should ideally happen only one time. Once the configuration file is downloaded access to the HTTP server will be discarded for that particular device.
2. Proposal
Since I can load a temporary shared secret on the devices before dropping them in the wild, I was thinking of using keyed-HMAC (Hash Message Authentication Code) to authenticate the device without having to send the secret key on the wire. Something similar to the AWS API authentication design and use the unique serial number of the device as Key ID.
Once authenticated the device is granted access to a resource, in this case the configuration file. In order to mitigate some of the threats identified the configuration file must be encrypted and signed(?) during transfer.
For this purpose I was thinking of using an authenticated encryption mode.
I can only use AES256 in CBC mode and HMAC-SHA256. Other "proper" authenticated encryption algorithm are not available within the framework.
3. Questions
Does it make sense?
In order to avoid adding complexity on something complex enough is it an option to use the pre-loaded shared secret as a key for the HMAC function and the shared secret Hash as Encryption Key for the AES encryption?
Does it allow the mitigation of the identified threats under that particular scenario?
Can the process be simplified and keep its security properties?
3. Resources
How to choose an Authenticated Encryption mode
Authenticated Encryption and how not to get caught chasing a coyote
Authenticating Requests Using the AWS REST API
Designing a Secure REST (Web) API without OAuth
Why can't I use the same key for encryption and MAC?

Both server and client know something secret, thus they can trust that there communication isn't being altered in route.  Effectively, using a connection via the shared key between them is like using SSL without the hand shake.  Normally SSL would use asymmetric cryptography to a) validate one or more parties in the communication and b) establish a shared key for communication.

You, however, are able to establish the trust in part a prior to releasing the device since both are in your possession.  Provided the key on the device is not compromised (which is the primary weakness depending on usage) then if a device is able to communicate in a way that decrypts, correctly, the message originated from the device.  So thus you only have to worry about replay attacks, but any simple mechanism could stop that (for example a counter or timestamp to avoid reuse or use of an older message than the current one.)


OpenVPN Client Authentication and CA How does a client verify that the OpenVPN server certificate was signed by the master CA?

Based on OpenVPN setup clients are usually supplied with only their own certificate and private key and CA certificate.

Like David Houde already said, OpenVPN usually uses a single CA to sign both client and server certificates. In case you have problems understanding how signing/verificating certificates works, you should read Using digital certificates in digital signatures first.

If the client receives a server certificate, he simply checks whether this certificate was signed by the CA he was provided with. If the check succeeds, the server is accepted.

Usually the server certificate also contains a parameter for extended key usage named "TLS Web Server Authentication". This parameter may be checked for by adding the following statement to your OpenVPN config:

remote-cert-eku "TLS Web Server Authentication"

This is used to ensure the server certificate provided to the client is actually what it claims to be. Otherwise another client could possibly identify himself as a server, since the same CA does sign both types.


Does Firefox use OCSP? And if it does use Online Certificate Status Protocol, is there a way to disable it, so that it uses CRL instead?

You can disable it:

To disable OCSP in Firefox:
Go to "Tools (or Menu button) -> Options -> Advanced -> Certificates" and uncheck Query OCSP responder servers to confirm the current validity of certificates.

(source: http://kb.mozillazine.org/OCSP_error_when_accessing_secure_sites)


Internal HTTP(s) vulnerabilities We use Rapidfire + network detective where I work, for doing non-intrusive internal scans on all of our clients' networks. Every week; half of the tickets I get for this are port 80/443 vulnerabilities for the web access pages for HP and Cisco switches/routers/iLO interfaces. Some include:

1.3.6.1.4.1.25623.1.0.11715 - Header overflow against HTTP proxy
1.3.6.1.4.1.25623.1.0.17231 - CERN httpd CGI name heap overflow
1.3.6.1.4.1.25623.1.0.11127 - HTTP 1.0 header overflow

The hardware is not out of date, the SSL certs are good. I disable HTTP logins for all devices I can and make sure they are up to date with the latest firmware but these alerts keep coming in for the same devices. I can't find anyone with the same issues online. Are there steps I can take to further secure these or is it safe to just ignore them?

You should check with your vendor. Many Vulnerability scanners just detect a version and then assume the vulnerabilities based on that version of the software. This doesn't allow for back patching and can be an annoyance to Systems teams as far as false positives. Something like this could be happening.

Also, you seem to mention it, but you have disabled TLS 1.0 right? Attackers will try to downgrade connections and see if the server allows out of date ones, which they often do as a default, like AWS's load balancer for example (at last check).

I would never ignore a finding, if possible. Escalate to the vendor.


Can a custom built CPU break hard drive encryption? While a hard drive is decrypted on boot up, can the original phrase be intercepted at some comparison calculation step by a specially built CPU or is there some higher math involved?
This would be blatant, so I guess not. But would like to make sure and I'm curious how it works indeed.

There isn't any comparison operation with the passphrase, because there's nothing to compare it against. The plain-text passphrase isn't stored in the system anywhere (if it was, an attacker could steal it without guessing, brute-forcing, or needing some legit user to enter it). The exact operations done depend on the disk encryption software (Bitlocker, FileVault, VeraCrypt, LUKS, etc. all work a bit differently) and what mode it's operating in (sometimes, there's no passphrase at all; the key comes from a file on a flashdrive and/or a hardware security module called a Trusted Platform Module or TPM) but generally, the passphrase is run through some form of password hashing / key derivation algorithm, which is a non-reversible cryptographic operation that turns a passphrase into a binary string suitable for use as a cryptographic key. Even the output of that function (the digest) isn't going to be compared against anything directly either - after all, if the attacker gets that, then it's just skipping the passphrase -> hashing step, so you can't store the digest anywhere either - but you can hash it again, or use it to decrypt some secret and check the integrity of the decryption, and in either case (hashed key's digest, or authentication tag for decryption), that is data that can be safely stored on the disk because there's no way to get any actual secrets back out of it.
With that said, of course a maliciously modified CPU could steal the passphrase as it's entered. Every keystroke on the keyboard will, after various operations that might take place off-CPU (e.g. in a microcontroller inside the keyboard or on the motherboard's USB controller), end up entering the CPU (computer firmware - the BIOS or UEFI - have at least a basic keyboard driver in them, and it runs on the CPU even if the OS isn't running yet). You're not going to be capturing it during any comparisons - because none are performed on the passphrase - but it's still there for capture (briefly).
Mind you, there's lots of other places you could capture such data. A classic example is a hardware keylogger, either inside the keyboard itself or between the keyboard and the motherboard. Another option is in the USB host controller on the motherboard. Another is in the RAM, since that's where keyboard input is buffered until the CPU processes it (and also, mostly inevitable, any time the user types a string such as a passphrase it ends up, at least briefly, resident as a string in RAM). Finally, there's the keyboard driver in the firmware / pre-boot code.
CPUs are the most complex components of most computers (high-end GPUs may have more transistors, but may well still be a simpler design writ large), and only a few companies are capable of manufacturing high-end x86 CPUs, so it's a relatively unlikely place for a malicious implant. Not out of the question, but you'd need a ton of resources, and by the time it's even viable to replace somebody's CPU with a malicious one, there are easier attacks by far.

Also, this isn't really breaking hard drive encryption. This is just stealing the passphrase needed to get the decryption key. That defeats the encryption, but it doesn't break it, any more than somebody finding the "secret" key under your door mat and using it to unlock your front door is "breaking" your lock. Actually breaking the encryption - for any modern cryptographic cipher, implemented even half-decently - requires expert cryptanalysts to study the cipher for a way to even proceed (other than dumb brute-force) and even then, the best known attacks against any modern ciphers are well outside the potential of any one CPU even if you let it run for decades. Quantum computers might change this, for some ciphers, but they're still far from practical for use on real-world problems of even the size "encrypted hard disk and you don't have the key".


Why are extended validation certificates not used with email Extended validation certificates are identity certificates issued to a legal entity. This means that anything signed by that certificate is "guaranteed" to come from the entity instead of just from the domain name.

Since phishing emails are a big deal and (at least in my mind) appear to be growing in prevalence, why don't companies sign emails using these certificates (and include the signature as an attachment)?

The trust infrastructure is already (mostly) in place and the verification could be handled fairly transparently by email clients using the OS or browser certificate store.

I imagine that this could render many of the "ENTER YOU BANKING CREDENTIALS IN 24 HOURS OR ACCOUNT WILL BE DELETE" emails and other, better crafted phishing emails, largely useless to the phishers.

According to the EV (SSL) Guidelines as of 1.6.5 (July 2017) from cabforum (warning: like others they've now 'optimized' their website to display as little data as possible, so to find anything useful you have to grovel through the pulldown) in clause 1:

  This version of the
  Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet
  and for code signing. Similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in
  future versions

Although FWIW the EV guidelines do not say anything about ExtendedKeyUsage, and in the baseline requirements (incorporated by reference) 7.1.2.3f says it MUST contain clientAuth and/or serverAuth and MAY contain emailProtection. So I think a member CA could issue an EV cert includig email without violating the rules. OTOH I doubt any email software currently checks for EV even when it supports X.509 (S/MIME) since this is not expected.

Of course there's the usual chicken-egg problem; legitimate email senders won't want to use this until at least a significant fraction of recipients are using email software or systems that support it, and at least most recipients won't even look for such support as long as no one is sending it. Possibly if some big players like gmail push this it might get some traction, in much the same way some browsers have been pushing improvements in web/HTTPS cryptography.


Being anonymous with bitcoin In the recent ransomware attacks, attackers have asked the targeted organizations to pay them in bitcoins. How can they be anonymous if they deal in bitcoins? Can they convert bitcoins to any other currency?

There is lots of information about "bitcoin - anonymousity" on this site. I would recommend checking it out.
Cite from the website:

There are basically three ways to de-anonymize Bitcoin users.
First of all, even though Bitcoin transactions are randomly transmitted over the peer-to-peer network, this system is not airtight. If an attacker, for instance, has the means to connect multiple nodes to the Bitcoin network, the combined data collected from these different nodes might be enough to determine where a transaction originated.
Second, Bitcoin addresses can be linked to real identities if these real identities are used in combination with the Bitcoin addresses in some way. This includes addresses used to deposit or withdraw money to or from a (regulated) exchange or wallet service, publicly exposed donation addresses, or addresses simply used to send bitcoin to someone (including the online store) when using a real identity.
But perhaps most importantly, all transactions over the Bitcoin network are completely transparent and traceable by anyone. It's typically this complete transparency that allows multiple Bitcoin addresses to be clustered together, and be tied to the same user. Therefore, if just one of these clustered addresses is linked to a real-world identity through one or several of the other de-anonymizing methods, all clustered addresses can be.

Just as a side note:
There are registers of reported bitcoin-addresses being used in attacks. So if a company gets a DDos threat, they can check if the address have been used before. If it is, the DDos threat is most likely fake. Because there is no way for the owner of the bitcoin account to see who has paid. This is just an example in how bitcoins can be used proactive.


What are the disadvantages of Tor? I've just started using Tor recently, and I'm not sure exactly what security issues come with the benefits.

What should/shouldn't I be worried about (in both everyday normal-web browsing use, in visiting hidden services, and in running my own)?

-- A bit of background for this question; what specifically prompted it --

I'm planning on going live with a rough web site for person/professional use within the next couple weeks, and I want it to be well-protected, but at the same time able to be remotely administered.

I do plan to actually harden the webserver (and use a strong SSH password, login to an account with as little privilege as possible, etc.), but I have no idea whether exclusively doing SSH administration over Tor would be a useful level of misdirection, or would just open me up to possibly undesirable attention from people monitoring the Tor network.

edit: The guy who mentioned 'Tor is just for anonymity' is correct. I guess I should rephrase that last bit:
From what I've read, it seems like I wouldn't need to configure my router to forward all requests to the SSH port if I made SSH only available through Tor. If that's the case, it would mean fewer people would be able to access the port, because fewer would be aware of it, and it would be easier to see irregularities in the server logs. It would be more for the purpose of defense-in-depth and making maintenance easier than anything else. However, since I'm not sure what the disadvantages might be, I'm asking this question to clarify.

Performance sucks

It's better than a couple of years ago, but still not great.
Low latency anonymizers are prone to traffic analysis.

In particular if somebody can observe your traffic and your target's traffic, they can correlate that.

Anonymous remailers avoid this problem by adding longer delays, but you can't use them for interactive applications, such as browsing the web.
Exit nodes see your traffic in plain

If you don't use a secure protocol on top of Tor, the exit node can sniff your passwords etc. Using SSL or SSH you should be fine, but be sure to validate the certificate/fingerprints.

This doesn't apply to using hidden services, since there is no exit node, and MitM attacks are prevented by the fingerprint in the domain. But be careful that you're accessing the correct domain, they're pretty hard to memorize/verify.

One interesting variant is connecting to a VPN over Tor. That helps with 3), provided you trust the VPN, but you need to figure out a way to buy VPN access anonymously.


Any place where I can find some template or base documents for IT/Infosec Compliance? We're facing an audit and we are sorely lacking in documentation regarding information security policies. I've done some Googling and have been surprised by the difficulty of finding a good "template" or base document for different aspects of compliance as they would be defined by common audits such as ISO 27002 or SAS 70. Anyone who has experienced compliance document hell and come out alive... please tell me where you found some help.

You can get some good templates from SANS


Should I trust zxcvbn with my password? I want to measure current and future password entropy with the zxcvbn formula.
Is there any way to test and detect if the input on this website is truly confidential?

EDIT:
1. I found an embarrasingly easy solution over at super user. In firefox, when saving page, choose the "complete" option so that js files will be included.
2. As SOJPM suggest there is no need to test your real password. An identical patterned one should do.

As far as I know, the zxcvbn project is an entirely client-side javascript app, meaning that, in theory, no data needs to be sent back to the server.

In order to find out if it's sending data back or not, you can do several things;

Use a packet sniffer, like wireshark, to inspect any data that this web page is sending back to the server.
On the page you link to, you can View Page Source and click through to all of the zxcvbn/*.js scripts that are being run. Have a look for yourself at what they're doing!
In the case of zxcvbn specifically; this is an open source project. You can find the source at github.com/dropbox/zxcvbn. If you are planning to use zxcvbn as a plugin on your own page, then you can look at the exact source code that you're running and make sure it's not doing anything suspicious. if it is doing something that you're not comfortable with, then modify it! Or, if JavaScript isn't your thing, there are open source zxcvbn ports to just about every language imaginable on github.


What are the methods by which an attacker can distinguish between DROP on IPtables and a Nullroute or non-allocated IP? Let's say we have a server set up with set to:

  iptables -P INPUT DROP

Without any other rules on the input chain.

Ignoring accessibility issues outside of physical server access, what are the methods that an external attacker could use to distinguish between this server and a nullrouted/unused IP address?

One can play around with the TTL (or hop limit with IPv6) of packets send to the destination to figure out where the packets gets lost. The idea is that a router will discard a packet if the TTL is reached and send an ICMP TTL exceeded back. This method is for example used by traceroute (tracepath, tracert...). Since null routing will discard the packet on a router before it reaches the target server this difference can be used to distinguish between null routing on a router or discarding the packet on the final server.


Windows - How to restrict access to VBScript.dll and JScript.dll? In a recent blog post from a company called Recorded Future, which specializes in data protection, details were provided on commonly exploited vulnerabilities on the Windows platform.

Recorded Future Blog: https://www.recordedfuture.com/blog/

Specific Post: Microsoft Targeted by 8 of 10 Top Vulnerabilities in 2018

Within that post, Recorded Future states the following:

  Additionally, there are no mitigating factors available to prevent CVE-2016-0189 — the only workarounds are restricting access to two common dynamic-linked library files: VBScript.dll and JScript.dll.

Question 1: What exactly does it mean to restrict access to VBScript.dll and JScript.dll?

Question 2: How best to do this with PowerShell or Group Policy at scale?

Point 1 - Restricting access means to block certain user groups from accessing these files. You don't want them to use them or interact with them.

Addressing point 2 - how to restrict access, I suggest using App Locker to block this.

In Local Security Policy, expand Application Control Policies -> AppLocker

1a. Before proceeding - select configure rule enforcement -> advanced -> Enable DLL rule collection, apply -> back to enforcement tab, at the bottom under DLL rules: check configured and then press ok.
Right click DLL Rules -> Create New Rule
Select Deny and the user or group who it should be denied to
Since the Path of the file can be changed, select the File Hash option for blocking
Browse to the file in question, and add it
Create!


Way to make "DNS unblockers" safe? Many people who live outside the US use "DNS unblockers" such as Unblock-Us to access region restricted services such as Netflix and Hulu. My understanding of these services is that for DNS requests to blocked services it instead returns an IP for one of their proxy services.

Netflix is approximately 5 times cheaper than the cheapest "pay TV" service in my country, so obviously DNS unblockers are a very attractive proposition. On the other hand, using DNS servers from some little known company is a huge risk! Obviously TLS provides some protection, but I'll acknowledge that I'd most likely fall for an SSL stripping attack for example.

My question is: What options are available to make these unblocking services less of a risk?

Currently, I have to set it as the default DNS service on my router because some of my devices don't have customisable DNS settings – however I override the DNS settings on my PCs to use Google's DNS or my ISP's. This would mitigate the risk somewhat, but it obviously doesn't help on devices that I want to use both Netflix and perhaps also access sensitive services, such as my iPad.

I was thinking I could perhaps set up my own DNS server (I have a media/file server on 247) which proxies DNS requests to say Google DNS ordinarily but uses my DNS unblocker for Netflix related requests. I'm not sure how to go about this, or how I might be able to determine what domains need to go to the unblocker.

There's a guide on how to do it here. Summary:

there is a simple way you can keep using your current DNS and make the changes locally to your PC instead to use Unblock-us's reverse proxies, without a DNS change. This involves editing your PC's HOST File and making the changes that unblock-us do on their public DNS, to your local PC.
For Netflix US for example, you need to make the following changes to your PC's HOSTS file:
204.12.200.61 movies.netflix.com
204.12.200.65 cbp-us.nccp.netflix.com


Recovering from malware in the registry I'm a trainee who writes malware samples to later be tested.  A  basic piece I wrote in C++ kills explorer.exe, taskmgr.exe and repeats this every second.  I used a bit of code to add my application to the registry under HKLM\Software\Microsoft\Windows\CurrentVersion\Run so that it runs automatically when the test machine is started. Because the test machine is a VM, I can restore to the last snapshot and be on my merry way.  If this happened in a real world situation, how would one fix this problem?  Killing explorer and task manager leaves the user with only the desktop with no icons to look at.  I know Windows 7 will do a system restore before the boot but is this true for XP?  BIOS?  Or would they have to try and reinstall Windows cleanly?

In Microsoft's documentation about run keys on Windows XP, it is stated that:

  By default, Run keys are ignored when the computer starts in Safe mode. Under the RunOnce keys, you can prefix a value name with an asterisk (*) to force the associated program to run even in Safe mode.

If not added under RunOnce with the force character, one could start in Safe mode and remove the key.


Are partially typed passwords a potential security risk? I just sat down at my work computer and began to unlock it by typing in my password, I got 6 of the 8 characters in and decided I wanted coffee and walked away to get it. I came back, realized I left most of the password in, typed in the remaining two characters and logged in. Out of pure curiosity, is there a security risk in that?

My thoughts are in most cases it wouldn't be problematic because it gives an attacker one attempt before it is reset and they must start from scratch. However, I suppose at a minimum it lets the attacker know your password is at least that number of characters long (assuming you typed it right) giving them an advantage for future attacks. Is there perhaps a way to grab the text that is typed into the login box, or maybe save the state so you can keep retrying from that partially completed point? What if this were a web page login as opposed to a desktop app?

Corporate espionage is a thing.

There could be a security risk if someone has seen you typing your password, or guesses the last two characters. It's not all that difficult to notice people's keystrokes and subconsciously remember them, especially the last few keys.

In the case of corporate espionage, someone might want to watch you type your password, and they might remember it.

  or maybe save the state so you can keep retrying from that partially completed point?

You have to admit, given the circumstances, this seems like next-level tinfoil hattery. I can just picture a guy in a grey suit walking up to your desktop, looking for your 20+ GB virtual machine disk, plus accompanying configuration data within a couple minutes, and taking it to a seedy cubicle in the corner of the office, then madly brute-forcing while cackling maniacally:

Let's take off the foil for a second. If you are running a virtual machine, then it's quite possible. You could save the state of the virtual machine at that point, and keep trying. The likelihood of this happening to you during a coffee break is pretty much zero. Same with the app state, only not as unlikely as a virtual machine.

With the virtual machine, a colleague would have to copy the contents of your virtual hard-drive, plus the accompanying settings, and mount it. More than likely, this would be in excess of 20 GB. Copying this virtual drive in such a short time while other people are around seems quite unlikely.

Someone will notice something.

What if this were a web page login as opposed to a desktop app?

Let's put on our tinfoil hats and see what we can do to retrieve the partially-typed password using only readily-available tools. Put yourself in the shoes of the attacker: how would you quickly get the password before the coffee break is over?

Using the developer console, you can modify the web page to change this:

<input type="password" name="pass" id="password"/>

To this:

<input type="text" name="pass" id="password"/>

(Removed jQuery as suggested by Doyle Lewis)
We can also get the values through the console input: you can use a variation of these (F12 > Console > Enter input):

console.log($("#password").val()); (jQuery)
console.log(this.pass.val);
console.log(document.getElementById("password").value); (dom)

Apparently Windows 8 and Windows 10 Enterprise have an "eye" icon that allows you to reveal the plain-text password when holding down the eye button. This becomes an even bigger threat when someone else can just click that one button, bypassing all of the effort used in the examples above.

But why would this be a potential security risk?

Re-equipping our [Tinfoil Hat (Mythic Warforged)], let's assume a worst-case scenario:

With your username and password, in an enterprise setting where it definitely isn't difficult to find your username (usually your badge ID, or email username), a malicious colleague can attempt to impersonate you on the network. For example:

Your corporation has WiFi access which requires your employee badge number and password to sign in.
Malicious colleague logs onto the corporate network using your credentials, on an unauthorized device, and then wreaks havoc / steals things without it leading back to them. Most security policies should require device registration first, but there are unfortunately ways around that.
You get blamed. It looks like you did it. And the spy who screwed things up may get away scott free.

How do I protect against this?

This very unlikely, but possible attack, and many other attacks that require physical access to your machine (not including hardware-based infections), is completely mitigated by locking your workstation before getting up, and not entering partial passwords. Make this your habit, and you won't have to worry about anyone doing something like this.

Don't get complacent, though.


What are weak IVs? Can we somehow stop or slow down WEP cracking by avoiding usage of them? Most of us dealing with wireless security must have cracked a WEP key, and while doing that must have come across texts like this:

  weak IVs, reveal more information about the secret part of the WEP key than others--about 9,000 weak IVs out of 16,000,000 possible ones.

What are these weak IVs? It would be great if someone enlightened me about how they reveal secret WEP keys? Can we somehow stop or slow down WEP cracking by avoiding usage of weak IVs?

The weak keys you are talking about are exploited by the FMS attack, as correctly pointed out by another user.

  It would be great if someone enlightened me about how they reveal secret WEP keys?

It's not easy. Keep in mind this is a (relatively complex) cryptographic attack, it's not a simple dictionary attack or something like that.

WEP is (should we say was?) based on a cryptographic algorithm called RC4. The way RC4 works is the following:

1) starting from a key - in our case,a shared key concatenated with an IV - it computes an "internal state" S[i], which is a pseudorandom array of 256 8-bit values, through a Key Scheduling Algorithm (KSA);

2) this internal state is the input of a block (PRGA - Pseudo-Random Generation Algorithm) that generates one pseudo-random byte k[i];

3) the internal state is changed and fed again into the PRGA, which produces another pseudo-random byte k[i]+1. The sequence of pseudo-random bytes is known as keystream;

4) the message (plaintext) is XOR'd with the keystream. Because of the properties of the XOR operator, this is like XORing each pseudo-random byte of keystream with a byte of message. Indeed, that's what happens.

One thing you have to know about the XOR: it is always true that A ⊕ B ⊕ B = A.

The FMS attack works as follows.

Because WEP is used in Wi-Fi, which (for technical reasons not related to security) uses a particular type of header, the first byte of any message "protected" by WEP is known and is 0xAA (AA in hexadecimal). Applying the XOR property, and considering that every byte of the ciphertext is derived separately, we can get the first byte of keystream. Let m1 = 0xAA be the first byte of plaintext and c1 the first byte of ciphertext, the first byte of keystream is m1 ⊕ c1.

Remember that the (fixed) shared key is concatenated with the IV, which changes at every packet but is always known to the attacker (since it's transmitted in clear). As the shared key is constant, a key is weak if the IV is weak.

Let's focus now on the first three bytes of keystream K[0], K[1], K[2].

As the keystream starts with the IV, K[0,1,2] are (the only) three bytes of the IV, and as such are known.  The attacker starts with these bytes and loads them into the KSA. If the IV is weak, the attacker can get a possible value of the fourth byte of the key. By repeating this procedure on several packets, the attacker can get a pretty good idea of the value of the 4th, 5th, bytes and so on.

  What are these weak IVs?

As we saw, weak IVs are IVs which allow to get hints about the key, one byte at a time. These hints get more and more concrete as the attacker collects more and more packets.

More specifically, an IV is weak (in the sense of the FMS attack) if it is of some particular kind such as, for example, A+3::ff:X, where A is the byte of the key to be found, ff is 255 in decimal and X is an arbitrary 8-bit value.

  Can we somehow stop or slow down WEP cracking by avoiding usage of weak IVs?

We can stop this attack by avoiding usage of weak IVs, but we cannot prevent WEP cracking at all. WEP is broken in many ways, most of which would work even if the underlying cryptographic algorithm wasn't broken (as RC4 is, for example through the FMS attack).

Do not use WEP, period. There's no reason to do that anymore.


How do I use a smart phone as an authenticator in the new Web Authentication specification? I have been learning about the new Web Authentication specification. I am a little confused as to how the following use case would work:

A user wants to login to an enterprise web application on their laptop or desktop, using their smart phone as an authenticator (as defined in the spec).

To clarify... the user would type in their username in the web application running in the browser on their laptop. They then click a button that says something like "Password-less Login With Smartphone". They would then click this button at which point they would be prompted on their smartphone for a fingerprint scan. Upon a successful scan they would be logged in to the site. This flow is outlined as an example workflow in the specification here. Also, Google did a nice presentation where they gave an example of something similar except that the web application they were running was already running on the smart phone (not a desktop or laptop). See here. I am interested in the use case where a user is running a web application on their laptop or desktop and want to use their smart phone as the authenticator.

This leads me to the following question(s):

At a high level, what is the process for setting up a smart phone as an authenticator? Is it possible to do this? Is this a use case that Web Authentication supports?

What I am looking for is a very high level of how somehow should setup the browser to interact with their smart phone the same way it would when using Yubikey or another similar device. All of the examples I have seen use Yubikeys or other USB devices as the authenticator for this particular use case, not a smart phone. Any insights would be helpful.

According to the (non-normative) introduction:

  Other authenticators MAY operate autonomously from the computing device running the user agent, and be accessed over a transport such as Universal Serial Bus (USB), Bluetooth Low Energy (BLE) or Near Field Communications (NFC).

So the client (browser) communicates with the authenticator (smartphone) using USB, BLE, or NFC using the Client to Authenticator Protocol (CTAP).

I'm not aware of any smartphone authenticator implementations as of yet, and no current browsers support connecting to an authenticator over BLE or NFC. This indicates bluetooth support was planned for Chrome 68, but I haven't seen any more recent mention of it.

Update: As noted here, Chrome 72 includes BLE support for authenticators that can be enabled by a flag.


Pseudonymisation - Should e-mail addresses in the application be masked? We are a B2B company and our application stores e-mail addresses provided by our clients. These e-mail addresses are required for us to discharge services. Our clients or our staff with  appropriate privileges can view these e-mail addresses after logging into their account in the application. Do we have to mask these e-mail addresses or implement other similar techniques for conforming with GDPR?

GDPR requires you to protect the personally identifiable information that you store, and to limit access to it. As a lot of people will have their name in their email address, one should regard emails as personally identifiable.

You should limit the access to email addresses, so that it is only viewed when needed, by as few people as possible, taking into account the time and cost needed to implement these safeguards.

Article 25 states:

  Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of
  processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the
  processing, the controller shall, both at the time of the determination of the means for processing and at the time of the
  processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are
  designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the
  necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of
  data subjects.
  The controller shall implement appropriate technical and organisational measures for ensuring that, by default,
  only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies
  to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility.
  In particular, such measures shall ensure that by default personal data are not made accessible without the individual's
  intervention to an indefinite number of natural persons.

http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L:2016:119:FULL

Based on this, I would argue that yes, you should mask the email addresses of the users so that they are only visible to staff when needed. If the staff logs into the system for the sole purpose of viewing the email addresses, I would argue that you don't have to make any changes. But if the staff uses this system all the time, giving them access to this information also when not needed, you might have to make some changes.


openssl crl "Error getting CRL issuer certificate" reasons CRL file A - http://pastebin.com/ZXGk9p0X
CA file B in directory "dir1" http://pastebin.com/05PKGCjH

openssl crl -in A -CApath dir1

gives the error
Error getting CRL issuer certificate

I had earlier posted a similar question - but there my cert was actually wrong.

Here I think it's correct

openssl x509 -in dir1\B

subject= /C=IN/O=India PKI/CN=CCA India 2011

openssl crl -in A -issuer

issuer=/C=IN/O=India PKI/CN=CCA India 2011

How do I troubleshoot this further?

Given that you did not specify the filename for the certificate my guess is that you just placed it into the directory given by -CApath without taking care of the special file name as needed. From the documentation of x509:

  -subject_hash
       outputs the "hash" of the certificate subject name. This is used in OpenSSL
       to form an index to allow certificates in a directory to be looked up by
       subject name.

Also the documentation of -CApath for openssl crl states:

  -CApath dir
  verify the signature on a CRL by looking up the issuing certificate in dir. This directory must be a standard certificate directory: that is a hash of each subject name (using x509 -hash) should be linked to each certificate.

If you use the hash c7f51c60 returned by openssl x509 -subject_hash as the base for the filename, i.e. put the certificate into dir1/c7f51c60.0 then it works. If you don't want to fiddle with these special filename just put all the certificate into a single file and use -CAfile instead.


Can an iPhone be accessed via a compromised router? Can someone have access to my iPhone if my router is compromised?
Such as:

having access to my Gmail app on iPhone
access to my Gmail/other passwords
be able to send or delete mails via iPhone?

No, compromising the router does not give you access to devices connected to the router. The attacker may attempt to exploit vulnerabilities in the connected devices to compromise the devices too, but if your devices are up to date, this would be very unlikely to succeed (unless you are a high value target for a sophisticated state-level attacker.)

Can someone use my ip address?

In the case of a Wifi router, yes they may be able to use your routers IP (which would be the same as your iPhone's public IP when your iPhone is connected to that Wifi), but that does not mean they will be able to access your iPhone or any accounts you are logged in to.


Encryption tool that supports multiple separate decryptions? Is there a tool that will allow me to encrypt n plaintexts with n corresponding keys such that:

the cipher text is one file with no clue as to the value of n.
decrypting with key i (1<=i<=n) produces plaintext i.
n > 1

Edit: an example of a scheme that meets the second and third criteria but not the first would be a tar file containing n separate GPG-encrypted files.

Edit 2: an example of a scheme that meets all three criteria would be TrueCrypt hidden volumes, but I am looking for something that works with individual files rather than a disk encryption system (plus this doesn't really meet the first criterion as the value of n is always 2)

Assuming that all ciphertexts are of the same length (some tricky padding could help with different lengths), you can just XOR the plaintexts together:

C = M1 xor M2 xor M3
K1 = M2 xor M3
K2 = M1 xor M3
K3 = M1 xor M2
M1' = C xor K1
M2' = C xor K2
M3' = C xor K3
... and so forth for Mn and Kn

Important: even if the plaintext is unpredictable, this "encryption" scheme is very weak; do not use it for confidential data.


How to prevent information leak from a Javascript app? I want to use a client-side JS app, but I want to prevent it from leaking sensitive data.

For example, I want to check if my password is compromised using the haveibeenpwned service, which accepts SHA1 hashes. I've found a site that lets me generate SHA1 hashes that do not use a server to do so. But I need to enter my password there, and I'm worried the service will leak it to some database.

I'd like to make sure the SHA1 generator site has no way of sending my password anywhere. I don't trust that site.

The process I'm thinking of:

Use incognito mode. This prevents the site from storing information.
After the page is loaded, shut it off the network by using the DevTools (f12 -> network -> offline). This prevents the site from communicating to the outside.

Is this process secure? Are there any ways a site could send or store anything?

Note: I know I can generate an SHA1 from the command line, but I'm looking for a secure web-based one.

The following process using Incognito Mode would be possible:

Load the page in Incognito window/tab
Disconnect (not just via the DevTool, more like pulling cables or shut down WiFi)
Do your SHA1 generation
Clean Up: Close the Incognito window/tab (to clear Cache&Cookies and stop eventually runnung JS script) This is important as the site might be able to upload some data asynchronously (after the reconnection)
Reconnect


Why do some EV certificates show the full address of the organization, but others only show the state or city? If I go to www.comodo.com, I can see their registered office address in the EV certificate:

CN = www.comodo.com
OU = COMODO EV SGC SSL
OU = COMODO EV SSL
O = Comodo Group Inc.
STREET = 1255 Broad St.
STREET = Suite 100
L = Clifton
S = NJ
PostalCode = 07013
C = US
2.5.4.15 = Private Organization
1.3.6.1.4.1.311.60.2.1.2 = Delaware
1.3.6.1.4.1.311.60.2.1.3 = US
SERIALNUMBER = 3830138

The same case with www.digicert.com:

CN = www.digicert.com
O = DigiCert, Inc.
L = Lehi
S = Utah
C = US
PostalCode = 84043
STREET = 2600 West Executive Parkway
STREET = Suite 500
SERIALNUMBER = 5299537-0142
1.3.6.1.4.1.311.60.2.1.2 = Utah
1.3.6.1.4.1.311.60.2.1.3 = US
2.5.4.15 = Private Organization

However, on www.jetbrains.com, the full address is not in their EV certificate:

CN = www.jetbrains.com
L = Praha 4
S = Praha 4
C = CZ
SERIALNUMBER = 26502275
O = JetBrains s.r.o.
2.5.4.15 = Private Organization
1.3.6.1.4.1.311.60.2.1.3 = CZ

The street address is also no present in the EV certificate of secure.powershop.com.au:

CN = secure.powershop.com.au
L = Melbourne
S = Victoria
C = AU
SERIALNUMBER = 154 914 075
O = Powershop Australia Pty Limited
2.5.4.15 = Private Organization
1.3.6.1.4.1.311.60.2.1.3 = AU

Under what circumstances will the full street address not be present in an EV certificate?

According to the CABForum, which produces the guidelines for EV certificates, the street number and postal codes are optional in the EV certificate contents:

  Address of Place of Business (EVG 9.2.7) – This field must contain the
  address of the physical location for the Subject. City, state and
  country information are required. Street number and postal codes are
  optional.