izogain

TLDR

Cisco Security Manager is an enterprise-class security management application that provides insight into and control of Cisco security and network devices. Cisco Security Manager offers comprehensive security management (configuration and event management) across a wide range of Cisco security appliances, including Cisco ASA Adaptive Security Appliances, Cisco IPS Series Sensor Appliances, Cisco Integrated Services Routers (ISRs), Cisco Firewall Services Modules (FWSMs), Cisco Catalyst, Cisco Switches and many more. Cisco Security Manager allows you to manage networks of all sizes efficiently-from small networks to large networks consisting of hundreds of devices.

Several pre-auth vulnerabilities were submitted to Cisco on 2020-07-13 and (according to Cisco) patched in version 4.22 on 2020-11-10. Release notes didn't state anything about the vulnerabilities, security advisories were not published. All payload are processed in the context of NT AUTHORITY\SYSTEM.

izogain

Turning PostgreSQL into a queue serving 10,000 jobs per second

RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.

On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.

So, many developers have started going straight t

izogain

worker_processes 1;

events {
	worker_connections 1024;
}

http {
	include mime.types;
	default_type application/octet-stream;
	sendfile on;

izogain

                _   _            _      ____             _    _ 
               | | | | __ _  ___| | __ | __ )  __ _  ___| | _| |
               | |_| |/ _` |/ __| |/ / |  _ \ / _` |/ __| |/ / |
               |  _  | (_| | (__|   <  | |_) | (_| | (__|   <|_|
               |_| |_|\__,_|\___|_|\_\ |____/ \__,_|\___|_|\_(_)
                                                 
                                  A DIY Guide

izogain

#/etc/pam.d/system-auth
#%PAM-1.0

# Jump two rules if login succeeds.
auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    optional                        pam_exec.so /home/pamcam.sh
auth    requisite                       pam_deny.so

# User gets here if authentication is successful. No denying, no cam module.
auth      required  pam_unix.so     try_first_pass nullok

izogain

Principles of Adult Behavior

1. Be patient. No matter what.
2. Don’t badmouth: Assign responsibility, not blame. Say nothing of another you wouldn’t say to him.
3. Never assume the motives of others are, to them, less noble than yours are to you.
4. Expand your sense of the possible.
5. Don’t trouble yourself with matters you truly cannot change.
6. Expect no more of anyone than you can deliver yourself.
7. Tolerate ambiguity.
8. Laugh at yourself frequently.

izogain

<?XML version="1.0"?>
<scriptlet>

<registration
    description="Bandit"
    progid="Bandit"
    version="1.00"
    classid="{AAAA1111-0000-0000-0000-0000FEEDACDC}"
	>

izogain

package main

import (
	"context"
	"flag"
	"fmt"
	"log"
	"net/http"
	"os"
	"os/signal"

izogain

Quick Tips for Fast Code on the JVM

I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.

This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea

izogain

GitHub for Bug Bounty Hunters

GitHub repositories can disclose all sorts of potentially valuable information for bug bounty hunters. The targets do not always have to be open source for there to be issues. Organization members and their open source projects can sometimes accidentally expose information that could be used against the target company. in this article I will give you a brief overview that should help you get started targeting GitHub repositories for vulnerabilities and for general recon.

Mass Cloning

You can just do your research on github.com, but I would suggest cloning all the target's repositories so that you can run your tests locally. I would highly recommend @mazen160's GitHubCloner. Just run the script and you should be good to go.

$ python githubcloner.py --org organization -o /tmp/output