声明
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,雷神众测以及文章作者不为此承担任何责任。
雷神众测拥有对此文章的修改和解释权。如欲转载或传播此文章,必须保证此文章的完整性,包括版权声明等全部内容。未经雷神众测允许,不得任意修改或者增减此文章内容,不得以任何方式将其用于商业目的。
前言
从fastjson1.24版本的反序列化利用方式知道有使用jdk7u21的版本利用链,ysoserial利用工具中也有7u21利用链。现在都是7u80版本了,这个漏洞真正直接利用,估计已经很难找到了。
但是这个利用链的构造有很多之前没接触过的java特性,就此好好学习一下,也算是fastjson的前置知识吧。
POC
先去Oracle官网下载漏洞jdk版本7u21,漏洞影响7u25之前的版本,整条链poc貌似只适用于7u21以前。
之所以说这是JDK反序列化链,是因为这个链中所有利用类都是jdk自带的类,其中payload最终关键类是 com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl类。
我们从ysoserial源码中抠出7u21的利用代码来分析,具体代码由于比较长,不全部在此贴出,只截取需要的部分,所有代码已上传github。
jdk7u21.java是一个包含基础核心原理POC。(Gadgets类参考github,或者可以去ysoserial中取)
public static void main(String[] args) throws Exception {
TemplatesImpl calc = (TemplatesImpl) Gadgets.createTemplatesImpl("calc");//生成恶意的calc
calc.getOutputProperties();//调用getOutputProperties就可以执行calc
}
请注意TemplatesImpl类的getOutputProperties函数是一个以get开头的函数,这是这个利用链在fastjson组件利用的关键。
跟踪getOutputProperties方法,来确认恶意TemplatesImpl类calc 需要的条件,先看调用栈:
newInstance
从调用栈中,可见最后是obj.newInstance(obj是虚指)触发poc执行恶意代码,调用栈再往下之后就是java class类的newInsatance内部实现了,不细纠。
newinstance实例化会默认触发执行static方法,构造方法代码,如下:
所以我们的payload需要放在最后执行的恶意类的static或构造方法中。知道这点后,我们从头开始慢慢寻找其他需要条件。
跟入TemplatesImpl类的getOutputProperties方法:
public synchronized Properties getOutputProperties() { try { return newTransformer().getOutputProperties();//我们进入newTransformer方法
} catch (TransformerConfigurationException e) { return null;
}
}
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl#newTransformer方法
public synchronized Transformer newTransformer()
throws TransformerConfigurationException {
TransformerImpl transformer;
transformer = new TransformerImpl(getTransletInstance(), _outputProperties,
_indentNumber, _tfactory);//此处没有啥限制条件,进入getTransletInstance()
if (_uriResolver != null) {
transformer.setURIResolver(_uriResolver);
} if (_tfactory.getFeature(XMLConstants.FEATURE_SECURE_PROCESSING)) {
transformer.setSecureProcessing(true);
} return transformer;
}
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl#getTransletInstance方法
在漏洞代码执行AbstractTranslet translet = (AbstractTranslet) _class[_transletIndex].newInstance();前,
先经过com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl#defineTransletClasses方法
_tfactory 与jdk版本
其中的限制条件4 _tfactory 这个参数是有说法的,在其他人博客中有存在对于 _tfactory 的参数的说明:
因为代码中存在 _tfactory.getExternalExtensionsMap() 所以需要 _tfactory 进行赋值 不能为null。
但其实这跟jdk版本是有关的,1.7下不同的jdk版本这段代码是不同的。
1.7u80版本的com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl#defineTransletClasses中就是存在_tfactory.getExternalExtensionsMap()这句代码的。
在1.7u80中,注释Gadgets类中添加 _tfactory这个字段的代码后(之后我们将详细分析Gadgets类),_tfactory=null就会发生null指针报错。
细心的同学可以注意到上面jdk1.7u80两个弹框成功不成功的下方都会null指针报错。
但是前者是在执行恶意代码AbstractTranslet translet = (AbstractTranslet) _class[_transletIndex].newInstance();后
的translet.postInitialization();处报错。
而后者是在恶意代码执行之前的defineTransletClasses函数报错。即没有成功执行payload
在同样注释_tfactory这个字段的代码的情况下,使用jdk1.7u21的环境,却可以成功执行,因为jdk1.7u21的情况下并没有_tfactory.getExternalExtensionsMap()这句代码。
但是1.7u21也可以兼容给_tfactory赋值的情况,所以还是给 _tfactory 赋值比较好,可以兼容不同的版本。
TemplatesImpl恶意类的限制条件
至此总结我们构筑一个恶意的TemplatesImpl类,在调用这个恶意类的getOutputProperties方法时,需要满足的限制条件。即,构筑恶意TemplatesImpl类的需要条件。
1.TemplatesImpl类的 _name 变量 != null
2.TemplatesImpl类的_class变量 == null
3.TemplatesImpl类的 _bytecodes 变量 != null
4.TemplatesImpl类的_tfactory需要是一个拥有getExternalExtensionsMap()方法的类,使用jdk自带的TransformerFactoryImpl类
5.TemplatesImpl类的_bytecodes是我们代码执行的类的字节码。_bytecodes中的类必须是com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet的子类
6.我们需要执行的恶意代码写在_bytecodes 变量对应的类的静态方法或构造方法中。
构筑POC
回首漏洞原理的POC
public static void main(String[] args) throws Exception {
TemplatesImpl calc = (TemplatesImpl) Gadgets.createTemplatesImpl("calc");//生成恶意的calc
calc.getOutputProperties();//调用getOutputProperties就可以执行calc}
在分析完第二句触发漏洞的语句后。回来看第一句构筑。由于需要动态对于类结构进行操作,有使用到Javassist包
Gadgets是ysoserial自主构建的一个利用类,看其中的createTemplatesImpl方法:
瞅一眼StubTransletPayload类的继承。
//很优秀的按照要求继承了AbstractTranslet类public static class StubTransletPayload extends AbstractTranslet implements Serializable { private static final long serialVersionUID = -5971610431559700674L;//以下看似是多余的,实际上是继承AbstractTranslet的必要,不然会报错。//transform(DOM document, SerializationHandler[] handlers) 需要实现 AbstractTranslet 的一个虚拟类
public void transform(DOM document, SerializationHandler[] handlers) throws TransletException {}//下面这个函数 需要实现AbstractTranslet类对应的Translet接口的一个接口
@Override
public void transform(DOM document, DTMAxisIterator iterator, SerializationHandler handler) throws TransletException {}
}
再瞅一眼往templates类的私有字段_bytecodes, _name , _tfactory 这些属性中塞数据的Reflections.setFieldValue方法。这里是通过反射机制修改私有属性。
public static void setFieldValue(final Object obj, final String fieldName, final Object value) throws Exception { final Field field = getField(obj.getClass(), fieldName);
field.set(obj, value);//获取了对应的字段后,进行赋值。
}//Reflections#getField
public static Field getField(final Class<?> clazz, final String fieldName) throws Exception {
Field field = clazz.getDeclaredField(fieldName);//通过反射机制获取该字段
if (field != null)
field.setAccessible(true);//接触private限制
else if (clazz.getSuperclass() != null) //判断父类,如果有父类,就获取父类的值,TemplatesImpl类没有父类,这里没用上。
field = getField(clazz.getSuperclass(), fieldName); return field;
}
可以看到上面的Gadgets类完美符合了我们之前在利用过程中提到的全部需要条件。但是Gadgets构造的恶意TemplatesImpl类比起我们需要的POC条件多1处东西:
_bytecodes多加了一个Foo.class类
我始终没有找到这个到底有啥用,去掉后实验,没有任何影响。如果有老哥知道,可以联系我,非常感谢。
payload位置static与构造函数
自己构造一波payload,再分析一个payload放置位置的问题
以上需要注意一个情况,我们的恶意字节码类lala类,使用了static修饰符。其实我们payload写在构造函数中是可以不使用static修饰符不会影响。
但是如果我们想把payload写在static初始化块中,类就需要使用static修饰符时。不然最后实例化是不会成功的。
就相当于是以下的情况,内部类是不允许存在static修饰符的,原理可以参考。
ps.突然发现非static方法块也是可以写payload…..但是不纠结这个了!!
至此我们完成了恶意Templates类构造以及TemplatesImpl.getOutputProperties触发点的分析(当然从上面的调用过程,我们知道直接调用TemplatesImpl.newTransformer()也是一样的,getOutputProperties其实就是调用了newTransformer(),在接下来的延长链中其实漏洞触发是在newTransformer)。
目前的结论已经可以移花接木到fastjson的利用链中形成一套完成利用链。以及其他很多组件的利用链的最后一步都是TemplatesImpl类(限于jdk1.7版本,1.8会编译错误,原因未知)。
但是就单独作为一条利用链来说,只有exp触发点和一点点长度的利用链是不够的,我们需要继续延伸到一个反序列化readObject点,使服务端一触发反序列化,就可以沿着利用链到exp触发点。
延长利用链
AnnotationInvocationHandler这是一个熟悉的类,在commons-collections一文的1.7最基础的利用链中,我们正是使用了AnnotationInvocationHandler的readobject函数作为反序列化入口点。
然而这里跟AnnotationInvocationHandler的invoke函数有关。在这之前我们需要先了解java的动态代理性质。
动态代理
动态代理是java的特性之一,其实就可以理解为web应用中的拦截器,在执行正式代码之前先过一个拦截器函数(比如spring的AOP)。但是以上类比只是为了便于理解,实际上spring的AOP之类的拦截器反而是基于java的动态代理实现的。
下面将举例动态代理SubjectImpl类,即在SubjectImple类前面建立一个拦截器。
DynamicProxy.java
Proxy.newProxyInstance三个传入参数:
1.loader,选用的类加载器。感觉随便选就好了。
2.interfaces,被代理类所实现的接口,这个接口可以是多个。(即需要拦截的接口)
3.h,一个 实现拦截器的invocation handler。
之后只要我们调用了返回之后的对象中被安排了代理的接口,就会进入invocationHandler的invoke函数。
以上执行结果就是:
before!
SubjectImpl.hello(): world!
after!
那么动态代理大概就分为几个部分:
1.被代理的接口类
2.被代理的接口类的实现类
3.继承InvocationHandler接口、实现invoke方法的拦截器类
4.Proxy.newProxyInstance完成拦截器,与被代理的接口类的绑定
5.调用这个返回对象的被代理接口即可。(此处注意这个返回的对象不是只有被代理的接口类中的接口,还有一些常用接口,之后会截图说明。)
我们说了那么多动态代理机制,是为啥呢?
class AnnotationInvocationHandler implements InvocationHandler, Serializable { //实现了InvocationHandler接口的invoke函数
public Object invoke(Object var1, Method var2, Object[] var3) {
...
}
}
其实就是因为AnnotationInvocationHandler类其实是一个InvocationHandler接口的实现类。它不只是在cc的利用链中作为反序列化点,还是作为动态代理的拦截器实现函数(有一个自己的invoke方法)
动态代理链接AnnotationInvocationHandler与Templates
我们的目的是连接代理后的对象Proxy的equal方法到Templates的newTransformer方法。
当建立动态代理后(Proxy.newInstance返回一个对象a),我们假设调用a.b(c)
先瞅一眼AnnotationInvocationHandler的构造函数有个底,我们可以知道有可控的this.type与this.memberValues
AnnotationInvocationHandler(Class<? extends Annotation> var1, Map<String, Object> var2) { this.type = var1; this.memberValues = var2;
}
bytheway,这里的AnnotationInvocationHandler构造函数是缺省修饰符,它在不同的包中是不能直接调用的。
反射机制中有说到,可以使用setAccessible(true)来开放权限。
调用a.b(c)。 sun.reflect.annotation.AnnotationInvocationHandler#invoke
//var1 当前的Proxy代理实例对象,即a.b(c)的a//var2 当前调用的方法,即a.b(c)的b//var3 当前调用方法的传入参数列表,即a.b(c)的cpublic Object invoke(Object var1, Method var2, Object[] var3) {
String var4 = var2.getName();//被调用方法名
Class[] var5 = var2.getParameterTypes();//获取传入参数类型列表
//如果调用的方法名是equals,传入一个参数,并且为Object类型,即a.equal((Object.class)c)
//此处的意思应该为判断a是否与传入的c完全相等。
if (var4.equals("equals") && var5.length == 1 && var5[0] == Object.class) { return this.equalsImpl(var3[0]);//我们进入此处,传入的是a.b(c)中的c的第一个参数
} else {
...
sun.reflect.annotation.AnnotationInvocationHandler#equalsImpl
equals方法会根据this.type类中的方法去遍历调用传入对象中的所有对应的方法。那么!
1.我们可以构筑一个AnnotationInvocationHandler类,构造函数中选择一个this.type,this.type这个类中需要包含我们要恶意执行的方法。
2.把这个AnnotationInvocationHandler类与随便什么接口进行绑定(因为我们需要调用的是equals,只要是一个Object对象就会有equals方法 maybe?)
3.调用这个代理类的equals方法,同时給入恶意实例,就会遍历this.type这个类中的方法对恶意实例中的对应方法进行调用。唯一的缺点就是调用的方法不能传入参数。(因为var5.invoke(var1);只传入了对象,没有传入参数)
我们需要调用的是TemplatesImpl.newTransformer(),刚好这个方法不需要传入参数!
再是this.type=Templates.class,因为TemplatesImpl继承自Templates接口,并且它有我们要的方法,并且在第一个(为啥需要恰好又刚好在第一个,之后有说法)。
public interface Templates { Transformer newTransformer() throws TransformerConfigurationException;
Properties getOutputProperties();
}
给出poc
this.type的讲究
为啥this.type需要选用类中第一个方法是我们需要调用的方法的类呢?
因为不是的话,就需要考虑更多,比如报错退出。可以看到在执行完我们的payload后是会报错退出的,当然这对我们paylaod的执行没有影响。
但是假如我们需要调用的方法不在第一个,而前面是一个需要参数的方法,就会因为没有传入参数而报错退出。(比如我们把Templates.class改成TemplatesImpl.class)
如果我们需要调用的方法前面有一些其他方法,但是都是不需要参数的,我们还需要构造this.memberValues,让前面这些函数的返回值与this.menberValues里面一致才不会返回false退出。就会有一串的麻烦(目前来看这样也是可行的,但是假如这里真的改了this.memberValues之后LinkedHashSet那关就过不去了!实际上我们只能且必须要找到一个第一个方法是能够代码执行的方法!)
所幸我们可以找到一个Templates类,它进行代码执行的方法是第一个,万幸。
进一步延伸
接下来需要触发proxy.equals(templates),这种a.equals(b)的形式。a是我们构建的动态代理返回对象,b是恶意TemplatesImpl类。
LinkedHashSet类继承自Hashset,具有Hashset的全部特点:元素不重复,快速查找,快速插入。新增的特性是有序,数据结构上使用双向链表实现。(之所以用LinkedHashSet就是因为其有序的特性,后面会说到为什么需要有序)
LinkedHashSet.java
public class LinkedHashSet<E> extends HashSet<E> implements Set<E>, Cloneable, java.io.Serializable {
... //给一个我们要用到的构造函数
public LinkedHashSet() { super(16, .75f, true);//进去这里看看
} //LinkedHashSet这个类其实根本没有自己实现过类,只有四个构造函数,实际上使用LinkedHashMap实现有序功能的
...
}
super就进入HashSet了,HashSet.java:
HashSet(int initialCapacity, float loadFactor, boolean dummy) {
map = new LinkedHashMap<>(initialCapacity, loadFactor);//可以看到使用LinkedHashMap创建了有序集合
}
具体是如何实现这个集合的,我们就不纠结了。我们需要通过LinkedHashSet连接writeObject序列化与readObject反序列化这个利用链入口至**a.equals(b)**这个我们之前得到的触发点。
先看LinkedHashSet的序列化与反序列化。LinkedHashSet获取的是LinkedHashMap的实例,而LinkedHashMap又继承自HashSet,所以最终的序列化与反序列化就是在HashSet类中。
我们跟着反序列化触发链来看。
java.util.HashMap#put
我们专注于if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {这句语句。(e为前一个元素,key为当前元素)
可以看到key.equals(k)符合我们前面说到的a.equals(b)的格式。在只有两个元素的情况下,k为有序集合中第一个元素,key为第二个元素。
即我们需要一个有序集合{templates,proxy}才能满足proxy.equals(templates)这一句触发语句。
这也就是为什么需要有序集合的原因,如果是普通集合,不会一定会符合这个a.equals(b)的顺序
由于这里代码(e.hash == hash && ((k = e.key) == key || key.equals(k)))调用第三个语句就需要满足条件
1.e.hash == hash:templates的hash == proxy的hash
2.(k = e.key) != key :templates(就是k) != proxy(就是key)(我们需要||左边这个表达式不满足,才会执行右边的漏洞触发函数key.equals(k)。这是||的特性,执行到一个为true的,后面的表达式就不执行了)
因为templates和proxy完全是两个不同的对象。所以第二个条件满足。
但是第一个条件需要hash相同,如果不是偷看答案的小白(我自己)肯定会突然僵住,特么这咋可能hash相等,当场直接gg。实际上套路还是很深。看hash是如何生成的
java.util.HashMap#hash
我们传入的obj有TemplatesImpl类,但是这个类中没有自实现hashcode方法。
有Proxy对象(进入AnnotationInvocationHandler拦截器实现类),proxy.hashCode会先进入AnnotationInvocationHandler的invoke拦截器。(跟equals一样一样的,任何函数都会先进入invoke方法)
sun.reflect.annotation.AnnotationInvocationHandler#invoke
public Object invoke(Object var1, Method var2, Object[] var3) {
String var4 = var2.getName();
Class[] var5 = var2.getParameterTypes(); if (var4.equals("equals") && var5.length == 1 && var5[0] == Object.class) { return this.equalsImpl(var3[0]);//我们之前payload触发在这
} else { assert var5.length == 0; if (var4.equals("toString")) { return this.toStringImpl();
} else if (var4.equals("hashCode")) {//往下看!这个可爱的invoke实现上对于hashCode这个函数还是有独特处理的!!!!
return this.hashCodeImpl();//进去看看
sun.reflect.annotation.AnnotationInvocationHandler#hashCodeImpl
private int hashCodeImpl() { int var1 = 0;
Entry var3; for(Iterator var2 = this.memberValues.entrySet().iterator(); var2.hasNext(); var1 += 127 * ((String)var3.getKey()).hashCode() ^ memberValueHashCode(var3.getValue())) {
var3 = (Entry)var2.next();
} return var1;
}
这边写的贼复杂,改成简单点
sun.reflect.annotation.AnnotationInvocationHandler#memberValueHashCode
private static int memberValueHashCode(Object var0) {
Class var1 = var0.getClass(); if (!var1.isArray()) {//不是数组的话获取传入值的hashCode。
return var0.hashCode(); //返回var0这个对象的hashCode
...
我们的目的是为了满足以下等式:
Proxy的hashCode = 127 * 可控键的hashCode ^ 可控值的hashCode == TemplatesImpl的hashCode
*与 ^(异或) ,前者优先级高,后者优先级低,所以正常从左到右运算
又 0 ^ n = n
那么只需要可控键的hashCode等于0就会出现:
127 * 0 ^ TemplatesImpl的hashCode == TemplatesImpl的hashCode
this.memberValues中map中键值对的值为我们的恶意TemplatesImpl类即可,接下来需要它的键名的hashCode为0
研究员就是会寻找到一些神奇的值比如"f5a5a608","" 这些值的hashCode为0!!!
所以我们在this.memberValues中赋值键值对 ("f5a5a608"->TemplatesImpl恶意类)即可。
看payload
this.memberValues的键值对的值先占位
以上代码还会有最后一个疑问,为啥我们填入this.memberValues的map要先试用override字符串来占位,直接填入恶意的攻击类templates不行么?
确实是不行的,因为我们可以看到我们在生成LinkedHashSet时调用了java.util.HashSet#add
public boolean add(E e) { return map.put(e, PRESENT)==null;
}
这里调用了我们触发漏洞的函数map.put(),同时也是按照我们的漏洞触发顺序去调用map.put,这会导致payload会在我们本地触发,之后会无法序列化成功(至于为啥序列化不成功不想追究了!)
所以一套完美的利用链就分析完了!
修复结果
我们在7u80版本中去查看AnnotationInvocationHandler的构造方法,会发现对于this.type进行了校验必须为Annotation.class。
AnnotationInvocationHandler(Class<? extends Annotation> var1, Map<String, Object> var2) {
Class[] var3 = var1.getInterfaces(); if (var1.isAnnotation() && var3.length == 1 && var3[0] == Annotation.class) { this.type = var1; this.memberValues = var2;
} else { throw new AnnotationFormatError("Attempt to create proxy for a non-annotation type.");
}
}
如果我们们使用以上的payload去打7u80版本的jdk就会在反序列化AnnotationInvocationHandler类调用其构造函数的时候,报错。
这也就是为什么之前的payload说到在高版本创建需要使用反射把恶意的this.type写进去,当然构造时可以这样,触发时就必须走构造函数,骚操作不了了。
主要组件的 LinkedHashSet -> AnnotationInvocationHandler -> templateImpl 就因为AnnotationInvocationHandler 反序列化失败而失败。
小结
一路分析下来,只能说这个利用链实在是太骚了。
从templates.newTransformer触发链的限制条件,使用javassist去构造templates恶意类。(其中分析了_tfactory与版本问题,payload位置static与构造函数的问题)
再通过java的动态代理特性,选中了AnnotationInvocationHandler这个拦截器。
我们通过AnnotationInvocationHandler的invoke拦截实现类的特性,选择了this.type特殊构造了AnnotationInvocationHandler类。链接了 proxy.equals(templates)到Templates.newTransformer()。
再是通过LinkedHashSet类,左打通了序列化与反序列化的入口点,右在反序列化恢复集合的过程中存在着一处a.equals(b)可以连接proxy.equals(templates)这一触发点。
最神奇的是为了满足到达触发点的要求,还反过头来利用AnnotationInvocationHandler类中的invoke方法中的hashCode路径。在AnnotationInvocationHandler构造中寻求了一处特殊的this.memberValues,来达成hash(a)=hash(b)的骚操作。
只可以说安全研究员真是大佬….这个穿针引线一处不差的。
虽然说这条利用链已经被封了好久了,但是我们也可以意识到被封杀的是AnnotationInvocationHandler构造方法处。
如果可以通过其他途径接上templates.newTransformer,就可以构筑一条新的链。因为单单templates.newTransformer是仍然可以作为payload执行的触发点的(比如7u80)。
漏洞修复
jdk版本升级至最新版(7u80)。
招聘启事
雷神众测SRC运营(实习生)
————————
工作地点:杭州(总部)、广州、成都、上海、北京
【职责描述】
1. 负责SRC的微博、微信公众号等线上新媒体的运营工作,保持用户活跃度,提高站点访问量;
2. 负责白帽子提交漏洞的漏洞审核、Rank评级、漏洞修复处理等相关沟通工作,促进审核人员与白帽子之间友好协作沟通;
3. 参与策划、组织和落实针对白帽子的线下活动,如沙龙、发布会、技术交流论坛等;
4. 积极参与雷神众测的品牌推广工作,协助技术人员输出优质的技术文章;
5. 积极参与公司媒体、行业内相关媒体及其他市场资源的工作沟通工作。
【任职要求】
1. 责任心强,性格活泼,具备良好的人际交往能力;
2. 对网络安全感兴趣,对行业有基本了解;
3. 良好的文案写作能力和活动组织协调能力。
雷神众测白帽运营(实习生)
————————
工作地点:杭州(总部)、广州、成都、上海、北京
【岗位职责】
1.准确了解白帽子爱好,发掘白帽子需求
2.负责各类周边、礼物的挑选与采购
3.对黑客文化有深刻认知
4.维护白帽关系
【任职要求】
1.具有良好的审美眼光
2.具备定制礼品礼物经验
3.较强的沟通以及协调能力
4.为人正直,具备良好的职业道德,能吃苦耐劳,具有良好的团队合作精神
【加分项】
1、具备美术功底、懂得设计美化等
2、有互联网运营经验
简历投递至 [email protected]
设计师
————————
【职位描述】
负责设计公司日常宣传图片、软文等与设计相关工作,负责产品品牌设计。
【职位要求】
1、从事平面设计相关工作1年以上,熟悉印刷工艺;具有敏锐的观察力及审美能力,及优异的创意设计能力;有 VI 设计、广告设计、画册设计等专长;
2、有良好的美术功底,审美能力和创意,色彩感强;精通photoshop/illustrator/coreldrew/等设计制作软件;
3、有品牌传播、产品设计或新媒体视觉工作经历;
【关于岗位的其他信息】
企业名称:杭州安恒信息技术股份有限公司
办公地点:杭州市滨江区安恒大厦19楼
学历要求:本科及以上
工作年限:1年及以上,条件优秀者可放宽
简历投递至 [email protected]
安全招聘
————————
公司:安恒信息
岗位:Web安全 安全研究员
部门:安服战略支援部
薪资:13-30K
工作年限:1年+
工作地点:杭州(总部)、广州、成都、上海、北京
工作环境:一座大厦,健身场所,医师,帅哥,美女,高级食堂…
【岗位职责】
1.定期面向部门、全公司技术分享;
2.前沿攻防技术研究、跟踪国内外安全领域的安全动态、漏洞披露并落地沉淀;
3.负责完成部门渗透测试、红蓝对抗业务;
4.负责自动化平台建设
5.负责针对常见WAF产品规则进行测试并落地bypass方案
【岗位要求】
1.至少1年安全领域工作经验;
2.熟悉HTTP协议相关技术
3.拥有大型产品、CMS、厂商漏洞挖掘案例;
4.熟练掌握php、java、asp.net代码审计基础(一种或多种)
5.精通Web Fuzz模糊测试漏洞挖掘技术
6.精通OWASP TOP 10安全漏洞原理并熟悉漏洞利用方法
7.有过独立分析漏洞的经验,熟悉各种Web调试技巧
8.熟悉常见编程语言中的至少一种(Asp.net、Python、php、java)
【加分项】
1.具备良好的英语文档阅读能力;
2.曾参加过技术沙龙担任嘉宾进行技术分享;
3.具有CISSP、CISA、CSSLP、ISO27001、ITIL、PMP、COBIT、Security+、CISP、OSCP等安全相关资质者;
4.具有大型SRC漏洞提交经验、获得年度表彰、大型CTF夺得名次者;
5.开发过安全相关的开源项目;
6.具备良好的人际沟通、协调能力、分析和解决问题的能力者优先;
7.个人技术博客;
8.在优质社区投稿过文章;
岗位:安全红队武器自动化攻城狮
薪资:13-30K
工作年限:2年+
工作地点:杭州(总部)
【岗位职责】
1.负责红蓝对抗中的武器化落地与研究;
2.平台化建设;
3.安全研究落地。
【岗位要求】
1.熟练使用Python、java、c/c++等至少一门语言作为主要开发语言;
2.熟练使用Django、flask 等常用web开发框架、以及熟练使用mysql、mongoDB、redis等数据存储方案;
3:熟悉域安全以及内网横向渗透、常见web等漏洞原理;
4.对安全技术有浓厚的兴趣及热情,有主观研究和学习的动力;
5.具备正向价值观、良好的团队协作能力和较强的问题解决能力,善于沟通、乐于分享。
【加分项】
1.有高并发tcp服务、分布式等相关经验者优先;
2.在github上有开源安全产品优先;
3:有过安全开发经验、独自分析过相关开源安全工具、以及参与开发过相关后渗透框架等优先;
4.在freebuf、安全客、先知等安全平台分享过相关技术文章优先;
5.具备良好的英语文档阅读能力。
简历投递至 [email protected]
安全服务工程师/渗透测试工程师
工作地点:新疆
1、掌握渗透测试原理和渗透测试流程,具备2年以上渗透测试工作经验,能够独立完成渗透测试方案和测试报告;
2、熟悉风险评估、安全评估;
3、熟练掌握各类渗透工具,如Sqlmap、Burpsuite、AWVS、Appscan、Nmap、Metasploit、Kali等;
4、熟练掌握Web渗透手法,如SQL注入、XSS、文件上传等攻击技术;
5、至少熟悉一种编程语言(php/java/python),能够独立编写poc者优先;
6、具有良好的沟通能力和文档编写能力,动手能力强;
7、对工作有热情,耐心、责任心强,具备沟通能力和良好的团队意识;
8、加分项:有安全开发经验/可进行代码审计工作;
9、加分项:有安全和网络相关证书,如CISSP、CISA、CISP 、CCNP、CCIE等认证者;
岗位职责:
1、参与安全服务项目实施,其中包括渗透测试与安全评估,代码审计,安全培训,应急响应;
2、独立完成安全服务项目报告编写,输出安全服务实施报告;
简历投递至 [email protected]
专注渗透测试技术
全球最新网络攻击技术
原文始发于微信公众号(白帽子):JDK反序列化Gadgets-7u21
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论